Showing posts with label fedup. Show all posts
Showing posts with label fedup. Show all posts

Tuesday, December 24, 2013

Upgrade to Fedora 20

This is a log of my tries to upgrade from Fedora 19 to Fedora 20 using fedup. The upgrade process wasn't really so flawless, but that was for three reasons. The first one was that on my laptop I have installed too many packages which creates problems by itself. Namely, on almost every update I have some problems with dependencies, so, it was expected to have problems during upgrade, too. Second problem was that I didn't pay attention to some details. Now, it might be argued that less skilled people will pay even less attention, and so, this will be a problem for them too, but then, I don't know. Finally, there was a third problem as well, and that were bugs in fedup package.

Ok, theoretically, to upgrade Fedora 19 to 20 you only have to do the following:
# fedup --network 20
and after that command finishes, reboot and the upgrade process will start. Finally, after one more reboot, you are in a new environment/OS. Of course, the process is a long one because everything is downloaded from the Internet. There is an option of using ISO image and downloading only updates/external repositories, but I didn't try it.

Problems

The first problems were related to available disk space. When fedup started download I realized that there could be problems with space. On root (/) partition I had available only few gigabytes, so I move two directories, /var/tmp/fedora-upgrade and /var/lib/fedora-upgrade, to /home partition where there was much more space, and created symlinks in the original directories so that fedup finds them.

After starting fedup again it downloaded everything necessary (continuing from where it stopped) and then it tested transaction. One problem was with the available space on the root (/) partition. That problem I solved by uninstalling some extra large packages. The easiest way to find out which packages take the most space is to use the following command:
# rpm -q --qf '%10{SIZE} %{NAME}\n' -a | sort -n
it will print out all packages with theirs sizes sorted from the smallest to the biggest one. So, I removed few biggest ones. I also removed some packages from /opt directory that I manually installed.

Ok, after I restarted fedup it didn't download everything again but after some tests of downloaded packages it tested the upgrade transaction. The following problems were reported:
WARNING: potential problems with upgrade
  ffmpeg2theora-0.29-4.fc19.x86_64 (no replacement) requires ffmpeg-libs-1.2.4-2.fc19.x86_64 (replaced by ffmpeg-libs-2.1.1-1.fc20.x86_64)
  gcc-python3-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python3-plugin-0.12-15.fc20.x86_64) requires gcc-python3-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python3-plugin-0.12-15.fc20.x86_64)
  perl-HTML-Template-2.95-1.fc19.noarch (no replacement) requires 4:perl-5.16.3-266.fc19.x86_64 (replaced by 4:perl-5.18.1-288.fc20.x86_64)
  rubygem-audited-activerecord-3.0.0-3.fc19.noarch (no replacement) requires 1:rubygem-activerecord-3.2.13-1.fc19.noarch (replaced by 1:rubygem-activerecord-4.0.0-1.fc20.noarch)
  gnome-shell-extension-xrandr-indicator-3.8.4-1.fc19.noarch (no replacement) requires gnome-shell-extension-alternative-status-menu-3.8.4-1.fc19.noarch (replaced by gnome-shell-extension-common-3.10.1-1.fc20.noarch)
  gcc-python3-debug-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python3-debug-plugin-0.12-15.fc20.x86_64) requires gcc-python3-debug-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python3-debug-plugin-0.12-15.fc20.x86_64)
  1:NetworkManager-wimax-0.9.8.8-2.fc19.x86_64 (no replacement) requires 1:NetworkManager-0.9.8.8-2.fc19.x86_64 (replaced by 1:NetworkManager-0.9.9.0-20.git20131003.fc20.x86_64)
  gcc-python2-debug-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python2-debug-plugin-0.12-15.fc20.x86_64) requires gcc-python2-debug-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python2-debug-plugin-0.12-15.fc20.x86_64)
  gcc-python2-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python2-plugin-0.12-15.fc20.x86_64) requires gcc-python2-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python2-plugin-0.12-15.fc20.x86_64)
  gazpacho-0.7.2-13.fc19.noarch (no replacement) requires python-kiwi-gazpacho-1.9.26-6.fc19.noarch (replaced by python-kiwi-glade-1.9.38-2.fc20.x86_64)
  python-iguanaIR-1.0.3-2.fc19.x86_64 (no replacement) requires iguanaIR-1.0.3-2.fc19.x86_64 (replaced by iguanaIR-1.0.5-2.fc20.x86_64)
