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

[Lucio Crusca]

Hello,

I've just migrated my Debian testing/unstable install from a HDD to a SDD (too many custom configurations to go for a clean install). The hardware is a Dell Precision M4500 notebook.
The HDD is a Seagate 250GB 7200rpm, the SDD is a Samsung 250GB EVO 850. The total capacity matches exactly.

Here is how I copied the disk contents over the SDD.
I booted a live Ubuntu from CD media, checked with fdisk that every partition is starting 4K aligned and used the following command to copy the disk contents:

dd if=/dev/sda of=/dev/sdb status=progress bs=4K

Then I shut off the notebook, swapped disks and booted with the SDD. The result was:

error: invalid arch-independent ELF magic.
Entering rescue mode...
grub rescue>

I've tried suggestions from Google, e.g. live boot, install grub-efi-amd64, grub-install /dev/sda and so on. It worked once only, but I'm not even sure it was thanks to what I did. Please note that I have no EFI partition and the BIOS is configured for Legacy boot, not EFI.

I've also tried the advice here http://stackoverflow.com/questions/18120835/debian-grub-rescue-invalid-arch-independent-elf-magic (first reply, e.g. reinstall grub-pc) but it didn't work, I still get the same error.

Any clues?

[Lucio Crusca]

Il 22/02/2017 09:18, Lucio Crusca ha scritto:
> the following command to copy the disk contents:
>
> dd if=/dev/sda of=/dev/sdb status=progress bs=4K
>

P.S. I've just tried cloning again with the SSD in the notebook and the HDD in the external USB/SATA adapter, this time booting Ubuntu from USB instead of CD media. This time the command was

dd if=/dev/sdc of=/dev/sda status=progress bs=4K

Before rebooting I checked that the first ~400MB of data had been correctly copied with these commands:

dd if=/dev/sdc of=./test1 bs=4K count=102400
dd if=/dev/sda of=./test2 bs=4K count=102400
cmp test1 test2

and I got no output from cmp, that means the two files are equal. Upon rebooting I got the same error again.

[Eero Volotinen]

Try using clonezilla: http://clonezilla.org/

--

Eero

[Lucio Crusca]

Il 22/02/2017 15:39, Eero Volotinen ha scritto:
> Try using clonezilla: http://clonezilla.org/

I can try, but I'd prefer understanding what I'm doing wrong, if possible.

[Tixy]

On Wed, 2017-02-22 at 09:18 +0100, Lucio Crusca wrote:
> I booted a live Ubuntu from CD media, checked with fdisk that every
> partition is starting 4K aligned and used the following command to
> copy the disk contents:
>
> dd if=/dev/sda of=/dev/sdb status=progress bs=4K

Did you unmount all partitions on /dev/sda and /dev/sdb first?
Ubuntu live CDs have a habit of mounting every partition it sees at
startup which will result in a corrupt disk copy.

The above method is how I clone disks, but I do verify the copy
immediately after with something like:

cmp -n <byte-size-output-by-dd-command> /dev/sba /dev/sdb

--
Tixy

[Lucio Crusca]

Il 22/02/2017 17:40, Tixy ha scritto:
> On Wed, 2017-02-22 at 09:18 +0100, Lucio Crusca wrote:
>> I booted a live Ubuntu from CD media, checked with fdisk that every
>> partition is starting 4K aligned and used the following command to
>> copy the disk contents:
>>
>> dd if=/dev/sda of=/dev/sdb status=progress bs=4K
>
> Did you unmount all partitions on /dev/sda and /dev/sdb first?

Yes I did. But, even if I didn't, I fail to understand how that could break grub.

> Ubuntu live CDs have a habit of mounting every partition it sees at
> startup which will result in a corrupt disk copy.

Just to play it safe, I'm going to make the copy again using sysrescuecd.

>
> The above method is how I clone disks, but I do verify the copy
> immediately after with something like:
>
> cmp -n <byte-size-output-by-dd-command> /dev/sba /dev/sdb

Thanks for the hint, I'll do that too.

[Tixy]

