Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178058 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 09:30 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 14:30 +0100
      Re: "Invalid arch-independent ELF magic" in grub after SSD migration Eero Volotinen <eero.volotinen@iki.fi> - 2017-02-22 15:50 +0100
        Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 16:40 +0100
          Re: "Invalid arch-independent ELF magic" in grub after SSD migration Mark Fletcher <mark27q1@gmail.com> - 2017-02-23 00:00 +0100
            Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-23 11:30 +0100
              Re: "Invalid arch-independent ELF magic" in grub after SSD migrationy Mark Fletcher <mark27q1@gmail.com> - 2017-02-23 12:20 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Tixy <tixy@yxit.co.uk> - 2017-02-22 17:50 +0100
      Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 19:00 +0100
        Re: "Invalid arch-independent ELF magic" in grub after SSD migration Tixy <tixy@yxit.co.uk> - 2017-02-22 21:20 +0100
          Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-22 21:50 +0100
            Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-23 00:30 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Richard Hector <richard@walnut.gen.nz> - 2017-02-23 11:10 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Stefan Monnier <monnier@iro.umontreal.ca> - 2017-02-23 15:10 +0100
    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Jonathan Dowland <jmtd@debian.org> - 2017-02-23 15:30 +0100
      Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-23 16:10 +0100
        Re: "Invalid arch-independent ELF magic" in grub after SSD migration Stefan Monnier <monnier@iro.umontreal.ca> - 2017-02-23 16:50 +0100
          Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-24 10:50 +0100
            Re: "Invalid arch-independent ELF magic" in grub after SSD migration "Thomas Schmitt" <scdbackup@gmx.net> - 2017-02-24 11:50 +0100
              Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-24 12:30 +0100
                Re: "Invalid arch-independent ELF magic" in grub after SSD migration deloptes <deloptes@gmail.com> - 2017-02-24 17:10 +0100
                  Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-25 10:20 +0100
                    Re: "Invalid arch-independent ELF magic" in grub after SSD migration Felix Miata <mrmazda@earthlink.net> - 2017-02-25 10:30 +0100
                      Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-25 10:40 +0100
                      Re: "Invalid arch-independent ELF magic" in grub after SSD migration Lucio Crusca <lucio@sulweb.org> - 2017-02-25 11:30 +0100
                    Re: "Invalid arch-independent ELF magic" in grub after SSD migration <tomas@tuxteam.de> - 2017-02-25 10:40 +0100
                    Re: "Invalid arch-independent ELF magic" in grub after SSD migration "Thomas Schmitt" <scdbackup@gmx.net> - 2017-02-25 11:30 +0100
                      Re: "Invalid arch-independent ELF magic" in grub after SSD migration deloptes <deloptes@gmail.com> - 2017-02-25 14:40 +0100
      Re: "Invalid arch-independent ELF magic" in grub after SSD migration Stefan Monnier <monnier@iro.umontreal.ca> - 2017-02-23 16:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#178135

tomas@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

[toc] | [prev] | [next] | [standalone]

#178149

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.

[toc] | [prev] | [next] | [standalone]

#178150

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/

[toc] | [prev] | [next] | [standalone]

#178151

-----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-----

[toc] | [prev] | [next] | [standalone]

#178154

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.

[toc] | [prev] | [next] | [standalone]

#178152

-----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-----

[toc] | [prev] | [next] | [standalone]

#178153

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.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#178160

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

[toc] | [prev] | [next] | [standalone]

#178111

> 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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web