Slackware on UEFI

jtsn · 09-23-2013, 02:08 AM

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

First I created a FAT32 filesystem image:

Code:

# truncate -s 50M isolinux/efiboot.img
# mkdosfs -v -F 32 isolinux/efiboot.img

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

Code:

# mount -o loop isolinux/efiboot.img /mnt
# find /mnt
/mnt
/mnt/EFI
/mnt/EFI/BOOT
/mnt/EFI/BOOT/message.txt
/mnt/EFI/BOOT/bootx64.efi
/mnt/EFI/BOOT/huge.s
/mnt/EFI/BOOT/elilo.conf
/mnt/EFI/BOOT/initrd.img

Finally I made a DVD this way:

Code:

# mkisofs -o /tmp/slackware-dvd.iso -iso-level 4 -R -J -A "Slackware Install" -hide-rr-moved -v -v -d -N -c isolinux/isolinux.boot -eltorito-platform x86 -b isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table -sort isolinux/iso.sort -eltorito-alt-boot -eltorito-platform efi -b isolinux/efiboot.img -no-emul-boot -input-charset utf-8 -m 'source' -V "SlackDVD" .

In the firmware I selected the UEFI DVD boot entry, ELILO showed up and successfully booted the installer.

volkerdi · 09-23-2013, 02:21 AM

Quote:

Originally Posted by jtsn

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

First I created a FAT32 filesystem image:

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!

jtsn · 09-23-2013, 02:55 AM

Quote:

Originally Posted by volkerdi

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.

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

jtsn · 09-23-2013, 06:02 AM

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.

Quote:

Originally Posted by volkerdi

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.

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

Quote:

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.

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.

jtsn · 09-23-2013, 07:26 AM

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:

Code:

--- build-efi-images.old        2013-09-12 16:23:42.000000000 +0200
+++ build-efi-images    2013-09-23 13:29:52.666098079 +0200
@@ -48,10 +48,8 @@
 # Skeleton configuration file which finds the real boot disk.
 cat >"$workdir/grub.cfg" <<EOF
 if [ -z "\$prefix" -o ! -e "\$prefix" ]; then
-       if ! search --file --set=root /.disk/info; then
-               search --file --set=root /.disk/mini-info
-       fi
-       set prefix=(\$root)/boot/grub
+       search --file --set=root /kernels/huge.s/bzImage
+       set prefix=(\$root)/EFI/BOOT
 fi
 if [ -e \$prefix/$platform/grub.cfg ]; then
        source \$prefix/$platform/grub.cfg
@@ -75,9 +73,9 @@
 mcopy -i "$workdir/memdisk-netboot.fat" "$workdir/grub-netboot.cfg" ::grub.cfg
 
 CD_MODULES="
-       all_video boot btrfs cat chain configfile echo efifwsetup
+       all_video boot btrfs cat chain configfile echo
        efinet ext2 fat font gettext gfxmenu gfxterm gzio halt hfsplus
-       iso9660 jpeg keystatus loadenv linux linuxefi memdisk minicmd
+       iso9660 jpeg keystatus loadenv linux memdisk minicmd
        normal part_apple part_msdos part_gpt password_pbkdf2 png
        reboot search search_fs_uuid search_fs_file search_label sleep
        test video"

(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

Code:

build-efi-images grub-mkimage /usr/lib64/grub/x86_64-efi /tmp/grub-efi x86_64-efi x64

And copied it as the only file to efiboot.img:

Code:

mkdosfs -C efiboot.img 2048
mmd -i efiboot.img ::/efi         # -i option requires floppy-5.5 package from -current
mmd -i efiboot.img ::/efi/boot
mcopy -i efiboot.img /tmp/grub-efi/gcdx64.efi ::/efi/boot/bootx64.efi

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.

Erik_FL · 09-24-2013, 02:46 PM

Quote:

Originally Posted by volkerdi

Reporting back!

Unfortunately, when I booted this in VirtualBox GRUB started but then just gave me a GRUB prompt and no menu. I also tried putting the entire contents of /EFI/BOOT/ in the El-Torito image to see if that would help, but there was no difference.

On other ISO images that use GRUB and support UEFI, what I've seen is that the El-Torito image only contains the GRUB binary. Perhaps this is another VirtualBox bug?

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.

jtsn · 09-24-2013, 04:24 PM

Quote:

Originally Posted by Erik_FL

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.

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).

Quote:

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.

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

Quote:

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.

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

Erik_FL · 09-24-2013, 08:53 PM

Quote:

Originally Posted by jtsn

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?

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).

Quote:

Originally Posted by jtsn

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).

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.

Quote:

Originally Posted by jtsn

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

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.

jtsn · 09-24-2013, 11:50 PM

Quote:

Originally Posted by Erik_FL

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.

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).

Quote:

ELILO is quite limited since it supports ONLY EFI System Partitions and NOT "normal" FAT partitions nor other filesystem formats such as EXT2.

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.

Quote:

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.

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.

Quote:

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.

Indeed.

Quote:

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.

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.

Quote:

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?

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.

volkerdi · 09-25-2013, 03:16 AM

Quote:

Originally Posted by jtsn

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:

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

Erik_FL · 09-25-2013, 01:10 PM

Quote:

Originally Posted by jtsn

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).

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.

Didier Spaier · 09-26-2013, 06:58 AM

FYI vmplayer in EFI mode boots OK Slackware64-current's installer as of Wed Sep 25 08:45:38 UTC 2013, just including

Code:

firmware = "efi"

in <vmname>.vmx

AlleyTrotter · 09-26-2013, 08:10 AM

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

Code:

BIOS Information
        Vendor: American Megatrends Inc.
        Version: P2.90
        Release Date: 07/11/2013
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 8192 kB
        Characteristics:
                PCI is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                BIOS ROM is socketed
                EDD is supported
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 kB floppy services are supported (int 13h)
                3.5"/2.88 MB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 4.6

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

jtsn · 09-26-2013, 03:30 PM

Quote:

Originally Posted by Erik_FL

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?

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.

Quote:

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.

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.

Quote:

I know that VirtualBox can boot from optical discs, but can it boot from an EFI System Partition on an optical disc?

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

volkerdi · 09-26-2013, 03:50 PM

Quote:

Originally Posted by jtsn

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.