New Year, New Hard Drives

Adding new drives

I'd purchased two Western Digital 1TB SATA drives to expand the available disk storage on amber. Two, because I planned to mirror the storage.

Prior to the upgrade, the disk setup was:

Disk Type Usage Grub Debian Windows
WDC 250GB SATA Windows 7 / Debian Lenny hd0 sdb C:
WDC 250GB SATA Windows XP hd1 sda D:

Installing the new drives and re-booting gave me my first problem: Debian would not boot. The boot process hung "waiting for root device". Inspection revealed that Debian's disk had been renamed; rather than sdb it was now sdc.

Obviously, adding the new drives had caused the renaming to take place. However, rather than figuring out the root cause of the renaming, I decided to make use of partition labels to ensure that the Debian disk could be found irrespective of the OS disk name. I rebooted after removing the new drives (Debian was called sdb again) and performed the following.

Label swap partition

The swap partition was unlabelled and had no UUID. It looked like the only way to add a label was using mkswap, so:

  # swapoff -a
  # mkswap -Lswap /dev/sdb6
  # blkid /dev/sdb6
  /dev/sdb6: TYPE="swap" LABEL="swap" UUID="56c83a17-5a30-4ab3-8dc3-5613f0473876"

Label ext3 partitions

The ext3 paritions are labelled by tune2fs:

  # tune2fs -Lroot /dev/sdb5
  # tune2fs -Lhome /dev/sdb10
  # tune2fs -Lrep  /dev/sdb11
  # tune2fs -Ltmp  /dev/sdb7
  # tune2fs -Lusr  /dev/sdb9
  # tune2fs -Lvar  /dev/sdb8
  # findfs LABEL=root
  /dev/sdb5

/etc/fstab has to be modified to reference the labels instead of devices, like so:

  # /etc/fstab: static file system information.
  #
  # <file system> <mount point>   <type>  <options>       <dump>  <pass>
  proc            /proc           proc    defaults        0       0
  LABEL=root      /               ext3    errors=remount-ro 0       1
  LABEL=home      /home           ext3    defaults        0       2
  LABEL=rep       /rep            ext3    defaults        0       2
  LABEL=tmp       /tmp            ext3    defaults        0       2
  LABEL=usr       /usr            ext3    defaults        0       2
  LABEL=var       /var            ext3    defaults        0       2
  LABEL=swap      none            swap    sw              0       0
  /dev/hda        /media/cdrom0   udf,iso9660 user,noauto     0       0
  /dev/hdb        /media/cdrom1   udf,iso9660 user,noauto     0       0

Finally, the GRUB menu.lst file has to be modified to indicate where the root partition can be located (I use the kopt facility):

  # kopt=root=LABEL=root ro printk.time=0

Don't forget (like I did) to update-grub before re-booting. Note that if resume is enabled, it will complain the first time you re-boot. After that, everything will be OK.

With the new disks re-attached, I could boot into Debian even though the Debian disk was now sdc.

Creating the mirror

This turned out to be very simple. The new disks were seen as sdb and sdd. First, I created a single partition on each disk, spanning the entire device using fdisk. To create the mirror, you need mdadm, which I installed via apt-get. Then:

  mdadm --create /dev/md0 --level mirror --raid-devices=2 /dev/sdb1 /dev/sdd1

Then, create the file system on the mirrored device:

  mkfs.ext3 /dev/md0

Finally, add a line into /etc/fstab to mount the mirrored device:

  /dev/md0    /tank       ext3    defaults    0       0

And now we have:

  # df -h
  Filesystem            Size  Used Avail Use% Mounted on
  /dev/sdc5             471M  294M  154M  66% /
  tmpfs                 1.5G     0  1.5G   0% /lib/init/rw
  udev                   10M  820K  9.2M   9% /dev
  tmpfs                 1.5G     0  1.5G   0% /dev/shm
  /dev/sdc10             19G  3.7G   14G  22% /home
  /dev/sdc11            100G   23G   72G  25% /rep
  /dev/sdc7             942M   18M  877M   2% /tmp
  /dev/sdc9             5.5G  1.4G  3.9G  27% /usr
  /dev/sdc8             1.2G  234M  924M  21% /var
  /dev/md0              917G  200M  871G   1% /tank
  topaz:/home/mark       20G  2.2G   16G  13% /mnt

Later...

After installing a new kernel image (2.6.26-21lenny3), I found that the md array was not being assembled automatically at boot time; therefore the mount onto /tank failed.

