[rhcos-4.18] coreos-boot-mount-generator: honor boot= karg better in multipath case #3506
Conversation
bc0ca58 to
9dba893
Compare
We don't need to test on FCOS for rhcos stable branches.
As described in openshift/os#1787, we need to loosen up our restriction that only a single `boot` and `root` labeled filesystem exists, at least past the first boot to start. There is code already that injects `boot` and `root` kargs to specify the exact UUID we want so this is feasible. There's currently two ways in which the boot device can be specified: - the `/run/coreos/bootfs_uuid` file exists; this is written by rdcore but is only available on first boot - a `boot=` karg, which supports the "dracut convention" (i.e. `boot=LABEL=` or `boot=UUID=`, etc.), exists; this is usually written by rdcore but is only available on subsequent boots If neither of those are specified, then we just default to `by-label/boot`. But currently, if multipath is enabled, we override all that and just always use `by-label/dm-mpath-boot`. This is not great, because a UUID might've been specified, and that's much stronger than a label. It also directly conflicts with the mentioned higher level goal of supporting multiple `boot` labels. Instead, rework multipath support so that it respects both `boot=` kargs and `bootfs_uuid` files. When possible, we use the multipathed version of the specified UUID/label written by our udev rules because it's less racy. Otherwise, we just use the non-multipathed one. (cherry picked from commit 33421b3)
9dba893 to
2aeea0c
Compare
|
/retest |
…` karg We want to be able to support the system having multiple filesystems present with the `root` and `boot` labels. This already mostly works today, because we add `root=UUID=` and `boot=UUID=` kargs which disambiguate them. The exception is multipath, where some places hardcode `/dev/disk/by-label/dm-mpath-[rb]oot` and so don't make use of the UUIDs at all. This obviously then becomes ambiguous in the presence of other similarly-labeled filesystems. The previous patch plugged a large gap in this story. Let's add a new test that covers the multipath + multiple boot disks + no root kargs to ensure this keeps functioning. Part of openshift/os#1787. (cherry picked from commit 0661e4e)
2aeea0c to
e4b223a
Compare
In the past we've just dropped all tests.
|
/ok-to-test |
|
I'm happy to merge this now, but if we're going to add the dracut patch should we just wait for that to land and include it in this PR so we don't have to bump the config in |
This is a new test and it's failing on s390x so let's deny it for now while we investigate. (cherry picked from commit 626c782)
This test is proving to be a bit flaky. Let's denylist it for now while we wait for an upstream fix [1]. [1] coreos/fedora-coreos-tracker#1937 (comment) (cherry picked from commit 4f3fce5)
I just added the denylist patches but maybe I misunderstood. So IIUC, you're preparing a patch to land on testing-devel, and then I'll cherry-pick in this PR, is that correct ? If so, I'm ok to wait. |
Waiting for #3508 to be merged, then I'll backport it in this PR |
Backporting #3475 to the rhcos-4.18 branch.
(cherry picked from commit 33421b36)
(cherry picked from commit 0661e4ed)