[Discuss] Grub, EFI, Partitioning…

[richard.pieri at gmail.com (Rich Pieri)]

On Tue, 3 Sep 2024 19:51:43 -0400
Steve Litt <slitt at troubleshooters.com> wrote:

> >It also brings cross-architecture portability;   
> 
> I'm not sure in what way it does this, but I'm sure it could have been
> done in a much simpler way.

The principle being that your UEFI code will run on ARM, AMD64, IA64,
or whatever other CPU architecture. A consistent API (or is it ABI?)
across architectures is needed. I don't disagree that there are simpler
ways to do this than UEFI if this were all that it did.


> Which isn't as important now that small NVMe drives are so darn cheap.

At the time they weren't.


> Haven't we been doing this since Knoppix came out? Or am I
> misunderstanding you?

I think you misunderstand. This isn't the OS booting and loading its
filesystems to a ramdisk. It's creating an OS on a ramdisk and booting
from it. Since the ramdisk is created at the firmware level it survives
reboots which is *very* useful for turnkey upgrades which require
multiple reboots to apply, and being RAM based it is many times faster
than USB or optical media. It matters when I have to apply upgrades to
dozens of servers.

It's how Red Hat's Leapp utility works: similar to Sun's miniroot on
swap mechanism but with a ramdisk.

The Ventoy tool does something very similar with ISO images.


> Yeah, chain loading was never fun. But these days multi-boot isn't as
> essential because we have VMs.

That's a matter of opinion particularly when performance is a high
priority.


> I didn't know about Lenovo going John Deere on us. That's disgusting.

Yup. I don't know if they still do it, but during the 2010s they used
device signing to lock out third party PCIe cards on some of their
tower systems.

-- 
\m/ (--) \m/