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
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
