`bootc backend generate-update-metadata` returns ENOENT inside container

[korewaChino]

I'm trying to experiment with creating a bootc and bootupd compatible container image standalone with DNF (no layering from bootc base images nor bootstrapping from rpm-ostree), however when I try to run bootc backend generate-update-metadata so bootc can install bootupd properly, it fails with:

[TRACE bootupd] executing cli
total 24336
drwxr-xr-x. 1 root root       88 Apr 21 06:48 .
drwxr-xr-x. 1 root root       20 Apr 21 06:48 ..
-rw-r--r--. 1 root root        0 Apr 21 06:48 .rpm.lock
-rw-r--r--. 1 root root 24821760 Apr 21 10:47 rpmdb.sqlite
-rw-r--r--. 1 root root    98304 Apr 21 10:46 rpmdb.sqlite-shm
-rw-r--r--. 1 root root        0 Apr 21 10:47 rpmdb.sqlite-wal
[src/ostreeutil.rs:61:9] "found" = "found"
[src/ostreeutil.rs:61:9] &arg = "--dbpath=/usr/lib/sysimage/rpm"
[DEBUG bootupd::ostreeutil] Using dbpath "--dbpath=/usr/lib/sysimage/rpm"
Generated update layout for BIOS: grub2-tools-1:2.12-28.fc42.x86_64
[DEBUG bootupd::efi] Unmounting
error: generating metadata failed: No such file or directory (os error 2)

The logger seems to not log enough data to point exact file paths (preferrably at TRACE level) to say which files are being accessed, so this might be more of an issue in the long run.

Looking at the code, the top-level call to generate_update_metadata() is wrapped with .context("generating metadata failed"), but deeper filesystem operations inside that call (e.g. file reads/writes or directory accesses) aren't consistently wrapped with .context() to include path details. As a result, when something like an ENOENT occurs, the error bubble-up loses valuable context, especially the actual file path being accessed.

Also, here's my Containerfile:

FROM fedora:42

RUN --mount=type=cache,target=/var/cache/dnf \
 dnf install -y \
    ostree \
    bootc \
    kernel \
    dracut \
    dracut-live \
    e2fsprogs \
    dosfstools \
    btrfs-progs \
    xfsprogs \
    bootupd \
    grub2 \
    grub2-common \
    grub2-efi \
    shim \
    grub2-efi-x64 \
    grub2-efi-x64-modules \
    grub2-pc-modules \
    grub2-tools-efi \
    grub2-tools
RUN mkdir -p /usr/lib/bootupd/updates
RUN bootupctl backend -vvvvv generate-update-metadata -vvvvvvvv
COPY prepare-root.conf /usr/lib/ostree/prepare-root.conf
LABEL containers.bootc=1

[HuijingHei]

Thanks for the report!
I am not quite sure to catch your meaning, IMU, you can not install kerenl on normal fedora container, but agree that we should do improvement on bootupd to get clear output for the error.