Rolling back Silverblue to older release (without saved deployment)?

Project Discussion
1

I have started seeing big problems with Gnome Shell. When I switch focus between windows there are visual glitches, hanging, and certain programs (Emacs) sometimes crashes.

Now, regrettably I had time to do two ‘rpm-ostree upgrade’ without using my computer much in between, so didn’t notice this.

I currently have deployments for fedora:fedora/33/x86_64/silverblue of 33.20210228.0 and 33.20210301.0.

Is it possible to somehow roll back to Silverblue from an earlier date without having a saved deployment for it.

I would have thought I could supply it somehow with a refspec to rpm-ostree rebase, but can’t find anything like that.

2

Hello @bkhl ,
It is possible using ostree. I have done this in trying to troubleshoot some issues early in SB use for me. Please refer to this discussion here https://discussion.fedoraproject.org/t/how-to-find-previous-images-earlier-than-rpm-ostree-rollback-or-the-boot-screen-allow-you-to-access/1019/4. Good luck.

3

Thanks, with that pointer I was able to work out that I needed to do:

sudo ostree pull fedora:fedora/33/x86_64/silverblue --commit-metadata-only --depth=10

(pull commits for last few days)

Then

ostree log fedora:fedora/33/x86_64/silverblue

Which shows me some old commits including this:

commit 20965dea3bda6eb92b30de6a970361d9cf7bea04fe6abb58b405a027b34f3cf5
Parent:  715eda394e11a1c0f357027a885b9ed29efac3942f1846bb912298e898b0642e
ContentChecksum:  e47661b41ab3a932053534ad8486d28e16c8ccd07a6d86026c524f1b555490a5
Date:  2021-02-26 23:10:57 +0000
Version: 33.20210226.0
(no subject)

Which I can then roll back to using:

rpm-ostree deploy 20965dea3bda6eb92b30de6a970361d9cf7bea04fe6abb58b405a027b34f3cf5
12 Likes
4

I passed for this kind of situation too.

In these moments … man … I :heart: Silverblue!

5

Thanks a lot for this. Bluetooth seems to be completely borked in recent versions of Silverblue, with the last working version being 33.20210227.0 (65841d98bcb02e4ead77a1de9a57fdaac6d6a7d5dcb7c2483826dc0bfca1c593) from the 27th of February. This helped me roll back to the working version until it’s fixed. Seems a bit surprising to me though that it hasn’t already been fixed despite multiple Silverblue updates!

I have a question though. The steps involved pulling the last 10 commits. Do I need to do any kind of cleanup to get rid of all the stuff I pulled? Am I now wasting space in any way with unnecessary data?

1 Like