This post is for people with, well, mature, installations of Fedora. The installers of yesteryear defaulted to a very small 250MB /boot partition. That’s so small it really gets in the way of using Fedora’s preupgrade feature.

These are the tricks I use whenever I’m upgrading one of these mature installations.

Firstly you must remove every kernel except the one you are currently using to run your system. That should clear out enough space for preupgrade to get things ready for you.

Even with the kernels removed preupgrade stil won’t have enough space to store the stage2 installer image. That’s it can download it during the install. When preupgrade completes you can reboot, select “Upgrade” via grub (if it is not selected by default) and try to do the upgrade.

Round about now you will discover the second problem. Even with a wired connection you can’t download the stage2 installer. Why not? Well, because preupgrade has incorrectly setup the kernel boot line causing the stage1 installer to try and download the image from the wrong place. You can fixup the kernel boot line using grub’s editing tools. Have a look for the parameter that tells the stage1 installer where to download stage2 and remove /LiveOS/squashfs.img from the end (stage1 automatically appends this).

With this obstacle knocked down you’ll encounter the third and final issuette. When anaconda scans the system to check there is enough disc space to complete the install it can’t find enough space in /boot. Now, by far the biggest thing in  /boot right now is the stage1 installer image which has already been copied to RAM. In otherwords if you can delete it from /boot before anaconda checks there’s enough space then the upgrade process will finally work! If you have an encrypted root filesystem this is no problem because you have to enter a password before the space check. If you don’t have any encrypted partitions then you’ll have to be the worlds fastest typist to beat the space check. Good luck!

These are the commands needed to delete the preupgrade stage1 installer:

mount LABEL=/boot /boot
rm /boot/upgrade/initrd.img
 rm /boot/upgrade/vmlinuz
 umount /boot
 rmdir /boot

Note that you may have to tailor the initial mount command if your /boot partition is not labeled /boot.

Finally don’t worry about the wanton destruction of the stage1 files. As I say they are already loaded into RAM and if for some reason the upgrade still don’t work and you need to reload them a try again then you can just re-run preupgrade.

Have fun…

I found a really nasty problem with the bug tracker we use at work last week. If someone else posts to it whilst you are composing your comment it refuses to accept it. It doesn’t offer a “post comment anyway” feature and advises instead that you:

• Press Back
• Select the comment you have just written
• Copy it to the clipboard
• Reload the page in your browser
• Paste the comment back into the text field

Other than the obvious epic fail regarding usability there is one additional problem in the instructions above. When you press back the rich text editing widget no longer has your comment in it! That’s right. Forty five minutes expressing my highly insightful view point as clearly as possible… gone.

Grrr…

I could tell the text was still there because I could press Forward and refresh but I just couldn’t see it.

At this point I fired up wireshark to try and capture my work as it went out over the network. This was when I realized that the bug tracker was using SSL and trying to launch a man-in-the-middle attach on myself was likely a waste of time.

So, the last resort of the desperate(ly lazy) is to grab the data from the memory image itself. That should be dead easy, I’ve been running GNU/Linux at home for almost fifteen years. I must have learnt my way around by now. Surely I just attach to a running process and dump its memory.

Having got the PID of the firefox process I fired up gdb:

 butch$ gdb
 GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
 Copyright (C) 2011 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law. Type "show
 copying" and "show warranty" for details.
 This GDB was configured as "i686-redhat-linux-gnu".
 For bug reporting instructions, please see:
 .
 (gdb) attach 23639
 Attaching to process 23639
 /usr/lib/firefox/firefox (deleted): No such file or directory.

At this point I tried the gcore command. No luck there either. gdb couldn’t figure out the memory ranges it needed to dump. Still I’m not one to give up. After trying and failing to scan /proc/23639/mem I decide to scan the list of the memory mappings and dump each one. When I discovered that firefox had over 700 blocks of mapped memory I decided to generate a gdb script to dump the memory automatically:

cat /proc/23639/maps \
| cut -d' ' -f1 \
| tr '-' ' ' \
| awk '{ print "dump memory core-" $1 "-" $2 " 0x" $1 " 0x" $2 }' \
> dumpmem.gdb

It worked. I have the memory in files. From here things get much easier:

cat core-* | strings | grep -C 40 BD-ROM | less

Yay.