On Wed, 2017-02-22 at 18:56 +0100, Lucio Crusca wrote:
> Il 22/02/2017 17:40, Tixy ha scritto:
> > On Wed, 2017-02-22 at 09:18 +0100, Lucio Crusca wrote:
> >> I booted a live Ubuntu from CD media, checked with fdisk that every
> >> partition is starting 4K aligned and used the following command to
> >> copy the disk contents:
> >>
> >> dd if=/dev/sda of=/dev/sdb status=progress bs=4K
> >
> > Did you unmount all partitions on /dev/sda and /dev/sdb first?
>
> Yes I did. But, even if I didn't, I fail to understand how that could break grub.

If the target disk (your SSD) already had partitions with filesystem and
Ubuntu mounted them, then any activity that modified those filesystem
could be written back to the disk at any time, e.g. to the sectors where
grub was copied to it after it was copied there.

At the very least, Ubuntu would cause writes to the SSD due to things
like superblock updates for mount time and count, and possibly access
timestamps in file inodes. But if it's a GUI desktop live CD, I wouldn't
be surprised if there wasn't background file indexing and thumbnailing
tasks running too, writing who knows what to the filesystem.

--
Tixy


If you don't think Ubuntu would write to a file-system unnecessarily,
(which I do, because I'm sure it'll have indexing an thumbnailing tasks
running in the backround)


you coppied it could cause modifications to be written to the SSD at
any time, say to the sectors where grub got copied to. If you don't
think Ubuntu would cause
Who knows what background tasks Ubuntu has indexi

then you copying a disk image to the SSD could result in corruption if
Ubuntu caused modifications to the SSD to happen in the same sectors
where Grub was. Say a filesystem superblock was near the start of the
original contents, an the loast mount time or file access times were
written out to that after grub was coppied there

[Lucio Crusca]

Tixy wrote:
> At the very least, Ubuntu would cause writes to the SSD due to things
> like superblock updates for mount time and count, and possibly access
> timestamps in file inodes. But if it's a GUI desktop live CD, I wouldn't
> be surprised if there wasn't background file indexing and thumbnailing
> tasks running too, writing who knows what to the filesystem.

I badly hope you are right, for two reasons:

1) the copy this time would work (sysrescuecd)
2) much more important, there would be yet another good reason to call Ubuntu names :)

cmp is running just now, it started a few minutes ago and it will take about 2 hours. No errors reported until now. I'll let you know the results.

[Mark Fletcher]

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.

So say you have 3 partitions, re-create them on the target disk and then
copy each of them from HDD to SDD.

Or, go one step further and create both partitions and filesystems on
the SSD, mount HDD and SSD filesystems and then cp -a the contents from
HDD filesystems to SSD.

Some months ago I migrated the two disks in my main Jessie machine from
HDDs to SSDs, and I used the last option above. The consensus on this
list at the time was that that was the best way to do it. It's certainly
the most tolerant of subtle differences between source and target disk.
It does require that grub be re-installed on the target disk, but with
everything copied over the grub.cfg will be in place so the install is
easy.

There was some discussion on this list of how I went about it at the
time, you can see that in the archives.

Hope that helps

Mark

[Lucio Crusca]

Il 22/02/2017 21:40, Lucio Crusca ha scritto:
>
> cmp is running just now, it started a few minutes ago and it will take about 2 hours. No errors reported until now. I'll let you know the results.
>

No errors reported by cmp. Still the system is not bootable, same error as before. What a pity, it wasn't Ubuntu to blame...

[Richard Hector]

On 22/02/17 21:18, Lucio Crusca wrote:
> Here is how I copied the disk contents over the SDD.
> I booted a live Ubuntu from CD media, checked with fdisk that every
> partition is starting 4K aligned and used the following command to copy
> the disk contents:
>
> dd if=/dev/sda of=/dev/sdb status=progress bs=4K

You checked the partitions (on /dev/sdb) with fdisk, and then did the dd?

I think you just overwrote the partitions you checked.

I don't know if this is related to your problem.

Maybe you'd be better off copying the partitions separately, and then
reinstalling grub.

Richard

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 23, 2017 at 07:53:45AM +0900, Mark Fletcher wrote:
> On Wed, Feb 22, 2017 at 04:35:16PM +0100, Lucio Crusca wrote:
> > Il 22/02/2017 15:39, Eero Volotinen ha scritto:
> > >Try using clonezilla: http://clonezilla.org/
> >
> > I can try, but I'd prefer understanding what I'm doing wrong, if possible.
> >
> >
> 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.

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 nothing magical about the boot sector or partition table, it's
just data which happens to be located (typically, these days) "before"
the partitions proper. Unless...