Finally, it asked for reboot to start upgrade. But, I decided to remove offending packages which were those with f19 tag in the package name. Then, I started fedup again. It again found some problems:
WARNING: problems were encountered during transaction test:
  broken dependencies
    gazpacho-0.7.2-13.fc19.noarch requires python-kiwi-gazpacho-1.9.26-6.fc19.noarch
    perl-HTML-Template-2.95-1.fc19.noarch requires perl-4:5.16.3-266.fc19.x86_64
    python-iguanaIR-1.0.3-2.fc19.x86_64 requires iguanaIR-1.0.3-2.fc19.x86_64
    kmod-VirtualBox-3.11.10-200.fc19.x86_64-4.3.4-1.fc19.x86_64 requires kernel-3.11.9-200.fc19.x86_64, kernel-3.11.7-200.fc19.x86_64, kernel-3.11.10-200.fc19.x86_64
    gcc-python3-plugin-0.12-15.fc20.x86_64 requires gcc-python3-plugin-0.12-15.fc20.x86_64
    gnome-shell-extension-xrandr-indicator-3.8.4-1.fc19.noarch requires gnome-shell-extension-common-3.8.4-1.fc19.noarch
    rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem-activerecord-1:3.2.13-1.fc19.noarch
    ffmpeg2theora-0.29-4.fc19.x86_64 requires ffmpeg-libs-1.2.4-2.fc19.x86_64
    gcc-python2-plugin-0.12-15.fc20.x86_64 requires gcc-python2-plugin-0.12-15.fc20.x86_64
    kmod-VirtualBox-3.11.9-200.fc19.x86_64-4.3.4-1.fc19.x86_64 requires kernel-3.11.9-200.fc19.x86_64, kernel-3.11.7-200.fc19.x86_64, kernel-3.11.10-200.fc19.x86_64
    gcc-python3-debug-plugin-0.12-15.fc20.x86_64 requires gcc-python3-debug-plugin-0.12-15.fc20.x86_64
    kmod-VirtualBox-3.11.7-200.fc19.x86_64-4.3.2-1.fc19.3.x86_64 requires kernel-3.11.9-200.fc19.x86_64, kernel-3.11.7-200.fc19.x86_64, kernel-3.11.10-200.fc19.x86_64
    NetworkManager-wimax-1:0.9.8.8-2.fc19.x86_64 requires NetworkManager-1:0.9.8.8-2.fc19.x86_64
    gcc-python2-debug-plugin-0.12-15.fc20.x86_64 requires gcc-python2-debug-plugin-0.12-15.fc20.x86_64
Continue with the upgrade at your own risk.
I tried again to remove some offending packages that were reported in the previous output, and started fedup again:
# fedup --network 20
setting up repos...
getting boot images...
.treeinfo.signed                          | 2.0 kB  00:00:00
setting up update...
finding updates 100% [===========================================================]
verify local files 100% [===========================================================]
testing upgrade transaction
rpm transaction 100% [===========================================================]
rpm install 100% [===========================================================]
setting up system for upgrade
Finished. Reboot to start upgrade.
I didn't managed to get rid of all transaction problems, more specifically there were problems with kmod-VirtualBox packages. But then, I gave up of trying to fix that and decided to continue with the upgrade. At that moment I made the next mistake which was that I rebooted before fedup finished. Namely, the last thing it printed was 'Finished. Reboot to start upgrade.' but it didn't give a prompt back. I mistakenly thought that it waits for me to reboot. But, it was actually still working! So, actually, nothing happened after boot. I was again in Fedora 19. After again starting fedup and checking what's happening I finally realized that fedup is still working (and consuming a lot of CPU) so I waited and finally I got the prompt back. Then I restarted the computer, selected fedora upgrade option, but nothing happened. I rebooted, and removed rhgb and quiet options from boot option to upgrade with fedup, and the last message I saw after removing rhgb and quite options from boot entry was:
[    5.733054] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input7
Waiting dropped me finally into dracut shell with a message there is no root. It turned out that this message was obscuring passphrase message! Namely, I was asked for the passphrase to unlock disk, but I didn't saw it and everything stopped. After few reboots I realized this as the message was partially visible and I finally realized what was the problem.

Then, something else happened, the upgrade process didn't start. I ended up in the Fedora 19. It also took me some time to realize that fedup "forgot" to put the following options to boot entry:
upgrade systemd.unit=system-upgrade.target
and it did it repeatedly! In other words,  So, I manually added it and the upgrade finally started. Or at least it seamed so. It stopped suddenly, but I noticed that it complained about not finding file package-list and then I realized that symlink is wrong because all the partitions are mounted under sysroot. Namely, because I moved packages to other partition and symlinked it, upgrade process couldn't find it.  Symlinks looked like this:
/var/lib/system-upgrade -> /home/system-upgrade
But during upgrade process, home is mounted under /sysroot directory. So, I had to run fedup again, and after it prepared the system for upgrade, before rebooting, I changed symlinks so that they look like this:
/var/lib/system-upgrade -> /sysroot/home/system-upgrade
Note that after reboot to upgrade if you want to try again, you have to start fedup again. Namely, immediately before upgrade process starts, the boot option is removed from grub. This is safety measure, but it is annoying in case you are trying again.

