On Mon, Apr 14, 2014 at 3:14 PM, Chris Murphy <li...@colorremedies.com> wrote: > > On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski <l...@mit.edu> wrote: >>> >>> Create a boot menu entry can be skipped if it's not a dual boot system. >>> /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default >>> on a system without an NVRAM entry already pointing to shim or grub, and a >>> fallback entry is created automagically. With Windows, yeah you probably >>> have to do something manually because it probably always boots Windows >>> otherwise. >>> >> >> Not on my crappy motherboard :( It apparently can't boot from >> EFI/BOOT on a hard disk. Sigh. > > Huh, you're sure? You have to either remove all removable NVRAM boot entries, > or you have to remove the file/device the entry points to trigger the use of > //BOOT/BOOT<arch>.efi. If this isn't working, what does happen instead? It > just hangs?
Hmm. I assumed that just asking the system to boot off that disk would do the trick. Apparently not. Removing other entries is hard, given the aforementioned OOPS. :( > >> >> I tried to clarify it a bit, though. >> >>> >>> >>>>>> It's currently mostly working, modulo the efibootbgr issue. But I >>>>>> don't actually know what to type into efibootmgr to fix it, the OOPS >>>>>> notwithstanding. I can probably figure it out once the OOPS is fixed. >>>>> >>>>> Strictly speaking you don't need to point UEFI non-Secure Boot computer >>>>> to shim.efi, you can just leave it alone and put a grub.cfg in the proper >>>>> place. At the grub prompt if you type set you should see either >>>>> config_directory= and prefix= to show where it's looking for the grub.cfg. >>>> >>>> https://bugzilla.kernel.org/show_bug.cgi?id=73761 >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1085957 >>> >>> I'm not familiar with this usage: efibootmgr -B -b 0 >>> >>> If 0 is the same as 0000 then that seems to ask for the removal of a fixed >>> entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. >>> But then it also shouldn't crash the kernel. >>> >>> A valid command would be efibootmgr -b 0003 -B >>> >> >> -B -b 0 seems to be the same as -B -b 0000, and my 0000 isn't the same >> as your 0000 :) > > I'm basing it off the 0000 entry in your bug 73761. It points to a DVD drive. > > >>> Something that properly deals with restoring shim, grub, grub.cfg, and >>> NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some >>> of the manufacturer NVRAM behaviors are pretty icky. And on top of that >>> don't seem to have a good way for users to reset/wipe it. It's something I >>> think the UEFI Forum ought to put in the standard and require it. >> >> Anaconda does this somehow, I think. Even just exposing that would be nice. > > No all it does is look for a Fedora boot entry in NVRAM and then uses > efibootmgr -b xxxx -B against it. It doesn't have a mechanism, nor should it, > to obliterate everything in NVRAM which can contain a lot more than just boot > entries. > > ls -l /sys/firmware/efi/efivars > > Two dozen variables. On my Mac there's 50+ items including speaker and > brightness level. > I meant that I assumed that anaconda set up a new boot manager entry. If it doesn't, and just relies on fallback, then I guess there's nothing to ask for. Of course, that'll change once anaconda becomes sensible enough to set up each ESP once and keep it unmounted from then on, since that'll involve changing the RPMs so they don't install to /boot/efi. Unless, of course, /boot/efi just becomes the efi boot template, in which case some script will need to propagate the contents. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
