Repository navigation
ci: Regenerate the initramfs after installing bootc from copr - #2
cgwalters-bot wants to merge 4 commits into
Conversation
cgwalters-bot
left a comment
cgwalters-bot
left a comment
There was a problem hiding this comment.
Review guide for head e41a5ba99c: where to look closely and what is safe to skim. It is advice from the bot's reviewer and doesn't replace reading the diff; the review app walks it.
Two-line CI fix: after installing bootc from copr in the Dockerfile used by the bootc-e2e jobs, regenerate the initramfs so bootc-root-setup.service in the initrd matches the installed bootc (current bootc writes only composefs.digest=, which the 1.16.13 initramfs in centos-bootc:stream10 ignores). The dracut invocation matches the pattern in bootc docs (kver from /usr/lib/modules, output to /usr/lib/modules/KVER/initramfs.img); hostonly=no comes from the base image dracut.conf.d, so no extra flags are needed. Dockerfile.bls does not use the copr and is unaffected. Low risk; the only cost is an extra dracut run in every stream9/stream10/Fedora build of this Dockerfile.
Hotspots
- note · logic —
Dockerfile:39-40(e41a5ba): Assumes exactly one kernel dir under /usr/lib/modules (true for bootc base images, and bootc container lint enforces it). Runs unconditionally, including on Fedora bases where no copr bootc is installed; harmless but slower.
We have cases where `grub2/grub.cfg -> ../loader/grub.cfg` and since we moved to cap-std APIs, the metadata gathering for the file fails since the target leads to outside the filesystem (which is the directory `grub2` in this case). To fix, use `std::fs` APIs to get metadata Use `GRUBCONFIG_FILE_MODE` constant instead of raw 0600 mode Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
bootc 1.16.14 (in copr) uses composefs.digest= cmdline, but since we don't rebuild the initramfs, we never include that digest as a condition for bootc-initramfs-setup to run which fails the VM startup Disable C10S tests for composefs, for now Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
grubcfg: Handle symlink that lead outside of `grub2`
|
Your approval was seen both times, and nothing happened because coreos/bootupd is on the human-text list: for those repos the bot does not open the upstream PR with its own title, description or commit messages. Approval alone is not enough there; it waits for you to edit the title, body and commit messages into your own words and then comment The bug is that the bot never said so here. Tracked in cgwalters-forge/tracker#388. Generated-by: https://github.com/cgwalters/#llms |
|
Correction to the above: your answer on tracker#245 (accept means post as the bot, upstream LLM rules advisory) makes the Generated-by: https://github.com/cgwalters/#llms |
The operator approved cgwalters-forge/bootupd#2 twice and saw nothing happen: coreos/bootupd is human-text, so the approval could not promote, but that was only said in the sweep's watch.txt, which they don't read. Eleven fork PRs are in that state. So with --apply, an approved fork PR that isn't promoted now gets one comment with the reason and their next step, and the same in its board item's News. The comment is keyed by approval, head and reason: a sweep with nothing new stays quiet, while approving again without fixing the cause is answered again rather than met with the same silence. A head that moved since the approval, which was not listed at all before, is said once per approval however often the head moves after it. A human-text PR approved with '/promote --human-text' was listed for a promote "by hand", which in practice meant a model running the command. The sweep runs it now: bot-pr promote is what checks that the text is theirs, and it refuses as before when it isn't. A refused head is also retried at once on a new approval instead of only after 6h, since "fix it and /promote again" is the next step the comment gives. Forge PRs are in the bot's own org, so none of this text goes upstream. Generated-by: AI
The operator approved cgwalters-forge/bootupd#2 twice and saw nothing happen: coreos/bootupd is human-text, so the approval could not promote, but that was only said in the sweep's watch.txt, which they don't read. Eleven fork PRs are in that state. So with --apply, an approved fork PR that isn't promoted now gets one comment with the reason and their next step, and the same in its board item's News. The comment is keyed by approval, head and reason: a sweep with nothing new stays quiet, while approving again without fixing the cause is answered again rather than met with the same silence. A head that moved since the approval, which was not listed at all before, is said once per approval however often the head moves after it. A human-text PR approved with '/promote --human-text' was listed for a promote "by hand", which in practice meant a model running the command. The sweep runs it now: bot-pr promote is what checks that the text is theirs, and it refuses as before when it isn't. A refused head is also retried at once on a new approval instead of only after 6h, since "fix it and /promote again" is the next step the comment gives. Forge PRs are in the bot's own org, so none of this text goes upstream. Generated-by: AI
The operator approved cgwalters-forge/bootupd#2 twice and saw nothing happen: coreos/bootupd is human-text, so the approval could not promote, but that was only said in the sweep's watch.txt, which they don't read. Eleven fork PRs are in that state. So with --apply, an approved fork PR that isn't promoted now gets one comment with the reason and their next step, and the same in its board item's News. The comment is keyed by approval, head and reason: a sweep with nothing new stays quiet, while approving again without fixing the cause is answered again rather than met with the same silence. A head that moved since the approval, which was not listed at all before, is said once per approval however often the head moves after it. A human-text PR approved with '/promote --human-text' was listed for a promote "by hand", which in practice meant a model running the command. The sweep runs it now: bot-pr promote is what checks that the text is theirs, and it refuses as before when it isn't. A refused head is also retried at once on a new approval instead of only after 6h, since "fix it and /promote again" is the next step the comment gives. Forge PRs are in the bot's own org, so none of this text goes upstream. Generated-by: AI
The operator approved cgwalters-forge/bootupd#2 twice and saw nothing happen: coreos/bootupd is human-text, so the approval could not promote, but that was only said in the sweep's watch.txt, which they don't read. Eleven fork PRs are in that state. So with --apply, an approved fork PR that isn't promoted now gets one comment with the reason and their next step, and the same in its board item's News. The comment is keyed by approval, head and reason: a sweep with nothing new stays quiet, while approving again without fixing the cause is answered again rather than met with the same silence. A head that moved since the approval, which was not listed at all before, is said once per approval however often the head moves after it. A human-text PR approved with '/promote --human-text' was listed for a promote "by hand", which in practice meant a model running the command. The sweep runs it now: bot-pr promote is what checks that the text is theirs, and it refuses as before when it isn't. A refused head is also retried at once on a new approval instead of only after 6h, since "fix it and /promote again" is the next step the comment gives. Forge PRs are in the bot's own org, so none of this text goes upstream. Generated-by: AI
The operator approved cgwalters-forge/bootupd#2 twice and saw nothing happen: coreos/bootupd is human-text, so the approval could not promote, but that was only said in the sweep's watch.txt, which they don't read. Eleven fork PRs are in that state. So with --apply, an approved fork PR that isn't promoted now gets one comment with the reason and their next step, and the same in its board item's News. The comment is keyed by approval, head and reason: a sweep with nothing new stays quiet, while approving again without fixing the cause is answered again rather than met with the same silence. A head that moved since the approval, which was not listed at all before, is said once per approval however often the head moves after it. A human-text PR approved with '/promote --human-text' was listed for a promote "by hand", which in practice meant a model running the command. The sweep runs it now: bot-pr promote is what checks that the text is theirs, and it refuses as before when it isn't. A refused head is also retried at once on a new approval instead of only after 6h, since "fix it and /promote again" is the next step the comment gives. Forge PRs are in the bot's own org, so none of this text goes upstream. Generated-by: AI
|
Not promoted: coreos/bootupd is human-text, so the title, body and commit messages sent there must be yours. Next: edit this PR's title and body (dropping the Generated-by: https://github.com/cgwalters/#llms |
|
Upstream LLM rules (advisory): coreos/bootupd's contribution policy record says human-text: code by the bot is fine, but the PR title and body, commit messages and comments must be cgwalters' own, except an answer on a thread where cgwalters summoned the bot. AI trailer: default (Generated-by: AI); nothing written, and precedent on main is Assisted-by (2 of the last 100 commits). The text sent there must be yours; the next comment says how. Record: Generated-by: https://github.com/cgwalters/#llms |
|
Upstream LLM rules (advisory): coreos/bootupd's contribution policy record says bot-ok: the bot may write the code and the text, with the AI trailer. AI trailer: default (Generated-by: AI); nothing written, and precedent on main is Assisted-by (2 of the last 100 commits). Nothing here holds this PR back: the bot promotes it now. Record: Generated-by: https://github.com/cgwalters/#llms |
The CI image replaces the base image's bootc with a newer build from copr but keeps the base image's initramfs, which bootc doesn't support. It broke the stream10 composefs UEFI boot test once bootc started writing only composefs.digest= in BLS entries: the bootc 1.16.13 initramfs in centos-bootc:stream10 only starts bootc-root-setup.service with a composefs= karg, so switch-root fails. Generated-by: AI
e41a5ba to
35948c7
Compare
|
Opened upstream as coreos#1168. Closing this review draft. |
3 participants
The CI image installs bootc from copr on top of centos-bootc but keeps the base image's initramfs. Current bootc writes only
composefs.digest=in BLS entries, while the bootc 1.16.13 initramfs incentos-bootc:stream10only startsbootc-root-setup.servicewith acomposefskarg, so the composefs UEFI boot test ends in emergency mode (job). A newer bootc with an older initramfs isn't supported, so this regenerates the initramfs after installing bootc.Tested on a 16-core RHEL 10 devspace, with the stream10 image built from
Dockerfile(copr bootc 202609261137.g83d1589142) and rootless equivalents of thebootc-e2esteps (bcvk to-disk --filesystem ext4in place of the privilegedbootc install to-disk --via-loopback, then the same OVMF QEMU boot asscripts/test-uefi-vm-boot.sh):ConditionKernelCommandLine=|composefs.digest(before: only=composefs).login:with this change; on main it fails with "Failed to start initrd-switch-root.service" and enters emergency mode.login:with this change.tests/tests/bootupctl-status-in-bootc.shand the build'sbootc container lint --fatal-warningspass.Not run: the stream9, aarch64 and grubcc=1 (Fedora,
Dockerfile.bls, which doesn't use the copr) variants, and the BIOS boot test.Generated-by: https://github.com/cgwalters/#llms
Review draft in cgwalters-forge, not upstream yet. This section is removed when the PR is opened upstream.
coreos/bootupd, basemainPVTI_lADOE9oHIs4BlJLczg9kEvUTo review:
/promoteon a line of its own, to open it upstream, ready for review. Either covers only the commits pushed so far.Signed-off-by: Colin Walters <walters@verbum.org>to the commits lacking it (the bot's and yours; anyone else's only if you ask), with you as committer./draftline (in the same comment or before) to open it upstream as a draft (/readyundoes that).