Can't install Debian to CF card in SATA adapter

[Mike]

Folks,

I'm building a new NAS box which has five HDDs in a RAID 5
configuration, using Linux software RAID. Historically this has caused
some challenges when dealing with /boot. Some time back I set upon the
idea of using an IDE > CF adapter and putting a small CF card in there
for /boot, with the logic that one could dd an image of the drive and
store it in a safe place, should the CF card die.

As time progressed I moved on to SATA > CF adapters.

For my latest incarnation, I find myself with a UEFI machine. I've
follwoed my usual practice. Debian seemed to install just fine and I
rebooted at the end of the installation but the Debian was not listed as
a boot option in the EFI NVRAM. Further, booting to the EFI Shell, I
can access the EFI parition, cd to EFI/debian and manaully call
shimx64.efi, giving the following output:

Reloc 0 block size 0 is invalid
Relocation failed: Unsupported
Failed to load imagE: Unsupported
start_image() returned Unsupported

I have tried changing the CF card twice, as well as changing the CF
adapter but no dice. I tried swapping out the adaper with a spare SSD I
had to hand and everything worked just fine this time.

I do have a near identitcal motherboard in another server, where I have
successfully used the SATA > CF trick, so I'm a bit perplexed as to what
may be going on here.

Please could anyone suggest any words of wisdom?

Thanks,
Mike.

[songbird]

Mike wrote:
>
> --82iZo52UH5hltGCH
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline

