-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
denylist: add snooze for multipath.partition #3291
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…service Fedora 40 during early startup (initramfs) mounts rootfs as read-only, so systemd-generators fail to modify it: ``` Welcome to Fedora CoreOS 40.20240524.dev.0 dracut-101-1.fc40 (Initramfs)! [ 1.857142] systemd[1]: No hostname configured, using default hostname. [ 1.857175] systemd[1]: Hostname set to <localhost>. [ 1.857230] systemd[1]: Initializing machine ID from random generator. [ 2.010194] systemd[1]: bpf-lsm: LSM BPF program attached [ 2.014388] ln: [ 2.014407] failed to create symbolic link '/var/log' [ 2.014414] : Read-only file system [ 2.014415] [ 2.038544] cp: [ 2.038553] cannot create regular file '/usr/lib/ignition/base.d/01-secex.ign' ``` This moves all config related logic to one place.
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325
Triggered by remove-graduated-overrides GitHub Action.
This should probably be in the branching steps for RHCOS.
It's dead code.
A big part of the new variants added in openshift/os#1445 is that we only minimally modify `/etc/os-release`. This means that e.g. `ID` is still `rhel` and `VERSION_ID` is e.g. `9.4` for the `rhel-9.4` variant. We do still inject `VARIANT` and `VARIANT_ID` though. Adapt these library functions here to handle this.
systemd v256 now runs the initrd with `ProtectSystem=yes`, which makes `/usr` read-only: https://github.com/systemd/systemd/blob/07748c53df5a72111d8b3eef49d275210d6018cd/NEWS#L168-L175 This breaks coreos-ignition-setup-user which wants to copy the Ignition config to `/usr/lib/ignition`. I think the right fix for this is to have Ignition learn to also source from `/etc` and `/run`, which is the standard nowadays: coreos/ignition#1891 But for now at least, we can safely remount `/usr` read-write ourselves without affecting the rest of the system since we're already running with `MountFlags=slave`.
No functional change. Prep for next patch.
On 512e disks, `sfdisk` (which is used by `growpart`) will end up growing the rootfs to a size not aligned to a 4K boundary. This is mostly fine because, well, the drive claims to be 512b-compatible. Issues arise however if one wants to also put LUKS on top: cryptsetup, trying to optimize performance, wants to set the sector size of the LUKS device to that of the physical value, which is 4K. But if the partition range itself isn't 4K-aligned, it will choke. Ideally, this should be fixed in sfdisk: util-linux/util-linux#2140 (Though cryptsetup could also learn to align the mapped area itself). Anyway, for now work aorund this by manually checking if the size of the partition is a multiple of 4k. If not, and the physical sector size is 4k, then trim off the edge of the partition to make it so. Note the partition start is always going to be aligned (they're 1M-aligned). Closes: coreos/fedora-coreos-tracker#1384 Closes: https://issues.redhat.com/browse/OCPBUGS-35410 See also: https://gitlab.com/cryptsetup/cryptsetup/-/issues/585
This test is still failing. Let's snooze again while we wait for coreos/afterburn#1074 to land.
Looks like kexec-tools is not compatible with kernel 6.9, add the test to denylist and snooze it for a couple of weeks. Tracking issue: coreos/fedora-coreos-tracker#1750 See rhkdump/kdump-utils#15
Triggered by remove-graduated-overrides GitHub Action.
Split all the things redundant with tier-x into a separate manifest that only gets inherited on <f42.
No functional change. This just makes it easier to share the list of dupes with RHCOS downstream.
This workflow bumps the fedora-bootc submodule. It's better than just using Dependabot because it only checks for changes in tier-0 and tier-x. AFAICT, there isn't a way to tell Dependabot to do this.
Currently, when building the squashfs, we drop the `sysroot.readonly` flag from the ostree config because `ostree-prepare-root` doesn't know how to handle it in the setup we have in our live environments. But now inheriting from tier-x, we also inherited the move of that knob to `/usr/lib/ostree/prepare-root.conf`, which is then included in the initramfs. That's much harder to override during the build process because we don't want to rebuild the initramfs. We could probably instead just append a CPIO to the live initramfs that shadows it but the real fix anyway is to adapt libostree to work in live environments.[^1] So for now, just undo this bit to go back to how it was set up before inheriting from tier-x, where the only sysroot.readonly knob lives in the ostree repo config. [^1]: ostreedev/ostree#1921
The `overrides.py` script needs to call `rpm-ostree compose tree --print-only`, and rpm-ostree will want to recurse into tier-x treefiles, so we need submodules here.
Triggered by remove-graduated-overrides GitHub Action.
Now that cosa supports looking at the `metadata` key, let's finally stop abusing the `rojig` key.
Aashish Radhakrishnan (1): Add crun to tier-x manifest
Since we dropped runvm_with_cache_snapshot this now fails. Let's make a similar change here as what we did in coreos/coreos-assembler#3970
multipath.partition fails after the recent kernel upgrade. See: coreos/fedora-coreos-tracker#1840
Triggered by remove-graduated-overrides GitHub Action.
Prefix our dracut configs with "60". This allow for other configs such as kdump to override ours if necessary. This will allow for the kdump initramfs to not ship our modules (e.g. ignition) making kdump initramfs smaller. Fixes coreos/fedora-coreos-tracker#1837
The multipath.partition test has been failing with the latest kernel version 6.13.0-0.rc0.20241119git158f238aa69d.2.fc42. Let us snooze this test for a month till January 6, 2025. Ref: coreos/fedora-coreos-tracker#1840
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The multipath.partition test has been failing with the latest kernel version
6.13.0-0.rc0.20241119git158f238aa69d.2.fc42
. Let us snooze this test for a month till January 6, 2025.Ref: coreos/fedora-coreos-tracker#1840