problems rolling back from F42 to F41
Hi,
So I decided to rollback from the F42 based bazzite because of problems with podman containers (https://github.com/ublue-os/bazzite/issues/2492)
However, doing the rollback I get the following error message:
GitHub
42.20250415: Stable breaks sudo inside of fedora containers · Issu...
Describe the bug So my development container (based on fedora-41) seems busted now in the F42 based bazzite. If I open a shell inside of that podman container and use sudo, I get a new error messag...
29 Replies
anyone have an idea for what to try next?
do you still have the 41 deployment? post rpm-ostree status -v
thanks for the reply! I haven't deleted any of my prior deployments on my machine.
kevinh@amdtop:~$ rpm-ostree status -v
State: busy
AutomaticUpdates: disabled
Transaction: rebase ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable-41.20250409.1
Initiator: client(id:cli dbus:1.311 unit:ptyxis-spawn-579aaac1-ccea-48a8-bae4-49cf2858446b.scope uid:1000)
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable (index: 0)
Digest: sha256:8d929716c9c5102f9b91fb830d21d5c3f9b6bfe0f63476722ff08a5a07c43276
Version: 42.20250414 (2025-04-15T22:09:44Z)
BaseCommit: 14c9a63e756079cc5d2c03875e54d64c24ac8783a9ac5826932158ca63c2c05a
Commit: db95e297a3bc5dd22c1042909cefbd108a7ef6b7a8feca389ced2c20ce30cf94
Staged: no
StateRoot: default
LayeredPackages: coolercontrol liquidctl msr-tools
ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable (index: 1)
Digest: sha256:8d929716c9c5102f9b91fb830d21d5c3f9b6bfe0f63476722ff08a5a07c43276
Version: 42.20250414 (2025-04-15T22:09:44Z)
BaseCommit: 14c9a63e756079cc5d2c03875e54d64c24ac8783a9ac5826932158ca63c2c05a
Commit: f5ee1ddf86c3e2ee79f3f4a6cd60cc827a09a2aac6f6a36fab31226803e20b9d
StateRoot: default
LayeredPackages: coolercontrol liquidctl msr-tools
you dont have a 41 image deployment anymore. as far as i understand you cant rollback or rebase to 41 from 42, most likely due to fedora 42 changes
hmm. bummer. the official announcement to try 42 says:
As always, if you find that you’d rather stay on Bazzite 41 for the time being you can roll back with rpm-ostree rollback.alas that rollback failed with the same error msg
true, but in my experiences i have never been able to go successfully go back from 42 to 41 via rebase or rollback. must boot into 41 from grub and remove the 42 deployment
i think this wasnt the case with 40->41 upgrade though
oh - so if I select an old 41 deployment from the grub menu (should still be there I think, right?) I can boot into that and then rebasing to 41.x flavors should work?
if this is all of the deployments you have ... then i think you're out of luck 🥲
oh strange. I was previously running 41 and just updated to 42 now (and it seems pretty fatally busted for developers)
(can't do sudo inside of child containers)
you could have applied a deployment changing command (rpm-ostree kargs or stuff) which deleted your unpinned 41 deployment
but if you didnt, im out of ideas honestly
oh thats it. so using ostree kargs discards old deployments? super bummer.
yeah it creates a new deployment
I guess I'll wait/hope that podman gets fixed. thanks for your help. using ostree kargs discarding all old deployments as a kinda hidden thing is a bummer.
i guess I'll read up on how to "pin" deployments so this doesn't happen in the future.
10 times i told kyle to test rollbacks
he didnt test rollbacks
at least this error is fixable
< the most important thing > 😕
he only did rpm-ostree rollback
we just need to add the f41 keys
for rpm fusion
try that and see if it works
its probalby the same key
it might also be a dark pattern problem. I doubt users are especteding using "rpm-ostree kargs" to set some kernel args to discard all non pinned deployments.
so you can do a copy
no this one is a bug with having rpm-fusion enabled and losing the previous key
oh thanks. i'll google to find out what rpm fusion is 😉
dont
fix is simple
cp /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-42 /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-41omg thats awesome thank you!
trying that now
find all the missing keys so we can symlink them
thanks - based on your ptr there was only one more. therefore the commands that just worked for me to rollback to the last f41 stable are:
^ to anyone else that needs to rollback to F41, these commands just worked yay! (also now that I'm back in F41 bluetooth works again and sudo works again inside of containers
you should probs post that on #🎮bazzite too if you havent
unles antheas alr did and my eyes cant see
alas - I spoke too soon. I rebooted after the rebase seemed to complete correctly. But after using it for a bit I realized I was in the same (somewhat busted) F42 based version. So I tried rpm-ostree status and saw something about "Finalizing deployment" had an error. details attached:
and the journalctl messages:
I guess the meat of the error is:
bwrap: execvp semodule: No such file or directory
Apr 17 17:41:59 amdtop ostree[9275]: error: Finalizing deployment: Finalizing SELinux policy: failed to run semodule: Child process exited with code 1
alas, I have to go out to a dinner now. i'll look at this again tomorrow (taipei time)
same here
I'm also having this issue, haha. The fix for rpmfusion works insofar as making the rebase appear to complete, but then on reboot it doesn't actually stage it and gives the same error above relating to the bwrap semodule.
Looks like it's not just us ubluers:
https://discussion.fedoraproject.org/t/fedora-silverblue-rawhide-cant-rebase-back-to-f41/142997
Fedora Discussion
Fedora Silverblue Rawhide can't rebase back to F41
As of Fedora Rawhide ~2024.01.18, I can’t rebase back to Fedora 41. I don’t have a Fedora 41 deployment to fix that. ❯ journalctl -b -1 -u ostree-finalize-staged.service Jan 21 13:11:15 abc123321bca systemd[1]: Finished ostree-finalize-staged.service - OSTree Finalize Staged Deployment. Jan 21 13:11:37 abc123321bca systemd[1]: Stopping os...
man - so crazy