News for hackers. Stuff that matters.
Re:Grub2 security update renders system unbootable by Spivak on Thursday July 30, 2020 @12:45PM (#24000272)
I feel like you're making this sound worse than it actually is

* systemd-boot doesn't support those filesystems as the /boot partition, all of those things for your / are totally fine. For most people having your /boot partition be XFS vs FAT32 is firmly in the "who cares?" realm.

* Nobody really supports OPAL, even grub. The only reliable solution is using https://github.com/sedutil/sedutil to unlock the disk and then soft reboot into any normal bootloader.

* You can do mdraid, you just have to stick the metadata at the end of the drive rather than the beginning. The utilities that set up your raid even warn you about this because this setup is so standard.

Re:Grub2 security update renders system unbootable by dijit on Thursday July 30, 2020 @01:02PM (#24000482)
> systemd-boot doesn't support those filesystems as the /boot partition, all of those things for your / are totally fine. For most people having your /boot partition be XFS vs FAT32 is firmly in the "who cares?" realm.

XFS is also not supported. But yes, your /boot can be fat32, but saying "nobody cares" is just needlessly dismissive, I can think of many reasons to care at least a little. Primary of which is lack of encryption and ability to mirror easily, another can be the possible corruption of /boot (FAT is not typically used for it's data consistency properties)

> Nobody really supports OPAL, even grub. The only reliable solution is using https://github.com/sedutil/sedutil to unlock the disk and then soft reboot into any normal bootloader.

I guess this is a fair statement, if you ignore that the "PBA" is actually using grub itself, but yes, the PBA is non-encrypted and usually lives as a separate partition, making it functionally equivalent between systemd-boot and grub2.

> You can do mdraid, you just have to stick the metadata at the end of the drive rather than the beginning. The utilities that set up your raid even warn you about this because this setup is so standard.

You can't boot to an mdraid device with systemd-boot, you can only have a separate (non mirrored or raid'd) partition on a drive, and point to that drive to boot.

Re:Grub2 security update renders system unbootable by Spivak on Thursday July 30, 2020 @01:24PM (#24000738)
> You can't boot to an mdraid device with systemd-boot, you can only have a separate (non mirrored or raid'd) partition on a drive, and point to that drive to boot.

Sorta kinda true in theory but not in practice. Yes systemd-boot isn't raid aware but if you configure mdraid to store its metadata at the end of the drive then you wind up with a, say, mirrored disk that to the firmware doesn't look like it's mirrored at all. And since the firmware just reads the partition it's safe and works.

So yes, you have to configure your firmware to look at both drives in a mirrored setup as a fallback but you can boot.

> but saying "nobody cares" is just needlessly dismissive

Fair, I'm more saying that having firmware that only supports a small set of simple filesystems is the usually the more normal situation, the fact that GRUB comes with all the drivers makes it the weird one.

Re:Grub2 security update renders system unbootable by yrro on Thursday July 30, 2020 @01:18PM (#24000674)
> You can do mdraid, you just have to stick the metadata at the end of the drive rather than the beginning. The utilities that set up your raid even warn you about this because this setup is so standard.

You're screwed when the firmware decides to write to the ESP though.

Re:Grub2 security update renders system unbootable by Spivak on Thursday July 30, 2020 @01:27PM (#24000775)
This is 100% true but I haven't been so unlucky as to encounter firmware that does this under normal operation. This has been the "firmware doesn't understand software raid" solution for ages.
Re:Grub2 security update renders system unbootable by yrro on Friday July 31, 2020 @11:17AM (#24009460)
Indeed, it hasn't happened to me but I remember reading about someone who discovered the hard way that their firmware fell back to storing boot variables in a file on the ESP for some reason. It's the sort of thing you only notice once you're staring at an error message, wondering why your ESP is corrupted.

It's hardware RAID or nothing, at least for the ESP for me!