On Thu, Aug 17, 2017 at 08:16:29PM -0400, Michael wrote: > Hello, > > On Fri, 18 Aug 2017 09:43:31 +1000 > Paul Ripke <s...@stix.id.au> 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.