Adventues in upgrading to Fedora 19 using ‘fedup’

So… after upgrading Fedora 18 installation to Fedora 19 (using DVD ISO image) via 'fedup' tool which was quite event-less* (not quite, read below); decided to upgrade second laptop running Fedora 17 to 19 directly using network (note that F17->F19 upgrade is not supported, IIRC).

Downloaded the latest f18 fedup noarch rpm (hey, it’s python!) from Koji directly and installed on F17 system. Did a 'fedup-cli --verbose --network 19'. After half an hour and around 2.0 GB of package downloads including third party ones, new ‘Upgrade’ boot entry is set up and reboot into it.
Boots into F19 upgrade plymouth screen… nothing happens – instead of progressing upgrade, system simply reboots after few minutes. After some head-scratching and trying to capture systemd errors, found the culprit to be a mount point entry in /etc/fstab with ntfs-3g file system – mount attempt was timing out and boot fails. Commented out that part, and then upgrade ran successfully. Reboot again, new Fedora 19 boot menu appears, boot into it. The reboot saga continues, this time with different systemd errors. Then recollect that I probably did something stupid while fedup was running (probably installing another kernel), looking at the grub entry shows that the boot target is still 'system-upgrade.target' which does not exist anymore after the upgrade. Manually correct the grub entry and voila – booting succeeds. Fixed the screw-up later by regenerating grub config – 'grub2-mkconfig -o /boot/grub2/grub.cfg' and later re-enable ntfs-3g mount point in /etc/fstab which was commented.

(*) Coming back to the first upgrade of Fedora 18 to Fedora 19 using ISO image – I had a weird setup – that is, the F18 installation was on an external USB hard disk and I boot from USB (it suffices to say there are non-technical reasons why I can’t install Linux on that laptop). But the internal hard disk of the laptop is faster and I tend to keep data there. As someone following ‘diskless install’ for a few years now and FAT filesystem cannot hold the DVD images, I was always interested if the NTFS filesystem was supported for install from. The DVD ISO image was kept in the ‘internal’ hard disk with NTFS partition  but 'fedup-cli --verbose --iso /path/to/Fedora-19-i386-DVD.iso' loudly complains that the ISO file is on ‘external’ hard disk (which is true because the OS is running from USB disk and thus the ‘internal’ hard disk is considered ‘external’) and it is not supported at the moment.
The next option to try was 'fedup-cli --device' method. For this, mount the NTFS partition which has DVD ISO image, then loop-mount the ISO image in another mount point – add these in /etc/fstab, assuming that packages need to be taken from loop-mounted location during actual upgrade run. Run  'fedup-cli --device /media/Fedora' which prepares the upgrade (this option does not copy the rpm packages into /var/lib/fedora-upgrade as the mounted device already have them – a sane thing to do). Reboot into the ‘Upgrade’ boot entry but this quickly failed and resulting in cleaning up the boot entry followed by a reboot – the error scrolled down were all related to not finding the rpm files. I didn’t investigate the issue further then, but now realize that it must be related to the mount points added in /etc/fstab failing.
In the end I copied the DVD ISO image into slow external USB hard disk itself  with Ext4 partition (from which the OS runs) followed by a 'fedup-cli --verbose --iso /home/rajeesh/Fedora-19-i386-DVD.iso' which worked flawlessly.

This is the first time I tried 'fedup' tool  and it is remarkably good – stable, fast, polished and easy. What was really impressive is that the well thought and sane behaviours – if you upgrade via network and something went wrong on the first try, the packages already downloaded to /var/lib/fedora-upgrade were kept and not downloaded again – huge win on usability and bandwidth. Also the ‘Device’ method do not copy packages unnecessarily either. What would I love to see in the future? Support for keeping ISO images in ‘external’ hard disks, and of course for NTFS partitions. Also, even packages excluded from update in yum.conf were also considered for upgrade and downloaded – perhaps a feature request for fedup to skip them?

fedup is a great tool, I want to thank the developers for making it so.

About these ads

5 thoughts on “Adventues in upgrading to Fedora 19 using ‘fedup’

  1. anonymous says:

    That’s interesting to hear that F17->F19 is not supported. I just upgraded two F17 systems this way a week or so ago.

  2. Rajeesh says:

    You are indeed correct that it is nowhere documented that F17 to F19 upgrade is not supported by fedup – at least I can’t find it,

  3. The concept of ‘supported’ is a bit of a tricky one, really. It’s not like you’re getting phone support or a refund. =) It’s more just a case of ‘the more complex you make the procedure, the more likely it is that something might go wrong’. In practice most of the 17->19 attempts I’ve heard of have been successful.

    fedup is, at base, fairly simple: it’s just doing a ‘yum update’ in two stages, the second in a minimal environment to try and avoid issues caused by updating running stuff. It’s about as likely to succeed as a yum upgrade, minus any updating-running-apps issues, and with the flexibility to let us do specific upgrade hooks when they’re needed – but none were actually needed for 17->18 or 18->19, both of those are pretty basic upgrades.

  4. no1knows says:

    I had the same reboot issue (having also foolishly installed a kernel during the fedup process). Your suggestion of removing the boot target entry from grub2.cfg also did the trick for me. Cheers!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s