Fedora can be a pain
We tried to do an upgrade on the Fedora 16 linux installation we have here yesterday and it failed completely. The linux Fedora distribution seems to be getting more tempermental as times go on, mainly when attempting to do upgrades from systems that have been running older versions for years if not a decade and more.
Yesterdays trial started with shutting down other machines that access it, mainly to make it easier afterward to have everything up and running properly.
So, we booted from the linux fedora 16 DVD and got a few screens into the install when the old “unhandled exception error” pops up.
naconda and python are just not happy and an hour of research and troubleshooting later makes me wan to pull my hair out.
OK.. take a deep breath and more coffee and try another approach, an inplace upgrade.
Restarting the old fedora 16, we do a
yum install preupgrade
yum clean all
This installs the inplace upgrade program, cleans up various cache and then runs the command line upgrader as we are connecting via ssh and not sitting at the keyboard.
[root@xena etc]# preupgrade-cli “Fedora 17 (Beefy Miracle)”
Loaded plugins: blacklist, whiteout
No plugin match for: rpm-warm-cache
No plugin match for: remove-with-leaves
No plugin match for: auto-update-debuginfo
Loaded plugins: presto, refresh-packagekit
Fetched treeinfo from http://fedora.mirror.nexicom.net/linux/releases/17/Fedora/i386/os//.treeinfo
treeinfo timestamp: Tue May 22 16:58:41 2012
MEMORY | 948 B 00:00
/boot/upgrade/vmlinuz checksum OK
/boot/upgrade/initrd.img checksum OK
Traceback (most recent call last):
File “/usr/share/preupgrade/preupgrade-cli.py”, line 330, in
File “/usr/share/preupgrade/preupgrade-cli.py”, line 220, in main
extra_args += ” ks=%s” % self.generate_kickstart(extra_cmds=self.kickstart_cmds)
File “/usr/lib/python2.7/site-packages/preupgrade/__init__.py”, line 607, in generate_kickstart
return dev.bootpath_to_anacondapath(targetfile, UUID=True)
File “/usr/lib/python2.7/site-packages/preupgrade/dev.py”, line 91, in bootpath_to_anacondapath
raise PUError, “/boot is on RAID device %s” % bootdev
preupgrade.error.PUError: /boot is on RAID device dm-0
guess what? We aren’t running any of the drives on RAID. grrrrr.
Now the last upgrade a few months back was from Fedora 15 to 16 and involved bypassing the limiting 100mb boot partition and that could be the cause here… /boot is now in the main partition of / and not on its own.
Event tried to install the Fedora 18 alpha but same problem.
I’m thinking the only way out of this before support is dropped is to put in a new drive and install fresh.
That would clear up a few other issues we have with the bios and operating system over mixing IDE and SATA drives. Besides the old IDE drive is in fact old and slow and probably near its end of life.
I have two other servers running fedora 16 and have run into various upgrade issues with them as well.
Too much legacy code and installation methods and too many new changes I suspect.