BIOS Drive0 - Kingston / SSD / 120GB
BIOS Drive1 - WD / HDD / 160GB
Both drives are SATA, and both are configured as AHCI in BIOS:
My weapon of choice when doing low level disk stuff or recovery is SystemRescueCd. It's a nice little gentoo-based bootable live CD/USB that has most of the tools you would ever need for recovery tasks.
While booted into SystemRescueCd, the SSD would be sda, and the HDD would be sdb.
A little digression: I used to check for physical devices by using fdisk -l. This is no longer the case. The reason is because fdisk -l also prints a LOT of spam, especially if you use LVM. Lack of support for GPT partition tables is also another reason. Sure, grep is always handy, but the more elegant solution is to use parted. The output below is from my laptop, not from the system I was working on at the time.
I find this list to be much more readable. The drawback is that you can't have a universal oneliner. I always use this method, because '
In some of my previous experiences, I would '
This is why for the HDD, I first removed all lvs/vgs/pvs, and then recreated the partition table using parted. I'm not saying this is the correct way to do this, or that parted wouldn't have done this automatically. I was just using the method I know works, because of lazyness :)
After I've prepared the HDD, it was time:
I could have used
Afer the dump. I've turned off the computer and used the BIOS-select-boot-device at startup to use the HDD.
This is when something interesting happened: Windows started booting off the HDD (that WD drive churns like crazy), and then the drive got silent, but Windows kept booting. Weird. I logged in... pretty fast. No peep from the HDD. This required investigation. I opened the "Disk Management" in Windows, and saw that the HDD was "ignored" because it had the same ID as the SSD. My guess is that the kernel started loading from the HDD, and then switched over to loading from the SSD once it found a problem, or because they had the same ID.
I shut down the computer, and disconnected the SSD. When I turned the computer back on, the boot sequence completed, HDD churning all the way, and I was able to log in. Success! The only problem was that the hard drive was heavily fragmented (20% according to Windows), which contributed to even more noise from the HDD. After the defrag, which took a couple of hours, the noise from the hard drive reduced significantly.
After the successful test, I installed Linux on the SSD - Debian Jessie. I hit a snag there. Grub did not do it's job at the end of the Debian installer. I had to once again resort to SystemRescueCd, chroot and re-run grub-install.
As a finishing touch, I swapped the SATA cables. I wanted the HDD to be Device0 in BIOS. The priority can be changed in BIOS, but I like things being as low level as possible. Booting into Windows, and looking at the "Disk Management" no longer ignored any of the drives, because our SSD had a brand new partition table, and non-Windows partitions.
BIOS Drive1 - WD / HDD / 160GB
Both drives are SATA, and both are configured as AHCI in BIOS:
- Kingston SSD: This was the primary, bootable drive which held Windows 7.
- WD HDD had a test Linux distribution with LVM, which I did not use or need. It was ready for nuking down.
My weapon of choice when doing low level disk stuff or recovery is SystemRescueCd. It's a nice little gentoo-based bootable live CD/USB that has most of the tools you would ever need for recovery tasks.
While booted into SystemRescueCd, the SSD would be sda, and the HDD would be sdb.
A little digression: I used to check for physical devices by using fdisk -l. This is no longer the case. The reason is because fdisk -l also prints a LOT of spam, especially if you use LVM. Lack of support for GPT partition tables is also another reason. Sure, grep is always handy, but the more elegant solution is to use parted. The output below is from my laptop, not from the system I was working on at the time.
# parted
(parted) print devices
/dev/sda (320GB)
/dev/mapper/sys-root (26.1GB)
/dev/mapper/sys-swap (2047MB)
/dev/mapper/sda5_crypt (114GB)
(parted) quit
#I find this list to be much more readable. The drawback is that you can't have a universal oneliner. I always use this method, because '
parted /dev/sda print devices' might not work on every system.In some of my previous experiences, I would '
dd if=/dev/zero of=/dev/drive-to-nuke bs=1M count=20' (nuke 20MB where disk begins). This would, of course, destroy the partition table and MBR. However, when you re-create the partition table (at least with fdisk), the LVM data creeps back up. I did not go in depth into researching why this is, but rather undo any LVM config on that drive before nuking.This is why for the HDD, I first removed all lvs/vgs/pvs, and then recreated the partition table using parted. I'm not saying this is the correct way to do this, or that parted wouldn't have done this automatically. I was just using the method I know works, because of lazyness :)
After I've prepared the HDD, it was time:
dd if=/dev/sda of=/dev/sdb bs=1MI could have used
bs=4096, to match the block size of both drives, but I just used that times 256, to see if the performance would be different. It turns out that the performance is the same. Disk dump speeds ran at about 50-60MB/s, which was the maximum for the HDD writes.Afer the dump. I've turned off the computer and used the BIOS-select-boot-device at startup to use the HDD.
This is when something interesting happened: Windows started booting off the HDD (that WD drive churns like crazy), and then the drive got silent, but Windows kept booting. Weird. I logged in... pretty fast. No peep from the HDD. This required investigation. I opened the "Disk Management" in Windows, and saw that the HDD was "ignored" because it had the same ID as the SSD. My guess is that the kernel started loading from the HDD, and then switched over to loading from the SSD once it found a problem, or because they had the same ID.
I shut down the computer, and disconnected the SSD. When I turned the computer back on, the boot sequence completed, HDD churning all the way, and I was able to log in. Success! The only problem was that the hard drive was heavily fragmented (20% according to Windows), which contributed to even more noise from the HDD. After the defrag, which took a couple of hours, the noise from the hard drive reduced significantly.
After the successful test, I installed Linux on the SSD - Debian Jessie. I hit a snag there. Grub did not do it's job at the end of the Debian installer. I had to once again resort to SystemRescueCd, chroot and re-run grub-install.
As a finishing touch, I swapped the SATA cables. I wanted the HDD to be Device0 in BIOS. The priority can be changed in BIOS, but I like things being as low level as possible. Booting into Windows, and looking at the "Disk Management" no longer ignored any of the drives, because our SSD had a brand new partition table, and non-Windows partitions.
No comments:
Post a Comment