I have some dim memories of some helpful firmware (was it disk? was it
BIOS? Didn't I say "dim"?) "protecting" the user of rogue software
writing to the boot sector. This was, AFAIR, the heyday of boot sector
viruses and hopefully long gone.

But hard/firmware vendors are known to do strange things: go check
your BIOS whether some funny RAID thingie is enabled.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliuuKcACgkQBcgs9XrR2kaEswCdEXLwO+ljybEvbto8FvwEAxYo
xjYAnAjAdKw0BrTttZfVVGOEay+0Cz2j
=LrqD
-----END PGP SIGNATURE-----

[Mark Fletcher]

On Thu, Feb 23, 2017 at 11:25:43AM +0100, to...@tuxteam.de wrote:
> On Thu, Feb 23, 2017 at 07:53:45AM +0900, Mark Fletcher wrote:
> > On Wed, Feb 22, 2017 at 04:35:16PM +0100, Lucio Crusca wrote:
> > > Il 22/02/2017 15:39, Eero Volotinen ha scritto:
> > > >Try using clonezilla: http://clonezilla.org/
> > >
> > > I can try, but I'd prefer understanding what I'm doing wrong, if possible.
> > >
> > >
> > 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.
>
> 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).
>

And yet, oh and yet, it WASN'T working, WAS it?

Hence my suggestion.

Mark

[Stefan Monnier]

> The HDD is a Seagate 250GB 7200rpm, the SDD is a Samsung 250GB EVO 850.
> The total capacity matches exactly.

You mean they really have *exactly* the same number of blocs?

> dd if=/dev/sda of=/dev/sdb status=progress bs=4K

FWIW, after doing that, I'd recommend you look at the partition table,
edit it (ever so slightly) and save the result: GPT partition tables are
duplicated: one copied at the very beginning and one copy at the very
end, so if the drives don't have exactly the same size the secondary
copy will appear corrupted.

Sadly, I don't think that explains your problem,


Stefan

[Jonathan Dowland]

On Wed, Feb 22, 2017 at 09:18:26AM +0100, Lucio Crusca wrote:
> dd if=/dev/sda of=/dev/sdb status=progress bs=4K

Why did you decide to do a block-level copy, rather than file-level? Too many
partitions/LVM volumes/etc? Personally I'd always recommend a file-level copy,
using something like rsync, which means no duplicate UUIDs, you aren't spending
time copying sectors that aren't referenced, the SSD gets fewer write cycles
and it can be interrupted and resumed. Or pvmove in some cases.

--
Jonathan Dowland

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 23, 2017 at 02:27:51PM +0000, Jonathan Dowland wrote:
> On Wed, Feb 22, 2017 at 09:18:26AM +0100, Lucio Crusca wrote:
> > dd if=/dev/sda of=/dev/sdb status=progress bs=4K
>
> Why did you decide to do a block-level copy, rather than file-level?

Not the OP, but there are other reasons to prefer a block-level copy,
among others "same UUID" (I know, I know), so no need to change fstab.

Usually I prefer a file-level copy, though.

Regards
- -- t

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliu+n8ACgkQBcgs9XrR2kYNswCfUJ6HRkan7zjLK/fXltCqc0qA
sOAAn32Y7UEFICksx7s/kYHpYQKq4J7g
=qsjO
-----END PGP SIGNATURE-----

[Stefan Monnier]

> using something like rsync, which means no duplicate UUIDs, you aren't
> spending time copying sectors that aren't referenced, the SSD gets
> fewer write cycles and it can be interrupted and resumed.

FWIW, copying files has its own form of overhead, so if the drive is
reasonably filled, it'll be faster to do a `dd` than an `rsync` (because
that uses the optimal (sequential) access) and it might very well result
in fewer writes for the flash memory of your SSD.

Anyway, another advantage of `rsync` is that it works even if the
file-system is currently mounted and accessed. E.g. I've cloned running
Debian systems with `rsync` with no problem, whereas doing it with `dd`
invariably leads to corrupted partitions.

> Or pvmove in some cases.

Personally I very rarely copy whole drives, but I do copy partitions
with `dd` sometimes (especially partitions with many small files where
`rsync` slows down noticeably).
Tho if I can use pvmove, that's a better option.


Stefan

[Stefan Monnier]

