On my home workstation, I used LVM for the one 160GB hard drive. When I first built the box (in May of 2004), I installed Fedora Core 2 for x86_64; it's a dual AMD Opteron 242 (1.6GHz). I created four partitions:

1. 100MB /boot/
2. 2GB swap (there's 1GB RAM, but I can expand to 8GB)
3. remainder (~96GB) LVM
4. 60GB Windows XP Professional

For a couple of weeks, I have been unable to install any updates to FC5. When I run yum update, I get a series of error messages telling me that yum needs additional disk space on the root partition in order to install packages. Strangely enough, almost none of those packages have files that end up in the root partition.

The root filesystem was a 512MB ext3 LVM logical volume. Sure, I could make it bigger, but I shouldn't have to. In fact, I should be able to have it be only about 256MB and still have a completely usable system. I have /home/, /tmp/, /usr/, /var/ and even /opt/ all split off onto their own LVs, so there's not that much stuff left on the root volume. In fact, running du -sx / shows that there is just barely 200MB of data present. However, running df / shows that it is 99% full (about 508MB used). Clearly, ext3 is not an efficient choice for a root partition when the bulky filesystems are split out like this.

So, I decided to "convert" to another filesystem type. I chose to use XFS for the root volume. Converting the root partition can be a little bit tricky, as the initrd needs to have the right drivers to work with it. Here's my step-by-step (assuming that the volume group is named system):

1. Create a new volume and format it with the new filesystem type (the size could be smaller, if desired):

   # lvcreate -L 512MB -n newroot system
   # mkfs.xfs /dev/system/newroot
   

2. Mount the new root volume and remount the current root volume read-only:

   # mkdir /mnt/temp
   # mount /dev/system/newroot /mnt/temp/
   # mount -o remount,ro /
   

3. Copy the contents of just the root volume to the new root volume (the -x switch is very important):

   # cp -ax /* /mnt/temp/
   

4. Unmount the new root volume:

   # umount /mnt/temp/
   

5. Run uname -r and record the value. This will be needed later when running mkinitrd.
6. Reboot the system into a rescue environment. In order to be able to boot with the new root partition, it is necessary to recreate the initrd. You could hand edit the existing one(s) to fix things up, but this will be quite a bit easier. Use a CD or a network bootable rescue environment for your distro (FC5 in my case).
7. If you let the setup for the rescue environment mount your partitions/volumes, that's fine, just make sure to unmount everything so you can switch root partitions. If you don't let it mount up the parts, that's fine too; just use the LVM commands for your rescue environment to activate LVM.
8. Rename the old root volume out of the way and rename the new one into place (this only works while the volumes are not mounted):

   # lvrename system root oldroot
   # lvrename system newroot root
   

9. Mount the (new) root volume and at least /boot/ and /usr/ on top of that:

# mkdir /mnt/system/
# mount /dev/system/root /mnt/system/
# mount /dev/sda1 /mnt/system/boot/
# mount /dev/system/usr /mnt/system/usr/

10. It's time to recreate the initrd. This is easiest when done chroot'ed into the system environment found on your hard drive (assuming your new root volume was mounted at /mnt/system/):

    # chroot /mnt/system/
    

11. Run mkinitrd. Depending on which distribution is installed, this could require quite a different set of switches than what I'm showing you here. In my case, it was Fedora, so I used the mkinitrd command found in the /sbin/new-kernel-pkg script, which is run as part of the post-install scripts from every Red Hat kernel RPM (just open up /sbin/new-kernel-pkg and find the right command to run, replacing "something" with the correct kernel version string recorded earlier from the uname -r command):

    # /sbin/mkinitrd --allow-missing -f /boot/initrd-2.6.something 2.6.something
    

12. Leave the chroot environment and unmount everything (yes, if you just cleanly exit the rescue environment, it should cleanly unmount everything, but let's just be sure it happens right, shall we?):

    # exit
    # umount /mnt/system/usr/
    # umount /mnt/system/boot/
    # umount /mnt/system/
    

13. Reboot. The system should come up with your root volume in use with a new filesystem type.

That's it. That wasn't so difficult, was it?

The entire thing could be done from within the rescue environment, including copying the contents of the root volume to the new root volume, if you like.

Today, I decided to figure out how to keep Windows client's clock synchronized with NTP. A quick Google search located an NIST PDF document titled, "Configuring Windows 2000 and Windows XP to use NIST Time Servers." There is also a link in the introductory pages of that document to the freely available download from Microsoft to enable Windows NT systems to be configured as NTP clients.

As it turns out, it's really easy to configure Windows 2000 and Windows XP Professional, as they both have native, out-of-the-box support to run as a NTP clients. So, to boil down the NIST's 12 page document, open a "DOS prompt" command shell as a user with admin rights and run:

> net /setsntp:servername
> net stop w32time
> net start w32time

That's it.

You could also use the Time/Date control panel. When I tried it (first) on one of my boxes, it had the default configuration of using a Microsoft time server already configured. When I changed it in that dialog box to use my time server, it griped that it wouldn't use the time I was providing as the server's stratum was lower than the host's. I wonder what goofy things Microsoft's time server is doing, as my time server is stratum 2. Anyway, I ran those three commands and it successfully switched over to using my NTP server.

You would think that the fact that Windows 2000 and Windows XP have the NTP client built-in would be one of those things that I would have already "just known." Well, I didn't, but now I do.

-A INPUT -p udp --sport 68 --dport 67 -m state --state new -j ACCEPT

Account Balance Update Dear LAMONT R PETERSON, Tier Level: {% if ( = " " ) %}Dividend Miles{% endif %} {% if ( = "S" ) %}Silver Preferred{% endif %} {% if ( = "G" ) %}Gold Preferred{% endif %} {% if ( = "P" ) %}Platinum Preferred{% endif %} {% if ( = "C" ) %}Chairman's Preferred{% endif %} Dividend Miles #: 1234567890 Welcome to the new Dividend Miles: You now have access to over 842 worldwide destinations at your fingertips and mileage-earning opportunities with over 100 partners such as hotels, rental car and financial service companies, just to name a few. . . . snip . . .

1. 700MHz AMD Duron processor
2. Syntax SV266AD motherboard
3. 1GB RAM, 1 DIMM from Crucial
4. 4GB Quantum Fireball hard drive (used for OS with separate LVM VG)
5. 45GB hard drive (Western Digital WD450AA)
6. 120GB hard drive (Western Digital WD1200BB