Rebase to 32 failed

Desktop Silverblue
#1

Hi all,
Been away from SilverBlue for a while (got frustrated trying to build a flatpak) but thought I’d jump back in with V32. So I tried to rebase from 31, but this was the result. I’ve tried this a few times today, managed to fix a couple of problems, but can’t fix this one.

ian@Silverblue:~> rpm-ostree rebase fedora:fedora/32/x86_64/silverblue
⠒ Receiving metadata objects: 0/(estimating) -/s 0 bytes... 
Receiving metadata objects: 0/(estimating) -/s 0 bytes... done
Checking out tree 91b2369... done
Enabled rpm-md repositories: fedora fedora-modular rpmfusion-nonfree-nvidia-driver updates rpmfusion-free-updates-testing rpmfusion-nonfree-steam
rpm-md repo 'fedora' (cached); generated: 2020-04-15T11:45:21Z
rpm-md repo 'fedora-modular' (cached); generated: 2020-04-14T10:21:32Z
rpm-md repo 'rpmfusion-nonfree-nvidia-driver' (cached); generated: 2020-04-14T06:39:01Z
rpm-md repo 'updates' (cached); generated: 2018-02-20T19:18:14Z
rpm-md repo 'rpmfusion-free-updates-testing' (cached); generated: 2020-04-14T08:23:18Z
rpm-md repo 'rpmfusion-nonfree-steam' (cached); generated: 2020-02-24T21:32:34Z
Importing rpm-md... done
Resolving dependencies... done
error: Could not depsolve transaction; 2 problems detected:
 Problem 1: conflicting requests
  - nothing provides system-release(31) needed by rpmfusion-free-release-31-1.noarch
 Problem 2: conflicting requests
  - nothing provides system-release(31) needed by rpmfusion-nonfree-release-31-1.noarch
ian@Silverblue:~>

I’ve tried disabling the rpm-fusion repos in the software manager, but that doesn’t seem to do anything.
What do I need to do to get around this error?
Thanks.

#2

Not sure if this is the recommended method, but removing the overlayed packages from rpmfusion and the rpmfusion repos themselves before rebasing, and then replacing them after the rebase works. Another way of doing that is to do an rpm-ostree reset before the rebase, and reinstall rpmfusion, etc after the rebase.

1 Like
#3

Thanks @joefidler. I tried the second option as it seemed easir than the first. I couldn’t remember what packages I had installed from rpm-fusion, and I don’t know how to find out, so option 2 it was. It certainly worked. The rebase to 32 was installed in a few minutes with no problems. It wiped a fair bit of stuff though, most noticeably dash-to-dock. In fact all my Gnome extensions. But that’s okay, it was time for a bit or a cleanout.
Thanks,
:wink:

#4

Glad to hear you got it running @mogplus8 . The packages that seem to cause this issue are the rpmfusion repos, where a “rpm-ostree reset” takes it to a state without any layered packages at all - which I guess accounts for why your extensions went - depending on how they were installed.

My understanding is that layered packages are supposed to move with the rebase so I don’t know why this issue effecting the rpmfusion repos packages is occurring, but it is a bit annoying. Anyway hope you can now enjoy 32.

#5

A quick way to deal with this error is to delete all packages from those repos and the repos itself via rpm-ostree. Then you can rebase to a newer version and reinstall the repositories without the need of a single reboot. Although, you will need to reboot to install the packages themselves from rpm-fusion.

#6

Thanks @deathwish. I was hoping that 32 would be a bit more stable and allow me to do more things that are a bit from left field, but not much has changed. I also managed to lose my 31 build somehow, not sure how, but all I have left now is four versions of 32, two with a “1” in the description, and two with a “0”, so not sure how that has occurred. A Grub problem maybe? And my base 31 has now gone, so I can’t rollback to it.

20200417_234903
20200417_234903800×450 194 KB

Have to say it’s a bit irritating that one of the best, and unique, features of Silverblue, the ability to easily roll back to a previous install, is hobbled by limiting the number of rollback versions to one.

Anyway, bottom line is that for me, a humble user who just wants to get things done and is not a techhead guru, Silverblue is still a bit too beta. I’m going back to my old friend Mint, which, for me anyway, is a lot more stable and usable, and does everything I want it to do with no fuss. Well, hardly any fuss. I’ll be keeping half an eye on SIlverblue though, because I really think it’s the future. And when I can just use it and everything just works, it will become my daily drive.
:wink:

1 Like
#7

Hi @mogplus8 sorry to hear that it is not going well. While it doesn’t excuse your bad experience, it is worth remembering that version 32 is still in beta with all the usual warnings around that. That unfortunately doesn’t fix what happened, and as you have seen it just ain’t ready to come out of the oven yet.

#8

@joefidler NOW you tell me!
On a slightly different tack, is it possible to rebase/downgrade to 31 if my old image has gone? Do I have to do a complete reinstall? Or is there an easier way?
Thanks,

