Consider an rpm-ostree history command
#1489
Comments
|
/me likey |
|
This could also allow us to track down more complicated upgrade path bugs |
|
I am planning to switch from normal Fedora to Silverblue and this would help a lot in keeping track of what happened to my laptop. |
|
Some of this is already in the journal. |
|
So, I started hacking on this with the idea of keeping it all in the journal. Basically, enhance the upgrader to write a structured msg to the journal when we create a new deployment and then enhance The main advantage of this approach is that we don't have to maintain our own db/logs on the side. It also gives us history basically for free, i.e. without needing for an enabled systemd service on boot to mark in the db when a deployment was booted into (not to mention doing it from the initramfs means we still notice boots even if they didn't boot successfully all the way). One downside though is that we're limited to what we can dump in the journal. E.g. one thought I had initially was just to keep the whole commit object around since that contains the pkglist, overlays, overrides, etc... With the journal approach, we'd have to find a good balance on what to include. |
Not all users of libdnf really need the functionality added by the SWDB database. This is especially true for rpm-ostree-based variants of Fedora and RHEL, which only use libdnf for composing on the server and package layering on the client. Some major differences that render the SWDB not useful for rpm-ostree: - rpm-ostree already keeps track of requested packages in a separate database (really, text file). - rpm-ostree always applies package installs from scratch on top of the base OSTree, so the concept of history is simply different (see e.g. coreos/rpm-ostree#1489). - rpm-ostree updates are performed offline, i.e. not on the live system. As such, we don't need to track the state of the RPM transaction as it happens in a separate database. If librpm throws an error, we just throw out the whole offline rootfs. - OSTree commits themselves already contain the list of packages that were installed in them, so that we can consult the commit metadata (or even the rpmdb directly) if we need to render the RPM diff on a system or OSTree branch.
|
Some related discussions in coreos/fedora-coreos-tracker#170. |
|
PR in #1813. |
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: coreos#1489
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: coreos#1489
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: coreos#1489
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: coreos#1489
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: coreos#1489
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: #1489 Closes: #1813 Approved by: cgwalters
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: #1489 Closes: #1813 Approved by: cgwalters
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: #1489 Closes: #1813 Approved by: cgwalters
This is the rpm-ostree equivalent of `dnf history`. As opposed to the history of the refspec (i.e. `ostree log`), this shows the history of the system, i.e. the refspecs the host deployed, checksums, versions, layered packages, etc... The amount of details remembered is similar to what shows up in `status`. There's definitely some further enhancements possible (e.g. printing package diffs, displaying rollbacks), though this seems in good enough shape as a first cut. Closes: #1489 Closes: #1813 Approved by: cgwalters
|
Hi, this is really awesome, thank you! But how to rollback to a previous state? I tried rpm-ostree rebase but I still have same LocalPackages and LayeredPackages as before... My goal is to get back in time, and revert what I did with rpm-ostree that was adding LocalPackages, adding LayeredPackages, and adding some kargs... |
|
For the package bits, use |
|
The history should have the list of |
In a discussion on IRC, one idea we discussed was something equivalent to
dnf history, i.e.rpm-ostree history, where one is able to see exactly which branches/versions/checksums were actually deployed on the system at which times.Somewhat related to #558, though this is orthogonal to the actual branch history on which the system is currently sitting on and is instead a history of the system itself. This can be useful for debugging/auditing.
The text was updated successfully, but these errors were encountered: