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