Originally posted by peterdk
View Post
HOWTO Convert legacy boot to UEFI boot
If you want that a board detects UEFI installs by its own then there must be EFI binaries on it with names that are hardcoded in the firmware. I would call that fallback mode. In the beginning only Windows and for some brands the generic EFI binary names - which need to be supported only for external (USB) drives by definition but Windows adds those as fallback if you install too, so this is most likely the reason why some brands searched for this instead.
For new boards you can expect that common EFI binary names from Ubuntu, Fedora, ... are hardcoded in the firmware as well, so you are able to switch drives from one board to the next and the installs are detected. This definitely never happened for Kanotix. That's why Kanotix has it's own fallback grub code and shows Kanotix EFI binaries if you boot in EFI mode. After boot from stick -> select the HD EFI -> just run "grub-install" and it will be shown next time (and will be default).
Another trick is: fake generic and Windows EFI. If there is no Windows on the drive where Linux is installed, just install the EFI binaries with those names as well. It will be shown as Windows if you attach first but you can always run "grub-install" to get the "real" name. Windows will be shown too of course. The generic location is in theory only searched if the drive is USB and removable, but that depends on the board as well. If you add both fake names you can boot it on any UEFI system.
Ok, right now I only wrote about GRUB2, so whats with sd-boot. The initial name of sd-boot was gummiboot and I basically liked it from the beginning. But in order to work for Linux the kernel needed to get an EFI header. This happend with Linux 3.3 officially but was backported for Debian wheezy's 3.2 kernel.
gummiboot/sd-boot can only start EFI binaries inside the ESP which means that you need much more space than GRUB2 to store all kernels and initrds you want to be able to select inside the ESP. If you do a fresh install onto a new hd this does not matter at all but you might need a 2nd ESP if there is no space left in the first (UEFI can support this, not a huge problem). What you usually see is, when sd-boot is used, the ESP is mounted to /boot. As I don't have got a Fedora install somebody else could confirm this. If you just need a GRUB loader that has support for the filesystem that stores the kernel+initrds the resulting EFI binary is much smaller - less than 1 MB. The typical ESP size used by Windows is 100 MB and systems using GRUB usually mount the ESP to /boot/efi.
So in order to convert a legacy install you need first the ESP. Preferred on each drive (it is not a real requirement but better for later separation). If you have got Windows on the same drive you should forget this in most cases as you run out of MBR partitions. I converted Windows installs from legacy to UEFI as well but thats not the point here. If you really happen to have got one spare primary MBR partition (not extended) so, from 1 to 4 only, then you can use that and format it with FAT32. If you want to make it perfect give it 0xEF as ID. Mount it to /boot/efi and use the next trick. If you have got no primary MBR partition left you need to convert the drive to from MBR to GPT. This can be done with "gdisk", after that create a FAT32 partition. Kanotix requires that this partition is flagged as ESP (if you use gparted "boot" and "ESP" are the same for GPT). It would not be needed just for converting but I would recommend it. Next step in both ways is to make sure that the new ESP is mounted to /boot/efi.
If you have got 64 bit installs of a common system you can usually expect that you have got the x86_64-efi GRUB target preinstalled. Otherwise the next command will not work (while booted or inside a chroot).
Without chroot we will use the fake approach:
Code:
grub-install --target=x86_64-efi --removable
Code:
test -d /boot/efi && test -f /boot/efi/EFI/BOOT/BOOTX64.EFI && test ! -f /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi && mkdir -pv /boot/efi/EFI/Microsoft/Boot && cp -v /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
Inside chroot, be sure that /boot/efi is mounted (and inside fstab) and the usual /proc, /sys, /dev of course just run "grub-install" while booted in live mode in efi mode (efibootmgr -v to verify).
After next boot run: "update-grub" (or "grub-mkconfig -o /boot/grub/grub.cfg") to add other Linux installs including (fake) UEFI Windows in the case of the chroot method or "grub-install" in case of the fake Windows approach to get the nicer name in the UEFI boot selection.
Done.
Comment