|
|
Crimson is dead, long live CrimsonThe need to re-decorate the 'computer' room led to a re-assessment of the hydrus IT estate. Time to declutter. There were far too many computers in the hydrus network:
Stuff had to go and the older machines were obviously the ones to axe. While crimson and chrome had served me well, their time had come. My plan was to move the crimson and chrome hard drives (2xFreeBSD and 1xDebian) to silver, since it had two spare IDE controller ports plus IDEs for handling RAID. At least crimson and chrome would live on in a reincarnated state. My first attempt wasn't too successful. I loaded crimson's hard drive into silver, making it the primary master drive. While it booted OK, the kernel would not boot as it had been compiled for a 586 chip. This was simple to fix: I put the disk back in crimson, installed the generic kernel from topaz and lo it booted. Crimson was back. Since the new hardware supported ACPI, I installed all the GENERIC modules. This left the root partition low on space, even without installing the debug version of the modules. At some point I would have to rebuild the disk to allow more room for the root partition. I then installed chrome's FreeBSD hard drive, putting the Debian hard-drive from chrome into storage. The chrome kernel also had to be replaced by GENERIC and modules (notably acpi.ko) added. I decided to install grub on the crimson drive, so that I would be able to boot all four operating systems. The grub menu.lst file looks like this: default 0 timeout 5 title FreeBSD root (hd0,0,a) kernel /boot/loader title Debian Lenny root (hd1,4) kernel /boot/vmlinuz-2.6.26-1-686 root=/dev/hdc5 ro printk.time=0 initrd /boot/initrd.img-2.6.26-1-686 title OpenSolaris root (hd1,2) chainloader +1 title FreeBSD (ghost of chrome) root (hd2,0,a) kernel /boot/loader I made topaz, the Toshiba laptop, the main server for hydrus, partly because it was the least power hungry, but also because it was quiet. And, it would be pleasant running the server on something a little more performant than a 120MHz processor. On the original silver hard drive, I erased the old Windows 2000 partition and turned them into UFS2 partitions for access by crimson/chrome (/tank and /tank1, respectively). I was initially concerned that I wouldn't be able to format the partitions, as they were logical not physical. I actually used the Linux fdisk to delete and coalesce the Windows 2000 partitions However, FreeBSD does create devices for the logical partitions so it is easy to newfs and mount them. Now silver has transmogrified into:
Resizing the FreeBSD partitionsEach of the FreeBSD instances, crimson, chrome and topaz, had been built a while ago, and the root partition size of 128MB was now too small for FreeBSD 7.x, as it required much more for all the modules, complete with debug symbols (two copies, active and old). I had previously installed 7.x without debug symbols, but figured now was the time to resize the root partition. My first attempt was with the chrome hardrive. Using crimson, I mounted each partition on chrome and tar'd the contents to a backup file. Then I used the sysinstall facility to alter chrome's partition sizes. This worked, but I was unable to newfs the disk partitions which gave me an "Illegal operation" error. There was little via google, but I rebooted crimson and then the new partitions were writable. For crimson and topaz, rather than the sysinstall front-end, I used bsdlabel directly. When invoked with bsdlabel -e ad0s1, it throws you into vi to edit the partition layout. The text looks something like this: # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 16 4.2BSD 2048 16384 8 b: 1048576 1048592 swap c: 78140097 0 unused 0 0 # "raw" part, don't edit d: 1048576 2097168 4.2BSD 2048 16384 8 e: 10485760 3145744 4.2BSD 2048 16384 28552 f: 1048576 13631504 4.2BSD 2048 16384 8 g: 63460017 14680080 4.2BSD 2048 16384 28552 This can be then edited to something like: # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 512M 16 4.2BSD 2048 16384 8 # / b: 1G * swap c: 78140097 0 unused 0 0 # "raw" part, don't edit d: 512M * 4.2BSD 2048 16384 8 # /tmp e: 5G * 4.2BSD 2048 16384 28552 # /usr f: 512M * 4.2BSD 2048 16384 8 # /var g: * * 4.2BSD 2048 16384 28552 # /home where the asterisks tell bsdlabel to compute the offset, or use the remaining disk space in the case of size. The repartition of topaz's disk was slightly more awkward than crimson/chrome, as it has no CD or floppy drive. However, I acquired a USB CD drive and booted from the FreeBSD 7.1 live file system CD. At first I thought it wasn't working as the boot was unbelievably sloooow. Eventually, I was able to get into Fixit mode in order to back up all the partitions. I figured I would do this via NFS onto crimson's /tank file system. I therefore exported /tank via the /etc/exports file and restarted mountd as stated in the man page, i.e. /etc/rc.d/mountd reload. No, /tank was still not mountable via NFS. It seems that using the rc.d mountd script does not work; an explicit kill -HUP `cat /var/run/mountd.pid` is required to get mountd to re-read /etc/exports. Later...After an attempt to install OpenBSD in place of Solaris, I accidently blew away the Debian install. Oops. I put the OpenBSD experiment on hold and decided to re-install Debian Lenny and coalesce the two tank partitions. Here's a table showing how the four disks in the now thoroughly schizoid machine are named and allocated:
The grub menu.lst file now looks like: default 0 timeout 5 title FreeBSD root (hd0,0,a) kernel /boot/loader title Debian Lenny root (hd1,0) kernel /vmlinuz root=/dev/hdc1 ro printk.time=0 initrd /initrd.img # This is not operational at present title OpenBSD root (hd1,3,a) makeactive chainloader +1 title FreeBSD (ghost of chrome) root (hd2,0,a) kernel /boot/loader
|