My fears that the disks had been damaged seemed unfounded, as the results of mdadm -E /dev/sdb1 showed:

  /dev/sdb1:
  Magic : a92b4efc
  Version : 00.90.00
  UUID : 50144dd5:53a81d78:173b5c72:0a49ac2c
  Creation Time : Wed Dec 30 15:17:44 2009
  Raid Level : raid1
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
  Array Size : 976759936 (931.51 GiB 1000.20 GB)
  Raid Devices : 2
  Total Devices : 2
  Preferred Minor : 0

  Update Time : Sun Feb 21 17:42:35 2010
  State : clean
  Active Devices : 2
  Working Devices : 2
  Failed Devices : 0
  Spare Devices : 0
  Checksum : 3f61d09b - correct
  Events : 86


  Number   Major   Minor   RaidDevice State
  this     0       8       17        0      active sync   /dev/sdb1

  0     0       8       17        0      active sync   /dev/sdb1
  1     1       8       49        1      active sync   /dev/sdd1

Manually assembling the array seemed to work with:

  mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdd1

In the end, I added the following line to the /etc/mdadm/mdadm.conf file:

  ARRAY /dev/md0 devices=/dev/sdb1,/dev/sdd1

Now the array was assembled at boot time. Still don't understand why I had to add the explicit ARRAY line to mdadm.conf.

Windows 7 boot setup

When I rebooted into Windows, yet more problems. GRUB complained there was nothing to boot. Oh yeah, that's right, now hd1 has become hd2. The simple fix was to update the /boot/grub/menu.lst file to point the Windows root to (hd2,0), which I did. Then I realised (or remembered I forgotten), that in the original install of Windows 7 beta, I'd updated from Windows XP and the Windows 7 boot code was all on the XP drive (D:). If I blew away the contents of D: (as was my definite intention) I would no longer be able to boot Windows 7. Hmm, better free Windows 7 from the boot dependency on D:. But that comes later...

So, before we go on, what does the disk setup look like now?

Disk Type Usage Grub Debian Windows
WDC 250GB SATA Windows 7 / Debian Lenny hd0 sdc C:
WDC 1000GB SATA ext3 mirrored disk hd1 sdb N/A
WDC 250GB SATA Windows XP hd2 sda D:
WDC 1000GB SATA ext3 mirrored disk hd3 sdd N/A

I was experimenting (in parallel) with Wake On LAN (WOL). Nothing I tried made it work, so my last option was to upgrade the BIOS. On re-boot, GRUB complained about "Error 22" and stopped. Hmm, the BIOS flash had altered the boot order and stopped GRUB booting - rather than change the BIOS boot order settings, I swapped the 250GBs SATA connections. This made GRUB OK. Of course, WOL still didn't work. More on this at another time.

This made me question how GRUB enumerates the disks. Surprise, it is by BIOS boot order. Once I realised this, I altered the BIOS boot order, such that the 250GB disks were defined before the 1000GB disks. Now the disk layout is:

Disk Type Usage Grub Debian Windows Physical Location BIOS Designation
WDC 250GB SATA Windows 7 / Debian Lenny hd0 sda C: Lower SATA:3S-WDC WD2500JS
WDC 250GB SATA Windows XP hd1 sdc D: Middle Lower SATA:5M-WDC WD2500JS
WDC 1000GB SATA ext3 mirrored disk hd2 sdb N/A Upper Lower SATA:4S-WDC WD10EADS
WDC 1000GB SATA ext3 mirrored disk hd3 sdd N/A Upper SATA:6M-WDC WD10EADS

Freeing Windows 7 from legacy Windows XP install

Back to the problem of removing the Windows 7 boot dependency on the D: (old Windows XP) drive. After some research via Google, the following command in Recovery mode from the Windows 7 DVD seemed to offer a fix, i.e to install the necessary boot code on "C:\":

  bootsect /nt60 C:

On reboot, I asked GRUB to boot from (hd0,0), where Windows 7 resides. Wndows 7 didn't boot, but I did get a clue from the error message, which complained about the absence of bootmgr. I copied bootmgr from D: (you need to unhide operating system files to see it) to the C: drive and tried once more to boot from (hd0,0). This time the complaint concerned missing boot options. Hmm, was this caused by a missing BCD (Boot Configuration Data) file? The BCD replaces the old boot.ini file, as far as I can tell.

More googling revealed a way of building the BCD, once again via the recovery console, using:

  bootrec /RebuildBCD

Another reboot. This time, I was met with a blank screen, but the disk was doing something. After a few moments, the Windows 7 login screen appeared. Partial success! But where was the splash screen? Back to Google. The problem seemed to be caused by the default locale (en-US) applied when the BCD was created. The fix (and this time it didn't need the Windows 7 DVD) was running the following command, which updates the locale, in a Command Prompt window with Administrator privileges (right-click on the Command Prompt icon to see the option to run as Administrator):

  bcdboot C:\Windows /l en-EN

Finally, the Windows 7 boot worked, complete with splash screen. To double check, I disconnected the D: drive to check the boot still worked. Yep, Windows 7 was now free of the XP legacy disk.