New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider an `rpm-ostree history` command #1489

jlebon opened this Issue Aug 3, 2018 · 5 comments


None yet
4 participants
Copy link

jlebon commented Aug 3, 2018

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.

@jlebon jlebon added the enhancement label Aug 3, 2018


This comment has been minimized.

Copy link

dustymabe commented Aug 3, 2018

/me likey


This comment has been minimized.

Copy link

dustymabe commented Aug 5, 2018

This could also allow us to track down more complicated upgrade path bugs


This comment has been minimized.

Copy link

gun1x commented Aug 5, 2018

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.


This comment has been minimized.

Copy link

cgwalters commented Aug 23, 2018

Some of this is already in the journal.

@jlebon jlebon self-assigned this Sep 25, 2018


This comment has been minimized.

Copy link
Member Author

jlebon commented Oct 1, 2018

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 ostree-prepare-root so that it writes to the journal the deployment path we're booting into. Combined, these two provide enough information to trace exactly when we rebooted into what branch/commit/etc...

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.

jlebon added a commit to jlebon/libdnf that referenced this issue Dec 20, 2018

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.
- 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment