ESP mount generator

[dbnicholson]

This adds a systemd generator to mount the ESP. The intention is to supplant the ESP mounting currently handled by systemd-gpt-auto-generator since it does not contain the policy to handle all the systems EOS runs on. I've tested this (in a VM) on the following configurations:

• Standard x86_64 EOS with GPT partitioning
• Standard x86_64 EOS with MBR partitioning (using eos-repartition-mbr from the original GPT)
• PAYG x86_64

I have not tested this on:

• Windows dual boot
• arm64 EOS

As we previously discussed, I'm sure this will get the dual boot case wrong. However, with this generator we can add the policy and tests for it. Trying to cram the policy into systemd-gpt-auto-generator would probably never work.

There's pretty extensive testing since I really don't want to regress any systems. You can test this on a real device by dropping it into /etc/systemd/system-generators/. Without the /efi directory it only does anything useful on PAYG. You can do a full test by creating a temporary deployment with an /efi directory:

sudo mkdir -p /etc/systemd/system-generators
sudo install -m755 eos-esp-generator /etc/systemd/system-generators/
# Adjust the refspec as shown in ostree admin status
eos_refspec=eos:os/eos/amd64/master
sudo mkdir esproot
sudo mkdir -m700 esproot/efi
sudo ostree commit -b esp -s "ESP testing" --tree=ref=$eos_refspec --tree=dir=esproot
sudo ostree deploy esp
reboot

When done, redeploy the normal ostree:

sudo ostree deploy "$eos_refspec"
sudo rm /etc/systemd/system-generators/eos-esp-generator

https://phabricator.endlessm.com/T29930

[dbnicholson]

OK, so this is nearly a rewrite of the generator that was primarily driven by the need to handle the Windows dual boot case. The significant changes are:

• For dual boot, look for the endless.image.device kernel command line argument and try to use the ESP from there.
• Use blkid for gathering partition data instead of sfdisk. I think sfdisk could still work, but the nested partition within disk JSON format made that awkward. I really wanted to use lsblk, but that depends on udev, which is blocked from starting until the generators complete.
• While trying to debug issues, I found out that generator stdout/stderr goes nowhere. As noted in systemd.generator(7), the only way to get output is to write to /dev/kmsg. So, I wrote a logging handler to do that, which seems to work nicely.
• Added a "gather mode" that I used to get test data.

I tested this on 4 different systems that are represented in the test data:

• Regular EOS with shim and GPT partitions
• Regular EOS with shim and MBR partitions
• PAYG with sd-boot
• Windows dual boot with shim

Earlier I wrote some instructions on how to test this by making a temporary ostree commit, but you can do it even easier. Since directories in the checkout are made on the fly, you can just make the /efi directory after temporarily making / mutable:

chattr -i /
mkdir /efi
chattr +i /
mkdir -p /etc/systemd/system-generators
install eos-esp-generator /etc/systemd/system-generators/

The /efi directory will persist until a new ostree deployment is made.

[wjt]

Impressive work.

[wjt]

I'm curious to know what the reason is!

(From a less careful codebase I might wonder if this is the UTF-16-encoding of U+0000 (two nul bytes) followed by a C byte string terminator (1 nul byte).)

[dbnicholson]

I found the spot in the systemd code where it happens, but it was quite a while ago. There weren't really comments, but I think it was sort of what you're suggesting. Whether you try to parse as a C string or UTF-16, you'll find a trailing NUL. But it just has easily could have been a mistake that's essentially irrelevant the way systemd reads the values. The Unicode handling was entirely bespoke. I'll try to find it again when I get a chance.

[dbnicholson]

I added the new changes as fixups so it would be easier to see the differences from the previous mega-commit. I'll squash them if you approve.

[wjt]

Looks great. Squash away!