Realized recently that my aurora install had stopped updating, and I’m not sure what happened at the time to cause it since I took so long to notice
rpm-ostree status reported no errors, and rpm-ostree upgrade –check reported no available updates, despite me being on a month old version:
original rpm-ostree status
ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable (index: 1)
Digest: sha256:161c2a141446c76e3714b99b3422a2ad7340d2477adf1f9e46c7638fe5494469
Version: 43.20251119.1 (2025-11-19T16:00:52Z)
BaseCommit: 39851ccc0ec4eb399bec0bc8fdc2d1a3b48e355fafb6f678f7a5f81d5a61f7b7
Commit: 08ec00174cababf03e435aaeab806bc30745aff74149db8c45030a1c19f179ba
StateRoot: default
rpm-ostree upgrade conflict
if I ran rpm-ostree upgrade then I got an error about a hardlink conflict between aurora-logos and fedora-logos. I assumed aurora-logos was part of the OS, but when I checked another computer of mine (that was on latest aurora), it didn’t have either of those packages… I also couldn’t find any way to tell why aurora-logos was installed, or why fedora-logos was trying to be installed.
I figured I should try to see where those packages were introduced/removed, so I tried to use rpm-ostree db diff to compare the versions, but my out of date computer didn’t recognize any newer commit hashes, and my up to date computer didn’t recognize the commit 39851ccc0ec4eb399bec0bc8fdc2d1a3b48e355fafb6f678f7a5f81d5a61f7b7 which my out of date computer was stuck on?
I went into the github container version history and tried to find my 3985… release, and I discovered it didn’t seem to be one of the standard daily or weekly releases at all, and in fact has zero downloads, so I have no idea how I ended up on it.
Comparing the out of date and up to date rpm-ostree status again it became clear that there was no latest- at the beginning of my Version like there should (?) be.
It seemed like I was on a stale ‘branch’ or something (to use git terms), so I figured I needed to get back to the ‘main branch’ (the latest- tags), so I rebased to latest-43.20251119, figuring that would fix it.
current rpm-ostree status
ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:latest-43.20251119 (index: 0)
Digest: sha256:196cbd40961dbe9ec9e4afb56ea3d3bc369c963afd9bb26f66beb90e57c80bff
Version: latest-43.20251119.1 (2025-11-19T19:54:19Z)
BaseCommit: b6eed3e4aa44543de45ed9eb585ba6e1e16a30d717d3da4c5c67cf0e66aaca39
Commit: 87ddd23a24a9c629eeb3c16743e70ff7e282de9d0a1a1b400df7ff070407b638
That seems to have worked fine, however, it’s still not finding any updates, either via rpm-ostree update or via the automatic check. I’m assuming this is because my ‘branch’ is now the specific latest-43.20251119 commit instead of just aurora-dx:latest?
the main question
Now that I’m here, how can I get it back on the right track? Is there a way to correct my image ‘field’ to just aurora-dx:stable so that I can then run rpm-ostree upgrade normally? Or is my only option here to rebase directly up to the latest aurora-dx:stable ?
bonus questions
- normally, in what situation would rebasing to the latest version not work, but updating would? I’m having a bit of a hard time understanding what difference there is to this at least in terms of ‘git’ reasoning
- is there a way I can ‘bookmark’ commit that’s a known-good state before messing with rebases/etc? currently I only ever see the two versions and as soon as you make changes the old one is lost, but in a situation like this, the old one is technically the stable (if out of date) system I’ve been running fine for a month, while the new one, while it seems to be working, isn’t exactly battle tested. I don’t want to experiment with more operations to fix things right now because as soon as I do anything I’ll lose the stable old commit I have
- is there any way to tell when running into an upgrade conflict like this what is causing the new package to be installed? it feels like there must be way more information about the upgrade process that’s being hidden, resulting in getting this strange hardlinking error message with no context, but I don’t see any ‘verbose’ option and aren’t aware of any relevant log files
- is there a way to override the
dnferror on atomic systems, at least for read-only actions, so that I can use it to query the state of the dependency tree/etc? I know I can’t use it to make modifications but when researching online there’s a lot of queries/etc that seem to only be possible using it - is there an easy way to find the release in github by commit hash? I couldn’t find any search field and had to resort to clicking through pages one by one