Backups were a pain, clonezille kept reporting bitsum errors backing up the home filesystem of my Dev server, filesystem checks found no errors.
So downloaded the latest release of clonezilla and burnt it to a DVD. It failed to boot on my Dev server…opps that has a CD drive not a DVD drive. I stuplidly had my blank CD container on the floor, doggie had pee’ed on it; off to the shops for more blank CDs, then burnt it to CD and finally started a backup for my Dev server.
Used the DVD copy to backup my spare desktop (and backup VM host machine) while that was happening.
And started upgrading all my machines using yum. I have never had a sucessfull upgrade using fedup and of course preupgrade is no longer supported; so yum is always the safest way I have found to upgrade. One major advantage of using yum is that is will also upgrade using all the repositories you have configured (if possible, see below); using the Fedora ISO’s or fedup will only use the Fedora repositories which will pretty much guarantee package conflicts if you have ever added another repository.
The steps are basically as below. If there are any incompatibilities between versions the yum distro-sync will report them; packages with conflicts need to be removed, there should not be many of them.
I had to only “rpm -e simplescreenrecorder async-http-client libbtctl directfb” for the upgrade to work.
yum update reboot yum check (and fix any problems, reboot if needed) yum -y distro-sync --releasever=21 --obsoletes reboot
Major issues found
- There is no F21 Dropbox repoistory yet. All yum commands against the F21 version must include “–disablerepo=Dropbox” in order for them to work
- The F21 version of hercules does not work correctly. It will freeze/hang, and if it is running screens in roll-delete mode they do not roll… my x3270 client is on a f17 machine and consistent problems with F21 hercules, no problems with F20 hercules; c3270 connections from F21 have the same issue. Could be a c3270 and hercules interoprability problem but either way hercules on f21 is currently unusable. I rolled back to the prior F20 disk image to resolve the issue; means webserver cannot be upgraded
Unusual issues found
On one Gnome desktop the keymap changed for F21, the @ key produced ” when used from a Gnome session on the local console (and ” produced @, they have buggered the keymap). If used via synergy to remotely manage the desktop the @ symbol is replaced by the omega symbol.
Issues occurs after Gnome login. @ can be used in a password at login but not in any terminal sessions or used to unlock the screen after the screen saver comes on; so it is within the Gnome environment. Also as ssh’ing into the servers from F20 and F17 machines accepts the @ key correctly… yup, its something Gnome changes when it starts up.
The workaround for the keymappimg issue for synergy remote control only was found in a five year old post from when fedora 10 introduced the same problems (http://superuser.com/questions/77734/synergy-linux-keyboard-problem).
Create a file ~/.Xmodmap on the F21 machine and add the following to it: keycode 24 = q Q at at at at You can activate it straight away with: xmodmap ~/.Xmodmap
The command must be run manually from a terminal session (or ssh session) after each reboot which is a minor pain.
This does not fix the issue of the @ and ” keys being remapped from the physically attached keyboard.
I may have to install the KDE desktop to see if that resolves the issue; although I quite like gnome.
This is a major issue for me as I use @ in passwords.
I’m not sure if this occurred on the laptop as well as I would have synergy’ed directly into that when upgrading it. So need to retest there.
