how to workaround rpm dependency?

[akdev1l]

Hi bootupd team,

I love the idea behind bootc so I've been trying to create a bootc image based on archlinux.

As part of creating a bootc image bootupd backend generate-metadata is called but this fails on arch linux as there is not rpm binary.

Is there a way I can work around this dependency? I am happy to hack around this in my image as it is just a proof of concept but not sure what to do

Also the readme suggest bootupd should be OS agnostic but looking for rpm means it is not really agnostic :-( are there plans to remove this dependency?

[cgwalters]

Absolutely, we can support other backends here in bootupd. It should be relatively straightforward to do. Do you know any Rust?

[akdev1l]

I know a little bit of rust, I can probably try and get it working on arch linux if you can provide some guidance on:

1. what is bootupd expecting from the package manager?
2. what is the purpose of the metadata being generated?
3. how does it relate to the grub configuration?

we were able to hack around this dependency by reusing generated files from fedora but naturally the resulting image couldn't boot (I think because the metadata pointed to Fedora-specific grub configuration?)

[cgwalters]

We basically just need version information. I think instead of hardcoding knowledge of rpm in bootupd, we could try having an external script that can be provided by the OS output it?

[symbioquine]

@cgwalters I'm curious about this too. Can you provide a bit more detail about what you mean when you say "We basically just need version information"?

Specifically, what I'm wondering is what it would take to boot existing container images (say Arch Linux) without any of the package layering stuff? I don't mind needing to build a custom image in order to install things. It looks like someone has actually already been trying to get that working. Maybe you can comment about whether that would be expected to work?

[BoukeHaarsma23]

@cgwalters is there any way I can help here? Can you give me some pointers on what needs to be done?

[cgwalters]

I was poking again at this; looking specifically at Debian for example, it looks like the deb already in /usr: /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi.

So this one then also relates a lot to #766 in that we should potentially just be able to take over or move what happens in the maintainer scripts? I am not finding offhand how that happens, I see at least

cat /var/lib/dpkg/info/grub-efi-amd64-signed.postinst 
#! /bin/sh
set -e

. /usr/share/debconf/confmodule

case $1 in
    configure)
	target=x86_64-efi
	# Check /boot/grub to see if we previously installed to an ESP. We don't
	# want to trigger the install code just by installing the package,
	# normally the installer installs grub itself first.
	if test -e /boot/grub/$target/core.efi; then
	    if [ -x /usr/share/grub/grub-check-signatures ]; then
		    /usr/share/grub/grub-check-signatures
	    fi
	    if [ -x /usr/lib/grub/grub-multi-install ]; then
		    /usr/lib/grub/grub-multi-install --target=$target
	    elif grub-install --help | grep -q 'auto-nvram'; then
		    grub-install --target=$target --auto-nvram
	    else
		    grub-install --target=$target
	    fi
	fi

	;;
esac



exit 0

But I don't think that's it, since I think the configure phase only runs once? Needs investigation.

[cgwalters]

OK and openSUSE is the same - grub is already in /usr, and they have a /sbin/update-bootloader program (in Perl 😢 ) - looks like the source is https://github.com/openSUSE/perl-bootloader

[frap129]

Hello! I've been working on getting bootc working with archlinux, and found this issue linked from containers/bootc#865. I'd like to help contribute to getting bootupd working on archlinux as well, to simplify installing a bootc based system.

The main issue with bringing bootupd support to archlinux is how the package version and build time are requested. Correct me if I'm wrong, but as far as I can tell, bootupd looks for files in /usr/lib/bootupd/updates/<arch>, replaces the prefix with /boot/efi/EFI/, and queries rpm for info about the package that owns them. This is problematic in two ways for archlinux:

1. The grub and shim packages do not install files to the efi parition. For grub, it is up to the user to use grub-install to install grub, and copy shimx64.efi to the right location to install shim.
2. archlinux does not have a standard esp mount point. If installing the kernel and initram to the efi partition, it would be /boot, making the efi directory /boot and not /boot/efi. For installations using separate esp and boot partitions, the arch wiki suggests /efi.

I'm fine with requiring that the efi mount point for bootupd compatible be /boot/efi, and I can work on a modified grub package that installs grubx64.efi to /boot/efi/EFI/arch. I'm by no means a "rust developer", I know enough of the language that I could modify bootupd to call pacman instead of rpm, but would need some guidance on handling the abstraction to account for both package managers.

A few questions I would like answered before I work on this:

1. Is there an intent to change how bootupd queries package versions? I see that debian installs grub to /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi, which also would not be covered by bootupd currently.
2. Does bootupd require shim? In the bootupd code, I found that shimx64.efi seems to be used to determine the efi vendor, but that call path doesn't seem to throw any fatal errors if its None. I personally do not use it on archlinux, as I use sbctl to sign my kernel and bootloader locally.
3. Is there interest in supporting archlinux? Compared to RHEL/Fedora/Debian, archlinux leaves a lot of the decisions and responsibility for system management to the user. Making these assumptions and hacking in pacman support that depends on a specific setup may not make sense for bootupd as a project.

I should also note that I am in no way affiliated with the archlinux project, I'm just interested in bootc for personal use.

[yjftsjthsd-g]

Curiously, as of my attempt to build an Arch+bootc VM today (full writeup: https://brianecole.com/blog/2025-03-27_bootc-movingarch.html ), we've switched from an "rpm" dependency to

[-] Manifest generation step
Message: Generating manifest manifest-qcow2.json
2025/03/27 22:53:27 error: cannot build manifest: initializing dnf in 349dc08b74e9b50c9a5af43d1c28a49bafffeb1a622977babf01026e4ba57318 container failed: exit status 127
output:
Error: crun: executable file `dnf` not found in $PATH: No such file or directory: OCI runtime attempted to invoke a command that was not found

Perhaps it's because I'm not a developer, but I can't tell from reading along - why does it care about the package manager at all? What version information does it need that isn't in /etc/os-release?

EDIT: It has since been pointed out to me that https://github.com/osbuild/bootc-image-builder is a separate project, so this may actually not be relevant to this thread.

[bigpod98]

I have no idea how bootc image builser works but it might be trying to either install something or find version of a package like grub

Which is what i saw with bootupd when this was posted(me and poster were working at same time sharing notes) bootupd triea to find version of grub whuch is something that wouldnt be in /etc/os-release

[cgwalters]

Is there an intent to change how bootupd queries package versions? I see that debian installs grub to /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi, which also would not be covered by bootupd currently.

Yes. Part of bootupd is really working around the fact that Fedora (only?) installs grub to /boot and doesn't have a direct install script. There's work to rectify that finally.

Does bootupd require shim?

It doesn't need to conceptually, no.

Is there interest in supporting archlinux?

Yes definitely.

could modify bootupd to call pacman instead of rpm, but would need some guidance on handling the abstraction to account for both package managers.

I think my strawman here is we should move the rpm-querying thing out into a helper binary and not be in Rust. Something similar was done in e.g. bootc-dev/bootc#1105 (comment)

[travier]

There is work in progress to move the binaries out of /boot into versioned folders in /usr. With that change, we would no longer need to rely on RPM to query the version in the image, it would be directly part of the path.

See:

• https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1
• https://src.fedoraproject.org/rpms/shim/pull-request/4
• https://src.fedoraproject.org/rpms/grub2/pull-request/140

[travier]

See also the discussion in https://gitlab.com/fedora/bootc/tracker/-/issues/61