On Sat, Aug 19, 2017 at 06:00:55PM +0200, Martin Husemann wrote: > On Sat, Aug 19, 2017 at 01:51:26PM +1000, Paul Ripke wrote: > > 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. > > It works fine for me with various diskless machines, server is running > netbsd-7.
Urgh, Don't mind me, looks like this was unfortunate upgrade timing and a remarkably deterministic hardware failure of some sort (likely RAM). I now get consistent failures booting netbsd-7 & netbsd-8 kernels with and without miniroots. scsibus0: waiting 2 seconds for devices to settle... wskbd0 at kbd0 mux 1 kbd0: reset failed cd0 at scsibus0 target 6 lun 0: <TOSHIBA, XM-4101TASUNSLCD, 1755> cdrom removable cd0: async, 8-bit transfers root on md0a dumps on md0b root file system type: ffs kern.module.path=/stand/sparc/8.0/modules cpu0: NMI: system interrupts: 0x40000000<VME=0x0,SBUS=0x0,ME> init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 init[1]: trap 0x21: pc=0x9daac sfsr=0x2054 sfva=0x32bb8 Thanks, all! -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
