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