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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, May 29, 2025 at 03:01:50PM -0400, Chuck Zmudzinski wrote:
> [...]
> db{0}>
> 
> > 
> > Perhaps it has something to do with the fact you're using what Xen calls
> > "com2" for the serial console.
> 
> Yes, that is exactly the problem, and since DOM0 cannot detect which port Xen
> is using, our DOM0 config just assumes it is always going to be com0, but in
> my case I cannot use com0 as the Xen console so I am using what NetBSD sees as
> com2 instead.

Yes, because doesn't hide the com port is uses from the dom0 kernel.
As noted in the kernel config file I don't know how to detect this situation.

[..]

> 
> The strange part is that it is necessary to pass -c to the DOM0 in boot.cfg to
> actually disable com* and the bootloader does not execute the userconf=disable com*
> command that is present in boot.cfg when booting NetBSD/xen DOM0. The userconf=com*
> setting works for the boot without Xen, but with Xen the bootloader ignores that
> setting in boot.cfg.

This is because the userconf command from the boot loader doens't make it
to the dom0 kernel.
Remember that when booting Xen; Xen is the kernel and XEN3_DOM0 a module.
I don't know if multiboot allows passing extended informations to a module.

> Yes this is very strange indeed! Here are more details...
> 
> Actually, dk12 is the fourth partition on wd1 (using gpt partitioning). When
> I pass wd1 as bootdev in boot.cfg the bootloader at least dropped me to a
> prompt and allowed me to enter dk12 as the boot device. In this case the
> bootloader thinks wd1a is the root device and wd1b is the dump device as
> shown in this quote from my earlier message:
> 
> > [     5.159642] boot device: wd1
> > [     5.159642] root on wd1a dumps on wd1b

that's not the boot loader. That's the XEN3_DOM0 kernel.

> 
> but when the bootloader realizes this is wrong it drops me to the prompt where
> I could enter dk12 as the root device, dk11 as the dump device, and then enter
> the default choices for the filesystem type and init and get a successful boot.
> I expect if I add a disklabel to wd1 and set wd1a as the root partition and
> wd1b as the swap/dump partition, it would work with the wd1 setting for bootdev
> in boot.cfg, but I have not verified that yet. This is not really so strange,
> and I probably just need to add the correct NetBSD disklabel to wd1 to fix it.
> 
> Here is the strange part:
> 
> When I pass bootdev=dk12 in boot.cfg, the bootloader strangely tries dk1 as root
> (which is wrong) and correctly detects dk11 as the dump device. But it never
> gives me the chance to enter the correct root device and instead tries to load
> init which of course it cannot find the NetBSD init on dk1 because dk1 is not
> the correct NetBSD root device. In fact on this box a Linux distro is installed
> on dk1, as evidenced by the filesystem type detected on dk1: ext2fs.

Hum this could be a bug is the boot argiment parsing. I don't have more than
9 partitions on my disks and root=dkX works in my case.

> 
> Here is where it stops to ask me for init, but it never gave me
> the chance to enter the correct root device of dk12. Of course it

Yes, it was given a root device, it won't ask again.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--