Fedora Core

This post follows on from my earlier one on Moving a FC5 Root Partition to LVM. In this episode, I conclude the work by moving the /boot partition to the new drive and do everything else necessary to remove the old drive.

One of my servers is pretty old, dating back to the dawn of recorded history — or Red Hat 7 as we now call it. Most of its storage has been migrated onto a new hard disk and the Logical Volume Manager some time ago. Finally removing the original hard drive requires a few tricky operations: moving the root partition, moving the boot partition, and moving the boot loader.

These operations are turning out to be tricky enough to make it worth writing down the procedure in case I ever need to use it again. So, here’s an aide-mémoire on moving a Fedora Core 5 root partition onto LVM.

Not installing security updates isn’t really a viable strategy these days. Even waiting a few days to see whether other people have trouble with the update is problematic when a zero day exploit might be available.

It’s a bit like playing Russian Roulette in a room full of people who feel their job is to point their guns at you until you pull the trigger.

Obviously this goes wrong once in a while. The recent Samba 3.0.23 update broke access from Windows and Mac machines on my Fedora Core 4 system, but some people with Fedora Core 5 are reporting that all logins to their systems are disabled.

After a bit of searching around and trying various things, I found that in my case I could bring my system back to life by “upgrading” to an older version of the four packages in question.

There is some indication that version 3.0.23a will be out real soon now… but that doesn’t really make me feel completely happy. Nor does the realisation that my FC4 system will officially be “legacy” next week and I’ll need an upgrade to at least FC5 to stay within my “properly supported” comfort zone.

This kind of thing does seem to happen more often with Fedora, and anecdotally seems to be related to their strategy of pulling in new releases rather than back-porting security fixes. Moving to a more “enterprise” style system for the places where I need stability rather than the latest features is probably the right answer for me; once RHEL 5 is out I will probably take a close look at it and the equivalent CentOS release.

[Update 20060729: the 3.0.23a release doesn’t fix the problem, at least for me.]

I have just spent most of the day trying to get a large SATA disk drive working in my main Linux server. Some combination of Fedora Core 3, Linux 2.6.11, the Seagate ST32508823AS drive, the drive firmware (3.1), the SATA controller, my motherboard, my motherboard settings, my processor, my power supply and for all I know my haircut and the phase of the moon are conspiring to make this not work. Well, to be precise it works really well until I try and move a few tens of GB of data on to it: then, it stops working.

I feel like a dog wearing a collar that gives it a shock when it crosses the invisible fence line placed by its owner. Something huge and inscrutable has decreed: thus far, and no further; bad dog, don’t go there. I could spend another day and perhaps make some progress, or perhaps not. Experience has taught me that the odds aren’t good that I will ever really understand the problem.

So instead I will buy an equivalent IDE drive for less money than I could earn in the time I’ve already wasted, and it will work and the collar will stop giving me shocks. Perhaps one day I will find a system I can make this drive work in.

This is not the most satisfactory outcome, but all I can do about it is bark in frustration.