Anyway, that symlink issue was the last problem, and it upgraded Fedora 19 to 20. It took me almost half a day to get to that point and I don't call this a most pleasant experience. In other words, I think that those things should be polished a bit better than they are.

One last thing, I had problems with fedup 0.7 and I had to upgrade to fedup 0.8. This was somewhere early in the whole process, but since I started to take notes later when I stumbled upon more problems, I didn't noted exactly where it happened, so I'm mentioning it here.

Thursday, July 4, 2013

Upgrading to Fedora 19

I just managed to install Fedora 19 and that was harder than it should be. Here are some remarks.

One thing to note. Every system is different and when I managed to fix something, it could be that I changed something else also, at first glance unrelated, to the problem itself. Yet, I don't have time to double check each fix I did. So, treat this as hints what could you do in case you have similar problems.

Failed attempt

First, I tried to uprade using FedUp tool. But that failed. Upgrade process requires certain amount of free space on root partition. Well, I have relatively small root partition and it is isolated from /home where there is a lot of space. For this reason I had to move FedUp working directories (/var/tmp/fedora-upgrade and /var/lib/fedora-upgrade) to home partition and create symlinks. After reboot into fedup, it briefly showed exception and then rebooted again into Fedora 18. The exception was:
[     0.421] (II) fedup.sysprep:remove_cache() removing /var/tmp/fedora-upgrade
[     0.424] (II) fedup:() Exception:
Traceback (most recent call last):
  File "/usr/bin/fedup-cli", line 181, in
    main(args)
  File "/usr/bin/fedup-cli", line 82, in main
    do_cleanup(args)
  File "/usr/lib/python2.7/site-packages/fedup/commandline.py", line 183, in do_cleanup
    remove_cache()
  File "/usr/lib/python2.7/site-packages/fedup/sysprep.py", line 195, in remove_cache
    rm_rf(d)
  File "/usr/lib/python2.7/site-packages/fedup/util.py", line 51, in rm_rf
    rm_f(d, rm=rmtree)
  File "/usr/lib/python2.7/site-packages/fedup/util.py", line 48, in rm_f
    log.warn("failed to remove %s: %s", f, str(e))
NameError: global name 'log' is not defined
At first, I thought that the problem was the inability to remove a directory, but then I realised that the problem is undefined log module/class! So, I opened file /usr/lib/python2.7/site-packages/fedup/util.py and replaced line 48 with a simple pass statement.

Reinstall

Then, I decided to reinstall Fedora from scratch. But, I didn't want to burn CD nor I wanted to go again through the network boot/install process again. So, I booted from USB stick. In essence, you need to download boot.iso file and using livecd-usb-to-disk tool write it on USB stick. Then, boot from this stick and off you go.

Luckily, installation process is much improved from Fedora 18.

Problems

During a boot process, I was dropped into a single user mode. Looking into logs (as suggested by the message just before the root password prompt) I found that dbus isn't working, i.e. there was the following message:
Cannot boot - no /var/lib/dbus directory. Created the directory and disabled SELinux.
It turned out that this directory, for some reason, wasn't created when dbus package was installed. So, I created that directory and disabled SELinux in /etc/sysconfig/selinux.

Next problem was that Firefox didn't want to start for some unknown reason. I have several different profiles and firefox would stuck at profile selection dialog box. But, this was something transient because after several tries it continued to work without any problems.

VMWare

First, I'm using VMWare Workstation 9.0.1. So, this text applies to that version. VMWare couldn't compile kernel modules, so I applied this patch. Simply unpack it to some temporary directory and run bash script. During the compilation process, there are a lot of warnings like this one:
/tmp/modconfig-ZB7ihE/vsock-only/linux/vsockPacket.h:113:4: note: in expansion of macro ‘ASSERT_ON_COMPILE’
    ASSERT_ON_COMPILE(sizeof (VSockPacket) == 56);
    ^
/tmp/modconfig-ZB7ihE/vsock-only/./shared/vmci_iocontrols.h: In function ‘VMCIVA64ToPtr’:
/tmp/modconfig-ZB7ihE/vsock-only/./shared/vm_assert.h:320:20: warning: typedef ‘AssertOnCompileFailed’ locally defined but not used [-Wunused-local-typedefs]
But, despite those warnings, modules compiled and I managed to start VMWare.

Then, I had a problem with entering serial key. When I pressed button Enter key... nothing happened. I entered it via a command line, like this:
/usr/lib/vmware/bin/vmware-vmx-debug --new-sn XXXXXXXXXXXXXXXXXXXXXXXX
After that, everything seemed to work. By the way, here is a very good page I used to get VMWare working.

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)

Blog Archive