search

ublue-os / config

A layer to provide configuration files (udev rules, service units, etc)
https://universal-blue.org
Apache License 2.0
45 stars 28 forks source link

FR: `just system-upgrade` #258

Closed boredsquirrel closed 5 months ago

boredsquirrel commented 5 months ago

Afaik ostree native containers (OCI images?) do not have automatic update support. So users need to do this manually, which totally sucks. It is the one thing that prevents me from installing ublue on peoples PCs, and install normal rpm-ostree Fedora instead.

It is rather easy to get the exact source path. You need the json output of rpm-ostree status to get the URL.

$ rpm-ostree status --json | grep -o '"container-image-reference" : "[^"]*' | tail -1 | cut -d '/' -f 3-
ghcr.io/secureblue/kinoite-main-userns-hardened:39

This makes upgrading pretty easy, as it is exactly the output you need. You can cut between the : to get the source and the releasever. And then just add 1 to the releasever, and you have the upgrade!

OSPATH=$(rpm-ostree status --json | grep -o '"container-image-reference" : "[^"]*' | tail -1 | cut -d '/' -f 3- | cut -d ':' -f 1)
RELEASEVER=$(rpm-ostree status --json | grep -o '"container-image-reference" : "[^"]*' | tail -1 | cut -d '/' -f 3- | cut -d ':' -f 2)

rpm-ostree rebase ostree-image-signed:docker://$OSPATH:$(($RELEASEVER + 1))

I am using exactly these commands currently to upgrade.

Should we implement this? It sounds pretty cool, and then could be bundled with some mechanisms to resolve layering conflicts (missing package on new version, or other issues) or creating a backup pinned deployment

dependency: bash

boredsquirrel commented 5 months ago

also generally, should just have

castrojo commented 5 months ago

Sorry this is an issue with your custom image and not us. Our images come with automatic update support by using the proper tags.

If you end up on a numbered release it's because you've manually opted in to lock the image to that specific version for one reason or another.

boredsquirrel commented 5 months ago

so, the solution is to use rpm-ostree rebase ostree-image-signed:docker://ghcr.io/IMAGENAME:latest and this will ensure you always use the latest image.

castrojo commented 5 months ago

Yeah that'll work, just remember that those conventions are up to the org/person making the images, so you can't always depend on them being there.

skopeo list-tags docker://ghcr.io/ublue-os/bluefin

Will return the tags of that image.