After rollbacks didn’t work on my computer with OpenSUSE Aeon, I distrohopped to Fedora Silverblue 41. When I tried to roll back this time copypasting commands from
https://docs.fedoraproject.org/fedora-silverblue/updates-upgrades-rollbacks/
, I selected the most recent snapshot available. However, when I restarted to apply the changes, this is what was displayed:
How would I be able to get out of this screen, and what can I do in the future to avoid this?
Hi and welcome to 
!
Can you boot into the deployment previous to the rollback (it should be the one with index 1)?
After login, please provide the output of the following commands:
rpm-ostree statuslsblk -fhistory (posting only the relevant few commands related to the rollback, starting with pulling the ostree commit log).Hello and thanks!
If booting into the deployment previous to the rollback means using rpm-ostree to roll back even further, then I cannot do so. I am getting an output saying ostree and rpm-ostree are commands not found.
No, I meant selecting the second GRUB entry when starting up the system. If GRUB is not presented when booting, it should be revealed by pressing Shift or Esc key.
Do you know if I’ll lose anything if I reboot? When I pressed control + D it warned me that not all disks have been found and that I might want to regenerate my initramfs
A reboot should’t cause any additional issues. You can avoid hard rebooting, by running the command sbin/reboot -f from the bash prompt instead.
Rebooted, here it is!
For rpm-ostree status:
fedora:fedora/41/x86_64/silverblue
Preformatted textVersion: 41.20250101.0 (2025-01-01T00:35:55Z)
Preformatted textBaseCommit: [random characters here]
Preformatted textGPGSignature: Valid signature [random characters here]
Diff: 29 upgraded
Preformatted textRemovedBasePackages: firefox firefox-langpacks 133.0.3-2.fc41
Preformatted textLayeredPackages: brace gnome-boxes mullvad-browser
Preformatted textLocalPackages: divested-release-20240607-1.noarch ente-1.7.7-1.x86_64
● fedora:fedora/41/x86_64/silverblue
Preformatted textVersion: 41.20241225.0 (2024-12-25T00:39:47Z)
Preformatted textBaseCommit: [random characters here]
Preformatted textGPGSignature: Valid signature [random characters here]
Preformatted textRemovedBasePackages: firefox firefox-langpacks 133.0.3-2.fc41
Preformatted textLayeredPackages: brace gnome-boxes mullvad-browser
Preformatted textLocalPackages: divested-release-20240607-1.noarch ente-1.7.7-1.x86_64
For lsblk -f:
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
│ Preformatted textvfat FAT32 ESP 1316-E446 3.9G 2% /boot/efi
├─sda2
│ Preformatted text ext4 1.0 [random characters here] 587.2M 33% /boot
└─sda3
│ Preformatted textcrypto 2 [random characters here]
└─luks- [random characters here]
Preformatted text btrfs fedora_fedora [random characters here] 1.8T 3% /var/home
/var
/sysroot/ostree/deploy/fedora/var
/usr
/etc
/
/sysroot
sr0
zram0
[SWAP]
For history:
208 ostree log fedora:fedora/41/x86_64/silverblue
209 rpm-ostree deploy 41.20250101.0
210 rpm-ostree status
211 lsblk -f
212 history
I’ve asked for the lsblk -f command in order to verify a match with the /dev/disk/by-uuid/3859... warning from the screenshot in the OP. This is not possible with redacted UUIDs. Which entry from the output does correspond to the UUID from the error message?
For better legibility, please edit your post and mark the different blocks of output as preformatted text with the </> button. Especially long lines of output benefit from such a formatting.
I am not sure why the rpm-ostree deploy command didn’t go well in your case. I have run a test for both a “future” deployment and a deployment “from the past”, and I could boot into either of those deployments. The difference is that my test system is not LUKS encrypted.
Besides, even though the documentation mentions that the new deployment “will not include overlayed packages and other changes”, this is not true anymore, as both layered packages and changes in /etc are included. So I am not sure what went wrong in your case.
To make sure the current (working) deployment is kept, you can pin it, so that it won’t be deleted by a new deployment. This is more of a backup measure, since previous deployments are only deleted after successful load of new deployments, so that one should never be in the situation of not having a bootable deployment. The command would be:
sudo ostree admin pin booted
Then you could try booting again into the other deployment, maybe it was just an isolated issue. Please note that you have deployed the last available commit, which is more or less the same as running rpm-ostree upgrade.
The UUID that corresponded was the one following btrfs fedora_fedora.
I made sure to pin the deployment, thanks!