Imaging a drive for Linux embedded system - boot fails

[timg11]

I have a device (Korg Kronos) that is based on embedded Linux. I'm trying to image the system onto a larger SSD.

My imaged drive fails to boot. The system does not give any helpful diagnostics or have console access, unfortunately.

The partition layout is like this:

/boot 16 Mib Linux Native
/ 220 Mib Linux Native
MBR2 502 Mib Linux Swap/ Solaris
MBR3 Extended
/korg/ro 526 Mib Linux Native
/korg/rw 27361 Mib Linux Native



I'm looking at the disk in gparted under Ubuntu. I see the partition MBR3 has a flag "lba".
The boot flag is present on the /boot partition.

The original drive was imaged to a single file, then restored to the new drive. The only restore option selected was "Write Standard MBR Code".

Normally I would expand MBR3 and /korg/rw to make the additional space of the new drive available. As a test, I connected the drive right after imaging.
Even before re-sizing the user partition (/korg/rw), the new drive will not boot. BIBM shows the partitions are identical on old and new drive, and /boot is marked Active.

Other owners of this device have been successful with this approach to upgrading the disk, but say they used "stand alone" dedicated disk imaging machines.

What am I missing? Is there something else needed to completely and fully image a disk for Linux?

[TeraByte Support(PP)]

Have you tried without the "Write Standard MBR Code" option? It may have GRUB or something else in the MBR for booting.

[timg11]

Thanks Paul!

For anyone else who experiences something similar, here is the key.

1) When selecting the target drive in IFL, there is a button for Geometry. Select it and choose "Use Original Geometry"
2) On the final options before starting the restore, select only "Assume original HD". As Paul said, do not choose "write standard MBR code"

You may see options about "Windows 7 MBR Code", which is yet another option, but it does not mean that "Standard MBR code" works for Linux. It is necessary to _not_ write any MBR code to preserve Linux ability to boot.

I also connected the target drive directly to the SATA port inside the computer running IFL. On previous tries, I used a USB to SATA adapter. Not sure that is the issue, but FYI.
I made the image of the original drive with the USB-SATA adapter, so it is probably OK.

[TeraByte Support(PP)]

When a drive is connected via USB it can change how it's seen (different geometry, etc.). You can often work around that with geometry options, but it's usually best to connect it internally so it's seen how it would normally be.