Re: nfsroot with netbsd-8

[Paul Ripke <stix%stix.id.au@localhost>]

On Thu, Aug 17, 2017 at 08:16:29PM -0400, Michael wrote:
> Hello,
> 
> On Fri, 18 Aug 2017 09:43:31 +1000
> Paul Ripke <stix%stix.id.au@localhost> wrote:
> 
> > I tried upgrading a little nfsroot sparc box to netbsd-8, and have
> > run into an interesting problem:
> > 
> > root on le0
> > nfs_boot: trying DHCP/BOOTP
> > nfs_boot: DHCP next-server: 192.168.0.1
> > nfs_boot: my_name=orac
> > nfs_boot: my_domain=private
> > nfs_boot: my_addr=192.168.0.12
> > nfs_boot: my_mask=255.255.255.0
> > nfs_boot: gateway=192.168.0.1
> > root on 192.168.0.1:/home/orac
> > root file system type: nfs
> > kern.module.path=/stand/sparc/8.0/modules
> > warning: lookup /dev/console: error 13
> > panic: init died (signal 6, exit 5)
> > 
> > So, the kernel loads successfully via nfs, configures le0 fine, even
> > loads /sbin/init - but fails on /dev/console. And the /dev/console
> > looks fine:
> > 
> > crw-------  1 root  wheel  0, 0 Dec 29  2016 /home/orac/dev/console
> > 
> > Looking at the nfs traffic during the boot, I see a permission denied
> > for an odd major/minor filehandle, which I think is the lookup on
> > /dev/console. Anyone have any ideas what's going on? fwiw, the server
> > is amd64, netbsd-7.
> 
> My guess: you probably need -maproot=0:0 in your /etc/exports line

Remember, this config was working with netbsd-7. I had -maproot=root in
exports, and just tried -maproot=0:0 with no change. Something appears
to have changed somewhere (nfs client? inode lookups? console handling?)
that appears to have broken the console lookup. While the 18,6 filehandle
lookups match the /home/orac raid partition major/minor, where does the
0,28 filehandle lookup come from? I may try to fire up a netbsd-7 kernel
and compare.

Thanks,
-- 
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.