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.
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"
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.
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
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.
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 |
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.