"near identical" is perhaps not identical enough. :(

to be practical IMO the SSD works, go with that.
the cost of time and effort to figure out the problem
is probably already larger than the cost of the SSD.


songbird

[Mike]

On Sat, Jan 21, 2023 at 09:11:56AM -0500, songbird wrote:
> Mike wrote:
> >
>
> "near identical" is perhaps not identical enough. :(
>
> to be practical IMO the SSD works, go with that.
> the cost of time and effort to figure out the problem
> is probably already larger than the cost of the SSD.
>
>
> songbird
>

That seems a little bit overkill, extravagant and uneligant but then I
hear what your saying.

I just checked the price of SSDs and how I LOL'd. How times have
changed!

On reflection not a bad idea!

That said, if anyone can offer any hypothesis, I would be intellectually
curious to figure out what is going on here. I would have though one
SATA drive would look like another, regardless of a actual media behind
it?

Regards and thanks,
Mike.

[Thomas Schmitt]

Hi,

Mike wrote:
> booting to the EFI Shell, I
> can access the EFI parition, cd to EFI/debian and manaully call
> shimx64.efi, giving the following output:
>
> Reloc 0 block size 0 is invalid
> Relocation failed: Unsupported

The web has remarkably few info on that problem.
The best i found is
https://www.mail-archive.com/edk2-...@lists.01.org/msg39858.html
"These messages are printed by the "shim" UEFI application:
https://github.com/rhboot/shim/blob/master/shim.c
probably when it attempts to load "grub"."
leading to
https://github.com/rhboot/shim/commit/956717e2b375d7c7f0faafec8f12a7692708eb9awhich meanwhile wandered from shim.c to pe.c, line 108:
https://github.com/rhboot/shim/blob/17f02339ed1be9e90738603fe3c95ae7dc300061/pe.c
The function is named "relocate_coff". The web explains in detail what
COFF is and what relocation means in that context.

All in all i get the impression that shimx64.efi complains about grubx64.efi
being a bad binary.
(Next i would try to compare that grubx64.efi with a grubx64.efi that is
known to work.)


Have a nice day :)

Thomas

[Mike]

Hi Thomas,

Thanks for taking the time to look into this.

I too found details on Google to be somewhat lacking. I had assumed the
error was with loading the shim, so you're feedback gives something to
think about. I have checked the sha512 of the shim and believe it to be
working (By believe, I mean it's a running server but apt-get may have
replaced stuff since it last rebooted) and it appears to be the same.
The grub efi is different. I have tried copying the grub efi from the
known working system but this did not help.

I don't think that it's a bad grub binary, as I have reinstalled several
times, with the same result. I have tried installing with EFI and /boot
on a 6TB HDD and that worked fine, as did a 120GB SSD. I had failures,
with the aforementioned error using a 256MB, 1GB and 2GB CF card in a
SATA adapter, as well as when using a 8GB USB flash drive in the
on-board USB port.

I'm a bit perplexed as to the difference between a SATA > CF adapter and
any other drive. I thought one would send instructions along the lines
of "give me block x" and receieve "<block of data>". Surely the host
would not be able to tell a difference. I was equally perplexed that I
got the exact same error when using a USB drive.

Regards,
Mike.

[Thomas Schmitt]

Hi,

Mike wrote:
> I don't think that it's a bad grub binary, as I have reinstalled several
> times, with the same result.

But if it's indeed shim which is complaining then it complains about the
content of grubx64.efi.

I guess that the problem would show up in the output of

objdump -x ...path.../grubx64.efi

which with the binary from debian-11.0.0-amd64-netinst.iso shows:
------------------------------------------------------------------------
/mnt/iso/EFI/boot/grubx64.efi: file format pei-x86-64
/mnt/iso/EFI/boot/grubx64.efi
architecture: i386:x86-64, flags 0x00000103:
HAS_RELOC, EXEC_P, D_PAGED
start address 0x0000000000001000
...
PE File Base Relocations (interpreted .reloc section contents)

Virtual Address: 00001000 Chunk size 232 (0xe8) Number of fixups 112
reloc 0 offset 33 [1033] DIR64
reloc 1 offset 4b [104b] DIR64
...
reloc 115 offset 0 [1000] ABSOLUTE

Virtual Address: a017a006 Chunk size 2688524326 (0xa03fa026) Number of fixups 1344262159
reloc 0 offset 58 [a017a05e] DIR64
...many.more...
reloc 1923 offset 0 [a017a006] ABSOLUTE

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000b000 0000000000001000 0000000000001000 00001000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00010000 000000000000c000 000000000000c000 0000c000 2**4
CONTENTS, ALLOC, LOAD, DATA
2 mods 0017a000 000000000001c000 000000000001c000 0001c000 2**2
CONTENTS, ALLOC, LOAD, DATA
3 .sbat 00001000 0000000000196000 0000000000196000 00196000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .reloc 00001000 0000000000197000 0000000000197000 00197000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
SYMBOL TABLE:
no symbols
------------------------------------------------------------------------

I'm not familiar with the nomenclature of objdump and shim.
Maybe objdump's "Chunk size" is what shim is complaining about.
(The numbers of the second occurence of that term look unhealthy.)

> I'm a bit perplexed as to the difference between a SATA > CF adapter and
> any other drive. I thought one would send instructions along the lines
> of "give me block x" and receieve "<block of data>".

I think the same.

> I was equally perplexed that I
> got the exact same error when using a USB drive.

Given the rare occurence of the problem in the internet i'd say it is not
about something as systematic as SATA versus USB.

[Mike]

I must confess to having not come across objdump before. I'm not sure
what to make of it's findings.

>
> > I'm a bit perplexed as to the difference between a SATA > CF adapter and
> > any other drive. I thought one would send instructions along the lines
> > of "give me block x" and receieve "<block of data>".
>
> I think the same.
>
>
> > I was equally perplexed that I
> > got the exact same error when using a USB drive.
>
> Given the rare occurence of the problem in the internet i'd say it is not
> about something as systematic as SATA versus USB.

It does appear to be rather niech. I have a very similar board in
another machine that works just fine. I too have searched the Interwebs
for ideas but to no avail. Given that I've reinstalled seveal times
with the same results, I'm sure it's not an issue with a corrupt file.
I've just checked the SHA 512 of the grubx64.efi from the non working
USB stick and the working SSD and they are alike.

I think the real irritation is that I can't even put together a
plausible hypothesis to test :-(