On 5/16/21 2:03 AM, Robin Cremer wrote:
> Responding to myself:
> Some progress:
> I put additional informational output between all commands in the suspect 
> area in GRUBs util/setup.c and pinpointed the bug:
>> #ifdef GRUB_SETUP_SPARC64
>>   {
>>     grub_partition_t container = root_dev->disk->partition;
>>     if (grub_strstr (container->partmap->name, "gpt"))
>>       bl.gpt_offset = grub_partition_get_start (container);
>>   }
>> #endif
> When installing on an md-device - or other special devices - it will never 
> have a partition table, thus "container" is null.

It might be trying to read the partition table from a fixed position where it 
wouldn't be when using
a software RAID, not sure. In any case, this definitely needs to be moved 
upstream and you should
put Eric Snowberg from Oracle in the loop as he is the expert on GRUB for SPARC.

> After that, access to struct members is tried without checking if it even 
> exists, leading to the segfault.
>> if (container && grub_strstr (container->partmap->name, "gpt"))
> actually works & installs on LVM if I put a hint for GRUB into the device.map 
> pointing to the UUID of the MDRAID.
> I'll try to get a patch for that submitted or discussed (I'm new to this and 
> not exactly sure if the change has other implications).
> It still won't boot, though. The first "stage" in the 2nd partition block is 
> executed by OBP and something along the lines
> of "GRUB FAIL - trap: Illegal Instruction" and on a second attempt "Unaligned 
> Memory Access" was encountered...

Most likely because the block numbers reported back by the software RAID don't 
map to the block numbers on the
physical device which is why the first stage is just loading random garbage and 
executing it which leads to


 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply via email to