Hi. how many old fedora silverblue images (commits) are available for downgrade from the fedora mirrors when running
$ rpm-ostree deploy
Hi. how many old fedora silverblue images (commits) are available for downgrade from the fedora mirrors when running
$ rpm-ostree deploy
You can pull the full ostree commit log for a certain release from the remote repository with:
sudo ostree pull --commit-metadata-only --depth=-1 fedora fedora/41/x86_64/silverblue
I expect all the pulled commit logs are available to downgrade.
But instead of --depth=-1
I would go with --depth=10
and then increase the value incrementally if an even older commit is needed, since the former flag might take too much time.
I have two questions, how can I view the commits and how dangerous is it to deploy old commits? Example I just remembered, I have a problem with the new kernel, could I just take an old commit where the kernel is not yet updated?
but does that also mean that all old corresponding to the commits ostree images are available to download from the fedora mirrors?
You can view information about the pulled commits with:
ostree log fedora:fedora/41/x86_64/silverblue
Afterwards you can see what would be downgraded betweeen booted deployment and an old commit with:
rpm-ostree db diff <old-commit>
Do this compare until you find a kernel downgrade to the version you would consider is working for you.
No more dangerous than staying on older commits without upgrading. You would be missing security fixes that were pushed in the meantime.
An alternative would be to override the kernel with the command sudo rpm-ostree override replace <http or local file paths of kernel packages to be downgraded>
, e.g.:
sudo rpm-ostree override replace https://koji.fedoraproject.org/koji/buildinfo?buildID=2673955
You would need to reset the override when your fix has been landed in the repos with
sudo rpm-ostree override reset <kernel packages that have been overridden>
.
Yes, it seems so, which means there is some overhead in managing atomic desktops. Not sure about older, unsupported versions though.
Many thanks for the great explanation.
Do I have to enter all packages?
LocalOverrides: kernel-tools-libs kernel kernel-modules-extra python3-perf kernel-modules-core kernel-core kernel-modules kernel-tools 6.13.8-200.fc41 -> 6.13.5-200.fc41
Yes you do. Dependency solving might work as well, but better go according to the manual:
Currently, the full NEVRA of the target packages must be specified.