Warning
This is experimental and not the recommended way.
Doing so will skip migration scripts between versions, that change files not contained in the immutable image. It can cause unexpected breakages.
Recommended and supported is this:
For documentation purposes, here are theoretical steps to upgrade across 2+ versions.
They are likely not worth the hassle, invest the time and update version by version.
Steps 1, 2, 6, 7 still apply there.
Theoretical Situation
You found that old Laptop of your grandma or something, laying around for some years. Maybe it is on Fedora 37, and you want to save time upgrading it.
Maybe the Fedora ostree remotes have shut down already, or for any reason there simply is no archived F38 imgage available, anywhere!
I use Fedora Kinoite as an example, on an x86_64 laptop. This does not work on other architectures, afaik.
1. Disable Secureboot
As the system is really old, you will need to disable secureboot for now. Otherwise the outdated bootloader files will cause errors.
2. Create a new user account
GNOME and KDE may introduce breaking configuration changes, and upgrading may introduce strange problems.
If you can, creating a new user is recommended.
sudo useradd newuser
sudo usermod -aG wheel newuser
sudo passwd newuser #enter password
Do not login to that user!
3. Rebase to the Fedora OCI Images
Rebasing to the latest ostree image causes these two problems with a missing public key to verify.
For some reason there seems to be no argument for rpm-ostree to ignore that.
But, using rpm-ostree’s compatibility with “ostree native containers”, you can rebase from the ostree remote to the unverified container without issues!
rpm-ostree rebase --experimental ostree-unverified-registry:quay.io/fedora-ostree-desktops/kinoite:41 --reboot
4. Login to the new user
After probably some time, your system will reboot and you can login to “newuser”.
The desktop will be the latest version, with default configuration created during first login.
5. Rebase back to the ostree version
The OCI images are not yet signed, and updates are bigger, needing more bandwidth.
So you may want to rebase back to the ostree remote.
rpm-ostree rebase --reboot fedora:fedora/41/x86_64/kinoite
This should not change any files but may still take a while and will reboot.
6. Update the bootloader
The bootloader is really outdated, and may not already be automatically updated with the system using bootupd. So you can do it manually.
sudo cp -r /usr/lib/ostree-boot/efi/EFI/fedora /boot/efi/EFI/
sudo cp -r /usr/lib/ostree-boot/efi/EFI/BOOT /boot/efi/EFI/BOOT
sudo cp /usr/lib/ostree-boot/efi/EFI/fedora/shimx64.efi /boot/efi/EFI/fedora/shimx64-fedora.efi
sync
Instead, you could also use bootupd
systemctl enable --now bootupd
rpm-ostree update --reboot
The rpm-ostree update should trigger bootupd and update the bootloader.
7. Re-enable Secureboot
Now that the bootloader “shim” files are updated, secureboot should work again.
If you are on traditional UEFI, secureboot is at least some security measurement.
Full measured and verified boot with dasharo or heads coreboot may be preferred, if security, trust in the firmware and tamper-resistance are high priorities for you.
Sources