Fedora – 26-27 DNF Upgrade Woes, and a Workaround..
After upgrading four Fedora systems (x86_64) from release 26 to 27, using # dnf system-upgrade download --refresh --releasever=27 --allowerasing --nogpgcheck --best -y
, two of these worked OK, but two failed – with a sudden reboot, back to F26 – and no (apparent) error displayed, after # dnf system-upgrade reboot
had rebooted the system, and the upgrade process had started, but before the actual rpms were processed:
......................... dnf[914]: 7f83cc874000-7f83cca73000 ---p 00030000 08:03 7865985 /usr/lib64/libexpat.so.1.6.6 dnf[914]: 7f83cca73000-7f83cca76000 r--p 0002f000 08:03 7865985 /usr/lib64/libexpat.so.1.6.6 dnf[914]: 7f83cca76000-7f83cca77000 rw-p 00000000 00:00 0 dnf[914]: 7f83cca77000-7f83cca9c000 r-xp 00000000 08:03 7896214 /usr/lib64/librepo.so.0 dnf[914]: 7f83cca9c000-7f83ccc9c000 ---p 00025000 08:03 7896214 /usr/lib64/librepo.so.0 dnf[914]: 7f83ccc9c000-7f83ccc9d000 r--p 00025000 08:03 7896214 /usr/lib64/librepo.so.0 dnf[914]: 7f83ccc9d000-7f83ccc9e000 rw-p 00026000 08:03 7896214 /usr/lib64/librepo.so.0 dnf[914]: 7f83cccb8000-7f83cccf8000 rw-p 00000000 00:00 0 dnf[91reboot: Restarting system .............. (system reboots, into F26 again..
I had encountered a similar problem before, and was able to work out a – rather convoluted – workaround..
In this upgrade, the F27 rpms are resident at /var/lib/dnf/system-upgrade , and each repo has its own sub-directory – the repo ID followed by a uuid-style numerical string, eg: fedora-cba4cf65782eccda , updates-09879b494aeba108 , rpmfusion-free-093775106f01a54b etc.. In each of these, the F27 upgrade rpms – if there are any – are in the packages sub-directory.. If there are no upgrade rpms for a particular repo, then the packages sub-directory will not exist..
As root, I created a temporary directory and copied each group of F27 rpms to this, so that the update/upgrade could be done all-at-once.. Then I checked for the kernel….xxx rpms, and installed (not updated!) these by # rpm -ivh kernel*rpm --nodeps --force
, and then deleted them.. After that, I updated all the remaining F27 rpms: # rpm -Uvh *rpm --nodeps --force
, and waited for this to complete (which takes some time!). After that, I simply re-booted the system, and it came back up – correctly – as Fedora 27.
Robert Gadsdon. November 15, 2017. (updated Nov 25, to clearly show double-dash in rpm commands, which normally get merged in ‘publishing’, and have to be handled in raw html!
Sunday, Nov. 25, 2017
Hello from France!
Many thanks for your help!
Trying to upgrade a laptop from fedora 26 to 27 by the method using “dnf system-upgrade”, I got exactly the same bug as you describe, and thanks to your method, I could eventually ugrade all packages from F26 to F27 and safely reboot under F27 with all my previous system configuration & home files preserved.
In upgrade phase one,
dnf system-upgrade download –refresh –releasever=27 –allowerasing –nogpgcheck –best -y ,
all required F27 packages were correctly downloaded, but upon reboot, the laptop refused to boot under the (26 to 27) upgrade process, and rebooted a second time under F26.
I have one question just for curiosity: how did you manage catch the error message during the first unsuccessful reboot, messages like
dnf[914]: 7f83cccb8000-7f83cccf8000 rw-p 00000000 00:00 0
dnf[91reboot: Restarting system
I have two minor remarks
– the proper rpm commands are with double dash “–” before force and nodeps:
rpm -ivh kernel*rpm –nodeps –force
rpm -Uvh *rpm -–nodeps -–force
– I actually did not “copy” all *rpm files gathered from various sub-directories in /var/lib/dnf/system-upgrade, to a single temporary directory, I simply created a symbolic links (“ln -s”) from all *rpm files to the same temporary directory.
And I worked with rpm -[iU]vH in this directory on the huge collection of symbolic links, instead of real copies of the files: in my collection of rpms, the total disk space is 2.7 Gbytes!
Thanks again, I hope that your message will help many linux aficionados using fedora 26!
—
Emmanuel Bigler
Additional remarks:
Actually I cut-pasted Robert’s commands from the original post to enter them into a terminal,
# rpm -ivh kernel*rpm –nodeps –force
# rpm -Uvh *rpm –nodeps –force
and I realize that double dashes were certainly there in the original post, but were converted into a single dash by my cut-past action!
Another mystery of computer science unsolved, for which a workaround was easy to find 😉
—
Emmanuel
This is another WordPress problem.. the double-dash typed in using the editor gets ‘merged’ into one when the page is ‘published’, whichever font is used.. And the ‘code’ tag does not work in the main pages, but does in these comments!
I did some more tests, and the ‘code’ tag does work, but only if you edit the page in raw html! I’ve updated the page to show this properly, now..
RG
Thanks Robert!
I’m familiar with double dashes merged into a single long one in LaTeX code.
I hope that all Fedora users facing the same problem of F26->F27 dnf upgrade can take benefit of your workaround which is versy simple to apply.