SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Originally Posted by volkerdi - in yesterday's Changelog
Looking into how to set up the boot support in the installer will be the next order of business, and I have a few different ideas about the way to go about that... probably some good material for a discussion on LQ.
So let's give PV some input peeps!
My thoughts:
You could have the installer look for an EFI partition and then mount it under /boot/efi, make a slackware directory on it and then copy the kernel and elilo into that. Then use a modified version of liloconfig to generate an elilo.conf file.
I quite like refind, because it automatically finds every OS you have installed, so I'd probably add that too.
The next step would be adding either refind or elilo (depending) to the UEFI using efibootmgr, and setting it as the default.
For non-dual booters, perhaps the installer could skip installing refind.
All of this assumes that "secure boot" is disabled. I don't own any hardware with that particular feature (and nor will I buy any), and I don't envy those who have to try figure this out.
'UEFI' support makes first appearance in 'Slackware64 -current'
Hi,
It seems you added additional information to OP.
So I am including the segment that PV posted to the changelog.
Support in the installer for legacy and 'UEFI' will need to do some initial identification to setup proper scheme.
And finally, rudimentary UEFI support makes its first appearance in -current in the form of a bootable USB image called efiboot.img. Still no support in the installer for setting up elilo, but this will at least get Linux installed without the need for Legacy BIOS support. Looking into how to set up the boot support in the installer will be the next order of business, and I have a few different ideas about the way to go about that... probably some good material for a discussion on LQ. BTW, a GPT FAT image like this one is _supposed_ to work as an El-Torito alternate boot image when creating an ISO image (extra mkisofs options: -eltorito-alt-boot -no-emul-boot -eltorito-platform 0xEF -eltorito-boot usb-and-pxe-installers/efiboot.img), but it's mostly not working here. I did get one of these to work when booted from an ISO, but all the attempts after that failed. Looks like it might be a problem with the -boot-load-size being detected properly for one magic EFI image and not for all the others. If anyone is brave or bored enough to look into that, hints are gratefully accepted. Anyway, that's it for now. Have fun!
As I understand it, elilo could in fact boot any OS on the system with a linux kernel (e.g. android-x86 for those with touchscreens!). Also, one need not use rEFIt or rEFInd at all, rather the firmware's own EFI boot manager to select an OS.
Thus perhaps it might also be worth considering some of the general principles outlined in Rod Smith's EFI bootloader pages, namely
creating the subdirectory under /boot/efi as /boot/efi/EFI/ELILO rather than /boot/efi/slackware;
allowing for the possibility that there already exists such a subdirectory in which case we just add to it rather than create a new one;
using efibootmgr or an equivalent tool (as described on the Rod Smith page linked to above) to inform the firmware of elilo so it also shows up on the firmware's list of bootloaders.
That way one could boot all linux OSes from the elilo prompt and use the firmware to choose a non-linux one e.g. windows. There is no problem with also using rEFInd or rEFIt, but if possible it might be nice for the slackware installer to also permit the other approach.
I would prefer to see Slackware move to GRUB 2, since GRUB 2 does not require that the kernel and initrd files reside in the UEFI system partition.
ELILO is a bit of a misnomer, since ELILO does not support anywhere near the flexibility of LILO. About the only thing that they have in common is the configuration file syntax. ELILO only understands file-systems that UEFI can access (FAT in an EFI system partition). Among other things that means ELILO booted from hard disk can't load a kernel or initrd from a CD/DVD unless the CD contains a special EFI boot image (El-Torito no-emulation). ELILO booted from the hard disk also can't load a kernel or initrd from USB hard disks unless those disks contain a FAT EFI system partition.
LILO supports Linux file-systems through the Linux kernel when LILO is installed. LILO creates sector maps for files and then uses raw disk access to load the files at boot time. ELILO does not support Linux file-systems at all. In theory, ELILO could do that in the same way as LILO.
ELILO does provide a few things that LILO does not.
Can list boot devices at boot time
Can manually enter a file name to boot
Can change configuration file without having to reinstall
Most of those things are made possible by UEFI and not software specific to ELILO.
GRUB 2 has some definite advantages over ELILO.
Ability to find files based on partition label or UUID
Loading from Linux file-systems
Loading from ISOs
Very few differences between BIOS versus UEFI booting
It would be helpful if Slackware included either an ELILO or GRUB 2 package even if setup does not automatically install and configure the boot-loader. Since GRUB 2 has some installation scripts it may be preferable to ELILO. GRUB 2 probably uses similar or identical scripts to install on a BIOS versus UEFI, so that could be an advantage. Slackware setup would only have to be modified to support GRUB 2, and not BIOS versus EFI installation of LILO or ELILO.
I will be happy if the Slackware setup DVD is able to boot on a UEFI system. To boot on a UEFI system requires a second El-Torito boot image on the DVD that contains a FAT file-system with a few files. I'm ignoring secure boot entirely, and assuming secure boot will be disabled.
The Slackware DVD does not actually need to use a boot-loader to boot on UEFI since the kernel can be built with the EFI loader stub. The UEFI boot image on the DVD can consist of a FAT file-system containing the kernel (built with EFI stub) and an initrd.
The boot DVDs that seem to be the most flexible are the hybrid DVDs formatted like this.
GPT in unused ISO area (first 16 sectors)
ISO Volume header
Default El-Torito no-emulation boot image (BIOS 80x86) ISOLINUX, GRUB / GRUB 2
Alternate El-Torito no-emulation boot image (EFI) FAT file-system image
Normal ISO file-system
The above allows the same ISO image file to be used to create either a DVD or a USB thumb drive. The GPT is ignored when the image is read as a DVD. For USB booting the GPT defines a partition starting at the location of the Alternate El-Torito EFI FAT file-system image.
The EFI FAT file-system image contains a UEFI boot-loader, and possibly the kernel and initrd files.
When booting from a USB, the USB can be mounted as an ISO image to access the packages and other files.
Leaving off the GPT works fine too, and then the USB image just has to be a different image than the ISO image.
The key thing here is that UEFI does not understand an ISO file-system. UEFI can only access a FAT file-system image, and only if that image is the correct kind of El-Torito boot image on the DVD. Strangely, the UEFI specification supports multiple EFI system partitions on a DVD using multiple El-Torito boot images. I've never tested that, so I don't know if it works in practice. It is also not clear to me if an EFI boot image can contain a GPT, or can only contain an un-partitioned FAT file-system image. I have never seen a boot DVD with a GPT inside the EFI boot image.
Secure boot is a whole subject itself. I'm not overly concerned with Slackware supporting secure boot, though I can see how it might be important for some Slackware users. I'm in favor of signing the boot-loader (or shim), and then providing the boot-loader a database of approved images controlled by the owner of the PC (not some signing organization). I also don't want to be forced to press a key every time I want to boot a self-approved image. If I can't use self-approval to boot what I want then I've lost control of my PC software. There are already plenty of unknowns for an end user when it comes to the security of the PC hardware and UEFI implementation. I don't see how my freedom of choice makes the system any less secure if I use the same diligence as the monopolies whom I trust.
A "secure" boot loader is a small enough part of an operating system, that I can live with it being a signed binary module that isn't built from source. The question boils down to who obtains the "blessing" for the boot loader. Either a generic Linux organization, or each individual distribution.
And finally, rudimentary UEFI support makes its first appearance in -current in the form of a bootable USB image called efiboot.img. Still no support in the installer for setting up elilo, but this will at least get Linux installed without the need for Legacy BIOS support. Looking into how to set up the boot support in the installer will be the next order of business, and I have a few different ideas about the way to go about that... probably some good material for a discussion on LQ. BTW, a GPT FAT image like this one is _supposed_ to work as an El-Torito alternate boot image when creating an ISO image (extra mkisofs options: -eltorito-alt-boot -no-emul-boot -eltorito-platform 0xEF -eltorito-boot usb-and-pxe-installers/efiboot.img), but it's mostly not working here. I did get one of these to work when booted from an ISO, but all the attempts after that failed. Looks like it might be a problem with the -boot-load-size being detected properly for one magic EFI image and not for all the others. If anyone is brave or bored enough to look into that, hints are gratefully accepted. Anyway, that's it for now. Have fun!
The El-Torito boot image for UEFI should not contain a GPT (if I understand the specification correctly). It should be a FAT file-system image. The FAT file-system image will be (in essence) mounted by UEFI as an EFI system partition that appears as a file-system device. Although the UEFI specification supports partitioned DVDs or CDs, the "partitions" are not designated using a GPT. Instead, each "partition" is a separate El-Torito no-emultation boot image with the EFI platform ID. Each one of those El-Torito boot images becomes an accessible EFI system partition and must contain a FAT file-system. You want the size to be a multiple of 2048 bytes (a CD sector). Most disks that I've seen use the size of a floppy disk image. The size of the El-Torito boot image (specified in the header) determines the partition size. So, it is not possible to use a USB disk image (that contains a GPT) for the El-Torito boot image.
The purpose of the GPT in some ISO images is to allow them to be also used to create a USB thumb drive. The GPT allows the thumb drive to look like a partitioned disk, and the GPT has a single EFI system partition that consists of the sectors where the FAT file-system (El-Torito boot image) is located. The boot image is double-mapped (via the El-Torito header and the GPT). So, the GPT is located outside the El-Torito boot image, and not inside the El-Torito boot image. When used this way the size of the partition is specified by the GPT. The El-Torito header is ignored, since the image was not mounted as an ISO, and was accessed as a raw hard disk.
The GPT is ignored when the image is read from a DVD or CD drive, since it is in the first 16 (unused) sectors of the ISO image. Leaving off the GPT has no effect on DVD or CD booting. It only prevents the ISO image from being useful when written directly to a USB thumb drive.
I found these hybrid ISO/Hard Disk images to be quite confusing. You also need a special program "isohybrid" to create a hybrid image. It is probably better to just leave the GPT out of an optical disk entirely. Then the USB disk image would be completely separate from the ISO image.
My opinion is no grub, but then again opinions are all like (you know what) everybody has one.
What is wrong with simple making the transition from CD/DVD install to USB install. Many systems are shipping without any optical drive, but they all have USB of one form or another. I have actually done a UEFI boot from the card reader in my USB printer and also from a card reader that plugs into a USB connector.
Every EFI system i have seen so far will legacy boot if no EFI is detected on the selected boot media. I don't know if that is part of the spec or not. You can always install in legacy mode and then use efibootmgr to add the EFI/UEFI boot. Or as Eric said build a stub kernel to get into EFI/UEFI.
We gave up on floppies maybe its time to drop CD/DVD also.
Don't most people download Slackware and create their own install method?
There certainly appear to be some sound reasons for choosing grub2. It is more flexible than either LILO or ELILO, and it avoids the redundancy of having a boot manager and a boot loader on UEFI systems.
Quote:
Originally Posted by AlleyTrotter
We gave up on floppies maybe its time to drop CD/DVD also.
Hey! I'm first in line to buy a Slackware USB stick. A 16 gigger with both 32 and 64 bit versions on it...
Actually without the secure boot thing, only with UEFI, then for 64-bit Slackware, if compile the kernel with UEFI stub, the kernel could be directly booted with the UEFI boot menu setting.
But it needs Slackware64 to be install first, and kernel be put under EFI partition, then default boot could be added into UEFI boot menu.
It does not work for a fresh install and needs some work with UEFI manager.
My opinion is no grub, but then again opinions are all like (you know what) everybody has one.
What should Slackware use for booting on UEFI; ELILO, no boot loader, or something like rEFInd? The "no boot loader" option works, but it makes passing kernel parameters difficult since the kernel image has to be modified to set the parameters. Having a boot loader is desirable in order to get a boot menu. Not only does that provide a way to configure boot parameters, it provides a way to dual-boot with Windows. The Windows EFI boot loader does not support booting any other OS, and UEFI firmware doesn't always provide a convenient boot menu.
Quote:
Originally Posted by AlleyTrotter
What is wrong with simple making the transition from CD/DVD install to USB install. Many systems are shipping without any optical drive, but they all have USB of one form or another. I have actually done a UEFI boot from the card reader in my USB printer and also from a card reader that plugs into a USB connector.
Making a DVD boot-able by UEFI is easily possible, and creating the media is not much different than for USB. I don't see a problem with requiring USB for installing on UEFI systems as long as the DVD and CD media is available for BIOS booting. Some older BIOS based computers refuse to boot from USB disks. I have one like that.
The difficult part of UEFI installation is actually setup. Setup has to decide about creating legacy partition tables versus GPT, create an EFI system partition, copy the boot loader files and update the UEFI NVRAM variables for booting.
Quote:
Originally Posted by AlleyTrotter
Every EFI system i have seen so far will legacy boot if no EFI is detected on the selected boot media. I don't know if that is part of the spec or not. You can always install in legacy mode and then use efibootmgr to add the EFI/UEFI boot. Or as Eric said build a stub kernel to get into EFI/UEFI.
Legacy BIOS booting isn't required by the UEFI spec, and manufacturers of UEFI computers such as HP don't officially support it. BIOS booting on UEFI is supported more by accident than by design. Motherboard companies have been implementing hybrid UEFI/BIOS firmware because it takes less time to get something up and running. The problems with a hybrid system and the extra complexity are an incentive for BIOS support to be eliminated. Newer UEFI motherboards could drop BIOS support, especially those used for retail computer manufacturing. Installing Windows on UEFI requires booting in UEFI mode, so that will eventually mean no need for, and no testing of BIOS booting on retail UEFI computers. The intention of UEFI was to replace BIOS, so my expectation is that BIOS will disappear on computers using UEFI.
Quote:
Originally Posted by AlleyTrotter
We gave up on floppies maybe its time to drop CD/DVD also.
I don't see a need to stop supporting DVD just because USB disks are supported. The cost of a USB thumb drive is still much higher than the cost of a blank CD or DVD. An 8GB thumb drive costs about $5 and two blank DVDs cost about $0.50. CDs and DVDs replaced floppies because they were nearly as inexpensive and hold much more data. It was the storage limitation of floppies that made people use CDs, and eventually floppies became more expensive than CDs. At the moment, most distros still fit on one or two DVDs and the cheaper media is nearly as convenient as a USB drive.
Mini CDs really should have replaced floppies. They fit in your pocket, where CDs do not. Instead, CDs replaced floppies. I think that the factors affecting popularity of media are the cost and the typical amount of storage needed. Why pay for more storage than you will use? Convenience is a consideration, but only after the price and storage capacity needs are met.
There is an argument to be made that retailers may want to eliminate optical drives from less expensive models to save money. Since retail computer manufacturers make us buy our own blank media to create restore disks, they can certainly get away with making us buy a USB thumb drive. The reason why retailers might not eliminate optical drives is because of movies. As long as Blue-ray movie players in computers continue to support DVD-ROM, I don't think that boot-able DVDs will pose a problem. This is primarily a matter of software, since the hardware for Blue-ray doesn't require a great deal more to support DVD-ROM.
Quote:
Originally Posted by AlleyTrotter
Don't most people download Slackware and create their own install method?
What I like most about Slackware is that it provides choices about how to do things like installing and configuring the OS. I suspect that everyone does something different depending on their situation. I mostly use DVDs for installing Slackware. That is partly because I have somewhat older computers and a retail laptop with unreliable USB booting. In my case, USB would be more convenient since I have to include other files for installing on fake RAID. Unfortunately neither of my computers with fake RAID will correctly boot a USB thumb drive.
I'm in favor of providing as many choices as are practical. I can see why Slackware wouldn't support installation from floppy disks, and perhaps not even CDs. However, I think that DVDs are reasonable and practical to support on UEFI. Slackware uses LILO by default and provides a package for GRUB. It would seem reasonable for Slackware to use ELILO (or something else) by default and provide a package for GRUB 2. The space required for GRUB 2 source and binaries is minimal compared to some of the other things already included in Slackware. I don't know, but I suspect that the dependencies of GRUB 2 are not a large problem.
As I understand it, elilo could in fact boot any OS on the system with a linux kernel (e.g. android-x86 for those with touchscreens!). Also, one need not use rEFIt or rEFInd at all, rather the firmware's own EFI boot manager to select an OS.
Thus perhaps it might also be worth considering some of the general principles outlined in Rod Smith's EFI bootloader pages, namely
creating the subdirectory under /boot/efi as /boot/efi/EFI/ELILO rather than /boot/efi/slackware;
allowing for the possibility that there already exists such a subdirectory in which case we just add to it rather than create a new one;
using efibootmgr or an equivalent tool (as described on the Rod Smith page linked to above) to inform the firmware of elilo so it also shows up on the firmware's list of bootloaders.
That way one could boot all linux OSes from the elilo prompt and use the firmware to choose a non-linux one e.g. windows. There is no problem with also using rEFInd or rEFIt, but if possible it might be nice for the slackware installer to also permit the other approach.
Cheers,
Michael
Those are very good suggestions. It might make sense to put just the Slackware kernel and initrd files under "/boot/efi/EFI/slackware" since they have to be somewhere in the EFI system partition and they are not part of ELILO. The files probably can't be loaded from "/boot", since "/boot" is probably not a FAT EFI system partition.
I agree with you that the ELILO files should be in an ELILO directory and should probably be left alone if they already exist.
Slackware setup should probably back up "elilo.conf" if it exists and add Slackware to any existing "elilo.conf". When "elilo.conf" does not already exist it would make sense for Slackware to add Windows to "elilo.conf" if the "/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi" file exists. There are probably a few other possible locations for "bootmgfw.efi" when using Vista or XP.
One question to be resolved is if Slackware should change "/boot/efi/EFI/boot/bootx64.efi" (the backup boot loader). My suggestion is to only create that file (using a copy of ELILO) if the file does not already exist. There is no defined way to identify what boot loader is in the backup file "EFI/boot/bootx64.efi". It can be a copy of any UEFI boot loader or any other UEFI application. The UEFI specification does not require a "/EFI/BOOT" directory on a non-removable hard disk, nor does it say what should create or change the contents of that directory. Boot loaders for non-removable media are required to be in "vendor" named directories under "/EFI" and add themselves to the NVRAM boot variables.
Thanks Eric for the very detailed explanation.
My humble opinion is that elilo is much simpler to understand/maintain than grub. Just as you I am speaking about the computers in my world which have been no problem with usb boot, gpt, mbr, (there is an mbr installed on a gpt disk) elilo and uefi.
To anyone who is still stuck on dual booting I would suggest a second hard drive (very inexpensive today even free in some cases ie salvage) then selecting the boot drive from the uefi manager screen at boot.
Why make it harder than it needs to be? A rhetorical question.
Personally I started using Slackware because I am frugal and inquisitive, now I support it out of gratitude to Pat for his hard work.
John
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.