On Mon, 2014-04-14 at 17:22 -0600, Chris Murphy wrote: > >> 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. > > No. Boot entries in NVRAM come first. See UEFI spec 2.4.0, section > 3.4.1.2, and 12.3.1.3 "This directory contains EFI images that aide in > recovery if the boot selections for the software installed on the EFI > system partition are ever lost." THREAD NECRO ALERT! Well, there's scope for all kinds of undefined behaviour there, really. The spec basically describes a certain minimal set of behaviours that must be implemented, but there's all sorts of scope for firmwares to implement other paths on top. If a firmware UI implements some kind of option that could be described as "just one time, boot from this hard disk", what that might do isn't really defined by the spec at all. It could mean "do a fallback path UEFI boot from this disk". Or it could mean "do a CSM (BIOS compatibility mode) boot from this disk". Or some firmware engineer who'd hit the crack pipe *really hard* could come up with some other meaning, I guess. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
