PreviousINDEXNext
OpenSMTPD and OpenBSD 5.2Installing Debian Wheezy (Testing)

Adding an SSD

To improve the performance of amber, I bought another 4GB of memory and a 250GB SSD (Samsung 840 Series), a 2.5" form factor. Since I'd run out of 3.5 hard drive bays, I had to buy a 5.25" to 2.5" adapter in order to mount the SSD in the case.

I planned to install a fresh Windows 7 on the SSD, figuring I knew all the pitfalls from my previous messing about with disks. However, as usual, there were some new learning experiences.

First, there seems to be no logic in how the motherboard detects and orders the hard drives. While it is possible to control the order of disks for grub, by specifying the boot order in the BIOS, Linux identifies the disks in the sequence detected by the BIOS. With the SSD connected, the BIOS disk order was:

  1. SATA:3S-WDC WD2500JS
  2. SATA:4M-Samsung 840 Series
  3. SATA:4S-WDC WD10EADS
  4. SATA:5M-WDC WD2500JS
  5. SATA:6M-WDC WD10EADS

I cannot figure out how this order relates to which SATA ports the disks are physically connected to. Maybe it is just how the disks respond to the initial probes.

The first problem was that the mirrored drives in Debian now had different device identifiers, sdb and sdd had become sdc and sde, respectively. The mirror array was not built. To fix this, I used the UUIDs of the drives in the mdadm.conf rather than the OS identifiers. This was performed with the following commands:

  # mdadm -Ebcs partitions # scan for arrays and display ARRAY directive
  ARRAY /dev/md0 UUID=50144dd5:53a81d78:173b5c72:0a49ac2c 
  # # test assembly with uuid
  # mdadm --assemble /dev/md0 --uuid=50144dd5:53a81d78:173b5c72:0a49ac2c

This worked, so I knew it was safe to place the ARRAY directive in mdadm's configuration file.

Here's a summary of the disk organisation:

Disk Type Usage Grub Debian Windows (HD) Windows (SSD) Physical Location BIOS Designation
WDC 250GB SATA Windows 7 / Debian Squeeze hd0 sda C: D: Lower SATA:3S-WDC WD2500JS
SSD 250GB SATA Windows 7 hd4 sdb G: C: 5.25" drive bay SATA:4M-Samsung 840 Series
WDC 250GB SATA Windows Data hd1 sdd D: E: Middle Lower SATA:5M-WDC WD2500JS
WDC 1000GB SATA ext3 mirrored disk hd2 sdc N/A N/A Upper Lower SATA:4S-WDC WD10EADS
WDC 1000GB SATA ext3 mirrored disk hd3 sde N/A N/A Upper SATA:6M-WDC WD10EADS

The next problem was getting the Windows 7 boot configuration to play with the GRUB boot. As had happened before, installing Windows 7 overwrote the GRUB MBR, so I had to restore it by booting into Debian via a GRUB boot CD.

I could boot Windows 7 on the SSD by chainloading into hd0, but GRUB didn't allow that to hd4, presumably because there was no boot sector on the SSD. I rectified this as described previously, except this time I used the bcdboot command to rebuild the system BCD.

I then wanted to edit the BCD files on both instances of Windows 7. On the SSD it needed one entry, so booting from GRUB would be direct, while on the old hard drive, I still wanted both entries, but clearly identified as to which was entry for the SSD and which was not. First I tried using bcdedit from the PowerShell window, but every attempt to set a new value was met with the same error:

  PS C:\Windows\system32> bcdedit /set {default} description "Windows 7 (SSD)"
  The set command specified is not valid.
  Run "bcdedit /?" for command line assistance.
  The parameter is incorrect.
  PS C:\Windows\system32>

This was deeply frustrating as it turns out this is a problem with Powershell, and works just fine from a Command Prompt window. The next issue was that no matter how I modified the description in the BCD file on the SSD, on boot, it would be the same as before. I finally discovered that the default store (the system store) that bcdedit was manipulating was not on the SSD but on the old hard drive. I had to use this style of command to make the changes I wanted:

  bcdedit /store C:\boot\BCD /set {default} description "Windows 7 (SSD)"
  bcdedit /store C:\boot\BCD /delete {1edd9dcc-f706-11de-8ee9-8fa35a0bc640}

It took me a while to figure out that the partition identifiers in the bcdedit display are relative to the instance that's booted. Now, the BCD on the SSD looks like this (when booted into the SSD):

  Windows Boot Manager
  --------------------
  identifier              {bootmgr}
  device                  partition=C:
  description             Windows Boot Manager
  locale                  en-EN
  inherit                 {globalsettings}
  default                 {default}
  resumeobject            {9cff3092-9941-11e2-b29d-0021855ea9d9}
  displayorder            {default}
  toolsdisplayorder       {memdiag}
  timeout                 30

  Windows Boot Loader
  -------------------
  identifier              {default}
  device                  partition=C:
  path                    \Windows\system32\winload.exe
  description             Windows 7 (SSD)
  locale                  en-EN
  inherit                 {bootloadersettings}
  osdevice                partition=C:
  systemroot              \Windows
  resumeobject            {9cff3092-9941-11e2-b29d-0021855ea9d9}
  nx                      OptIn
  detecthal               Yes

While on the old version of Windows 7 it displays as (when booted into the old hard drive):

  Windows Boot Manager
  --------------------
  identifier              {bootmgr}
  device                  partition=C:
  description             Windows Boot Manager
  locale                  en-EN
  inherit                 {globalsettings}
  default                 {default}
  resumeobject            {1edd9dcd-f706-11de-8ee9-8fa35a0bc640}
  displayorder            {default}
                          {1edd9dcc-f706-11de-8ee9-8fa35a0bc640}
  toolsdisplayorder       {memdiag}
  timeout                 30

  Windows Boot Loader
  -------------------
  identifier              {default}
  device                  partition=G:
  path                    \Windows\system32\winload.exe
  description             Windows 7 (SSD)
  locale                  en-EN
  inherit                 {bootloadersettings}
  osdevice                partition=G:
  systemroot              \Windows
  resumeobject            {1edd9dcd-f706-11de-8ee9-8fa35a0bc640}
  nx                      OptIn
  detecthal               Yes

  Windows Boot Loader
  -------------------
  identifier              {1edd9dcc-f706-11de-8ee9-8fa35a0bc640}
  device                  partition=C:
  path                    \Windows\system32\winload.exe
  description             Windows 7
  locale                  en-EN
  inherit                 {bootloadersettings}
  osdevice                partition=C:
  systemroot              \Windows
  resumeobject            {1edd9dcb-f706-11de-8ee9-8fa35a0bc640}
  nx                      OptIn
  detecthal               Yes

So, was it worth the hassle and money? I timed the duration between boot menu selection and the display of the user login screen:

Boot Device Boot Time
Hard Drive 33s
SSD 21s

The SSD cuts boot time by about a third. Not stellar, but nice to have. The other benefit is that program start-up time on the SSD is almost instant, no disk lag at all. Mmmmm, nice!

PreviousINDEXNext
OpenSMTPD and OpenBSD 5.2Installing Debian Wheezy (Testing)