GRUB 2.04 Release Candidate Brings Globs Of New Features

[scineram]

Grub is basically superfluous in this modern era. At least it will not work with OpenZFS going forward. Just use any other UEFI bootloader.

[Guest]

F2FS support sounds pretty cool, it will kill the need for any other file systems in my use, especially considering that it seems to perform well on SSDs. I guess it will be time to recompile coreboot and move all my data to a superior file system.

[fuzz]

Grub is basically superfluous in this modern era ... Just use any other UEFI bootloader.

Except for systems still around that don't have UEFI....

[starshipeleven]

Except for systems still around that don't have UEFI....

That's nearly a decade old hardware, btw.

(I'm also disregarding ARM and such because they don't usually boot GRUB)

[fuzz]

That's nearly a decade old hardware, btw.

Yes, my primary workstation is a dual socket Opteron board with a pair of Opteron 6344s. No UEFI, but still serves me well for many things.

[starshipeleven]

Yes, my primary workstation is a dual socket Opteron board with a pair of Opteron 6344s. No UEFI, but still serves me well for many things.

And I still maintain a ton of Geode systems around the place with OpenWRT (yes they also use GRUB to boot) that are perfectly fine for basic firewall and IP phone server duties.

Does not make GRUB any less superfluous in the modern (UEFI) era.

[fuzz]

And I still maintain a ton of Geode systems around the place with OpenWRT (yes they also use GRUB to boot) that are perfectly fine for basic firewall and IP phone server duties.

Does not make GRUB any less superfluous in the modern (UEFI) era.

Superfluous: "Being beyond what is required or sufficient."

It exists for hardware that is still in use in the "modern" era. Not superfluous.

With all the legacy stuff out there, I prefer software that is still in use gets maintained as long as possible -- if only for security patches.

America's Cities are Running on Software From the 80's

[starshipeleven]

Superfluous: "Being beyond what is required or sufficient."

For modern hardware it is superfluous.

It exists for hardware that is still in use in the "modern" era. Not superfluous.

For legacy hardware it is not superfluous.
But legacy hardware isn't what is most common.

America's Cities are Running on Software From the 80's

I always said USA is a third world country.

The issue isn't running 80s software, the issue is gross mismanagement of this software so that it can't be just put in a VM and run on a server, while people use a modern frontend for it.

Some more laughs https://arstechnica.com/information-...has-no-backup/

[starshipeleven]

show me how i get /boot as RAID1 with UEFI so that it don't matter which of my 4 disks are dying

has debianxfce infected you?
Have you never seen the warning mdadm spews when you build an array?

mdadm:
Note: this array has metadata at the start and may not be suitable as a boot device.
If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90

You can boot a basic RAID1 array with a non-RAID-aware bootloader (i.e. u-boot). Make the /boot partition a mdadm RAID1 with metadata=0.90 option. This will have a whole list of limitations that are irrelevant if you use it for a /boot partition, but it will appear like a normal partition to non-mdadm-aware bootloaders.

For the UEFI partition you can just set up a generic rEFInd setup (i.e. refind as /EFI/BOOT/bootx64.efi) and then copy the partition to all the disks and never touch them again, or keep a single one on a USB drive inside the server.

I never tried RAID-ing the UEFI partition itself (as with rEFInd it's static, no changes need to be synced) but it should theoretically work too with this method.

[starshipeleven]

Not every system in the world is EFI, there are also a lot of systems which use OpenFirmware (IEEE1275), for example.

u-boot and coreboot systems (commercial ones in industrial equpment, not DIY firmware replacement) dwarf them.

But yeah ok fair enough, I was implicitly assuming x86 and ARM devices used in IT, not industrial or embedded.