I did some further testing and was able to boot the Slackware DVD via UEFI.

First I created a FAT32 filesystem image:

Then I copied the EFI directory from -current as of before the Sep 23 change (with ELILO, because GRUB currently doesn't work):

Finally I made a DVD this way:
In the firmware I selected the UEFI DVD boot entry, ELILO showed up and successfully booted the installer.

If you were just going to use elilo, it should be possible to use usbboot.img as the image rather than creating a new one. It's got all the same stuff in it.

I'd be curious if that works. As far as GRUB goes, it does work here in VirtualBox from the EFI directory. If VirtualBox is truly as flaky as you say, I'd think that's a decent sign that it does work.

BTW, I copied slackware64-current to a FAT32 USB stick and booted it here using Tianocore UEFI firmware on a Core2Duo machine. The GRUB menu came up, I selected huge.s with KMS, and the installer started just fine. I'm planning to keep using elilo on the usbboot.img (it's good to have a few options), but in my testing here I'm not finding problems with GRUB. The last piece of the puzzle is going to be figuring out how to get it to load grub.cfg when started from an El-Torito image because it doesn't want to do that so far. And I might also need to use search commands in grub.cfg to handle a few corner cases.

Thanks for the test report!

That was just for being failsafe: FAT32 because I know of some firmwares have that issues with FAT16/FAT12. ELILO because GRUB2 in UEFI mode is just broken for me and crashes on my machine[1] (which is a real showstopper for a install DVD). If I had built the El Torito DVD with GRUB, that would have proved nothing, but just crashed instead. :-)