> among others "same UUID" (I know, I know), so no need to change fstab.

Yuck! I recommend you stay away from UUIDs in your fstab. Instead name
your partitions. If you use LVM (which you should do anyway for all
kinds of other reasons) your volumes are already named anyway so there's
nothing special to do, and for those rare cases where you have to use
a "real partition" rather than an LVM volume, then label the
file-system.

That gives you much more readable /etc/fstab entries, and that saves you
from having to worry about which operation preserves UUID and which
doesn't and when do you need to change the UUID and when you don't (and
how).

Of course, you may say that I just traded managing UUIDs against
managing names, but in my experience it's simpler, more upfront, and
intuitive, so I'm never caught off-guard.


Stefan

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 23, 2017 at 10:45:55AM -0500, Stefan Monnier wrote:
> > among others "same UUID" (I know, I know), so no need to change fstab.
>
> Yuck! I recommend you stay away from UUIDs in your fstab. Instead name
> your partitions.

Agree -- only in half. I think those are different things and are thus
to be used differently.

For "permanently" or "semipermanently" mounted things, label/name
is a good match. For travelling things, where you want to avoid
inadvertent collissions, UUID might be better (you might argue that
in this case the UUID shouldn't be in the fstab in the first place;
but using the UUID to "recognize" the partition is here the right
thing to do).

[...]

> Of course, you may say that I just traded managing UUIDs against
> managing names, but in my experience it's simpler, more upfront, and
> intuitive, so I'm never caught off-guard.

I may, but I won't say :-)

For partitions which don't move much (and that's almost surely the
set in fstab) we are in violent agreement. Still you might want to
have an "errant disk" in the fstab (the proverbial back-up USB
drive which comes and goes): then I would definitely use UUID, to
avoid dumping my backups to the wrong drive. But then, this one
perhaps wouldn't be documented in fstab.

Regards
- -- tomás

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliwAPEACgkQBcgs9XrR2kZHSACeO/ekKlI9inPsDlt02TavRr+r
WxwAn2XyKu8qsinW65dThSRqGuGbhApU
=n2p1
-----END PGP SIGNATURE-----

[Thomas Schmitt]

Hi,

whatever merits the various address methods for partitions may have,
the GRUB message "invalid arch-independent ELF magic" is about a program
file and not about a partition.

Pick any source file of this list in a current
git://git.savannah.gnu.org/grub.git clone:

./grub-core/loader/i386/bsdXX.c: return grub_error (GRUB_ERR_BAD_OS, N_("invalid arch-independent ELF magic"));
./grub-core/loader/ia64/efi/linux.c: N_("invalid arch-independent ELF magic"));
./grub-core/loader/multiboot_elfxx.c: return grub_error(GRUB_ERR_UNKNOWN_OS, N_("invalid arch-independent ELF magic"));
./grub-core/kern/dl.c: return grub_error (GRUB_ERR_BAD_OS, N_("invalid arch-independent ELF magic"));
./grub-core/kern/elf.c: return grub_error (GRUB_ERR_BAD_OS, N_("invalid arch-independent ELF magic"));
./grub-core/kern/elf.c: return grub_error (GRUB_ERR_BAD_OS, N_("invalid arch-independent ELF magic"));
./util/grub-module-verifierXX.c: grub_util_error ("invalid arch-independent ELF magic");

It's always the same gesture when looking for the data described in
https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#File_header


So why does the reigning GRUB not like the file in the perfect disk copy ?
Maybe because it is not accessing the copied disk at all but rather reads
garbage from somewhere else ?
(The internet has rumors that re-installing GRUB would help. Shrug.)


Have a nice day :)

Thomas

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Feb 24, 2017 at 11:43:00AM +0100, Thomas Schmitt wrote:
> Hi,
>
> whatever merits the various address methods for partitions may have,
> the GRUB message "invalid arch-independent ELF magic" is about a program
> file and not about a partition.

[...]

Thanks, Thomas. Even-headed as always, and the most insightful contribution
in this thread so-far :)

regards

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliwGEEACgkQBcgs9XrR2kY79wCfQnTmXGus6NEwbrySqDUm9mCA
DxQAoII1mS50/swLFMyuz+weaWyVld3V
=w7E2
-----END PGP SIGNATURE-----

[deloptes]

