Re: Dom0 - fatal page fault in supervisor mode when root FS is on a slice of disklabel lying on a raidframe device, built up from two GPT wedges

[Matthias Petermann <matthias%petermann-it.de@localhost>]

Am 23.08.2018 um 13:16 schrieb Manuel Bouyer:
> On Thu, Aug 23, 2018 at 01:11:28PM +0200, Matthias Petermann wrote:
> > Am 23.08.2018 um 13:01 schrieb Manuel Bouyer:
> > > On Thu, Aug 23, 2018 at 12:58:32PM +0200, Matthias Petermann wrote:
> > > > Do you have pointer for me where the root= argument is documented?
> > >
> > > It used to be in the howto, I didn't check recently.
> > >
> > > > I just tried with this boot.cfg line:
> > > >
> > > > menu=Xen:load /netbsd-XEN3_DOM0.gz console=pc;multiboot /xen.gz
> > > > dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin root=/dev/raid0a
> > >
> > > should be:
> > > menu=Xen:load /netbsd-XEN3_DOM0.gz console=pc root=raid0a;multiboot /xen.gz dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin
> >
> > That was it! Thank you - you saved my day! The system is booting now and I'm
> > looking forward to setting up the VMs. I owe you a drink.
>
> Actually, if you can set up a serial console I'm still interested in
> the details of the panic, and a stack trace. It would be better to have the
> kernel ask for its root filesystem than panic ...

Yes, sure... this would have been my next question, why the NetBSD/xen 
kernel behaves different than the standard kernel. I agree we still need 
better understanding why this happend. I will followup on this tomorrow 
- assuming the hardware arrived until then.

Thanks again,
Matthias


--
Matthias Petermann <matthias%petermann-it.de@localhost> | www.petermann-it.de
GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572  C3D7 7B1D A3C3 5C3E 6D75