For distro upgrades, I usually use pxe/tftpboot and do clean remote installs. So I thought I’ll give yum preupgrade a try for my remote test machines. I should also mention, this F15 machine is a minimal(@core) install.
Existing F15 install
# cat /etc/redhat-release Fedora release 15 (Lovelock)
Run the pre-upgrade command to upgrade to F16 branched pre-release
preupgrade-cli "Fedora 16 Branched Pre-release (Verne)"
Everything went smooth.
Once, preupragde-cli is done, run the yum distribution-synchronization which synchronizes the installed package set with the latest packages available.
# yum distro-sync
Post preupgrade, let’s do some quick clean-up of dependency problems, orphans(installed pkgs which are not available from currently configured repos), duplicates, leaves(packages which are no longer needed by any other pkgs on the system)
# package-cleanup --problems ; package-cleanup --orphans \ package-cleanup --dupes ; package-cleanup --leaves
And reboot the host. There we go !
# cat /etc/redhat-release Fedora release 16 (Verne)
Kashyap Chamarthy 
Just tried this and have had a number of problems.
1. once I’ve logged in I get the “sad computer” icon and have to log out and log back in (which doesn’t help since the sad mac just shows up again) – I’ve worked around this problem a bit by switching to a vt and using setenforce 0 to make selinux permissive but still not a permanent solution
2. once I’ve logged in (properly this time) the screen often doesn’t refresh – meaning I do something, but the something doesn’t cause a change until I do either: 1)go to and back from Overview, or 2) switch to a vt. This seems like a gtk issue since things update properly with things made from shelltoolkit
3. consolekit won’t authorize when I attempt to use packagekit gui (it’s not that it doesn’t recognize the password but it never lets me put in the password)
4. anaconda didn’t install grub2 so I’m still using an f15 kernel (I have to say that I’m wondering if this is caused by my not getting rid of all the orphaned packages, specifically the old kernels)
Have you encountered any of these issues?
Anyway, thanks for letting us know preupgrade is working now.
Best/Liam
Liam, like I mentioned at the beginning of the post , the F15 box I was pre-upgrading, is just a headless, minimal install server which I use as a Virtualization host — Only @core packages. No Gnome*, nothing else. That’s probably the main reason I was able to smoothly pre-upgrade. So I haven’t tried full blown distro pre-upgrade.
Thank you Liam for letting me know about the above issues :) . I’ll be careful. Also, a useful tip skvidal mentioned on Fedora test list — perform your pre-upgrade/yum update inside a ‘screen’ session, so that, even if X crashes, you can connect back to the session from your virtual terminal.
Kashyap,
Thanks for the response. I did notice that it was a core install but I interpreted that to mean standard Gnome rather than the core package set. Reading hard:)
Thanks for the screen tip but since preupgrade is pretty bomb-proof (nothing committed till it completes) I just let it run in guake. One issue I did notice, however, was that on reboot grub wasn’t pointing to the anaconda instance so that needed to be changed.
BTW, I fixed the gnome session: I touched /.autorelable.
What’s really annoying is that I haven’t seen these issues crop up for other F16 people.
Trailblazers FTW!
Best/Liam
Sure. Nice, that you got the gnome session fixed by auto relabling. :)
Go Trailblazers !
issue 4 is a known bug: https://fedoraproject.org/wiki/Common_F16_bugs#preupgrade-bootloader-fail
Thanks Adam for pointing to that. So, you think my f16 pre-upgrade install is still un-broken? (w/o grub2) . We had some probs.(specifically for libguestfs) during Virtualization test day on TC2 due to grub/grub2 conflicts.
$ rpm -qa | grep -i grub
grub-0.97-79.fc16.x86_64
grubby-8.3-1.fc16.x86_64