Le 10/08/2016 à 01:28, Mark Fletcher a écrit :
On Wed, Aug 10, 2016 at 12:19 AM Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:Le 09/08/2016 à 15:35, Mark Fletcher a écrit :2) The partition table layout needs to be right for UEFI, and what works for an MBR boot won't work for UEFI.I'm not sure I understand what you mean. Legacy and EFI boot have different requirements (legacy needs a boot loader in the MBR, EFI needs a boot loader in the EFI system partition), but they are not incompatible, so it is possible to have the same installation boot either in legacy or EFI mode. When it's not possible is only due to firmware bugs.I meant the very fact that EFI requires particular partitions to exist,
Actually I am not even sure of this, although I didn't read the EFI specification.
I could see with efibootmgr that an EFI boot variable stores the full location (GUID and position) of the partition containing the boot loader, so I wondered if the partition really had to by of the "EFI system" type. I manually registered a copy of GRUB EFI core image stored on a standard FAT partition (so that the UEFI firmware can read it) with efibootmgr, and could successfully boot it from the UEFI boot menu. So either the EFI system partition is not a requirement, or this UEFI firmware implementation was more permissive.
So it could be that the EFI system partition is only needed to boot with the default bootloader, when no EFI boot variable is defined for the device (e.g. when it is a removable device such as the installer).
Granted, a FAT partition is not that common on GNU/Linux systems, so that does not help us much.
while non-EFI requires only that at least 1 partition exist.
This is not a standard BIOS requirement. The BIOS should be partition agnostic and only check the 0xAA55 (or 0x55AA) signature in the last two bytes of the MBR. Unfortunately, I observed that some BIOSes I call "broken" check the MSDOS partition table and require that one partition with the boot flag exist.
Many misconceptions exist about requirements and limitations of the BIOS. For example, a common belief is that the BIOS cannot address more than 2 TiB of a disk. However such a limit does not exist in the BIOS specification, but only in the MBR/MSDOS partition table format. As usual you may come across a particular BIOS implementation with that limit, but it's a bug. Of course one is free to act as if all BIOSes have this limit for safety, but it is not a general truth.
It's entirely feasible to construct a partition scheme that works happily with non-EFI boot but will not work with EFI boot -- indeed, almost any reasonable structure that a user comes up with that makes sense from a legacy perspective in the absence of knowledge of EFI's requirements, will not work with EFI, at least because it doesn't include the EFI boot partition required by EFI. So no, compatible they certainly ain't.
They are compatible in the sense that adding what is required for the EFI boot does not remove the compatibility with the BIOS boot. They can coexist, if you prefer.
What is extremely hard is booting a machine MBR and then setting it up to boot UEFI.I would not say "extremely", but harder than the other way around. One reason is that you need to create an EFI system partition on the boot disk, usually going through the hassle of reducing another partition.Have you ever tried it?
Of course I have. Otherwise I would not dare to be so affirmative.
grub-install won't be able to work because the system calls it tries to make fail. virtual file systems (efivars or something? I forget exactly) that need to be populated... aren't.
Correct, but there is a workaround. Booting in EFI mode to have access to EFI variables is needed only to create an EFI boot entry. But you don't need an EFI boot entry to boot the default boot loader. This is how the installer boots from a removable medium, but it also works on a fixed drive (actually some broken UEFI firmwares can only launch the default boot loader, ignoring existing EFI boot entries).
grub-install as a --removable option to install the core image in the default boot loader location /boot/efi/efi/boot/boot<arch>.efi, assuming the EFI system partition is mounted on /boot/efi. You can also copy the core image from the standard Debian location /boot/efi/debian/grub<arch>.efi manually. <arch> may be ia32 or x64 depending on the firmware architecture.
Alternatively, some EFI firmwares are sophisticated enough to allow you to select manually the EFI file to boot from without an EFI boot entry.
Bringing up a machine from a legacy boot and then getting the infrastructure in place to be able to run grub-install is hard.
Yes, I acknowledged it was hard, but not extremely hard when you know the few steps.