Why does replacing drive with a dd clone cause machine to hang at boot?

Question

I have a home-brew media server based on a 800MHz Intel Atom with two big LVM drives and Debian 9 on a 250GB 2.5" drive. The latter is showing bad blocks, so I am intending to replace it.

I booted from a Debian live CD and dd'd the entire 250GB disk surface onto a new WD Blue 1TB drive with dd if=/dev/sda of=/dev/sdd with the new disk connected to a USB-SATA interface. Then I fitted the drive into the media server replacing the 250GB one. The machine hangs on boot, just after printing the drive ID and before the boot loader starts. The boot loader was grub legacy. I booted from the live CD and chrooted into the clone which appeared to work fine. So I mounted the LVM volumes, and installed grub2 to the new /dev/sda which claimed to have been successful. But booting from the new HD still locks the machine up as before. I've also run update-initramfs -u -k all, grub-install, update-grub and whathaveyou as one would expect.

I then tried out this boot repair cd which also claimed success but made no difference to the result. The machine hangs early after power-up.

I was warned about not having a small /boot partition near the front of the drive, so I've created one now. No difference. I also tried leaving a 6MB gap before the first partition, aligning to 4K sectors and so on, repeating the whole grub install and boot-repair-disk attempt every time. Every time: won't boot, crashes before you can get into the BIOS screen, but boot from CD and you can chroot into it, so the data seems intact.

Retrofitting the old drive works just fine (for the moment).

This is a very simple machine, MBR msdos-style boot, no EFI, only one OS installed.

Is there a good reason the machine won't boot from a clone of an old 250GB drive made onto a 1TB drive? How does it know? The drive ID doesn't appear anywhere in /boot/grub that I can find. It's all UUIDs.

The old drive has 512B physical sectors, and then new one has 4096B ones, but it has 512B emulation, right?

Here's some of the output from the boot repair CD running against the new drive.

Drive: sda _____________________________________________________________________
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sda1    *      1,036,288   477,345,791   476,309,504  83 Linux
/dev/sda2         477,347,840 1,953,525,167 1,476,177,328   5 Extended
/dev/sda5         477,349,888   489,932,799    12,582,912  83 Linux
/dev/sda3              12,288     1,036,287     1,024,000  83 Linux


Drive: sdb _____________________________________________________________________
Disk /dev/sdb: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sdb1                   1 4,294,967,295 4,294,967,295  ee GPT


GUID Partition Table detected.

Partition  Attrs   Start Sector    End Sector  # of Sectors System
/dev/sdb1                    3415,628,048,06415,628,048,031 Logical Volume Manager (LVM) partition (Linux)

Attributes: R=Required, N=No Block IO, B=Legacy BIOS Bootable, +=More bits set

Drive: sdc _____________________________________________________________________
Disk /dev/sdc: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sdc1                   1 4,294,967,295 4,294,967,295  ee GPT


GUID Partition Table detected.

Partition  Attrs   Start Sector    End Sector  # of Sectors System
/dev/sdc1                 2,048 5,860,532,223 5,860,530,176 Logical Volume Manager (LVM) partition (Linux)

Attributes: R=Required, N=No Block IO, B=Legacy BIOS Bootable, +=More bits set

"blkid" output: ________________________________________________________________

Device           UUID                                   TYPE       LABEL

/dev/loop0                                              squashfs   
/dev/mapper/exported-archive 4b899a61-2f1c-4cd8-bc32-ce435912ba87   ext3       
/dev/mapper/exported-media 36a5370f-d49a-4da3-9bc8-fefa0d005f4f   ext3       
/dev/mapper/exported-photos af677e44-2a83-4aba-8b37-c38c3b07a10b   ext3       
/dev/mapper/exported-web 27040136-28bf-464d-9802-c20511ad661f   ext3       
/dev/sda1        7788ea31-5e63-4869-a80e-40c99c6128b3   ext3       
/dev/sda3        6f547317-4688-435f-a69d-787bf7262f29   ext3       boot
/dev/sda5        a311a5cb-4f03-4930-a028-bf87b4dd8e55   swap       swap
/dev/sdb1        yGbmYE-Lvk1-8lZj-0xQz-u57b-L1sV-0RjV66 LVM2_member 
/dev/sdc1        ShaGRu-GqRZ-4fS3-k0zp-g5x4-5Kae-uLoC9o LVM2_member 
/dev/sr0         2017-10-29-01-25-15-00                 iso9660    Boot-Repair-Disk 32bit
/dev/zram0       a9802c34-25bd-4f6f-b3e5-d75c62fe8adc   swap       
/dev/zram1       5ea34823-7d6a-4ac5-bb49-7fa9c8bbecea   swap       
/dev/zram2       dcc2c96c-1f33-4604-b5ac-d62964731bd4   swap       
/dev/zram3       0eb6d924-359e-4fed-b904-788ce185bb0a   swap       

Answer 1

Prelim

I assume youve backed up — redundancy proportional to the value of the data!
dd​s as well as tarballs

So… You did a full-device dd uh…uh.
Double that for badblock source disk. And again for quite different source and target disk architectures

Following are slight improvements (for completeness only) I dont really expect real benefits. What I recommend is below these

Partition dds

Manually partition the new disk; dd each partition individually

Partition copys

Manually partition the new disk; mkfs; high level copy the file system. cp -a has given me trouble where tar c... source|tar x... target has worked

But I assume you've tried the above and its not worked. So…

Does the new disk work?

To try just install a fresh new debian on the new disk. Does it work?

If no the of course we are dealing with a completely different problem

Assuming yes then

Side-by-side

[For simplicity I am assuming you avoid the LV stuff]

• When installing the new OS (above) manually partition and choose for two root systems — one for current (new) installation one for (copy of) your old. Lets LABEL them DebCurrent DebOld
• Proceed with new install into DebCurrent
• Copy over old disk root to Debold
• Re-point /etc/fstab of Debold
• [Assuming the DebCurrent boots]
• At the time of booting
  • Enter grub prompt
  • Open up the working stanza for DebCurrent
  • Hand edit to point to DebOld; Try to boot

But… (I'm guessing) the problem is still there. And its a

Hardware Mismatch Issue

Maybe the problem is that

• Motherboard is old (MBR-BIOS)
• Disk is new — prefers gpt

IOW the default is:

old: BIOS-MB + MBR-disk
new: EFI-MB + gpt-disk

No possibility of mix-n-match, ie in the windows world this is not solvable without shelling out more bucks for a new EFI MB.

However in the linux world you can use a gpt disk with a bios-MB The key thing there is that you need to create a BBP — a tiny 1MB special bios boot partition near the beginning of the disk.

You can do that with parted though Id recommend all gpt things to be done with gdisk

Added later

Making the bbp

I strongly recommend that for gpt disks the actual partitioning be done with gdisk. This keeps alignment well. Thereafter marking the type as BBP may be easier with (g)parted. Note the parted and gdisk links above