@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. 
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:
- 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”.
- 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 
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.
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. 
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
Did you have to layer nano and then run it as sudo? Since /etc/ostree/remotes.d/fedora-workstation.conf is read only?
Also did anyone else have issues with https://getfedora.org/en/static/checksums/Fedora-AtomicWorkstation-29-1.2-x86_64-CHECKSUM giving a 404 error for the past few days?
The link should be: https://getfedora.org/en/static/checksums/Fedora-Silverblue-29-1.2-x86_64-CHECKSUM
How exactly are you trying to rebase?
Thanks! When I went to https://getfedora.org/ and to the silverblue page the verify link was what I posted. So it looks like someone forgot to rename the link to silverblue from atomic workstation…
But I followed what znmeb did and ostree remote gpg-import fedora-workstation -k /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64
then rpm-ostree rebase fedora-workstation:fedora/29/x86_64/silverblue
From there my computer didn’t boot all the way.
Edit:
I didn’t do ostree remote gpg-import fedora-workstation -k /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64
But rather I downloaded the fedora 29 gpg keys and ran the command ostree remote gpg-import fedora-workstation -k fedora29.txt * Although I am not at the computer I tried this on, so I can’t check my history.
Well that ended well… What exactly went wrong?
I don’t have any pictures but it was booting up and got stuck on one of the services. After about ~3mins I turned in off and rolled back to fedora 28.
But how did you end up rebasing to 29? Did you just edit the existing gpg key in /etc/ostree/remotes.d/fedora-workstation.conf?
I just used ostree import for the GPG key and rpm-ostree rebase -b whatever/branch/is/29 for the rebate.
If you decide to try 29 again, could you let it hang, then boot back into 28 and save + upload the output of journalctl -b-1? That’s the system logs, which should help to debug the issue.