Re: "Invalid arch-independent ELF magic" in grub after SSD migration
tomas@tuxteam.de 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.
Reply to: