install fstab for `/boot` conflicts with transient etc

[stephan-tolksdorf]

After install to-filesystem the generated fstab is present in the sysroot etc folder, but not the usr/etc folder, which then with a transient etc leads to the file missing after boot in the etc overlay, because the lower is usr/etc.

[cgwalters]

Hi, thanks for the report.

As of the current code, we only write a fstab entry for /boot if we detect one in use. One solution is to not use a separate /boot partition. Another option is to align with https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ - though it doesn't quite cover the "classic linux /boot" partition I think. (Though that needs some digging in and testing, I may be wrong and we could actually just use that even if it's not VFAT)

I think we can unconditionally switch to-filesystem to use the (somewhat new) systemd.mount-extra kernel argument instead of us writing a fstab. That functionality isn't in RHEL9 today is the only trap, but we could probably detect the systemd version in use.

If systemd is new enough we should unconditionally use the karg I think. If systemd is too old and transient etc is in use, then we error out by default.

[stephan-tolksdorf]

Thanks! systemd.mount-extra seems interesting, I'll try that.

Currently I'm helping myself by copying the fstab to /usr/etc before the first boot. (In my workflow I build images for the partitions which are then copied to the target disk by an installer script. root is luks encrypted, while boot isn't.)

[cgwalters]

Currently I'm helping myself by copying the fstab to /usr/etc before the first boot.

That will go away on the first upgrade, so it can't really work in general.

[stephan-tolksdorf]

The idea is to do upgrades like first installations, i.e. overwrite the root and boot partitions with the new disk images from a script.

[cgwalters]

The idea is to do upgrades like first installations, i.e. overwrite the root and boot partitions with the new disk images from a script.

OK, though at that point you're only using 10% of bootc; in particular it will be hard to implement transactional updates. If the goal is to absolutely minimize state drift, see #404 (which has some recent WIP).

The first solution though to state drift in /etc is just to limit which tools write to it. For /var, it's possible to clean things on shutdown/reboot via e.g. tmpfiles.d.

[cgwalters]

Outside of using the DPS...today we always inject a boot= karg, so one simple thing to do for people affected by this is to switch to mounting /boot via a static systemd unit embedded in the OS i.e. have /usr/lib/systemd/system/boot.mount which uses that karg to mount (or of course just mount via a static label like LABEL=boot).

We could try to include a generator to do that included in bootc, but it'd require a fair amount of validation to ensure we weren't breaking any systems which already mount /boot via some other mechanism (systemd-fstab-generator does this kind of thing re fstab).

---

It's worth highlighting here too that a different unfortunate intersection of this is right now e.g. Anaconda requires /boot with bootc https://issues.redhat.com/browse/RHEL-66155.