It's that time again! The systemd v261 release is coming closer. Let's restart the "what's new" series of posts for this iteration! Hence:

1️⃣ Here's the 1st post highlighting key new features of the upcoming v261 release of systemd. #systemd261 #systemd

systemd-repart is systemd's dynamic disk partitioner and image generation tool. It only deals with GPT disk labels – or more precisely, it only dealt with GPT disk labels *so* *far*. With v261 there's…

…limited support for another type of disk label: ISO9660/El-Torito.

You might wonder what that's good for, after all ISO9660/El-Torito is a concept from the CD-ROM/DVD era, and that era is kinda over, no?

Well, as it turns out many VM environments still boot with an emulated CD-ROM drive, and for installers it is hence nice to build "universal" images that boot both when put on a USB stick *and* when put on an (emulated or real) CD-ROM.

Now, if you know UEFI well…

…you might be aware that UEFI also supports putting a GPT partition table directly onto a CDROM without the need of ISO9660. And you'd be right with that. But there's one problem with that:

CD-ROMs use 2048 byte sectors, while USB sticks use 512 byte sectors. In the interest of having fully universal installer images it's hence interesting to have one boot path for the 2048 byte sector case (CD-ROM) and another boot path for the 512 byte sector case (USB sticks) within the…

…same image. Hence this is what happens here: if this new mode is enabled via --el-torito=yes, then the ESP of the disk image becomes available both as a 512b sector ESP, and as a 2048b sector ISO9660 El-Torito boot file system.

TLDR: just enable that knob and your bootable UEFI images can both be booted on (virtual or real) CD-ROMs and USB sticks, the exact same way. Yay!

And of course it doesn't stop after UEFI, once in the initrd, we probe the gpt table on the cdrom and attach it as a loop device, and from that point onwards the cdrom behaves as a regular (read-only) block device. Getting all of that to work also involved two kernel patches, one to the loop driver and one to the cdrom driver, both of which are now on their way to the stable trees.
@daandemeyer hey, that's material for another episode! Pssst! 🤫