Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The flaw with UEFI is that the list of installed operating systems is stored in the motherboard's NVRAM and not in the EFI system partion on the disk itself.

When your motherboard dies and you need to put in a new one, now you have to boot off a CD/DVD/USB Stick to get to the boot manager utility. Then you have to figure out the command line parameters since the first time the OS installer did it for you.

At minimum the motherboard setup menu should give you FULL editing cabability of the NVRAM variables. I should be able to add, modify and delete any and all entries without having to boot something first.

Last motherboard I tried using the efibootmgr on got bricked. And there was no way to clear it like you can with normal BIOS NVRAM.



This is nonsense. UEFI has a fallback path and all common OSes can or do install a fallback bootloader which restores the NVRAM variables.


You may not agree with me but don't call it nonsense.

From the article about the fallback path: "This mechanism is not designed for booting permanently-installed OSes."

Plus there is only one fallback path so we're back to the situation of multiple OSes fighting over the fallback path.

And from the article a disadvantage of the BIOS: "It’s inconvenient to deal with – you need special utilities to write the MBR, and just about the only way to find out what’s in one is to dd the contents out and examine them."

But now with UEFI we need a special utility to manipulate the EFI NVRAM variables. The motherboard setup only lists the names of the entries. No editing and no listing of the details.

So my criticism is valid. The information stored in the UEFI bootmanager NVRAM should have been in a file(s) in the system partition.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: