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: 7f83cc874000-7f83cca73000 ---p 00030000 08:03 7865985 /usr/lib64/libexpat.so.1.6.6 dnf: 7f83cca73000-7f83cca76000 r--p 0002f000 08:03 7865985 /usr/lib64/libexpat.so.1.6.6 dnf: 7f83cca76000-7f83cca77000 rw-p 00000000 00:00 0 dnf: 7f83cca77000-7f83cca9c000 r-xp 00000000 08:03 7896214 /usr/lib64/librepo.so.0 dnf: 7f83cca9c000-7f83ccc9c000 ---p 00025000 08:03 7896214 /usr/lib64/librepo.so.0 dnf: 7f83ccc9c000-7f83ccc9d000 r--p 00025000 08:03 7896214 /usr/lib64/librepo.so.0 dnf: 7f83ccc9d000-7f83ccc9e000 rw-p 00026000 08:03 7896214 /usr/lib64/librepo.so.0 dnf: 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!