I will try out mastering a DVD with usbboot.img (I'm rather sure, that it works) and try some install media from some other UEFI capable Linux distributions. Some of them use GRUB2, too. I will also search for a firmware update.

[1] Asrock H77Pro4/MVP with AMI UEFI P1.50

I have updated the UEFI firmware and the crash problem is gone. Now Slackware -current boots just fine from a USB drive using GRUB. So this issue is resolved.

There is also a possibility to setup QEMU/KVM with the more complete TianoCore UEFI implementation, it could make testing easier:

http://sourceforge.net/apps/mediawik...php?title=OVMF

I just looked at ubuntu-13.04-desktop-amd64.iso. They have a very complicated setup to support Secure Boot. Inside the FAT12 /boot/grub/efi.img they have /efi/boot/bootx64.efi signed by Microsoft, which seems to load /efi/boot/grubx64.efi signed by Canonical (the same stuff is inside the EFI directory on the disc itself). Then it loads /boot/grub/grub.cfg from the ODD filesystem, and continues with /casper/vmlinuz.efi.

Wow, I'm reverse engineering open source software... I will continue my research and report back, when I've found some useful information.

Okay, I found the answer. Inside ftp://ftp.slackware.com/pub/ubuntu/p....debian.tar.gz is the script debian/build-efi-images, which I used as a starting point. They embed a configuration file inside the grubx64.efi, so GRUB searches for /.disk/info on the DVD and then loads the grub.cfg

I slightly modified the script, so it searches for the Slackware kernel, and removed some modules, so it builds with Slackware's GRUB:

(As quick & dirty solution, it sets /EFI/BOOT on the DVD as GRUB's root directory and then reads the configuration from there. The modules list may have to be modified further to accomodate Slackware.)

I created a gcdx64.efi with
And copied it as the only file to efiboot.img:


I recreated another Slackware DVD image with the command I posted previously in this thread and successfully booted the installer via GRUB/UEFI from the DVD.

HTH.

1 members found this post helpful.

I think I can shed some light on the GRUB UEFI boot issues. I looked at the software in GRUB that determines the "root" and "prefix" settings. GRUB handles optical devices on UEFI as a special case. In most cases, GRUB sets the "root" device based on the device that loaded the GRUB image. For a UEFI optical device GRUB sets the "root" to the parent UEFI device of the UEFI device that loaded the GRUB image. In the case of optical media the EFI System Partition is the El-Torito no-emulation FAT file-system UEFI device. However, GRUB has no device name assigned to the ESP on optical media, and it is not visible to grub commands. So, even though GRUB was "booted" from the EFI system partition, GRUB cannot read or load any files from there. How GRUB finds the parent device is by parsing the ESP device path provided by EFI. GRUB makes some assumptions about the EFI System Partition device path, and those assumptions might not be true for every UEFI firmware implementation.

For optical media, in essence, the "root" device of GRUB is a UEFI raw block device and the file-system is provided by GRUB not UEFI. GRUB, in fact, never sees the EFI System Partition on the optical device as a file system or GRUB device. There is no (cd0,0) or similar name for the ESP, but there is only the (cd0) device.

If you are having problems booting from optical media, you may find it helpful to use an EFI command shell to inspect the device paths for the optical device and the ESP on the optical device. You have to do both of those while the boot disc is present. I'm not sure if VirtualBox supports the functions needed for an EFI command shell, but you can download the command shell from the UEFI site. I did that for my HP system that came with no command shell.

I can understand why GRUB doesn't support the concept of "partitioned optical discs" but that is basically how UEFI handles optical booting. UEFI treats each EFI System Partition (El-Torito image) on an optical disc as if it was a partition, only the boot catalog takes the place of the partition table. In fact the UEFI specification does not limit the number of ESPs on any disk (including optical) to one. In theory there can be multiple ESPs on an optical disc, though only the first one will be a default boot location.

The problem is that GRUB may need a more sophisticated way of parsing the UEFI device path to find the "parent" block device for the optical disc. If the "parent" device is not immediately above the ESP device then GRUB has to skip over the other devices between the two in the device path. Also, there are complicated naming rules for EFI devices in device paths. If an implementation does not follow those rules exactly, it can cause problems when parsing a device path.

I have not spent any time testing the VirtualBox UEFI implementation. Based on my experience with VirtualBox, it is probably not a good test environment. VirtualBox is very loose with how it emulates standards, and tends to only support the bare minimum needed for its intended guest operating systems. Each release of VirtualBox introduces new features at the expense of breaking old features. If you were to get something working with VirtualBox UEFI there is no certainty that it will work with a real UEFI system or even the next version of VirtualBox. The UEFI support in VirtualBox is fairly recent, and recently added features in VirtualBox are buggy at best, and completely unusable at worst.

VirtualBox is very useful, and parts of it a very good, but it is necessary to "cherry pick" versions to find one that works with any particular host and guest OS. To test UEFI you would have to figure out which version is the closest to a "real" UEFI implementation and has no serious bugs affecting optical booting. I suspect that the UEFI features in VirtualBox are mostly to support an Apple OS but I haven't confirmed that. Apple has one of the most non-standard implementations of UEFI and UEFI booting. Strangely, Microsoft followed the UEFI standard very closely. The problem is mostly the UEFI firmware developers, and you can think of Oracle as a UEFI firmware developer when it comes to VirtualBox.

The only solution that I know of right now is a lot of testing and experimentation on different systems. I wish I could be helpful but I have only one UEFI system and VirtualBox. I have not been enthusiastic about doing anything new with VirtualBox, since I've been struggling just to keep doing what I was as new releases come out and break things.

1 members found this post helpful.

So if I understand you correctly, GRUB doesn't use high-level firmware functions for loading files from the ESP (as ELILO does), but tries to read the raw blockdevice with its own filesystem drivers instead? I wonder how this works out, if the firmware decides to write to the ESP?

This concept fits well into the 16 bit BIOS world, but I don't think it's adequate for the "64 bit DOS", which is UEFI. That needs something, that works more like LOADLIN (ELILO does).

Or you completely ignore the device path and just search all available devices for your install media. That is what Ubuntu does.

There is a UEFI implementation for QEMU/KVM available: OVMF.

For optical discs GRUB doesn't use high-level (FAT Filesystem) firmware functions. I have not looked to see how GRUB handles EFI System Partitions on hard disks. Certainly for EXT2 and other Linux Filesystems GRUB must use the raw (block I/O) devices of UEFI. It is only the files of FAT Filesystems in EFI System Partitions that can be accessed using the high-level functions of UEFI. Even the FAT file-systems in "normal" partitions do not have filesystem devices in UEFI. UEFI only supports reading files from EFI System Partitions and not other FAT32 partitions. If bootloaders support other types of FAT partitions, they have to use their own FAT filesystem software.

ELILO is quite limited since it supports ONLY EFI System Partitions and NOT "normal" FAT partitions nor other filesystem formats such as EXT2. ELILO does have an advantage because it can (in theory) read files from the El-Torito boot image containing the EFI System Partition on an optical disc. GRUB cannot do that because it doesn't access "partitions" on an optical disc. However GRUB can read the normal ISO9660 filesystem of an optical disc and ELILO cannot. It may be that ELILO is a better boot loader to use for install discs because it is simpler and uses the EFI filesystem driver. That may allow ELILO to use the UEFI default device path without specifying one. There would be no problem locating the files because they would be on the same device from which the boot loader was read.

This is one of the glaring limitations of UEFI. It doesn't attempt to provide a standard set of filesystems or partition types other than the EFI System Partition. At the very least there should have been support for EXT2 (including as an EFI System Partition). I think the rather stupid thing is the amount of complexity provided in UEFI for graphics support compared to the rather limited support for accessing filesystems. Which is generally more important for "booting"?

UEFI doesn't do anything to keep filesystems and block I/O devices in sync. There is really only one filesystem supported (the EFI System Partition). I don't call it a "FAT" filesystem because it cannot access normal FAT partitions, and it can access some non-standard FAT partitions (inside an El-Torito boot image).

UEFI doesn't claim to be an Operating System although one can think of it as a very limited OS. UEFI is not even really a "DOS" unless you limit yourself to talking about EFI System Partitions and not other FAT partitions. UEFI focuses heavily on ACPI and block I/O devices but not much on filesystems and executable file formats. Really only the Portable Executable (PE) format is supported and that uses EFI specific file types. Microsoft further confuses this by using two different PE file formats, both having the ".efi" extension. The "winload.efi" file, for example is NOT a standard UEFI PE file. That file is only loadable by the Windows boot loader. In fact, the Windows boot loader cannot load a standard UEFI PE file, and that is why it cannot chain to another UEFI boot loader. It is only the Windows boot loader "bootmgfw.efi" that is a standard UEFI PE file, and can be loaded by other bootloaders.

That is a pretty good solution. However, GRUB still has to parse the UEFI device paths to figure out what devices are available. UEFI does not have the concept of "BIOS drive IDs" so "hd0" or "cd0" have no implied meaning. GRUB has to look at the ACPI information and device paths to figure out what types of devices are present and assign the names and numbers. GRUB mostly uses UEFI as a block I/O layer after it determines the available devices. A bug in a UEFI block I/O driver or a problem with a filesystem could cause GRUB to hang or crash before it finds the files that it wants.

I have said nothing about the graphics issues of UEFI and the problems of supporting UEFI in graphics cards. Bootloaders and the BIOS handled that through a combination of text-mode services, video BIOS extension ROMs and VESA graphics standards. What graphics modes should a boot disc use and how should it handle the wide variation in systems?

Right now the safest way to boot from UEFI is to put all the files accessed by the bootloader in an EFI system partition and use ELILO. I don't know if that can work for an optical disc. I have tried it using an optical disc on my one UEFI test system and could not get it to work.

UEFI can read and write to any FAT partition and with the right EFI file system driver installed, it can at least read any other filesystem. The VirtualBox firmware can read and boot from ISO 9660 directly and Apple Macs can read HFS+ partitions and do weird non-standard stuff with it (the ESP on Intel Macs is empty by default).

ELILO boots just fine from "normal" FAT partitions, and any filesystem you have a driver for. Use http://www.rodsbooks.com/refind/drivers.html to load ext4_x64.efi and then just execute ELILO from your usual Linux /boot or / Linux partition.

It is called "Extensible" for a reason.

If GRUB can't access the ESP through the firmware, it cannot be really be called EFI-capable. And ELILO can read optical discs, once is has the right driver, like on VirtualBox.

Indeed.

Well, regardless of what people claim, UEFI is a 64 bit single tasking hardware abstraction layer with an API that can execute EFI applications (mostly boot loaders). It resembles the FAT file system functionality of DOS, has some framebuffer support (replaces the VESA interface usually used on DOS) and can load drivers for accessing additional devices and filesystems (remember CONFIG.SYS?). So surely it is a (very limited) operating system. Because of that, it doesn't allow you to switch the operating mode of the CPU. You are usually restricted to AMD64 (x86-64) long mode on x86 UEFI platforms, even for your real OS kernel.

Well, 16 bit boot loaders just expect to run on a 100 % compatible VGA graphics card with a 16 bit IBM-compatible VGABIOS with VBE extensions. Direct hardware access is the norm, and the BIOS is only used for mode-setting.

On UEFI you just call the firmware using GOP (graphics output protocol) to interface with the framebuffer. All APU graphics solutions (AMD/Intel) have native EFI driver support for the integrated GPU and there are no issues with that.

People using legacy add-in graphic cards with a VGABIOS may have issues. The firmware uses the CSM (the BIOS emulation) to access the VBE extensions, which may or may not work. They were once used on DOS and occasionally for graphical installers only, so vendors didn't put any effort in that functionality. With UEFI that stuff suddenly became important, because it is now a requirement for the EFI frame-buffer to work.

But this will be solved, once add-in cards come with native UEFI ROMs preinstalled.

Nicely done. I figured the exact same thing out yesterday.

1 members found this post helpful.

Thank you for bringing me up to date on the progress of EFI bootloaders. It looks like many people are contributing to the improvement of EFI support.

I don't doubt that everything you mentioned is possible. My concern is with the chances of additional drivers or filesystems working with a particular UEFI implementation. From what I've seen so far UEFI firmware often just barely does what the computer vendor intended. Other UEFI capabilities such as support for third-party drivers might not work reliably. UEFI has a lot of good things, but who is making sure retail computers support those features?

The response that I've gotten so far from HP is that they only support Windows 8 and their own "recovery" software and not "other" operating systems or bootloaders. The HP system that I have has never successfully booted an optical disc using UEFI. I did get an EFI command shell to mostly work. I downloaded it from the UEFI web site, not HP. Eventually I just installed everything to use BIOS booting because my most important boot discs would not work with UEFI on the HP system.

I know that VirtualBox can boot from optical discs, but can it boot from an EFI System Partition on an optical disc? My VirtualBox comments were directed more toward the suitability of VirtualBox as a test bed for EFI boot discs rather than its overall usefulness. In spite of my criticisms of VirtualBox it has a lot of capabilities and is generally improving. I just question the amount of effort that Oracle is willing to put into the EFI firmware part of it. If Oracle does fully support EFI features that would be a great help to many people including me.

FYI vmplayer in EFI mode boots OK Slackware64-current's installer as of Wed Sep 25 08:45:38 UTC 2013, just includingin <vmname>.vmx

current dated Wed Sep 25 08:45:38 UTC 2013
The UEFI boot from DVD was detected here and the install went fine.
Below is my machine's BIOS if it matters. upon starting the machine I was presented with two options for the DVD.

ACHI PS2: TSSTcorp DVD+/-RW TS-H
UEFI: TSSTcorp DVD+/-RW TS-H

Naturally I selected the UEFI

Great job Pat, especially doing it on a VM.
John

At least on my machine the EFI file system drivers work. I let ELILO load kernel and initrd from an ext4 /boot. Without EFI it can't do that, because unlike GRUB it doesn't have any support for reading filesystems by itself.

That's the reason why China based Lenovo is still growing in the PC market, while HP is driving itself out of that business. Even Windows Vista SP2 and Windows 7 support UEFI, and no sensible person - even without any Linux ambitions - would buy a machine, which runs only with Windows 8 exclusively. Look how well that Surface sells!

Beside that: EFI Driver support is mandatory, because add-on devices are supposed to contain them inside their option ROMs, especially graphic cards and storage controllers.

AFAIK it directly reads the ISO 9660 filesystem and ignores the ESP.

It directly reads and uses the /EFI directory on an ISO9660 filesystem if there's no El-Torito boot image, but it will prefer the El-Torito boot image if it exists. I know this because I made an ISO with an El-Torito boot image (containing the GRUB EFI binary), and with an /EFI/BOOT/ directory on the ISO itself containing the GRUB configuration files and no EFI binaries. It booted fine.