Bootc image does not boot on rpi

[say-paul]

Describe the bug
Raw image generated from bootc container using bib does not boot on raspberry pi.

To Reproduce

1. Containerfile

FROM quay.io/fedora/fedora-bootc:41-aarch64
RUN dnf install -y avahi i2c-tools && \
systemctl enable avahi-daemon

2. sudo podman build -t bib_image .

sudo podman run     --rm     -it     --privileged     \
--pull=newer     \
--security-opt label=type:unconfined_t     \
-v $(pwd)/output:/output     \
-v /var/lib/containers/storage:/var/lib/containers/storage     \
quay.io/centos-bootc/bootc-image-builder:latest     
--type raw --rootfs ext4    
--target-arch aarch64 bib_image

4. sudo xz -z -k -v disk.raw
5. Using arm-image-installer flash the disk.raw.xz into a SD card
6. Boot rpi with the flased sd card insterted.

Expected behavior
rpi should boot.

OS version:
fedora 41

[miabbott]

I would guess that installing a raw disk image generated by b-i-b using arm-image-installer has not been tested (or is supported).

I would suggest trying the bootc install-to-disk flow where you run the container image and target the SD card that you would use in the RPi - https://bootc-dev.github.io/bootc/bootc-install.html

[pcdubs]

The disk image generated by b-i-b does not include the Rpi firmware, uboot and has a GPT partition table.

[miabbott]

The disk image generated by b-i-b does not include the Rpi firmware, uboot and has a GPT partition table.

osbuild/bootc-image-builder#701

[say-paul]

The issue has inflated into a generic feature, that is to move the payload with bootupd especially around /boot and esp. This is in design discussion and some active PRs trying to solve the issue:
Discussion: coreos/bootupd#766
PR: coreos/bootupd#935
coreos/bootupd#938

[say-paul]

tracking issue in bootupd: coreos/bootupd#959

[say-paul]

with the PR: coreos/bootupd#935
which adds command: extend-payload-to-esp, I am am able to boot into rpi4 with bootc base image without(almost) any hack.

from the local branch build and install the rpi4 specific firmware using Containerfile:

ARG base=quay.io/fedora/fedora-bootc:42
FROM $base as build
RUN <<EORUN
set -xeuo pipefail
dnf -y install cargo git openssl-devel
EORUN
# Now copy the source
COPY . /build
WORKDIR /build
# See https://www.reddit.com/r/rust/comments/126xeyx/exploring_the_problem_of_faster_cargo_docker/
# We aren't using the full recommendations there, just the simple bits.
RUN --mount=type=cache,target=/build/target --mount=type=cache,target=/var/roothome \
    make && make install-all DESTDIR=/out

FROM $base
# Clean out the default to ensure we're using our updated content
RUN rpm -e bootupd
COPY --from=build /out/ /

RUN dnf install -y uboot-images-armv8  bcm2711-firmware
# stage uboot to to be installed to esp via bootupd install
RUN bootupctl backend extend-payload-to-esp /usr/share/uboot/rpi_arm64
# stage the devicetree and overlay to  be installed to esp via bootupd install
RUN bootupctl backend extend-payload-to-esp /boot/efi

Then building the image out the above container via b-i-b(which runs bootupd install in background) and flash into sd card.

Though there are still one manual thing that i have do to make it work.

1. Rename u-boot.bin to rpi-u-boot.bin ( from uboot-images-armv8)
   OR
2. change `kerenel=rpi-u-boot.binu-boot.bin in config.txt (bcm2711-firmware)

I dont know which rpm is easier to change but either one should be done to make the process smooth.
cc @nullr0ute

[nullr0ute]

1. Rename u-boot.bin to rpi-u-boot.bin ( from uboot-images-armv8)

That would require more special casing in the build process.

2. change `kerenel=~rpi-u-boot.bin~u-boot.bin in config.txt (bcm2711-firmware)

There's multiple u-boot.bin that could end up in the ESP depending on HW.

Neither of those are particularly great, I'll give it a think as none of the above dependencies are merged as yet.