Assumption of `/dev/disk/by-label/{boot,root}` for non-live targets about fedora-coreos-config HOT 7 CLOSED

Sure, but that's a generic Ignition code which also needs to handle e.g. the OpenSUSE thingy.

I said this somewhere else but it is for sure actively mind-melting that we need to handle and consider:

• FCOS using both Ignition and OSTree
• Silverblue/(older FIoT and others) using OSTree but not Ignition
• OpenSuse MicroOS using Ignition but not OSTree
• A whole lot of other distributions (traditional Fedora/RHEL etc.) using neither

from fedora-coreos-config.

I said this somewhere else but it is for sure actively mind-melting

You have no idea :)

from fedora-coreos-config.

Some nuance that we need to consider: our *.mount units use [email protected], which does a BindsTo on the device [1]. If the device changes underneath, then the unit fails and the device is unmounted. This causes errors like:

ostree[40698]: error: Unexpected state: /run/ostree-booted found, but no /boot/loader directory

[1] https://github.com/systemd/systemd/blob/master/units/systemd-fsck%40.service.in#L14

from fedora-coreos-config.

So for root, I think we're agreed having it be overridable via karg (and that actually works today already).

I can see wanting the same thing for boot on complex devices. So then our generator would just check first to see if a boot= karg is given and generate a boot mount from that before falling back to /dev/disk/by-label/boot?

from fedora-coreos-config.

Colin also had an interesting idea here on finding boot from what GRUB injects already, which would be really cool. Though I'm not sure how it'd translate to complex devices (e.g. if you boot on multipath, then you might actually be booting on one of the constituent devices, right?)

from fedora-coreos-config.

Aside but I'm pretty sure
ostree[40698]: error: Unexpected state: /run/ostree-booted found, but no /boot/loader directory isn't related - that's in the real root (in the case you're referencing during shutdown). The only bit of ostree-the-code that runs in the initramfs is ostree-prepare-root.service.

On second boot [6] has no dependencies on the actual device being there.

Sure, but that's a generic Ignition code which also needs to handle e.g. the OpenSUSE thingy. In this repo we use

@cgwalters suggested that for second boot we use explicit kargs of root=... which could address this issue.

Right, I think that's the simplest and even more importantly - it's basically the default for how most Linux systems work. It's definitely what Anaconda ends up using for example. We'd just be using labels to bootstrap.

from fedora-coreos-config.

I think this is basically fixed, for complex root we inject root= nowadays.

from fedora-coreos-config.