|
|
New Year, New Hard DrivesAdding new drivesI'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:
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 partitionThe 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 partitionsThe 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 mirrorThis 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 setupWhen 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?
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:
Freeing Windows 7 from legacy Windows XP installBack 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 the PowerShell with Administrator privileges (right-click on the PowerShell icon to see the option to run as Administrator): bcdedit 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.
|