LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-18-2017, 02:01 PM   #1
colinh2
Member
 
Registered: Dec 2015
Posts: 31

Rep: Reputation: Disabled
Recommended way to boot EFI computers?


I've just done a slackpkg upgrade-all. At the end it asks whether I want to run lilo. But because of EFI (and using ext4) I have to say "no" and do a bunch of stuff (creating initrd.gz and copying files etc).

I'm using a DELL XPS13 (9343). Now, I *think* I can get it to boot in "legacy mode" and I'm tempted to try it; I used to use lilo and was very happy with it. Then I used a Macbook Pro for a long time and was *forced* to use EFI.

Apart from Slackware I have a (mostly unused) Arch installation on this laptop.


Is there any reason I should use EFI instead of MBR?
 
Old 05-18-2017, 02:11 PM   #2
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 8,877

Rep: Reputation: Disabled
Quote:
Originally Posted by colinh2 View Post
Is there any reason I should use EFI instead of MBR?
No. But why not just run eliloconfig? It will take care of copying the kernel linked to by /boot/vmlinuz and /boot/initrd.gz if it exists to the EFI System Partition. Nothing to do manually. And if you use a huge kernel you don't need an initrd, so that's no more work than running lilo.

Last edited by Didier Spaier; 05-18-2017 at 04:39 PM.
 
Old 05-18-2017, 02:35 PM   #3
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,075

Rep: Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741
Well, eventually systems will likely stop supporting "legacy" mode for UEFI, so there will be no choice but to use EFI. However, we aren't there yet, and if you have the option, you're certainly welcome to use it.

