4 ms·

The UEFI entries are just regular EFI variables, except they use a special GUID: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C cf https://stackoverflow.com/questions/673

by csdvrx 3y ago

The UEFI entries are just regular EFI variables, except they use a special GUID: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C cf https://stackoverflow.com/questions/67395528/ https://stackoverflow.com/questions/67395528/ and the actual description in https://github.com/erikberglund/AppleNVRAM/blob/master/EFI/8BE4DF61-93CA-11D2-AA0D-00E098032B8C.md https://github.com/erikberglund/AppleNVRAM/blob/master/EFI/8... with examples on how to access them from an UEFI shell on https://oofhours.com/2019/09/02/geeking-out-with-uefi/ https://oofhours.com/2019/09/02/geeking-out-with-uefi/ These variables are what `efibootmgr` lists and can change on Linux, what `bcdedit /enum firmware` lists on Windows, and what GetSetVariable can manipulate on Windows cf https://github.com/ProSlatisa/GetSetVariable/tree/master/VariableCfg https://github.com/ProSlatisa/GetSetVariable/tree/master/Var... Ultimately, each are OS-specific solutions, while it would be interesting to make a crossover between efibootmgr and GetSetVariable (and that C program) to create a tool working on both Linux and Windows with cosmopolitan to restore/hack 8BE4DF61-93CA-11D2-AA0D-00E098032B8C variables, because a quick search on that magic shows some people have uploaded their efivar to github for other models so it must be a common issue!

timschumi 3y ago
> Ultimately, each are OS-specific solutions, while it would be interesting to make a crossover between efibootmgr and GetSetVariable (and that C program) to create a tool working on both Linux and Windows I seems that nobody except for Linux (for some not yet determined reason) is having issues with retrieving EFI variables on this hardware, and one could potentially classify this as a bug in `efibootmgr` as well (due to how it handles creating the new entry in unknown conditions). In either case, Linux is the only thing affected by this, so in real-world setups Linux is going to be the only boot option that is available while the boot menu is in a broken state.
- crote 3y ago
  There's a pretty decent chance nobody else is actually trying. The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition. Especially in laptops, a lot of hardware / firmware issues are simply "solved" by baking a fix into the pre-installed Windows version. It's a solution for 99% of users, so why bother spending time looking into the root cause?
  - peppermint_gum 3y ago
    >There's a pretty decent chance nobody else is actually trying. The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition. From TFA: "Note: At this point, I checked that Windows and various other UEFI tools are able to read the variables just fine, so Linux’ output is confirmed to be incorrect."
    - csdvrx 3y ago
      > From TFA: "Note: At this point, I checked that Windows and various other UEFI tools are able to read the variables just fine, so Linux’ output is confirmed to be incorrect." UEFI is a bit complicated and it's well known the EDD3 specifications can cause issues to efibootmgr, for example on Dell https://github.com/rhboot/efibootmgr/issues/86 https://github.com/rhboot/efibootmgr/issues/86 I just think it'd be nicer to have a multiplatform way to tweak UEFI boot variable, so you can fiddle with your UEFI variables from either Linux or Windows without having to actually go into the UEFI shell or use a PE32 like RU.EFI : https://ruexe.blogspot.com/ https://ruexe.blogspot.com/
    - 791076443 3y ago
      Hhhhh 8uhga
  - timschumi 3y ago
    > The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition. > Especially in laptops, a lot of hardware / firmware issues are simply "solved" by baking a fix into the pre-installed Windows version. It's a solution for 99% of users, so why bother spending time looking into the root cause? The Windows versions I installed for testing were non-OEM versions. They still behaved as expected. Notably, Windows didn't just know about all the standard UEFI variables, but also about a non-standard one that I added for testing. This means that there definitely is a way to ask for the list of variables so that the UEFI accepts it (sadly, reverse engineering that is a pain), and that the Linux kernel is most likely the place where an actual fix has to happen. Of course, yes, at the end of the day, the root cause is a specification non-conformity in the UEFI itself.

by csdvrx 3y ago

timschumi 3y ago

> Ultimately, each are OS-specific solutions, while it would be interesting to make a crossover between efibootmgr and GetSetVariable (and that C program) to create a tool working on both Linux and Windows I seems that nobody except for Linux (for some not yet determined reason) is having issues with retrieving EFI variables on this hardware, and one could potentially classify this as a bug in `efibootmgr` as well (due to how it handles creating the new entry in unknown conditions). In either case, Linux is the only thing affected by this, so in real-world setups Linux is going to be the only boot option that is available while the boot menu is in a broken state.

crote 3y ago
There's a pretty decent chance nobody else is actually trying. The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition. Especially in laptops, a lot of hardware / firmware issues are simply "solved" by baking a fix into the pre-installed Windows version. It's a solution for 99% of users, so why bother spending time looking into the root cause?
- peppermint_gum 3y ago
  >There's a pretty decent chance nobody else is actually trying. The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition. From TFA: "Note: At this point, I checked that Windows and various other UEFI tools are able to read the variables just fine, so Linux’ output is confirmed to be incorrect."
  - csdvrx 3y ago
    > From TFA: "Note: At this point, I checked that Windows and various other UEFI tools are able to read the variables just fine, so Linux’ output is confirmed to be incorrect." UEFI is a bit complicated and it's well known the EDD3 specifications can cause issues to efibootmgr, for example on Dell https://github.com/rhboot/efibootmgr/issues/86 https://github.com/rhboot/efibootmgr/issues/86 I just think it'd be nicer to have a multiplatform way to tweak UEFI boot variable, so you can fiddle with your UEFI variables from either Linux or Windows without having to actually go into the UEFI shell or use a PE32 like RU.EFI : https://ruexe.blogspot.com/ https://ruexe.blogspot.com/
  - 791076443 3y ago
    Hhhhh 8uhga
- timschumi 3y ago
  > The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition. > Especially in laptops, a lot of hardware / firmware issues are simply "solved" by baking a fix into the pre-installed Windows version. It's a solution for 99% of users, so why bother spending time looking into the root cause? The Windows versions I installed for testing were non-OEM versions. They still behaved as expected. Notably, Windows didn't just know about all the standard UEFI variables, but also about a non-standard one that I added for testing. This means that there definitely is a way to ask for the list of variables so that the UEFI accepts it (sadly, reverse engineering that is a pain), and that the Linux kernel is most likely the place where an actual fix has to happen. Of course, yes, at the end of the day, the root cause is a specification non-conformity in the UEFI itself.