I accidentally switched to rawhide by typing 39 instead of 38 when upgrading to new Fedora. And now I want to be landed gentry into 40 stable. Does that sound possible?
F40 is currently the rawhide version and will not be released as stable for about 8 months (approximately April 2024).
F38 is stable and F39 is currently the branched version that is nearing release time (expected in October).
If you are looking for Stable F40 then you have a long wait. If you want to continue to use rawhide that is simple â just continue to do updates.
I personally have not been successful in moving from rawhide to any of the stable releases directly, but have been able to follow the branched release and flow through the beta stage to release.
2 Likes
39 seems fine to me to try. So how to ensure dnf fixes to 39 and doesnât move further?
What is the output of cat /etc/fedora-release ?
If that shows as Fedora release 40 then an update has already been done that was past the branch point and it may not be possible to step cleanly to the F39 branch. I have not tried such. If it still shows as release 39 then moving to the branch may be possible.
One would need to disable the rawhide repo and enable the fedora 39 branch repo before trying to do another update.
1 Like
$ cat /etc/fedora-release
Fedora release 39 (Rawhide)
But, dnf up wants to add 40 key, and I am hesitant to give it a go.
Fedora - Rawhide - Developmental packages for the next Fedora release 1.6 MB/s | 1.6 kB 00:00
Importing GPG key 0xA15B79CC:
Userid : "Fedora (40) <fedora-40-primary@fedoraproject.org>"
Fingerprint: 115D F9AE F857 853E E844 5D0A 0727 707E A15B 79CC
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-40-x86_64
The 40 key by itself is not an issue.
Upgrading with the rawhide repo still enabled will move you along the rawhide path and likely prevent taking the branch.
This should give you more info about branching off.
https://fedoraproject.org/wiki/Template:Rawhide_branched_install_methods
1 Like
In this case you can run
dnf update --releasever=39 --refresh
which will fix the version to 39. After that you can again omit the --releasever=39 option.
1 Like
Might need to do distro-sync instead of update so fedora-release and other packages get downgraded properly
1 Like
On my VM which has rawhide I tested a switch to the F39 branch.
This command seems to work for that since there were a lot of packages that needed to be downgraded from the update I did 2 days ago. (350 packages that were either upgraded, downgraded, or installed new (kernels update)
dnf distro-sync --releasever=39 --refresh --disablerepo rawhide --enablerepo fedora --allowerasing --best
All those options managed the couple of conflicts that were initially shown and the VM is now running F39 instead of rawhide.
3 Likes
I did that when I tried to upgrade to 38, but I messed the number. Instead of sticking to 39, dnf switched to rawhide and seem to stuck there.
This command helped to make the switch, thanks.
sudo dnf distro-sync --releasever=39 --refresh --disablerepo rawhide \
--enablerepo fedora --allowerasing --best
But the root cause of the problem - why I ended up on rawhide in the first place - is not addressed. Why dnf put me to rawhide when I should have been ended with unstable 39 instead? There is a similar report here.
Fedora 39 was ârawhideâ until about 10 days ago, where Fedora 39 was split off and"rawhide" became the new Fedpra 40 version. So by using Fedora 39 before it was separated off from rawhide, you put yourself in rawhide.
Why have 39 before it is separated?
If one were to do the same now and use 40 as the release version they would now be put into rawhide as well. Rawhide carries the next upcoming release version continuously, until it is branched for the final couple months of development to be released. At that point the rawhide branch gets the next version number while the branch for release continues to carry the upcoming release number.
What this means is that rawhide has been 39 since 38 was branched back in February, and rawhide is 40 now that 39 has already been branched.
This. For tools that assume the release version is a number, doing this is safer than using ârawhideâ as a release version too.
Safer for that? dnf --releasever=rawhide is a valid option that doesnât crash.
Still looks like a bug to me. I donât see the rationale why those who need rawhide should not use rawhide and use 40 instead (and 41 when 40 becomes unstable branch).
For tools that parse /etc/os-release and check for specific OS versions. these require special handling for distributions like Debian that use codenames for their development branch (sid is the Rawhide equivalent)
I could imagine it will be safer is to require some sort of confirmation when choosing to upgrade to a non stable release. Thatâs certainly a nice improvement.
But most people who choose to switch to the upcoming version likely want to end up on the branched release - though yes, there is a race condition: if you donât update at the right time you donât get switched to the branched release either.
Itâs easy to switch between branched and rawhide early on anyway, the differences will still be minimal
Using releasever with the rawhide release number is only another option that works when desired. Though it can cause unanticipated results when the user inadvertently uses releasever with the number that is in use with rawhide at the time. That kind of error rests on the shoulders of the user involved and is not really a bug since it was user error related. Dnf actually performed as the user instructed it to do.
System administrators actually learn to proofread the commands they type before they commit. Especially when it may affect the entire OS. It is impossible for anyone to prevent a user making a typo.
I seriously doubt that one or 2 similar errors in a several year period will change the way rawhide is managed. In fact I do not recall seeing anyone mentioning a similar issue ever in the past.
1 Like
I have to post this link twice in the thread.