On top of what Didier wrote, it is also not recommended by Pat to use slackpkg to upgrade kernels (even though it's enabled by default). If you check /etc/slackpkg/blacklist, it will show the following statement.

Quote:
# Automated upgrade of kernel packages aren't a good idea (and you need to
# run "lilo" after upgrade). If you think the same, uncomment the lines
# below
It is recommended to install them manually, most electing to run installpkg on the new kernels, regenerate initrd, edit their bootloader, then test the new kernel. Once you've verified the kernel works fine, you can remove your old kernel and adjust the bootloader accordingly. This leaves you with a known-good working kernel and a way to fall back to it if the new kernel doesn't work as it should.
 
Old 05-18-2017, 02:56 PM   #4
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 8,877

Rep: Reputation: Disabled
Patrick Volkerding provides instructions in an email to the slackware-security mailing list whenever he makes a kernel upgrade for security reasons (which has been always the case for kernel upgrades of Slackware stable, as far as I remember), that can safely be followed in all cases, I think. For instance see the most recent email of this kind.
 
Old 05-18-2017, 03:28 PM   #5
Gerard Lally
Senior Member
 
Registered: Sep 2009
Location: Brú na Bóinne, IE
Distribution: Slackware, NetBSD
Posts: 1,555

Rep: Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026
Quote:
Originally Posted by colinh2 View Post
I've just done a slackpkg upgrade-all. At the end it asks whether I want to run lilo. But because of EFI (and using ext4) I have to say "no" and do a bunch of stuff (creating initrd.gz and copying files etc).

I'm using a DELL XPS13 (9343). Now, I *think* I can get it to boot in "legacy mode" and I'm tempted to try it; I used to use lilo and was very happy with it. Then I used a Macbook Pro for a long time and was *forced* to use EFI.

Apart from Slackware I have a (mostly unused) Arch installation on this laptop.


Is there any reason I should use EFI instead of MBR?
Like most other computer interfaces of the last 10 years or so the Unified Extensible Firmware Interface is a half-finished, bug-ridden heap of junk. I had nothing but trouble with it last year. If your setup is straightforward it's fine, but if you do anything like LVM and/or software RAID and/or Xen then forget about it. My advice is to use the legacy option as long as your hardware supports it.
 
Old 05-18-2017, 03:34 PM   #6
Daedra
Senior Member
 
Registered: Dec 2005
Location: Springfield, MO
Distribution: Slackware64-14.2
Posts: 1,575

Rep: Reputation: 390Reputation: 390Reputation: 390Reputation: 390
Quote:
Originally Posted by Gerard Lally View Post
Like most other computer interfaces of the last 10 years or so the Unified Extensible Firmware Interface is a half-finished, bug-ridden heap of junk. I had nothing but trouble with it last year. If your setup is straightforward it's fine, but if you do anything like LVM and/or software RAID and/or Xen then forget about it. My advice is to use the legacy option as long as your hardware supports it.
Quote:
Well, eventually systems will likely stop supporting "legacy" mode for UEFI, so there will be no choice but to use EFI. However, we aren't there yet, and if you have the option, you're certainly welcome to use it. -bassmadrigal

That is what I am doing, I haven't even tried to boot EFI yet. I just use the "legacy" mode. When I install Slackware I load lilo into the root partition then boot to my Windows 10 partition and use EasyBCD to add Slackware the the windows boot loader and chainload lilo that way. Probably not the most elegant way of doing things but it works and I don't feel like messing with something that isn't broken.
 
Old 05-18-2017, 04:34 PM   #7
colinh2
Member
 
Registered: Dec 2015
Posts: 31

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by bassmadrigal View Post
On top of what Didier wrote, it is also not recommended by Pat to use slackpkg to upgrade kernels (even though it's enabled by default). If you check /etc/slackpkg/blacklist, it will show the following statement.

It is recommended to install them manually, most electing to run installpkg on the new kernels, regenerate initrd, edit their bootloader, then test the new kernel. Once you've verified the kernel works fine, you can remove your old kernel and adjust the bootloader accordingly. This leaves you with a known-good working kernel and a way to fall back to it if the new kernel doesn't work as it should.
Well, I have the old kernels and initrds in /boot/efi/EFI/Slackware and edit the elilo.conf there, so I could boot a previous configuration, if necessary.

... oh. I just checked. I only have a complete /lib/modules/4.4.38/ directory (and a mangled old 4.4.14).
 
Old 05-18-2017, 06:23 PM   #8
colinh2
Member
 
Registered: Dec 2015
Posts: 31

Original Poster
Rep: Reputation: Disabled
Didier,

it's not so much the work, it's more that I'm inclined to agree with Gerard. UEFI is a horrible mess:

[rant deleted]
 
Old 05-18-2017, 06:56 PM   #9
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,075

Rep: Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741Reputation: 3741
Quote:
Originally Posted by colinh2 View Post
Well, I have the old kernels and initrds in /boot/efi/EFI/Slackware and edit the elilo.conf there, so I could boot a previous configuration, if necessary.

... oh. I just checked. I only have a complete /lib/modules/4.4.38/ directory (and a mangled old 4.4.14).
Those kernels would remain in place unless something with elilo removes them. The Slackware kernel packages will add kernels into the /boot/ directory, and if those packages are upgraded or removed, those kernels would also be removed. But, I believe eliloconfig just copies kernels and initrds out of the /boot/ directory into the /boot/efi/EFI/Slackware/ directory. Those are untracked by pkgtool, so they wouldn't be removed when the kernel is removed/upgraded.

As for your mangled /lib/modules/4.4.14/ directory, my first guess is that you compiled some custom kernel modules that were installed there. pkgtool will remove all the original files in the package, but it won't remove newly added ones. If there are new files in a directory, it would prevent that directory from being removed when the package is removed.
 
Old 05-18-2017, 08:34 PM   #10
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 2,218

Rep: Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546
Quote:
Originally Posted by Gerard Lally
If your setup is straightforward it's fine, but if you do anything like LVM and/or software RAID and/or Xen then forget about it.
If you have properly configured your initrd, then it should "just work". There is no technical reason EFI should get in the way at all.
Quote:
Originally Posted by colinh2
UEFI is a horrible mess:
Not really. Granted, UEFI isn't very well documented, but this website has some good, clear information about it: http://www.rodsbooks.com/refind/

It's mostly a matter of understanding where to put things.

The one thing I dislike about EFI is that it uses the FAT filesystem, which makes it prone to damage. That said, it works fine with filesystems created with GNU tools.

As with everything else, Slackware's implementation of EFI support is probably the most sane available.
 
1 members found this post helpful.
Old 05-19-2017, 04:18 AM   #11
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 8,877

Rep: Reputation: Disabled
To those who despise UEFI... Please read the current specification, then come back. See you next month. Or maybe, next year?

More seriously:
  • UEFI is a specification. This in itself is a big progress as there is no BIOS specification instead. And the availability of this spec makes UEFI something very well documented.
  • Not all implementations are fully compliant, and some include not specified features but that's mostly vendors' responsibility (old implementations by Apple come to mind).
  • The specification contains some unclear statements that could lead to diverging interpretations. How can that be avoided in a document 2656 pages long? The Pascal specification in BNF probably contains less ambiguous statements, but it's certainly easier to specify a programming language from scratch than an interface that has to cope with a wide variety of contexts on both sides, notwithstanding the great job done by Niklaus Wirth.
  • There are a lot more divergences in BIOS implementations. As an example, just 2 days ago H. Peter Anvin posted in the Syslinux mailing list:
    Quote:
    The bytes CD 18 (INT 18h) at the beginning of a boot sector is supposed to tell the BIOS that "this device isn't bootable, try the next one"; unfortunately not all BIOSes handle that correctly (although most recent ones do.)
    If someone knows something about BIOS, it's Peter.
  • The layout of firmwares' boot menus vary widely among implementations, but that is explicitly out of the specification's scope.
  • Usage of LVM or software RAID is not in the scope of the specification, as at time of finding the root device for instance, the firmware has already handed over the system to the OS.
  • Needless to say, UEFI provides useful features not available in a BIOS implementation, like ability to modify the firmware's boot menu from the OS, not using a boot manager at all (as e.g. with an Linux EFI stub, that bundle a kernel and possibly an initramfs with a built-in command line in an EFI image, providing a live system in only one file), even upgrading the firmware itself from the OS.

Last edited by Didier Spaier; 05-19-2017 at 06:13 AM. Reason: s/bootloader/boot manager/
 
Old 05-19-2017, 12:34 PM   #12
askfor
Member
 
Registered: Aug 2016
Posts: 84

Rep: Reputation: 46
My disk is not exceptionally large, and I have no need for so many partitions. I am going to postpone UEFI until I really need it.
 
Old 05-19-2017, 01:11 PM   #13
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 8,877

Rep: Reputation: Disabled
The UEFI specification does not require the use of a GUID Partition Table anyway. It allows to continue using a Legacy Master Boot Record. On the other hand if you use LiLo you are in good hands: we know who is the official maintainer

Last edited by Didier Spaier; 05-19-2017 at 01:13 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
resize efi question [/boot/efi] with boot flag gparted mtdew3q Fedora 4 03-19-2017 10:02 PM
[SOLVED] Can't find /boot/efi/EFI/Slackware/vmlinuz kernel configuration ironQiu Slackware 4 02-09-2015 06:21 AM
boot efi disk with without a non-efi bios pc... masavini Programming 1 11-12-2013 08:48 PM
EFI boot manager: making it the default (NOT a dual boot issue) Something Else Linux - Software 1 05-15-2013 11:12 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:01 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration