boot.mount: mount by UUID instead #1256
Conversation
overlay.d/05core/usr/lib/dracut/modules.d/35coreos-ignition/coreos-boot-edit.sh
Outdated
Show resolved
Hide resolved
overlay.d/05core/usr/lib/systemd/system-generators/coreos-boot-mount-generator
Outdated
Show resolved
Hide resolved
jlebon
force-pushed
the
pr/boot-mount-uuid
branch
from
22fcb47 to
fd174d9
Compare
|
Updated! |
| # And similarly, only inject boot= if it's not already present. | ||
| boot=$(karg boot) |
There was a problem hiding this comment.
E.g. in FIPS mode, we'll already have a boot= karg there. (We should change that code to use boot=UUID too.)
| # Copied from | ||
| # https://github.com/dracutdevs/dracut/blob/9491e599282d0d6bb12063eddbd192c0d2ce8acf/modules.d/99base/dracut-lib.sh#L586 | ||
| # rather than sourcing it. | ||
| label_uuid_to_dev() { |
There was a problem hiding this comment.
Another thing we could put in rdcore in the future?
There was a problem hiding this comment.
Maybe. This runs in the real root, and so far rdcore has been about the initramfs only. It'd be a bit awkward, though I guess we could just embed the full dracut path to it?
Though in this case, since we want to just implement the same API as dracut/fips, it seems simpler to just copy-paste the API implementation itself. If there are bugs in there, at least we'll have the same bugs as dracut. :)
|
I think this is also going to want some careful manual testing, definitely for things like upgrades etc. |
|
From a commit message:
I think you mean that there's precedent in the FIPS module, and not that the FIPS module has precedence over coreos-boot-mount-generator? |
Lifted from `coreos-boot-edit.sh`. Prep for future patch.
With the new `karg` helper, this is trivial to do now.
There are already other places which assume that `rdcore` is in `PATH` so drop the full path to be more generic.
This is analogous to `systemd-fstab-generator` parsing `root=` kargs. There is a precedent for this in the FIPS module. In fact, we lift code from there to make sure we're API compatible. The goal of supporting a `boot` karg is to eliminate possible races for the `by-label/boot` symlink in the real root if multiple exist. Part of: coreos/fedora-coreos-tracker#976
jlebon
force-pushed
the
pr/boot-mount-uuid
branch
from
fd174d9 to
d1c79d7
Compare
Ahh yup, thanks! I rebased this now and added a simple test. I forgot to do it in two force-pushes to make it easier to see the interdiff. But essentially the only changes are the additions in |
|
Can I get another stamp on this? |
This ensures that the rootfs will always mount the correct boot filesystem in the future (see previous patch). Part of: coreos/fedora-coreos-tracker#976
The new `boot` karg will only show up on the second boot and onwards. So for the first boot, let's persist it in `/run` to tell `coreos-boot-mount-generator` the UUID to use.
jlebon
force-pushed
the
pr/boot-mount-uuid
branch
from
d1c79d7 to
89066d5
Compare
All our reboot tests currently target some special feature which significantly modifies the system. But we should also have a reboot test which is just using the defaults. This patch adds such a test.
Sure, done! I initially didn't do this because we don't have a vanilla test which reboots and it felt funny to tack it onto another existing rebooting test which was testing some orthogonal thing. But I think we should cover the vanilla case more explicitly. I added a new rebooting testcase for this. Would be interesting to somehow merge that with misc-ro and other non-exclusive tests though it'd require some thought. |
I added some tests here, but one test I did manually was boot up the very first stable release, bring it fully up to date and then update to this PR to confirm that the boot mount still works fine (i.e. correctly falls back to mounting by label). (Related: coreos/coreos-assembler#2519). |
This makes the mount more resistant to other filesystems labeled
bootthat may get plugged in at any point.
Part of: coreos/fedora-coreos-tracker#976