Web lists-archives.com

Re: "Invalid arch-independent ELF magic" in grub after SSD migration





tomas@xxxxxxxxxx wrote:
In the OP's context this doesn't make much sense. From the OP's mail

   dd if=/dev/sda of=/dev/sdb [other params elided]

That would copy boot sector, partition table and everything. If

  (a) the one (or the other) disk isn't broken
  (b) no one else is concurrently writing to the copied disk

everything should work. And from the thread up to now, I gather that
there's at least good evidence against (b).

There's also good evidence of (a), because cmp reported no errors (besides, I had also checked dmesg and smartctl of both drives).

There's nothing magical about the boot sector [...]
I have some dim memories of some helpful firmware [...]
But hard/firmware vendors are known to do strange things: go check
your BIOS whether some funny RAID thingie is enabled.

Not really much in the BIOS screens of Dell laptops. That does not exclude the BIOS is doing some "helpful magic" behind the scenes nevertheless.

deloptes wrote:

Usually grub-install helps. I assume the problem is due to different disk
architecture or precisely how the PC would access SDD - so might be
hardware vendor related. Are you sure it points to the same piece of data
or sector/block when giving control to grub loader? I vote for
grub-install.
I lack the skills to understand how grub (or the BIOS firmware if grub hands the task to it) could access SSD any different than HDD, given that, as far as I know, the SATA protocol is just the same. However it is indisputably true that my knowledge does not reach far enough.

In such a case I do boot from live usb stick, chroot and perform grub
install.

Tried that too, to no avail.

Mark Fletcher wrote:
> I am not sure I can explain why this would be necessary (theoretically,
> it wouldn't) but you might want to try manually recreating the partition
> structure on the SSD and then using dd (or just cp actually) to copy
> each partition.

I ended up installing a clean Debian base system (same version as the one I was trying to migrate, Linux Kernel 4.9, Grub 2.02~beta3), just to make sure Debian had no compatibility issues with my SSD and that my SSD had no compatibility issues with my notebook. To my surprise, that worked like a charm. I can only infer there actually is some "magic" going on behind the scenes and that "magic" must be there in the debian installer.

Then I copied partition contents over with cp run in a live systemrescuecd, except /boot, /dev /proc and /sys. It more or less worked (some apt-fu needed to fix a few package state issues).
I'm now writing from the SSD-migrated Debian GNU/Linux system.

I hate to workaround problems without understanding them, this is a loss.

Thanks everyone for your support anyway.