Not an early adopter, I. Not for technologies I’m not helping develop….
I finally upgraded to Fedora Core 7. It went smoothly, with just two hiccups, one which Fedora could ease, and the other which was entirely my fault but serves as a good warning of how things could go wrong.
When updating the laptop, Anaconda complained about there not being
enough space to proceed with the installation. I had to resize my root
partition. Partition resizing is relatively easy in general if you’re
using Logical Volume Management (LVM), as I am, but has an extra wrinkle
when you’re trying to resize the root partition itself. Here are the
steps that I took, gleaned from various sourced but mostly from the
LVM
HOWTO:
- Boot from the rescue disk, mount filesystems when prompted
Unmount the partition you’ll be shrinking to make room for the partition you’ll be extending. My shrinking partition was /dev/VolGroup00/LogVol06, mounted on /mnt/sysimage/scratch
umount /mnt/sysimage/scratch
Check the shrking partition’s filesystem
e2fsck -f /dev/VolGroup00/LogVol06
Resize the shrinking partition’s filesystem. The second argument below is the new size of the partition expressed as the number of 4K blocks
resize2fs /dev/VolGroup00/LogVol06 965120
Reduce the shrinking partition, extend the growing partition. In my case, the growing partition was /dev/VolGroup00/LogVol00
cd /usr/sbin
lvm lvreduce -L-350M /dev/VolGroup00/LogVol06
lvm lvextend -L+350M /dev/VolGroup00/LogVol00
Reboot from rescue disk, do not mount filesystems when prompted
Expand the growing partition’s filesystem
cd /usr/sbin
lvm vgchange -a y
e2fsck -f /dev/VolGroup00/LogVol00
resize2fs /dev/VolGroup00/LogVol00
After doing all this, I could successfully upgrade my system.
The second hiccup occurred on my desktop. After upgrading and a day or
so of subsequent use, I suddenly found that post-boot, the login
screen (gdm) would not appear; in its place, X showed only a message
box that said Greeter application appears to be crashing. Attempting
to use a different one. VNC sessions would not boot up properly, logging instead (in ~/.vnc) a different message: GConf Error: Failed to contact configuration server; ...
After much web research, I found two possible culprits. One was the
accessibility option in gdm, so I turned that off: I sshd in
remotely, ran gdmsetup and turned off accessibility. That made the
greeter show up, and I could log in….but my session immediately
terminated with a different dialog box showing a log message that I
was out of disk space. VNC sessions still would not initiate properly.
The other possible culprit was my root partition being full. Unlike my
laptop, my desktop does not use LVM, as I’ve been upgrading through
several generations of Linux for, egads, eight years now. df showed
my root partition being full at 100%, although, interestingly, the
ratio of the df-reported Used and Available space was clearly
less than 100%. Apparently, the system restricts about 10% of the disk from
non-root use (otherwise Really Bad Unrecoverable Things Happen), and
df takes that into account when reporting the Use% column.
Anyway, I deleted or moved/symlinked all the files or directories that
I thought were safe, but to no avail. I discovered on the Internet
that a standard utility,
parted, will
resize partitions—but you can’t change the starting location of an
ext2 or ext3 partition, and in my case, the root partition was the
last one on the disk. I was really SOL, up a creek without a paddle,
on a trip without a toothbrush….you get the idea.
This particular story had a happy ending, though. Looking through /
again, I discovered backup directories that shouldn’t have been
there. Apparently something had gone wrong with my automatic back-up
scripts and they had been written to the wrong location. I deleted
those directories, my root partition usage fell by almost half, and my
system is functional again.
The morals of this story are:
- never let your root filesystem get too full
- use LVM whenever you can to make partition resizing easier
