I have upgraded my personal laptop to #Fedora#Silverblue just in time for the upgrade to Fedora 40 to be an update in the background and then a trivial, quick reboot into the upgraded system with an option to roll back if something goes wrong.
I started this update in December, by starting with a new (larger) drive. I put it into a USB-3 NVME carrier, attached it to a VM, and did an install and updates until it looked like I got the software I wanted complete.
Then an unrelated hardware failure made me back-burner it until tonight. I booted the VM, did a quick rpm-ostree upgrade, and rebooted the VM into the latest release. Four months of updates and it was fast and trivial. Copied my home directory over from the old drive to the new drive, popped it in, and I'm up and running.
I'm really looking forward to not watching minutes of updates scroll by with the system unusable at the boot screen.
And if I need any files from the old install, I have the old drive in the USB-3 NVME carrier. ☺
But after that, the update to Fedora 40 with rpm-ostree rebase fedora:fedora/40/x86_64/silverblue just ran in the background for 10-15 minutes and was then an uneventful quick reboot after the "command finished" notification popped up, at my convenience, no slower than any other reboot.
If it hadn't worked right for some reason, ESC at boot time to get the grub menu and choose 39 instead would have been easy.
@bkhl Yup! I figured that was the case , and thanks for confirming. This was my first rebase after finally switching to Silverblue last week, after years of expecting to migrate "soon"... 😁
I've been tempted to rebase to Fedora Atomic Desktop with the upgrade to 40. I ran it in the past and then for some reason decided I wanted regular Fedora Workstation. The package entropy has finally caught up with me after a few years, so it's time to reinstall either way.
@burdickjp Atomic systems are nice for avoiding package entropy, definitely!
This is in some ways conceptually close to what we built (but failed to successfully commercialize) at rPath with the "system model" where we had a complete but parsimonious description that completely avoided package entropy.
But it was much slower than basing on OCI images and layering on top of them.
@mzurich As far as I know, as someone who really doesn't like the dock experience, so would have no direct experience: What you are actually asking is whether dash to dock is compatible with gnome 46 yet — is that right?
Add comment