#9

Hi @mogplus8 - I’m just a community member and rely on reading other forum sections here or silverblue.fedoraproject.org for the project’s current status - I am not sure if Silverblue 32 is even out of rawhide yet or if it will release at the same time as Workstation 32.

#10

Sorry @joefidler, the comment was meant to be tongue in cheek (is there an emoticon for that? There should be).
:wink: Ian

PS Turned out to be too easy. rpm-ostree rebase fedora:fedora/31/x86_64/silverblue
Btilliant!

#11

@mogplus8 Glad you got it resolved and all good. Cheers, Joe.

#12

There is
rpm-ostree admin pin 0
to keep e.g. the topmost install.

#13

@tmstaedt I haven’t been able to find where this function is documented. I found one reference in the rpm-ostree man page, which talked about an install being “pinned”. By that, and your example, I’m guessing that a particular install can be set to never be deleted. Is this correct? If so I could “pin” every time I deploy a new install, and thus build up a list of many installs, and overcome my problem. Correct?
Thanks.

#14

The actual command is: ostree admin pin 0.

An example is found here (search for “How can I upgrade my system to the next major version”):

https://docs.fedoraproject.org/en-US/fedora-silverblue/faq

#15

Hello @mogplus8,
Sorry to hear you have been having such a time with F32SB. I had upgraded my system a bit ago from 31 to 32, and I too had rpmfusion repos enabled with the usual codec suspects installed. I found I had to remove the ref’s, and uninstall the repo rpm’s to be able to upgrade. The ref’s are enabled/disabled with sudo ostree remote add/delete<ref><ref-url>. A quick way to remove ref’s is to delete their metadata files in /etc/yum.repos.d then run rpm-ostree cleanup -m then do rpm-ostree update prior to rebasing to the new version. I did that approach, and had to uninstall the offending packages from rpm-fusion (free and non-free) after that I could do the rebase to the new version. Once the new version was booted into I re-enabled the repos and reinstalled the bits I wanted from them. I had this documented because of this topic you started here, so I could provide an outline in better detail of what the steps are and in what order. Would that be something of interest to you?

#16

Does the rpm-ostree ex reset command accomplish the same thing as manually removing this layered packages and refs? What is the recommended approach?

#17

This post describes how to use the reset command:

#18

The rpm-ostree reset command will remove any mutations of the base image that you have installed (layered packages) and return your system to the current base image as released from Fedora’s repo, no layered packages. It will not affect any user data or environment settings, aside from what removal of the layered packages would require. AFAIK this also means anything that the layered packages place in the user home dir. So when you re-install those layered packages usually preferences are still setup as you had them. I didn’t want to reset my system because of a few codecs, so I removed the ref’s (with ostree), deleted the metadata for the repos in /etc/yum.repos.d, did a cleanup on my image with rpm-ostree cleanup -m then uninstalled the offending packages. I reboot at this point before I do the rpm-ostree update, then follow that with another reboot and finally the rebase. I know there is a lot of talk around about the need to reboot or not but I apply this simple approach, if I make a change to rpm-ostree in some way, other than meta-data cleanup, I reboot.
As for the recommended approach, rpm-ostree is a variant of ostree, and ostree is the sysadmin command for Silverblue, when you need more control over your install than rpm-ostree gives. There is a lack of a clear documentation trail that I can point you to other than read the fedora system administrators guide for the release you are using, as this technology is becoming more relevant to the sysadmins so there is an increase of info there with each release.
In keeping with this topic’s thread, this link is to the administrators guide for rpm-ostree and this here is the link to the FAQ for Silverblue about upgrades/rollbacks/pinning commits. etc…
rpm-ostree ex is for the experimental commands and options, such as making your immutable OS mutable. I would strongly recommend against doing such unless you have specific need to, and understand the ramifications. You can just use rpm-ostree reset <option> with the option of resetting layered, overrides, iniramfs, all. Or you can specify exactly what to remove with --uninstall, and you can even install overlayed packages with the same command.

1 Like
#19

Thanks for the info @jakfrost. I did not see the rpm-ostree reset in the man page, so I thought the ex option was needed. I am almost ready to pull the trigger on a rebase to 32 and wanted to make sure I did it the right way. Hopefully in the future this process can be improved to not need to remove the rpm-fusion packages and repos before a rebase. Are there significant technical reasons why this could not be automated?

#20

I think the reasons are related to licensing from Fedora POV, plus the inevitable out-of-synch issue faced by contributing projects to the repo. Not all projects follow Fedora’s release cycle cadence. On the upside, Fedora contributors are regularly adding more FOSS versions of missing codecs for instance in the Fedora repo, this will eventually lead to better upgrade results for those of us forced to use the ‘non-compliant licensed’ bits in order to have a functioning DE.