[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: adventures in UEFI & PXE land



Hi

[ grub-efi's actual package names are architecture dependent, my 
  explantions below use grub-efi-amd64 (64 bit UEFI for x86_64) for 
  examples, substitute it with grub-efi-ia32, grub-efi-arm or 
  grub-efi-arm64 where needed. ]

On 2015-03-05, Paul Wise wrote:
[...]
> I had some adventures in UEFI land. I had an Intel NUC fried during a
> lightning storm but the hard drive was fine so I wanted to get the hard
> drive to boot within a new NUC. I didn't have any USB stick so I went
> with PXE boot from my laptop. The existing system on the hard drive was
> wheezy but the installer image I was using was jessie.

Once you're on jessie's version of grub-efi, I'd suggest to configure
grub-efi-amd64's debconf settings to include (unless you're dual booting
with an OS that reclaims /boot/efi/EFI/BOOT/ for itself, e.g. windows is
supposed to do this):

grub-efi-amd64  grub2/force_efi_extra_removable boolean true

This instructs (very recent) grub-efi packages to also install itself
to the default path (originally intended) for removable media, in other
words a fallback location the UEFI mainboard firmware can find and load
without an UEFI boot entry. This allows you to simply move the HDD to
another UEFI based system (of the same UEFI architecture) and boot from
that HDD directly (by selecting it from the boot manager included in
your mainboard's UEFI firmware). Some mainboard firmwares also tend to
forget UEFI boot entries after upgrading itself (some extremely buggy
ones forget it after each reboot)...

Using this fallback procedure allows to avoid using an external rescue
medium when moving harddisks to another system (or in the other 
scenarios of broken mainboard firmwares depicted above), however it's
only a safe setting if no other operating systems claim that location
in dual-boot environments.

Even on wheezy (or jessie without grub2/force_efi_extra_removable being
set), it would have been possible to copy /boot/efi/EFI/debian/grubx64.efi
to /boot/efi/EFI/BOOT/BOOTX64.EFI and your mainboard's UEFI firmware 
should have offered /boot/efi/EFI/BOOT/BOOTX64.EFI for booting the already
installed system without having to use an external rescue system, like 
d-i (assuming the default MODULES=most in 
/etc/initramfs-tools/initramfs.conf and no too special customisations).

[...]
> Intel Visual Boot Manager had a question mark as the Debian icon instead
> of the swirl and the name of the OS was "debian" instead of "Debian".
[...]

Debian's grub packages, which are the ones steering efibootmgr to set up
the UEFI entries behind the curtain, enforce all-lowercase for the UEFI
boot entries.

/var/lib/dpkg/info/grub-efi-amd64.postinst:
[...]
      grub-efi-ia32|grub-efi-amd64|grub-efi-ia64|grub-efi-arm|grub-efi-arm64)
        bootloader_id="$(config_item GRUB_DISTRIBUTOR | tr A-Z a-z | \
                         cut -d' ' -f1)"
[...]

GRUB_DISTRIBUTOR is defined in /etc/default/grub and must correspond
to the path used on the EFI System Partition, which is on a FAT32 
filesystem. grub-efi requires /boot/efi/EFI/${GRUB_DISTRIBUTOR}/ to
pre-exist or it will silently skip invoking efibootmgr.

Regards
	Stefan Lippers-Hollmann

Attachment: pgpauA3N10gox.pgp
Description: Digitale Signatur von OpenPGP


Reply to: