Re: Problems booting NetBSD/Xen on Intel NUC 12 Extreme w/ i9-12900

[Johan Stenstam <johani%johani.org@localhost>]

Hi Manuel,

> On 10 May 2023, at 21:31, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> 
> On Wed, May 10, 2023 at 03:04:37PM -0400, Greg Troxel wrote:
>> Johan Stenstam <johani%johani.org@localhost> writes:
>> 
>>> 2. How important is it to keep in exact sync between xenkernelNNN and
>>> xentoolsMMM? I.e. assuming I get past the current crash and get a
>>> running system with xenkernel415, is it imperative that I find a
>>> xentools415 to go with it or would xentools413 be sufficient?
>> 
>> I built xentools415 on March 14, as part of testing what was to become
>> 2023Q1.  The host was netbsd-10 (so 10_BETA). I would recommend testing
>> with 10 rather than 9 for a new system.
>> 
>>> 3. When trying 10_BETA + xenkernel415 I notice that the distribution
>>> doesn?t include the kernel modules,
>>> i.e. /stand/amd64-xen/10.0/modules/ is empty. It seems that there is
>>> no difference in the .kmods between GENERIC and XEN_DOM0 systems, so I
>>> just copied them over. But it surprises me as one of the things that
>>> will be much improved with NetBSD 10 is Xen performance, so why then
>>> isn?t the distribution kit complete?
>> 
>> It's a bug that you need separate  modules, and my understanding is that
>> as of 10, you don't.
> 
> AFAIK NetBSD/xen still need separate modules (and I don't think it's going
> to change). But as I don't use modules I don't know how they're supposed
> to be built.

Well, I have them (copied from /stand/amd64/ to /stand/amd64-xen/), so either way this should not be the issue.

>>> 4. What should I try next to get this running?
>> 
>> The suggestion you received about more RAM is a good one.
>> 
>> There is surely a way to get debugging.  Adding -d to the NetBSD boot
>> might help.  It might be possible to use kgdb on serial.
> 
> You can also set console=com0 for NetBSD (even if you're not using
> a serial console) and vga=current,keep for Xen.
> This way Xen will keep control of the vga console when starting the dom0
> kernel, and NetBSD will output to the console through Xen.

Now this was a truly wonderful suggestion!

I now haw a serial console with output to the screen. Slow as molasses, as I didn’t think to set the baud rate to something sensible. But there is output and I can see NetBSD booting, one dmesg line at a time. After a long time it ends like this:

…
WARNING: 2 errors while detecting hardware; check system log
boot device: dk0
root on dk0 dumps on dk2
Your machine does not initialise mem_clusters; …
root file system type: mods
kern.module.path=/stand/amd64/10.0/modules
exec /sbin/init: error 2
…
init: trying /rescue/init
exec /rescue/init: error 2

And there it stops. And we know a lot more. 

For context, this is an UEFI system, with a GPT partitioning table, dk0 is the UEFI/MSDOS partition, NetBSD root is dk1, etc. Compare that tail end of the output to a (successful) boot of 10_BETA GENERIC:

…
boot device: ld0
root on dk1 dumps on dk2
root file system type: ffs
kern.module.path=/stand/amd64/10.0/modules

I have no idea what has caused NetBSD/Xen to think that the boot device is dk0, but that’s clearly where everything goes south.

Any suggestions?

Regards,
Johan