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.
Using the method as described by comet.berkeley I had to make one change in the script the line
spit out an error about can't preserve permissions on VFAT. So I changed it to cp -rv and the script built the image.
Pressing F11 from the UEFI boot message on my system brings up the boot device screen which displays the various options.
My DVD appeared as a normal dvd and also as UEFI-dvd so the system definitly sees it as a UEFI boot option. Naturally I selected the UEFI option and got this error
Code:
ELILO v3.14 for EFI/x86_64
.................................(many .'s)
bzImage.c(line 198):Could not read boot sector from huge.s.
elilo.c(line 84):Cannot find a loader for huge.s
You're running into the same errors I had here already. This is why the request had been to master the DVD the usual way and report back on whether having /EFI/BOOT/ on it worked. Not to figure out how to make an El-Torito image, master with the El-Torito options, etc... that's what I was hoping to be able to avoid.
The problem above seems to happen whenever the kernel and initrd aren't in the same directory as elilo and the elilo.conf adjusted to point to them there (i.e., with no slashes in the filename). That problem only happens with El-Torito. The paths work as expected if the image is booted directly.
Quote:
PPS Pat V. How did you build your elilo as it seems to work differently than the one used by Eric_FL, comet.berkeley and the one I built locally??
I'd been using the one that was built upstream, but maybe my own test copy ended up on there by mistake. In that case the only difference was a delay added if errors had occurred so that I'd be able to read them. Otherwise I'd get dumped back to UEFI so quickly that it wasn't possible. Both copies worked the same here otherwise.
Well, this ain't good. It's probably KMS which is failing. That was needed here to get past the video garbage on UEFI, but evidently on other systems it causes problems.
Maybe try passing nomodeset as a kernel option at boot and see how that goes?
Thanks Pat. I'll try that when I get a chance, and see how it goes.
Well, this ain't good. It's probably KMS which is failing. That was needed here to get past the video garbage on UEFI, but evidently on other systems it causes problems.
Maybe try passing nomodeset as a kernel option at boot and see how that goes?
Thank you! That worked!
At the install boot prompt I typed in "huge.s nomodeset" and pressed enter.
BOOT: huge.s nomodeset
I'm still trying to get elilo to work... most of the time when it fails the screen goes blank and it falls back to the isolinux boot.
I did get more information from elilo by adding: verbose=5
to the elilo.cfg file.
Except that the image could be the same image as usbboot.img, in which case it won't take any additional space. The mkisofs mastering process won't repeat the image -- it will just map to where it already exists in the usb-and-pxe-installers/ directory.
The EFI boot image can't be the same image as "usbboot.img" because the USB boot image contains a GPT. The El-Torito EFI boot image does not contain a GPT.
The entire Slackware DVD image (ISO file) could be the same as the usbboot.img if "isohybrid" is used to tack a GPT on the front of the DVD image.
The EFI boot image can't be the same image as "usbboot.img" because the USB boot image contains a GPT. The El-Torito EFI boot image does not contain a GPT.
The entire Slackware DVD image (ISO file) could be the same as the usbboot.img if "isohybrid" is used to tack a GPT on the front of the DVD image.
No, the usbboot.img does not contain a GPT. In any case, regardless of whatever the UEFI spec says it makes no difference whether the El-Torito image has a GPT or is just a raw FAT filesystem. Both work (or don't) equally.
No, the usbboot.img does not contain a GPT. In any case, regardless of whatever the UEFI spec says it makes no difference whether the El-Torito image has a GPT or is just a raw FAT filesystem. Both work (or don't) equally.
That's an interesting observation. I have only been able to test one UEFI computer so it's been difficult to learn what is actually supported by UEFI machines.
I decided to see how Debian did EFI on their install CD-ROMs so I downloaded
the first one, and using dumpet it showed there was no EFI on a Debian install CD.
Last edited by aaazen; 03-27-2013 at 08:38 AM.
Reason: spelling
Well, this ain't good. It's probably KMS which is failing. That was needed here to get past the video garbage on UEFI, but evidently on other systems it causes problems.
Maybe try passing nomodeset as a kernel option at boot and see how that goes?
I hit TAB when the screen came up, and typed 'huge.s nomodeset', and it worked perfectly.
Thanks for the tip, Pat
This is why the request had been to master the DVD the usual way and report back on whether having /EFI/BOOT/ on it worked.
Sorry for getting OT Pat.
Now to get back OT (could that be On Topic or is it always Off Topic?). As for the March 27 current. Burned using the instructions in 'isolinux/README.TXT'
My system does not offer a UEFI boot option for this version of current
john
PS pretty obvious as there were no changes to EFI/BOOT
Last edited by AlleyTrotter; 03-27-2013 at 05:09 PM.
Reason: silly PS
I just tried it and it works about the same as the old version.
Two elilo.conf options that help debug are:
debug
verbose=5
But I researched other CD/DVD with working EFI boot blocks.
Gparted, Clonezilla and Fedora are using Grub2 which reuses the kernel and initrd from directories outside of the EFI image directory. This saves disk space and make things simpler.
Arch Linux uses gummiboot which wastes space like elilo does, doubling up the kernel and initrd files:
But I researched other CD/DVD with working EFI boot blocks.
Gparted, Clonezilla and Fedora are using Grub2 which reuses the kernel and initrd from directories outside of the EFI image directory. This saves disk space and make things simpler.
Arch Linux uses gummiboot which wastes space like elilo does, doubling up the kernel and initrd files:
Thanks for posting all the interesting information. I took a look at a few boot DVDs myself.
Windows uses a 12-bit FAT floppy size El-Torito image containing the boot manager. The Boot Configuration Database and other files are outside the El-Torito image and located in the ISO file-system. Windows also uses two different kernel loaders depending on whether it is loading via BIOS or EFI ("winload.exe" versus "winload.efi"). Even though "winload.efi" has a ".efi" extension, it is not a standard EFI application. Because of that the Windows boot loader cannot chain to another normal EFI boot loader or application. It can only "run" programs marked as "IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION".
The difficult question to answer is what method of booting a UEFI CD/DVD is compatible with the most (non-Apple) computers. Since Apple does not adhere to the UEFI standard, there are additional considerations to make a CD/DVD boot on an Apple computer.
Some boot discs do have a "/EFI/BOOT" folder in the ISO file-system, and some tack a GPT on the front of the ISO in the unused sectors. I have seen boot discs without that folder. So far I have never seen an EFI boot disc without the El-Torito EFI image, and none of those that I have seen contain a GPT inside the El-Torito image.
It does not appear that using just the "/EFI/BOOT" folder in the ISO file-system is likely to allow booting on the majority of UEFI systems. Certainly it will work on some of them. I have only tested on one computer so I can't speak from experience. As someone pointed out, it is not necessarily a requirement to install Slackware from a boot-able CD/DVD.
The immediate issue is what configuration works the best for normal UEFI booting from the hard disk.
T
The immediate issue is what configuration works the best for normal UEFI booting from the hard disk.
I have been using a GPT partition scheme without problems. I use a EFI partition as the first one on sda. Set the UEFI boot variables using 'efibootmgr -c' with all defaults which gave me a UEFI boot option named 'Linux'. This launches elilo.efi.
Code:
john@retired:~$ ls -1 /boot/efi/
Shellx64.efi* -- the efi shell
bzImage*
bzImage-3.8.4* -- various kernels
bzImage-3.8.5*
elilo.conf*
elilo.efi*
initrd.gz*
vmlinuz-generic-3.2.29
This has worked flawlessly for me over the last several months, so naturally ya'll know how I'm voting for best. I might add I am constantly making changes and trying out knew stuff with this setup and it has been very simple to maintain.
Cheers
john
[edit] this configuration will also legacy boot you can install lilo into the 'protected MBR' on the GPT disk.[/edit]
Last edited by AlleyTrotter; 03-30-2013 at 03:32 PM.
Reason: added note about legacy
Arch Linux uses gummiboot which wastes space like elilo does, doubling up the kernel and initrd files:
If the ISO is built properly, elilo won't waste any space. The reason it doesn't waste space is that the kernels/initrd in /EFI are hardlinks to their other locations. And the usbboot.img is also supposed to be usable as the El-Torito image, in which case it will be mapped from its existing location.
It's still not working though, so we'll see if it ends up being used to boot the installer or not...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
