How to find previous images earlier than rpm-ostree rollback or the boot screen allow you to access

ostree

#1

Awhile ago, after an upgrade on Silverblue of the ostree image, I had an issue where I had to create a new user to be able to use the image, just like it was a first time installation. I went with it largely because I couldn’t seem to avoid it, and I wanted to see if I could figure out what was the issue. Now I need to go back to that image and ‘rpm-ostree rollback’ will only go back one image, while 'rpm-ostree deploy ’ will work, ‘rpm-ostree status’ only shows the same two images. Since rpm-ostree is based upon ostree, more specifically the libostree, I figured ostree might help. So using ‘ostree refs’ I got a listing of my current installed refs that ostree “sees” on my system. In that list were three refs of interest to me ‘rpmostree/base/0’ ‘rpmostree/base/1’ and ‘rpmostree/base/2’, why because of their name only. The command ‘ostree show rpmostree/base/0’ showed me the version number I needed for the rpm-ostree deploy command in order to roll back to my image prior to the point I could get using the grub menu or rpm-ostree rollback. I had reasoned the earliest would be 0 and the latest would be 2, and I seem to be correct (with a caveat) so I am going to see if I can replicate my issue to detail. I wanted to share this so others who may be experiencing similar issues can at least have a starting point. The caveat to keep in mind I think is that when you redeploy an earlier image, that juggles the position of the other two in order precedence. So it is best to note the version of the most recent image you have installed using the ‘ostree show ref’ command above.
[Edit]: After successfully deploying the old image, I found it wasn’t far enough back in history to be able to repeat the original issue I had at this link https://pagure.io/teamsilverblue/issue/65. I began experimenting (guessing) with the version id and was able to successfully deploy an image from as far back as December 19, 2018. Still no success in repeating the steps to create the issue though.


#2

hey @jakfrost - i think something like this RFE would be what you are looking for: https://github.com/projectatomic/rpm-ostree/issues/1489


#3

Yes, That is pretty much exactly what I am looking for, something like what Git already has with how it handle commits. I was able to guess at actual references on my workstation and re-deploy them all the way back to December 19 2018 so far. If it didn’t exist (I guess that may mean I never had it) there were no references and a message like this would appear which also could mean the remote.


If I could find an image, I could deploy it like normal. I have gone through several image/upgrade cycles yesterday to try to replicate the issue I mentioned above with no success at failure. I am beginning to really think I need to roll back my podman an buildah to be as close to the same state the machine was in when the issue arose.


#4

Unfortunately rpm-ostree doesn’t parse version strings and associate them with commits. I think there is an RFE bug for that.

You’ll want something like this:

[dustymabe@hattop ~]$ sudo ostree pull fedora:fedora/29/x86_64/silverblue --commit-metadata-only --depth=5


GPG: Verification enabled, found 1 signature:

  Signature made Thu 24 Jan 2019 08:23:43 PM EST using RSA key ID A20AA56B429476B4
  Good signature from "Fedora 29 <fedora-29@fedoraproject.org>"


GPG: Verification enabled, found 1 signature:

  Signature made Wed 23 Jan 2019 09:03:08 PM EST using RSA key ID A20AA56B429476B4
  Good signature from "Fedora 29 <fedora-29@fedoraproject.org>"


GPG: Verification enabled, found 1 signature:

  Signature made Tue 22 Jan 2019 08:18:23 PM EST using RSA key ID A20AA56B429476B4
  Good signature from "Fedora 29 <fedora-29@fedoraproject.org>"


GPG: Verification enabled, found 1 signature:

  Signature made Mon 21 Jan 2019 07:54:39 PM EST using RSA key ID A20AA56B429476B4
  Good signature from "Fedora 29 <fedora-29@fedoraproject.org>"


GPG: Verification enabled, found 1 signature:

  Signature made Sun 20 Jan 2019 07:48:09 PM EST using RSA key ID A20AA56B429476B4
  Good signature from "Fedora 29 <fedora-29@fedoraproject.org>"


GPG: Verification enabled, found 1 signature:

  Signature made Sat 19 Jan 2019 07:52:19 PM EST using RSA key ID A20AA56B429476B4
  Good signature from "Fedora 29 <fedora-29@fedoraproject.org>"
6 metadata, 0 content objects fetched; 3 KiB transferred in 1 seconds                                                                                                                        
[dustymabe@hattop ~]$ sudo ostree log fedora:fedora/29/x86_64/silverblue
commit c30bd737662f94ff08e070dd73f7e803f790bc3ae0a07fd40ca8ae4ee456b327
ContentChecksum:  5fd75ef3347899cf0c626820a276615024b13311d0c5627ddf45f170f7abbb21
Date:  2019-01-25 01:23:32 +0000
Version: 29.20190125.0
(no subject)

commit a8b5679616474f4280ec45025066d4f971d16acf6835d49e1718dd305365eb62
ContentChecksum:  dc82246e71d7f8101c5bb4270707cd06713077cacfe36e232e8083cf5a5e86f0
Date:  2019-01-24 02:02:48 +0000
Version: 29.20190124.0
(no subject)

commit c44dbb8bed4e1e3b6a94c51749e96f9c6d4f5841a5179ef89ebd7472263ca93f
ContentChecksum:  4f31c7c40e89462105125859848c2f46ca9155c007d57b8c1f7b6282d7aa449d
Date:  2019-01-23 01:18:07 +0000
Version: 29.20190123.0
(no subject)

commit cc179340ed53393683ead798a381717512f09aa6ad050f9d479ffdd8c0664dc3
ContentChecksum:  139fc52579d116c036c3f2257ea52d39ebdf52e8bc2d52ab4551c91067218ee2
Date:  2019-01-22 00:54:25 +0000
Version: 29.20190122.0
(no subject)

commit b15eaaa5d007cb4307cbe9e7bcb868292609f5483fabfbac342ccd842ee2fe50
ContentChecksum:  98392c194a13acf70d6c032b2a58622599e8284b2b6b6ee3f620ff28e43f4272
Date:  2019-01-21 00:48:02 +0000
Version: 29.20190121.0
(no subject)

commit 60a9643b331204d7a0d04aa2826e34416cb31ccd901c667752dcdd65ba49e49d
ContentChecksum:  607752f1345ee5445a7ab092956975b9e248e73fd982244ec07424ab5a1b5597
Date:  2019-01-20 00:52:12 +0000
Version: 29.20190120.0
(no subject)

<< History beyond this commit not fetched >>

Note that my remote is named fedora and the ref I’m pulling is fedora/29/x86_64/silverblue. They combine to make fedora:fedora/29/x86_64/silverblue.

Feel free to change depth to a higher value or -1 to grab all commit metadata for the history of the ref.


#5

Thank you @dustymabe for responding on this, very cool!