I was on Silverblue 39 1126 and tried to upgrade to 1130 by running command “sudo rpm-ostree upgrade”, I got the following errors:
What should I do?
I think I may provide more background here. The first time, I run “rpm-ostree upgrade”, there is one conflict (the first one iirc). I did some search online, and install two packages systemd-container and systemd-devel using “rpm-ostree install systemd-container” and “rpm-ostree install systemd-devel”.
The weird thing is when I tried to install the two packages above, it seemed that the upgrade is also executed, at least the kernel is upgraded to 6.6.2 after I install the two packages.
But after the installation of the two packages, the number of conflicts is increased to 3 (as shown in the screenshot).
That image shows that the system already has packages installed that are newer versions than what is being installed by the upgrade. Thus version conflicts.
You also are showing version conflicts between i686 packages and x86_64 packages. Are the i686 packages necessary? if not then they may be removed to eliminate the conflicts.
Layering additional packages is unlikely to resolve conflicts. If anything, it would make it worse
Please share the output of rpm-ostree status
I think I didn’t install those i686 packages. It also surprised me. Maybe it is because some packages I installed depend on them?
I run the command:
“rpm -qa | grep ‘systemd’”
and didn’t find systemd-container.i686
I also run
“rpm -qa | grep ‘i686’”
and there is no i686 packages installed in my system.
One thing I feel pretty weird when I searched for the package “systemd” in fedora. As you can see in the screenshot, it seems systemd-254.5-2 is listed as testing but 254.7-1 is listed as stable, does this mean in the package repository systemd-254.5-2 is newer than 254.7-1?
BTW, the systemd version on my system is 254.5-2
I can’t reproduce this problem even with all of those packages layered minus keyd and using that base image version. I don’t know what’s going wrong, but I’d suggest you drop your layered packages with rpm-ostree reset -l, upgrade, and then add them back.
If you want to debug this further, please share the errors with systemd-container and systemd-devel removed, preferably as text using the preformatted text tool (or ```).
I have already uninstalled systemd-container and systemd-devel using command sudo rpm-ostree uninstall, below is the screenshot of the output of the command
Then I run sudo rpm-ostree upgrade, and this is the error message for conflict:
Please consider using the preformatted text tool button </> as already suggested.
Reading, copying, quoting, and searching on text within images is difficult or impossible.
Use copy & paste from the screen then either highlight the text and use the button or use the triple back quotes [ ``` ] as already noted on the lines before and following the text.
That clears things up a bit. What’s happening is that one of your layered packages is pulling in systemd-container, and rpm-ostree can’t find the correct version to match systemd in the new base image (254.7-1). I think rpm-ostree refresh-md should fix it, but enough time has passed that the rpm-md cache should now be expired anyway.
Ideally, rpm-ostree would be smart enough to make sure that the client-side metadata cache is at least as new as the compose image, but it currently doesn’t do that, AFAICT.
First off, you don’t use sudo with rpm-ostree upgrade. Everything it does, is from the system perspective already, and it expects you to be a user, not sudo. Try the upgrade that way first please.
OK, I didn’t know that. I’ll try run rpm-ostree upgrade when I got home today. I have been running the upgrade command with sudo for about a month. Just out of curiosity, Are there any negative effects for running rpm-ostree upgrade with sudo?
I tried to run rpm-ostree upgrade this morning, it seems the problem is solved, i.e. no conflicting packages. But I don’t think I have done any change to my system from the last time I updated the error information here. Weird.
Thanks for the suggestions. This is the first time I posted here, so I don’t know much about how to make the information clear and easily accessible to others.
That’s what I meant by “enough time has passed that the rpm-md cache should now be expired anyway”.
The updates repo cache expires after 6 hours, so that’s the longest it could stay broken in the worst case.
1 Like
OK. Just curious about how the metadata in rpm-ostree can be wrong. Is the error in the server-side or there is a corruption locally?
I’m not certain, but it doesn’t hurt to use the command as intended. As for the cache, you can use rpm-ostree cleanup -m to clean up the metadata and then retry the update.
The issue is client-side, but it’s not corrupted, just stale.
Fedora is made from daily composes. Those composes pull in updates marked for stable (like the systemd update involved in this issue) and create new rpm-ostree base images incorporating those updates. rpm-ostree upgrade pulls the latest base image and then applies any layered packages. For that, it need to download repository metadata just like dnf-based variants do.
For simplicity, let’s pretend that the compose is published at midnight. If you ran an rpm-ostree command at 23:00, the updates repo would be refreshed if its metadata cache was at least 6 hours old. After midnight, rpm-ostree upgrade would pull in the new base image but continue to use the old cache for layered packages until it expired at 5:00. This works most of the time even if it’s not ideal, but the more layered packages you have, the greater the chance of encountering a version incompatibility.
1 Like