Fun little thing I have been working on: teach systemd to boot directly into a disk image downloaded via HTTP within the initrd.

In v257 systemd learnt the ability to download disk images at boot via systemd-import-generator, both DDIs and tarballs, and place them in /var/lib/machines/, /var/lib/portables/, /var/lib/confexts, /var/lib/extensions/. The goal was to provide a way to provision any of these resources automatically at boot. But now that we have this, we can take it a step further:

download the root disk image itself with this. There were a bunch of missing bits to make this nice though:

First of all, for raw disk images we need to attach them to a loopback block device, to make them mountable. Easy-peasy, systemd-dissect --attach already delivers that.

Then, for tar disk images we need to bind mount the downloaded and unpacked image to /sysroot/ (which is where the rootfs goes before we transition into it).

Then, to make this nicer, it makes sense to allow deriving the URL to download the rootfs image from directly from the UEFI HTTP boot URL. Or in other words: if you point your UEFI to boot a UKI from some URL (i.e. http://example.com/somedir/myimage.efi), then that UKI's initrd is smart enough to derive from that same URL a different URL for the rootfs (by replacing the final component, so that it becomes http://example.com/somedir/myimage.raw.xz).

@pid_eins partially related to this, theres ongoing work in U-Boot to utilise the "pmem" feature on ARM boards at least.

This will enable the bootloader to download one disk image with everything on it and make it accessible to the initrd via /dev/pmemX just like any other block device. So you can directly HTTPs boot distro images or installers with little/no modifications

@cas uefi ramdisk support works the same way: they insert a fake pmem entry in the memory table and linux can directly consume it then.

but i am not too keen to rely on that tbh. i much prefer to download a smallish UKI as first step, and then the big root from linux userspace. simply because firmware code quality sucks ass, and linux is quite OK...