swapping disk with UEFI hardware - a dead end?
pjones at redhat.com
Thu Jun 28 14:04:47 UTC 2012
On 06/28/2012 09:40 AM, Lennart Poettering wrote:
> On Thu, 28.06.12 09:29, Peter Jones (pjones at redhat.com) wrote:
>> Having sent that mail it became obvious that what's happened is that your
>> new x220 board doesn't have the efi boot variable set. Some machines allow
>> you to boot from a file, in which case it'll be /efi/fedora/grubx64.efi .
>> If your firmware doesn't have that, you'll need to boot some install/rescue
>> media to get to a shell. In either case you'll need to use efibootmgr to
>> add /efi/fedora/grubx64.efi to the boot order.
>> That's all assuming it's F17; if it's earlier, it'll be /efi/redhat/grub.efi .
> Hmm, so if grub would also install itself into /efi/boot/bootx64.efi
> then this problem would just go away as that is the default file that
> the EFI bios will execute. This would enable disk images that just boot
> without any need to register them in the bios...
> Is there any reason why Fedora doesn't create that file?
> (it's a pity FAT can't do symlinks, hence it should just be a copcy of
You're not wrong, we just haven't solved this right yet. Using
/efi/boot/bootx64.efi on non-removable media was an addition to the spec in
2.3.1 , which came out right /before/ we joined the USWG, and it isn't what
we'd really like to be there. Among other problems, obviously if you're dual
booting then each OS is just going to clobber theirs on top of the other one,
so whichever you install first doesn't get to play in a failure scenario.
We haven't simply switched to using grub for that, because we don't really
want the normal bootloader there as the "boot file of last resort". The idea
is to have that file look for your normal bootloader and re-add Boot####
entries automatically if it gets run, and then have it exec your real
bootloader. I have the beginning of some code to do this, and it'll probably
go in shim. We're also going to propose a best-practices at USWG for more
standardized discovery in this situation, so we can do something more standard
across OSes without worrying about clobbering this file as we do now.
We could put grubx64.efi there as a stop-gap, and if we don't have what I've
mentioned above ready for F18, we probably will.
More information about the devel