Re: Xen boot strangeness (Was: Re: [SOLVED] Re: Xen 4.18.5_20250521nb0 not ELF binary (Was: Re: EFI and Xen))

[Chuck Zmudzinski <frchuckz%gmail.com@localhost>]

On 5/30/2025 4:35 PM, Greg A. Woods wrote:
> At Fri, 30 May 2025 06:29:49 -0400, Chuck Zmudzinski <frchuckz%gmail.com@localhost> wrote:
> Subject: Re: Xen boot strangeness (Was: Re: [SOLVED] Re: Xen 4.18.5_20250521nb0 not ELF binary (Was: Re: EFI and Xen))
>>
>> I am not sure I understand why it is even necessary to do this search for the
>> boot device on modern UEFI/GPT partitioned systems.
> 
> With the current restriction in Xen multiboot of needing to tell the
> kernel where to find the root filesystem, this search is actually
> completely bogus for _all_ Xen/multiboot setups.
> 
>> Why not just allow the user
>> to directly specify the root device and the dump device in the boot.cfg file
> 
> Exactly what I've always thought.
> 
>> Maybe such simplicity is not possible or so easy with old legacy BIOS booting
>> and MBR partitioning and on such systems
> 
> No, there's no difference for legacy systems.  The bootloader still
> can't automatically pass the "bootdev" to the kernel in "the old way",
> The bootloader does still need figure out, or be told how to find and
> load /xen and /netbsd.  However the NetBSD kernel also still needs to
> know where the root (and optionally dump) partition is, and it has to be
> told explicitly on its command line from the string given in /boot.cfg,
> so using the idea of "bootdev" instead of being explicit about the
> actual root device name is pointless.
> 
> On one such legacy system I pass "bootdev=sd0" and it figures out which
> partition to use, but in theory this could/should be "root=sd0a" (maybe
> with "dump=sd0b").

Yes, it can figure it out on legacy systems because there is a disklabel
on sd0 and the both the kernel and the bootloader can figure everything
out in that case, I am sure. The problem is that with UEFI/GPT there is
no disklabel but a GPT instead and that strange code that we still use and
that you posted in an earlier message in this thread stupidly presumes
there is a disklabel with [a-p] partitions even when we pass bootdev=dk*
to the kernel in the case of UEFI/GPT, which is obviously wrong. The wedges
are already partitions. There are not supposed to be devices like dk0a,
dk0b, etc., but the code we to find the "booted_partition" presumes there
are such devices.

> 
> Using "bootdev=", with all the old baggage of still having to sort out
> the root partition from that is pointless -- all it might make easier is
> IFF the "device" part in the "boot" command could be copied exactly, but
> in my experience that's not what most people seem to do anyway (unless
> implicitly, as I do with "sd0", but that's not a copy per se then), so
> let's stop using it!  Let's just be specific that we're specifying the
> actual root partition device name, as the kernel knows it (i.e. _not_ as
> the bootloader might know it).

I agree.

> 
> 
> Chuck, I think only one or two other tests might be useful.
> 
> Try using "bootdev=hd2d", i.e.:
> 
> menu=Boot normally with Xen:dev hd2d:;load /netbsd-XEN3_DOM0.gz -c console=xencons bootdev=hd2d;multiboot /xen.gz dom0_mem=2G dom0_max_vcpus=4 com1=9600,8n1,0x40c0,16,1:0.0 console=com1 cet=no-ibt pv-l1tf=false
> 
> I don't think that will work because "hd2[a-p]" didn't appear in the
> list when you typed "?", but it might be worth trying.  (How did you
> figure out it should bew "hd2d" anyway?)

It's all documented very well in the x86 boot(8) man page.

For example, from that page is documented a ls command that
we can execute at the boot> prompt:

ls [path]
               [Not available for x86/pxeboot(8)] Print a directory listing of
               path, containing inode number, filename, and file type.  path
               can contain a device specification

I used this to find out that hd2d: was the NetBSD root device when I
execute ls hd2d:/ at the boot> prompt and saw a listing of files
and directories on the NetBSD root partition.

I am sure setting bootdev=hd2d will not work. Those are names of
devices the bootloader understands, not the NetBSD kernel. If
I type something that is not on the list when I type ? at the
"root device" prompt, it just prints out the list of the possible
names for the root device again. I am sure setting it to hd2d will
just cause it to prompt me for the root device at boot time since
it does not recognize a device by that name.

> 
> That's what I mean by saying "bootdev=" would only be useful if one
> could exactly copy the "device" part to it.
> 
> Hmmm.... I guess if one told the bootloader to use a GPT partition by
> "NAME=label", then one could hopefully tell the NetBSD kernel the same
> (but with the "wedge:label" syntax.
> 
> Chuck if you have a plain label (not just UUID) on your root partition,
> maybe you could try:
> 
> menu=Boot normally with Xen:dev NAME=rootlabel;load /netbsd-XEN3_DOM0.gz -c console=xencons bootdev=wedge:rootlabel;multiboot /xen.gz dom0_mem=2G dom0_max_vcpus=4 com1=9600,8n1,0x40c0,16,1:0.0 console=com1 cet=no-ibt pv-l1tf=false

I am not sure if it is easy to replace a plain label on a wedge with
a label. I am surprised the NAME=... form of specifying bootdev did
not work. I may have mis-typed or mis-copied the UUID, I don't know. 

> 
> Either way the idea is to tell both the bootloader and the /netbsd
> "module" where the root filesystem is -- the "booted device" is just
> useless legacy information which allowed legacy users to assume that the
> root partition was the literal first partition on a device.

I think that code to search for the boot device when the actual
root partition, whether it was wd0a or wd0e or whatever is given
to the kernel from boot.cfg is not useless in the legacy case. We need
that code to strip the last character and get the device on which
we can find the disklabel. Then we read the disklabel and figure out
if we have a swap device that can be presumed to also be a dump device,
etc.

So that code is *not* useless on systems using a NetBSD disklabel. It is
useless with UEFU/GPT systems when there is usually no disklabel but wedges
corresponding to the GPT partitions instead, and the fact that we
still try to find a "booted_partition" when we pass dk12 as bootdev is simply
wrong!

I proved it! I am ready to post the results (in a separate message) of
the test I did with a kernel in which I patched that crazy code so it
would skip searching for a "booted_partition" when I passed dk12 as the
bootdev to the kernel in boot.cfg...

> 
> --
> 					Greg A. Woods <gwoods%acm.org@localhost>
> 
> Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
> Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>