initramfs inspection breaks using build containers

[supakeen]

When building with:

image-builder build qcow2 \
  --bootc-default-fs xfs \
  --bootc-build-ref quay.io/jbtrystramtestimages/cosa:latest \
  --bootc-ref quay.io/fedora/fedora-coreos:stable

The following error occurs:

WARNING: bootc support is experimental
Manifest generation step
Building manifest for bootc-based-qcow2
error: failed to run lsinitrd --mod --kver 6.18.8-200.fc43.x86_64: exit status 4, output:
Image: /boot/initramfs-6.18.8-200.fc43.x86_64.img: 35M
========================================================================
Version:
 
dracut modules:
========================================================================
 
stderr:
/usr/bin/lsinitrd: line 357: /boot/initramfs-6.18.8-200.fc43.x86_64.img: Permission denied
/usr/bin/lsinitrd: line 400: /boot/initramfs-6.18.8-200.fc43.x86_64.img: Permission denied
/usr/bin/lsinitrd: line 437: /boot/initramfs-6.18.8-200.fc43.x86_64.img: Permission denied
xzcat: /boot/initramfs-6.18.8-200.fc43.x86_64.img: Permission denied
xzcat: /boot/initramfs-6.18.8-200.fc43.x86_64.img: Permission denied

This is probably related to the introduction of initramfs inspection in: osbuild/images#2202

[supakeen]

This is failing because the default user in the build container is not root, it's builder, who doesn't have permissions to lsinitrd.

We can either:

1. Pass -u root.
2. Ignore lsinitrd failures as 'no modules enabled'.

I'm feeling like the second.

[supakeen]

As a workaround users can chmod their initramfs to something readable by their default user.

[achilleas-k]

We run lsinitrd as part of the container resolve info call right? And that's needed to init the build container, but we don't care about the build container's initrd mods.

I think it would make sense to separate the build container resolve call from the base one, maybe with a function arg or with a different function. We resolve quite a lot from the build container that we don't need already (default rootfs, os info, size). In fact, it seems we only really need to verify the architecture and get the image ID (I'll have to check the manifest to make sure). So a resolve call ResolveBasic() (or perhaps even the regular container resolver) would solve our issue.

[supakeen]

We run lsinitrd as part of the container resolve info call right? And that's needed to init the build container, but we don't care about the build container's initrd mods.

I think it would make sense to separate the build container resolve call from the base one, maybe with a function arg or with a different function. We resolve quite a lot from the build container that we don't need already (default rootfs, os info, size). In fact, it seems we only really need to verify the architecture and get the image ID (I'll have to check the manifest to make sure). So a resolve call ResolveBasic() (or perhaps even the regular container resolver) would solve our issue.

We could do that; and then wait until we hit the next case where the actual container contains a UKI, or doesn't contain dracut.

While a good idea to have a ResolveBasic/Minima (which I'll do a PR for) for the build container it will pop up again on an actual container; hence I feel like we should ignore any lsinitrd failures as 'no modules found'. This only affects the pxe-tar-xz image type as it's the only image type that tries to verify this; and it would still fail as it can't find modules in an empty list.

[achilleas-k]

We could do that; and then wait until we hit the next case where the actual container contains a UKI, or doesn't contain dracut.

Right now, lsinitrd is only run if kernel info is loaded:
https://github.com/osbuild/images/blob/7328a3efc2b79ed6a84bee5bdf18add18d07f13c/pkg/bootc/resolver.go#L186-L187

and the kernel info loader only logs an error when it fails:
https://github.com/osbuild/images/blob/7328a3efc2b79ed6a84bee5bdf18add18d07f13c/pkg/bib/osinfo/osinfo.go#L338-L341

which can happen if there's no usr/lib/modules or we can't find the kernel at the expected path:
https://github.com/osbuild/images/blob/7328a3efc2b79ed6a84bee5bdf18add18d07f13c/pkg/bib/osinfo/osinfo.go#L253-L284

I think for now those cases will be covered. But seeing this now, you're right, it's better if we don't fail when resolving if we don't find non-required info. We can produce errors later if the information is required for the image we're building and it was not found.

[supakeen]

Let's start with initially resolving much less for the build container and consider the general idea of inspecting containers to be informational only (and fail later, not during the inspection) with a few more people involved.