osbuild: use bootc install to deploy the container #4224
Conversation
|
Skipping CI for Draft Pull Request. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request introduces changes to use bootc install to deploy the container, which simplifies the image build process. There are a few critical issues in the YAML manifest related to copy-paste errors that lead to incorrect configurations for the 4k image builds and missing options for loopback devices. These issues need to be addressed.
|
I switched the CI on this to run against |
|
A few diffs picked up by We should probably profile each diff (maybe in coreos/fedora-coreos-tracker#1827) and evaluate whether it's a change we want to make or not. |
|
I can't get a built qemu image to boot. I suspect probably the root= and boot= UUIDs added on the kernel command line? |
do you mind sharing more logs ? What I am getting locally is ignition failing on coreos/fedora-coreos-tracker#1250 |
|
Ahh. I see that too now: |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
looks like removing those make the boot process go further (ignition completes), and out of the initramfs but fail to mount the boot partition. |
|
Blocked on bootc-dev/bootc#1441 |
|
ok this works with the following PRs :
for the bootc PR, it can be built then added into the image through |
jbtrystram
force-pushed
the
osbuild-bootc-install-fs
branch
from
59f1061 to
254f877
Compare
|
follow-up : either find a way to get the boot components inside cosa, or change the bootc code to call bootupd from the deployed root . I think the latter is preferable. |
Made bootc-dev/bootc#1460 |
jbtrystram
force-pushed
the
osbuild-bootc-install-fs
branch
4 times, most recently
from
bb4270f to
310bd60
Compare
|
Alright, marking this as ready for review as all the bits are in place. This will need a release of bootc. |
There was a problem hiding this comment.
Some comments.
I think there are a few things we need to iron out before we can really move forward with this:
- supporting both old and new paths at the same time
Do we need to? Usually when we make a change this large we roll it out slowly, which means we have to support both ways for some time.
This PR is ignoring that fact, but TBH looking at OSBuild configs that support both would be pretty intimidating, so I'm not excited about trying to do that either. I'd be interested in @jlebon or @travier's thoughts.
- We need to make sure any/every diff that exists between images generated this way and the old way are considered and acknowleged as acceptable before we'd make this change.
|
Thank you for your patience here JB. I don't see anything too alarming in the patch set here. Mostly small stuff. I do want to spend some time with this change testing it out locally and poking around the built images. I'll try to do so tomorrow. |
|
A couple of things:
|
Thank you so much for looking into this Dusty ! another set of eyes is really helpful. |
See #4224 (comment)
We'll have to re-add this symlink in a postprocess I guess. I can change stages/org.osbuild.ostree.aleph to have it take an argument that only does the symlink if the aleph already exist. Note that this aleph is generated by bootc and have different content than ours.
Looks like this is a leaked overlay mount, see this todo |
|
Added a commit that fixes the missing aleph file symlink. This also fixes the live artifact build Requires osbuild/osbuild#2226 |
The log disk usage message comming every 10 seconds is quite noisy, hide it when we are in a shell in osbuild. I aslo added a couple of helpful tips in comments given by @dustymabe to work with osbuild.
Bootc is looking for the prepare-root config file in the buildroot environnement because the main assumption is that it's run from the target container. However, in osbuild, it's run from te buildroot, because podman inside bwrap (inside supermin in our case) causes issues. It's fine for RHCOS and SCOS where we use the target container as the buildroot but we cannot do that for FCOS because we require python in the buildroot. For now, insert a prepare-root file in the supermin VM (use as the buildroot for osbuild) until either : - bootc learn to look into the container for it [1] - we ship python in our images and can use them as buildroot. Another approach would be to layer python and the osbuild dependencies on top of our image and use that as the buildroot, but that would create room for packages drift (what was in the repos at build time?). At least using COSA it's easier to keep track of versions. [1] bootc-dev/bootc#1410
jbtrystram
force-pushed
the
osbuild-bootc-install-fs
branch
from
bcb4d05 to
096dc64
Compare
|
@dustymabe : Rebased and updated. I included a manifest knob and a env var to make use of the bootc manifest.
It looks like those come from running
Do you know any code that rely on the output of |
OK i dug more on this and it's another instance of bootc-dev/bootc#1559 It would be nicer to have bootc actually chroot before calling bootupd, because it would have the added benefit to use the bootupd (and other) binaries that will ship on the image rather than what is in the buildroot. Another way would be to use our image as the buildroot, but once again, we don't ship python. |
this rpm provides locales under `/usr/share/locale`. grub2 install these files inside the /boot partition using what exist on the host. Mooving to bootc install results in an empty folder because those files don't exist in the buildroot, so add them. In the previous manifest we were using a chroot before calling bootupd which made sure bootupd (and by extension grub2) would pull content from the target root. It would be nicer to have bootc install also chroot before calling bootupd, it would have the added benefit to use the bootupd (and other) binaries that are shipped on the image rather than what is in the buildroot. Again, this is a complication coming from not having python in the image so we can't use ourselves as the buildroot, which would alleviate a lot of pain. See coreos#4224 (comment) And bootc-dev/bootc#1559
jbtrystram
force-pushed
the
osbuild-bootc-install-fs
branch
from
2b1ca62 to
fdadef3
Compare
this rpm provides locales under `/usr/share/locale`. grub2 install these files inside the /boot partition using what exist on the host. Mooving to bootc install results in an empty folder because those files don't exist in the buildroot, so add them. In the previous manifest we were using a chroot before calling bootupd which made sure bootupd (and by extension grub2) would pull content from the target root. It would be nicer to have bootc install also chroot before calling bootupd, it would have the added benefit to use the bootupd (and other) binaries that are shipped on the image rather than what is in the buildroot. Again, this is a complication coming from not having python in the image so we can't use ourselves as the buildroot, which would alleviate a lot of pain. See coreos#4224 (comment) And bootc-dev/bootc#1559
|
Ok I cleaned up the commits and addressed everything. |
Prep work to add a knob for using bootc install in osbuild. Refactor the override logic in a helper function so we can easily add those knobs down the line.
jbtrystram
force-pushed
the
osbuild-bootc-install-fs
branch
from
fdadef3 to
f672aff
Compare
this rpm provides locales under `/usr/share/locale`. grub2 install these files inside the /boot partition using what exist on the host. Mooving to bootc install results in an empty folder because those files don't exist in the buildroot, so add them. In the previous manifest we were using a chroot before calling bootupd which made sure bootupd (and by extension grub2) would pull content from the target root. It would be nicer to have bootc install also chroot before calling bootupd, it would have the added benefit to use the bootupd (and other) binaries that are shipped on the image rather than what is in the buildroot. Again, this is a complication coming from not having python in the image so we can't use ourselves as the buildroot, which would alleviate a lot of pain. See coreos#4224 (comment) And bootc-dev/bootc#1559
Instead of deploying the container to the tree then copy all the contents to the disk image, use bootc to directly manage the installation to the target filesystems. Right now this requires to use the image as the buildroot so this requires python (for osbuild). This is tracked in [1]. As we have python in rawhide now I duplicated the manifest and added a switch in the osbuild wrapper script. We can keep the manifest duplicated until we are confident to roll this to all streams. [1] bootc-dev/bootc#1410 Requires: bootc-dev/bootc#1460 bootc-dev/bootc#1451 osbuild/osbuild#2149 osbuild/osbuild#2152 All of which have landed in osbuild-159 and bootc 1.6
a few tests are failing, i'll look into it tomorrow |
|
Next up is bootc-dev/bootc#1710 ( we want to set |
Create symlinks to the aleph file created by bootc so our tests and tooling find the aleph at the expected path. Shipping the osbuild patches until [1] is merged. [1]: osbuild/osbuild#2226
this rpm provides locales under `/usr/share/locale`. grub2 install these files inside the /boot partition using what exist on the host. Mooving to bootc install results in an empty folder because those files don't exist in the buildroot, so add them. In the previous manifest we were using a chroot before calling bootupd which made sure bootupd (and by extension grub2) would pull content from the target root. It would be nicer to have bootc install also chroot before calling bootupd, it would have the added benefit to use the bootupd (and other) binaries that are shipped on the image rather than what is in the buildroot. Again, this is a complication coming from not having python in the image so we can't use ourselves as the buildroot, which would alleviate a lot of pain. See coreos#4224 (comment) And bootc-dev/bootc#1559
Properly label the filesystem mount points before calling bootc, otherwise `/sysroot` and `/boot` end up being `unlabeled_t`
jbtrystram
force-pushed
the
osbuild-bootc-install-fs
branch
from
f672aff to
01b2a13
Compare
|
Fixed the labels issue in the last commit |
|
Failing tests : Except From what I understand, during the boot, This does not happen in the non-bootc case because that |
This comment was marked as off-topic.
This comment was marked as off-topic.
alright I was able to work around this with the following changes in our initrd services in FCOS : I'll push a container and start the test suite |
|
hmmm ok 1 last test failure : |
4 participants
Instead of deploying the container to the tree then copy all the contents to the disk image, use bootc to directly manage the installation to the target filesystems.
Right now this requires to use the image as the buildroot so this requires python (for osbuild). This is tracked in [1].
[1] bootc-dev/bootc#1410 Requires osbuild/osbuild#2149