F16->17 preupgrade - does it handle the /usr move?

Steve Dowe sd at warpuniversal.co.uk
Fri Jun 8 10:48:44 UTC 2012


On 07/06/12 17:08, Steve Dowe wrote:
>  On 07/06/12 15:55, Michael Cronenworth wrote:
> > Preupgrade takes care of the /usr move automatically. It occurs
> > when you boot into the preupgrade anaconda.
>  Superb - thank you both for that info.
>
>  Looks like an interesting evening ahead!

An interesting evening it was too.  And morning, for that matter.

So, preupgrade almost worked, but it failed when trying to update 
jboss-as-7.1.1-2.fc17.  I saw someone else having a similar problem 
here: https://lists.fedoraproject.org/pipermail/users/2012-May/418940.html

Well, I decided to take the bull by the horns and tackle this problem.  
Here's what happened:

After running preupgrade and rebooting into the second-half of the 
preupgrade process, I received this error prompt:

"Error Installing Package:  A unpack error occurred when installing the 
jboss-as package.  This could indicate errors when reading the 
installation media.  Installation cannot continue."  [ Exit Installer ]

I clicked the Exit Installer button then hit Crtl-Alt-F2 to access the 
root shell.  The theory here was that if the JBoss application server 
packages were removed, the upgrade process might skip this...

# chroot /mnt/sysimage
# yum remove jboss*
# yum remove ovirt*
# exit
# init 6

Rebooted and found there was a Fedora 17 (3.4 kernel) option in the grub 
menu above the "Upgrade..." option.  I tried it, and faced a kernel 
panic. So, I rebooted into the "Upgrade to Fedora 17" option in grub.  
Anaconda came back up... 155 packages to go ....

All packages were then installed/upgraded but, during the clean-up 
operation, there was another installer error prompt:

"Error Running Transaction: There was an error running your transaction 
for the following reason: Rpmdb changed underneath us." [ Exit Installer ]

I guess this was inevitable.  So, I clicked Exit Installer and the 
machine automatically rebooted.  The option for Fedora 17 (Kernel 3.4) 
was selected, but the "Upgrade.." option was still present, so I 
selected that instead.

Anaconda quickly reported "Performing post-upgrade scripts"  before 
rebooting automatically.  This time, the "Upgrade..." option had 
disappeared from the grub menu.

The F17 (kernel 3.4) option was still present so I tried that - kernel 
panic still.  Rebooted into F16 (kernel 3.3) option - this worked, 
albeit with a few errors along the way in the boot-up screen.  Up came 
GDM, so I logged in as my user, then opened a terminal and, as root, ran

# yum update

...   but older ruby packages relating to ovirt were still creeping 
through.

I removed all ovirt / openshift / jboss packages I could find, removed 
the repos also, and also did a

# yum remove ruby*

This removed 60-odd packages.

Once complete, I ran:

# yum --releasever=17 distro-sync

... which updated a handful of packages (glade, groff, numactl-libs, 
yum, powertop, soprano, mdadm, xorg-x11-drv-intel, etc)

Something still wasn't right though.  An "# echo $releasever " showed no 
"17", so I quickly checked which fedora-release we were on:

# cat /etc/fedora-release
Fedora release 17 (Beefy Miracle)

# rpm -qa fedora-release
fedora-release-16-1.noarch
fedora-release-17-1.noarch

Got rid of 16:

# rpm -e fedora-release-16-1.noarch

My focus now was on getting the right kernel to boot properly. A reboot 
and a

# yum search kernel

seemed to download the rpm package list again, so I'm guessing the yum 
cache was updated for Fedora 17.  It also showed me many kernel-related 
packages include a kernel version 3.4 (f17) rpm.

However, a

# yum reinstall kernel-3.4

told me that "Installed package kernel-3-4.0-1.fc17.x86_64 is not 
available" (<- sorry, I didn't note this bit down, so technically this 
text may be slightly incorrect).

As it was al;ready installed, I figured I may as well remove it and then 
see what  "yum update" brings...

# yum remove kernel-3-4.0-1.fc17.x86_64

The package was removed.

# yum update

...indeed brought kernel-3-4 back and installed it again.

I rebooted.  However, instead of a kernel panic, this time I got dumped 
into the dracut debug shell with a few warnings on screen (for 
reference, my hostname is polaris):

dracut warning: unable to process initqueue
dracut warning: /dev/mapper/vg_polaris-lv_root does not exist
dracut warning: /dev/vg_polaris/lv_root does not exist
dracut warning: /dev/vg_polaris/lv_swap does not exist
dracut warning: crypto LUKS UUID <my partition's LUKS UUID> not found

I rebooted and checked this - the UUID reported by dracut is correct, 
and kernel 3.3 finds it ok.

I also checked the grub menu entries as specified in 
/boot/grub2/grub.cfg - 3.3's and 3.4's are identical except for the 
obvious references like kernel version and initrd file name.

I'm unsure whether to make this an issue in bugzilla, given my 
unorthodox route here, but it seems like there is an issue with the F17 
initrd being created while running in F16's 3.3 kernel.  Could anyone 
comment on this?

Anyway, I hope the above is helpful to someone in the same quandary - at 
least my system is back up again!

Cheers,
Steve

-- 
Steve Dowe

Warp Universal Limited
http://warp2.me/sd



More information about the users mailing list