Rebasing from Silverblue F28 to 29

rpm-ostree rebase fedora-workstation:fedora/29/x86_64/silverblue
Receiving metadata objects: 1/(estimating) 142 bytes/s 569 bytes
error: Commit 8781ad5a58f3a7dbedaad23391fa439dbb6bb3bcf9a7b267148e4fa3aad102c0: GPG signatures found, but none are in trusted keyring

Hi I am getting the above error

Sigh… see make gpgkeypath 🗝 support being a list 📓 · Issue #773 · ostreedev/ostree · GitHub. basically the gpgkey you currently have configured for the remote is the f28 gpg key. You’ll have to change it out for the f29 gpgkey. For example:

[root@vanilla-f29-atomic ~]# cat /etc/ostree/remotes.d/fedora-atomic.conf 
[remote "fedora-atomic"]
url=https://kojipkgs.fedoraproject.org/atomic/repo/
gpg-verify=true
gpgkeypath=/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-primary

Find your file in the /etc/ostree/remotes.d/ directory and update it to say 29 instead of 28.

1 Like

I think the missing GPG signature in the keyring is a bug.

A workaround for me was to download https://getfedora.org/static/429476B4.txt and save it as “fedora-29-key.txt”, then run:

ostree remote gpg-import fedora-workstation -k fedora-29-key.txt
4 Likes

Thanks Garrett, that seems to have done the trick!

though note that until there’s a new compose

That happened now, it includes lvm2 again.

https://kojipkgs.fedoraproject.org/compose//branched/Fedora-29-20180905.n.0/logs/x86_64/Silverblue/ostree-4/create-ostree-repo.log

I got Silverblue 29 rebase to work:

sudo ostree remote gpg-import fedora-workstation -k /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64
sudo rpm-ostree rebase fedora-workstation:fedora/29/x86_64/silverblue

but the boot didn’t come all the way to to a login screen. gdm started but that’s as far as it got

It’s a bit blurry but if you zoom in you can read it -“Started GNOME Display Manager”.

  ostree://fedora-workstation:fedora/29/x86_64/silverblue
                   Version: 29.20180905.n.0 (2018-09-06 02:15:39)
                BaseCommit: 8781ad5a58f3a7dbedaad23391fa439dbb6bb3bcf9a7b267148e4fa3aad102c0
              GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
           LayeredPackages: chrome-gnome-shell chromium cockpit docker-compose f28-backgrounds-extras-gnome git git-lfs
                            gnome-shell-extension-dash-to-dock gnome-shell-extension-native-window-placement
                            gnome-shell-extension-openweather gnome-shell-extension-pomodoro
                            gnome-shell-extension-screenshot-window-sizer gnome-shell-extension-topicons-plus
                            gnome-shell-extension-user-theme gnome-tweaks kernel-tools powertop python3-speedtest-cli
                            vim-enhanced

I bet it’s your gnome-shell extensions that are stopping you from reaching the desktop. They probably aren’t compatible with gnome 3.30

@znmeb Sorry scratch my last post… I didn’t read your post correctly. I thought you got to the login screen

I’m planning to re-run the rebase tomorrow and this time I’ll capture the package deltas. :wink:

I re-ran the rebase to Silverblue 29 and captured the package changes:

Package changes - https://gist.github.com/znmeb/9fd8888bdb7688d6faf372fdb405a19e

My guess it’s one of two things:

  1. The upgrade to the 4.18 kernel requires different amdgpu command line settings for my ancient AMD “Sea Islands” GPU. I can test that by letting it boot up with “radeon”.
  2. Some vital package was removed - an awful lot of packages that look important got taken away, as you can see from the gist.

I couldn’t get a console to look at messages - once it prints out that it has started gdm the keyboard no longer accepts keystrokes :frowning:

Update: the 4.18 kernel / AMD Sea Islands issue is at least part of the problem. I can get a console with carefully minimized “kargs” settings. But still no GNOME Display Manager login prompt.

The amdgpu driver is in rapid flux these days to cope with numerous new cards and it’s not at all surprising that a five-year-old card isn’t getting treated fairly. I can at least troubleshoot gdm now. :wink:

Is it also possible to rebase to CentOS with everything working (inheriting set-up like user accounts etc.)?

And I got the following error:

cannot update repo 'rpmfusion-free-updates': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink

How can I solve this? And the error appeared not before downloading the whole image – can’t this be checked in advance? Quite some checks just are done afterwards, this wastes a lot of time…

// At installing the RPM Fusion 29/branched RPMs on F28SB via sudo rpm-ostree install <RPMs>), I get these error messages:

0. nothing provides system-release(29) needed by rpmfusion-free-release-29-0.5.noarch
1. nothing provides system-release(29) needed by rpmfusion-nonfree-release-29-0.5.noarch

//// After uninstalling all layered RPMs, removing local RPM-Fusion packages and COPR files of /etc/yum.repos.d/, I was able to rebase. Sadly, F29SB turns out to be extreeeemly slow and lauchnching some programs (for example gnome-terminal) caused the whole system to freeze (all extensions disabled). Should I report this anywhere, or is this normal for the current beta phase?

Update: An rpm-ostree rebase from Atomic Host 28 to Silverblue 29 was successful in a Virtual Machine Manager virtual machine with 2 GB of RAM and 1 core. There are some anomalies with the desktop - I can log in normally (default Wayland) but if I try to log in with GNOME on Xorg it sits there for about a minute and drops me back to a GDM login. The display seems painfully slow - I’m going to push the RAM up to 4 GB and add a processor before I do any more testing on it.

The slowness might be due to an sepolicy issue that has just been fixed. Until a new image is available, you can try editing /etc/selinux/config and changing SELINUX to permissive instead of enforcing.

OK … meanwhile, the rebase from F28 to F29 doesn’t work any more -

1218 metadata, 5103 content objects fetched; 152174 KiB transferred in 371 seconds
Checking out tree 478cb22... done
Enabled rpm-md repositories: fedora updates
Updating metadata for 'fedora': 100%
rpm-md repo 'fedora'; generated: 2018-09-11 16:03:23
Updating metadata for 'updates': 100%
rpm-md repo 'updates'; generated: 2018-02-20 19:18:14
Importing metadata 100%
Resolving dependencies... Forbidden base package replacements:
  gnome-classic-session 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-common 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-window-list 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-launch-new-instance 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-apps-menu 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-places-menu 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-alternate-tab 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
failed
error: Some base packages would be replaced

I’m trying with fedora/29/x86_64/testing/silverblue now.

1672 metadata, 5676 content objects fetched; 357496 KiB transferred in 428 seconds
Checking out tree 5d8558f... done
Enabled rpm-md repositories: fedora updates
Importing metadata 100%
Resolving dependencies... Forbidden base package replacements:
  git-core 2.19.0-1.fc29 -> 2.19.0-0.0.rc0.fc29 (fedora)
failed
error: Some base packages would be replaced

Yeah, I’m getting the same thing when I try to upgrade my already-F29 system. Something got broken…

Funny, as now it works for me! xD

By the way, as we speak of SE-Linux: I get one or two geoclue warnings almost every time I log in, and sometimes I even get immediately thrown out of the shell again, when I log in.

And is it ok to layer atomic and use it still, or may this cause issues? It’s nice that I don’t have to type in my password with atomic. :slight_smile:

Based on the similarity of your errors to my errors, you might have gnome-tweak-tool installed? Try removing it.

Worked for me! Just changed to 29 from 28 and the GPG key is now good to go. Thanks for your help.

1 Like