coreos / coreos/bootupd

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

Open
#915 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
196
Forks
55
Avg merge
3d 2h
Merged PRs (30d)
14

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the failure with the provided Fedora 42 Containerfile and bootupctl backend -vvvvv generate-update-metadata -vvvvvvvv. Inspect src/cli/bootupd.rs, src/bios.rs, and src/efi.rs, especially filesystem operations inside generate_update_metadata(). Done means ENOENT failures identify the accessed path and filesystem activity provides enough trace context to locate the failing operation.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
operating-systems
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.