to...@tuxteam.de wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, Feb 24, 2017 at 11:43:00AM +0100, Thomas Schmitt wrote:
>> Hi,
>>
>> whatever merits the various address methods for partitions may have,
>> the GRUB message "invalid arch-independent ELF magic" is about a program
>> file and not about a partition.
>
> [...]
>
> Thanks, Thomas. Even-headed as always, and the most insightful
> contribution in this thread so-far :)
>

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.

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

Regarding the point mentioned above about UUID I should admit that uuid is
very helpful when assembling raid devices on a chasis with multiple disks
which get initialized randomly (you do not expect to have sdd or sdh for
the same drive after each boot. I found out it helps a lot. IT also helps
to have it in grub. It is not very human readable, but is also not that
much of overhead to find out which your uuid is pointing at.

regards

[Lucio Crusca]

to...@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.

[Felix Miata]

Lucio Crusca composed on 2017-02-25 10:16 (UTC+0100):
...

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

> Thanks everyone for your support anyway.

Did you look for any significant differences between the working and non-working
grub.cfgs? Does Grub see your SSD as an NVMe device and need to embed a
different binary or load a different module for it?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Feb 25, 2017 at 04:28:33AM -0500, Felix Miata wrote:
> Lucio Crusca composed on 2017-02-25 10:16 (UTC+0100):
> ...
> >I hate to workaround problems without understanding them, this is a loss.
>
> >Thanks everyone for your support anyway.
>
> Did you look for any significant differences between the working and
> non-working grub.cfgs? Does Grub see your SSD as an NVMe device and
> need to embed a different binary or load a different module for it?

This is actually an interesting point. I always forget Grub has become
an OS on its own and that disk isn't always dis. Yes, Grub seems to need
special magic for NVMe.

Thanks

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlixUNYACgkQBcgs9XrR2kZIwACfaL1RD7Cwd3XsEOKLW+Y+aCEL
FPgAn3nBejDT4ZVeXkWu/XPQsgAhQmdt
=UAuV
-----END PGP SIGNATURE-----

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Feb 25, 2017 at 10:16:18AM +0100, Lucio Crusca wrote:

[...]

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

I know that feeling. Makes for an interesting life ;-P

regards
- -- t

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlixUAsACgkQBcgs9XrR2kb6YACfdC71ajMDnJ7d2QwXboFXHIA4
4UoAnj8mNv7MChAfhszBc8wLReRnKlLr
=0yLx
-----END PGP SIGNATURE-----

[Thomas Schmitt]

Hi,

Lucio Crusca wrote:
> 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.

Even more, all disk-like storage devices are operated via SCSI commands
independly of the bus technology. So with USB, SATA, PATA it's all the same.
A block written to Logical Block Address X should be retrievable from that
same address, however its data are stored pysically.

> Then I copied partition contents over with cp run in a live systemrescuecd,
> except /boot, /dev /proc and /sys. It more or less worked

It's easy to guess that /boot is the main suspect in this list.
But still no idea why a blockwise disk copy should not work when it comes
to identifying a program file as ELF format. Somehow GRUB must get to the
wrong file content.

[Lucio Crusca]

Felix Miata wrote:

> Did you look for any significant differences between the working and
> non-working grub.cfgs? Does Grub see your SSD as an NVMe device and
> need to embed a different binary or load a different module for it?

I think you've caught it! Here is what seems to me the most interesting
diff:

< set root='hd1,msdos5'
---
> set root='hd0,msdos1'

The difference in the partition number (msdos5 vs msdos1) is expected
because, when I did the clean install, I did not carry over the Windows
partitions. The difference in the drive identifier is more interesting
instead. Why does grub identified the old HDD as hd1 but the SDD as hd0?
I've never had more than one drive installed in the notebook (it's a
sure bet, because it doesn't have room for two drives). Moreover, the
old disk is a plain disk only, not a hybrid:

https://www.cnet.com/products/seagate-momentus-7200-4-st9250410as-hard-drive-250-gb-sata-300-series/specs/

Anyway, that's likely the reason why grub couldn't find its files on the
SSD. Misleading error message though.

[deloptes]

Thomas Schmitt wrote:

> It's easy to guess that /boot is the main suspect in this list.
> But still no idea why a blockwise disk copy should not work when it comes
> to identifying a program file as ELF format. Somehow GRUB must get to the
> wrong file content.

+1