Re: GPT attributes in dkwedge [PATCH]

[oster%netbsd.org@localhost]

September 15, 2023 at 10:15 AM, "Martin Husemann" <martin%duskware.de@localhost> wrote:


> 
> On Fri, Sep 15, 2023 at 04:01:15PM +0000, Emmanuel Dreyfus wrote:
> 
> > 
> > A multiboot bootloader cannot, because all the information that is passed
> >  is about partition numbers. There is no way of specifying a LBA offset, 
> >  hence the setup where you have a GPT inside raidframe seems impossible
> >  to support.
> > 
> 
> Can you describe your setup and the boot order in more details?
> I guess there is some fundamental misunderstanding somewhere.

Since I was the one who mentioned the issue to Emmanuel allow me to chime in here.... 
 
> Where does your kernel live and how is it loaded? What partition(s)
> have the bootme flag? I would never expect it to make any sense in the
> inner GPT of a raid set, but only the (outer) GPTs of the components
> (so firmware finds the bootloader).

This came from attempting to install NetBSD-10_BETA on some new hardware, 
using sysinst, and following my nose as though I were a beginner (full 
disclosure: sysinst was modified to automatically add 'absent' for a 
missing component for a RAID 1 set so I would only need to have a single 
component available.  But otherwise a vanilla 10-beta install).

I took wd0 (or equivalent) and asked it to put a RAID partition on it.  
It happily made a new GPT for me, with one partition for RAID.  (i.e. 
no EFI partition, which bit me after).  I then put that new RAID partition 
into 1/2 of a RAID 1 set, and  old it to configure and install to raid0. 

I told it 'use default partitions'.  The resulting partitions were similar to:

chicken# gpt show -a raid0
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2        32         Pri GPT table
        34        30         Unused
        64    262144      1  GPT part - EFI System
                                 Type: efi
                                 TypeID: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
                                 GUID: 00c87892-e798-48dd-b0c7-abf421d25302
                                 Size: 128 M
                                 Label: 
                                 Attributes: None
    262208  14823680      2  GPT part - NetBSD FFSv1/FFSv2
                                 Type: ffs
                                 TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648
                                 GUID: ca6ef7c6-551b-475b-9211-fa08d0402165
                                 Size: 7238 M
                                 Label: 
                                 Attributes: biosboot
  15085888   4184064      3  GPT part - NetBSD swap
                                 Type: swap
                                 TypeID: 49f48d32-b10e-11dc-b99b-0019d1879648
                                 GUID: 78bbf8c1-d5ac-43ad-8f06-d545206c2fb8
                                 Size: 2043 M
                                 Label: 
                                 Attributes: None
  19269952        31         Unused
  19269983        32         Sec GPT table
  19270015         1         Sec GPT header
chicken# 

(the above is from a test VM.  The original machine that I had this issue on
 is now in production with custom GPT setup.  But it is trivial to replicate
 the setup).  That is, it automatically created the EFI partition as the 
*first* partition in the RAID set. I later learned that if I made a EFI 
partition (with the right /usr/mdec/*.efi bits) on wd0 I would get a lot 
further.  I would get even further still if I didn't just 'use default partitioning' 
in sysinst, and have my "/" GPT partition as the partition at index 1 in the 
RAID.  Without Emmanuel's changes "/" needs to be at GPT partition index 1, 
otherwise rf_buildroothack() won't work. 

To answer your last questions: The kernel lives on raid0 in GPT partition 2. 
By default, it isn't loaded, as UEFI can't find it, as there is no EFI partition
by default on wd0.  If I add an EFI partition with /usr/mdec/*.efi in efi/boot, 
then the kernel is correctly loaded from raid0 in GPT partition 2.  The 'bootme' flag
is added to GPT partition 2, but that doesn't help with rf_buildroothack() if '/'
isn't actually at GPT partition 1.  And I agree that I wouldn't expect it to find
the EFI bits in the RAID set, but that's where sysinst put things by default.

So no, Emmanuel's changes arn't needed if you really know what you're doing
on an install with sysinst, but a novice just following the default is 
currently going to really be a long way from a bootable system. (I'm not 
even touching the need to set 'bootme' or to populate the out-of-RAID EFI 
partition or to mark the RAID set as '-A soft' in order to get to something
 working.... and I also see addressing these as something that can happen after 
netbsd-10 is shipped, as I think this will require some involved changes to sysinst)

I hope this helps clarify things.  
(Yes, I'd be happy if rf_buildroothack() could Go Away, or at least be reduced in 
complexity..)

Thanks.

Later...

Greg Oster