On 15/06/2024 20:35, Dale wrote:
I'm not opposed to efi.  I remember when the old Grub reached its end of life. Grub2 is different but it works.  I don't use the eye candy part so that makes it even easier.  The biggest thing, I copy my kernels and such over manually and I keep a couple older ones that I want to be available.  I also plan to install memtest, a rescue image or two and those need to be available as well.  I may still use Grub, I may not. Right now, I'm clueless.  I'm just trying to follow the docs which given all the options available are confusing to follow.

At the end of the day, all these things are pretty much the same. Back in the ancient days, you had a switch panel you toggled to put in the boot code.

Then they put a basic interpreter in ROM.

Then they got rid of basic and put code in that said "here's a bit of disk controller code, go to chs(0,0,0), read one block and execute it".

Now UEFI is just a bit more fancy code that says "here's a gpt table reader, a vFAT driver, and a mini program that looks in any FAT partition it can find for an EFI directory, and runs whatever it finds in there".

So the principle hasn't changed, but the detail has.

And of course, all the rules get bent by the various manufacturers. Bear in mind that basic EFI predates vFAT so even in UEFI vFAT isn't actually mandatory. Apple don't use it, iirc. There's nothing stopping GNU's OpenBIOS project or whatever it is using ext4. But vFAT is the official "lowest common denominator" which everything must support if it's not "single vendor for hardware and software". Which is why, of course, MS can't play fun and games - if they say Windows won't support vFAT they'll get hammered for anti-trust.

More and more everything is turning into "System on a chip", and that includes the bios! It has just enough of a driver now to read everything it needs from the attached storage, and that's your modern UEFI.

Cheers,
Wol

Reply via email to