[pups] Progress on 2.11BSD kernel

[pups] Progress on 2.11BSD kernel

[Ian King]

Well, given the excellent advice I received here (especially from Steven
Schultz), I got the networking kernel to build after moving a few modules
around between overlays.  It was indeed the overage on DATA/BSS that was
killing my build.  I did a 'make install' and sync'ed, then restarted.

<sigh>

Now, when I respond to the boot prompt with 'ra(0,0)unix', I'm getting the
following:

<banner for the image, date, time, etc.>
panic: iinit
no fs on 5/0

I'm booting from an RD54, and checking both 'ls -l /dev/ra*' and
/dev/MAKEDEV, it sure looks to me that the major device number for this
drive is 5 - am I missing anything yet?  That's what I called out as the
ROOTDEV in my config file (in sys/conf), with '5,1' as the SWAPDEV.  (I
snuck a peek at the CURLY config file as well, and it shows major device 5
for ra.)  Note that this is exactly the same device as I have been using all
along with the GENERIC kernel, so I know there's really a filesystem there.
(FWIW, I didn't define an autoboot device.)  In ufs_subr.c, I see where this
message is apparently generated in the getfs() function, but I can't really
tell from that where it's biting me.

Hey, if it wasn't a challenge, it wouldn't be fun, right?  Right?  TIA --
Ian

PS: I'm really glad I followed the advice to copy my old (GENERIC) kernel
image to 'oldunix' - so I can still boot!

[pups] Progress on 2.11BSD kernel

[Steven M. Schultz]

Hi -

> From: "Ian King" <iking at killthewabbit.org>
> I tried changing the partition type with disklabel -e -r but, when I exited
> vi, I got an error message saying that the type I'd provided was not valid.
> Viewing the label (with disklabel -r) showed the fstype set to 'unknown'.

	"unknown" or "unused"

	On my virtual 11 I see disklabel report:

8 partitions:
#        size   offset    fstype   [fsize bsize]
  a:    16720        0   2.11BSD     1024  1024         # (Cyl.    0 - 39)
  b:     8360    16720      swap                        # (Cyl.   40 - 59)
  c:   340670        0    unused     1024  1024         # (Cyl.    0 - 814)
  h:   315590    25080   2.11BSD     1024  1024         # (Cyl.   60 - 814)

> Just for grins, I tried modifying the drive type, too - no success there,
> either.  The disklabel utility isn't having any of that; again it claims
> 'unknown'.

	Ah, that says something is corrupt somewhere.

	If you look at /usr/include/sys/disklabel.h you'll see the
	table of filesystem types:

static char *fstypenames[] = {
        "unused",
	"swap",
	"Version 6",
	"Version 7",
	"System V",
	"2.11BSD",
	"Eighth Edition",
	"4.2BSD",
	"MSDOS",
	"4.4LFS",
	"unknown",
	"HPFS",
	"ISO9660",
	0
};

	So for 'unknown' to appear there would need to be a 10 in the type
	field instead of a 5 (for "2.11BSD").   'unused' is a 0 obviously.

	Try booting up a standalone disklabel and see what it says without
	a kernel getting involved.

	Steve

[pups] Progress on 2.11BSD kernel

[Steven M. Schultz]

Hi -

> From: "Ian King" <iking at killthewabbit.org>
> Now I know I'm missing something.  I tried following your advice, using the
> disklabel utility running under the old kernel.  From what you say below, I

	Which part of the advice?   ;)

	The part of the advice that might be most useful was to put a 
	copy of the standalone disklabel program in / and boot it - NOT
	run the usermode version while the system is running.

	cd /sys/pdpstand
	make
	cp disklabel /

	then reboot the system and at the ':' prompt enter ra(0,0)disklabel

	there are things that can be done with the standalone version that
	are either impractical under a kernel (because the 'a'/root partition
	is open/busy) or because the standalone version has no safety checks.

> assume you are referring to the 'fstype' parameter on the partition, not the
> 'type' parameter for the drive, correct?  The drive type is MSCP, and the
> partition fstype is 2.11BSD.

	'fstype' is what I had in mind.  

  a:    16720        0   2.11BSD     1024  1024         # (Cyl.    0 - 39)

> I tried changing the partition type with disklabel -e -r but, when I exited
> vi, I got an error message saying that the type I'd provided was not valid.
> Viewing the label (with disklabel -r) showed the fstype set to 'unknown'.

	Now I am confused.   2.11BSD is correct - but then it's "unknown" and
	that would cause the 'iinit' panic that started this thread of
	discussion.

	Down the path of logic that results in a 'iinit' panic and the 
	'no fs' there's a check for the filesystem type and "unknown" was the
	likely cause (or at least that was the hope).

	If the standalone disklabel program says it's "2.11BSD" then there's
	something else going on - the next likely thought is that 'rootdev'
	or related entity isn't set to the device that is the actual root
	filesystem.

> Just for grins, I tried modifying the drive type, too - no success there,
> either.  The disklabel utility isn't having any of that; again it claims
> 'unknown'.

	That's not used for anything important.

> Oh well, while I'm waiting for your reply I can rebuild my kernel with a
> higher MAXUSERS parameter.  :-)

	~12 is a good number - not much need for more than that as a rule.

	Steve

[pups] Progress on 2.11BSD kernel

[Ian King]

Steve,

Now I know I'm missing something.  I tried following your advice, using the
disklabel utility running under the old kernel.  From what you say below, I
assume you are referring to the 'fstype' parameter on the partition, not the
'type' parameter for the drive, correct?  The drive type is MSCP, and the
partition fstype is 2.11BSD.

I tried changing the partition type with disklabel -e -r but, when I exited
vi, I got an error message saying that the type I'd provided was not valid.
Viewing the label (with disklabel -r) showed the fstype set to 'unknown'.

Just for grins, I tried modifying the drive type, too - no success there,
either.  The disklabel utility isn't having any of that; again it claims
'unknown'.

Oh well, while I'm waiting for your reply I can rebuild my kernel with a
higher MAXUSERS parameter.  :-)

Thanks -- Ian

----- Original Message -----
From: "Steven M. Schultz" <sms@2BSD.COM>
To: <pups at minnie.tuhs.org>
Sent: Wednesday, March 19, 2003 9:36 AM
Subject: Re: [pups] Progress on 2.11BSD kernel


[snip]
> > Now, when I respond to the boot prompt with 'ra(0,0)unix', I'm getting
the
> > following:
> >
> > <banner for the image, date, time, etc.>
> > panic: iinit
> > no fs on 5/0
>
> That says the kernel was not able to mount the root filesystem.  The
> earlier messages about the kernel build date, etc appear because
> the kernel prints those directly from internal strings  (and the
> kernel is loaded by /boot who doesn't "mount" the root filesystem).
>
[snip]

> The times I have seen the 'iinit' panic it's meant that the disklabel
> was either missing _or_ that the root ('a') partition was not of
> type FS_V71K.   I SUPPOSE it's far fetched, but possible, that the
> old kernel predates the check for the filesystem type, thus it ignores
> the type of partition 'a' and assumes it's a valid filesystem.
>
> If you have a copy of the standalone 'disklabel' program installed
> in / you can boot that with
>
> ra(0,0)disklabel
>
> and examine the label that way.   Or boot the tape and load the
> utility that way.   Using the old kernel and running disklabel
> would work too.   If the 'type' for the 'a' partition is not 'FS_V71K'
> that's the problem.
>

[pups] Progress on 2.11BSD kernel

[Steven M. Schultz]

Hi -

> From: Johnny Billquist <bqt at update.uu.se>
> Are the UMRs allocated and set up statically?

	The clist and buffer cache UMRs are initialized at system boot time.

> (I haven't looked inside 2BSD for a while now, and can't remember much of
> the internals anymore.)

	And I haven't been around a UNIBUS system for a long time and the
	memory of having to deal with UMRs has faded.

> How many UMRs does the system use? 8 for buffer cache, you might expect
> one or two DH11s, that would require a few more, ethernet takes another
> few, but it seems there shouldn't be such a shortage.

	There are only 31 total - so a few allocated here, a few allocated
	there could result in not having enough.

> What did I miss?

	Swapping.  The kernel has to always be able to get UMRs to be
	able to swap out a process.   The memory is fuzzy but I think the
	kernel reserved 7 as to be able to swap 56KB at a time of a process
	but it could get by with less.   

	One UMR is 'reserved' by the hardware to cover the "I/O Page".

	The clist takes up 1 UMR for DMA terminal devices.

	Ethernet of course takes a UMR or two.  At one time a couple of the
	ethernet drivers (DEUNA) were a bit braindamaged and allocated more
	UMRs than they needed - I fixed that though.

	MSCP and TMSCP devices need UMRs to map their command and response
	rings.   The initial MSCP driver was definitely suboptimal in that
	regard - again, something I tended to (the problem showed up when
	more than 1 controller was present in a system).   Those UMRs are
	permanently allocated at boot time by the drivers when they initialize.

	Tape drivers need to have UMRs (although I don't know of too many
	folks with the old TE16 drives around on a UNIBUS system) available.

	It started adding up and on a system with several types of devices
	each of which wanted to reserve a couple UMRs the available pool for
	dynamic use (by tapes and swapping) was sometimes too small.

	Cheers,
	Steven Schultz

[pups] Progress on 2.11BSD kernel

[Johnny Billquist]

On Wed, 19 Mar 2003, Steven M. Schultz wrote:

> 	The buffer cache must be entirely mapped by UMRs - so if you have a 
> 	32KB buffer the kernel will reserve 4 UMRs on a UNIBUS system.   
> 	Realistically a 64KB buffer cache is about the maximum a UNIBUS system 
> 	can have because that takes 8 of the UMRs.  

Are the UMRs allocated and set up statically?
(I haven't looked inside 2BSD for a while now, and can't remember much of
the internals anymore.)

> 	With the old (thankfully no longer in use, etc) 3Com ethernet boards
> 	you had to disable 4 UMRs so the system could access the memory in the
> 	card - that made for a very tight fit.

How many UMRs does the system use? 8 for buffer cache, you might expect
one or two DH11s, that would require a few more, ethernet takes another
few, but it seems there shouldn't be such a shortage.

What did I miss?

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt at update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[pups] Progress on 2.11BSD kernel

[David Evans]

On Wed, Mar 19, 2003 at 03:08:46PM -0800, Steven M. Schultz wrote:
> >   OK.  From what I recall (that turned-off machine again...) the entire
> > discussion on tuning MAXUSERS and friends is based on allocation of UMRs.
> > Might be a good idea to slip in a note about what to do when you don't have
> 
> 	It is less a matter of MAXUSERS than it is of NBUF.   NBUF sets
> 	the number of disc cache buffers.

  Yeah, sorry, it was NBUF that I was thinking of.  It's been aboutn a month
since I've had a chance to fiddle with my /73.

> 	The other constraint, even for Qbus systems, is the D space requirement.
> 	The 1KB portion of the disc buffer is "external" to the kernel (is 
> 	mapped in/out as needed) but there is a header structure which is
> 	part of the kernel's permanent address space.  Each buffer header is
> 	24 bytes so even without UMRs around it's not feasible to have a 200KB
> 	cache because that'd use 4800 bytes of kernel D space (which is always
> 	on the edge of being overflowed it seems).
> 

  Cool, thanks.

-- 
David Evans          (NeXTMail/MIME OK)             dfevans at bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie     http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo         "Default is the value selected by the composer
Ontario, Canada           overridden by your command." - Roland TR-707 Manual

[pups] Progress on 2.11BSD kernel

[Steven M. Schultz]

Hi -

> From: David Evans <dfevans at bbcr.uwaterloo.ca>
> 
>   OK.  From what I recall (that turned-off machine again...) the entire
> discussion on tuning MAXUSERS and friends is based on allocation of UMRs.
> Might be a good idea to slip in a note about what to do when you don't have

	It is less a matter of MAXUSERS than it is of NBUF.   NBUF sets
	the number of disc cache buffers.   MAXUSERS affects the size of the
	proc table, file table, and other tables which are in the permanent
	(not mapped in/out) portion of the kernel's address space but does 
	not affect the disc buffer cache which is the entity requiring UMRs
	on a UNIBUS system.

	The buffer cache must be entirely mapped by UMRs - so if you have a 
	32KB buffer the kernel will reserve 4 UMRs on a UNIBUS system.   
	Realistically a 64KB buffer cache is about the maximum a UNIBUS system 
	can have because that takes 8 of the UMRs.  

	With the old (thankfully no longer in use, etc) 3Com ethernet boards
	you had to disable 4 UMRs so the system could access the memory in the
	card - that made for a very tight fit.

	The other constraint, even for Qbus systems, is the D space requirement.
	The 1KB portion of the disc buffer is "external" to the kernel (is 
	mapped in/out as needed) but there is a header structure which is
	part of the kernel's permanent address space.  Each buffer header is
	24 bytes so even without UMRs around it's not feasible to have a 200KB
	cache because that'd use 4800 bytes of kernel D space (which is always
	on the edge of being overflowed it seems).

	On a 11/73 I've used a 100KB buffer cache but when I was using 11/44s
	and /70s the max was 64KB.

	Cheers,
	Steven Schultz

[pups] Progress on 2.11BSD kernel

[David C. Jenner]

Carl Lowenstein wrote:
>
> You could put your SCSI drive into one of those pull-out
> "mobile adapter" things.  But you probably should not pull
> it out without idling the SCSI bus first.

This is exactly what I am doing at the moment for my 11/73.
I got a "CD SCSI RACK" real cheap surplus that has hardware
for 8 half-height drives (originally CDs).  I'm putting
several SCSI "disk trays" into it, as well as a couple of
fixed harddrives and a tape drive.  I may even try to put my
RX floppy drives into it, although I'll have to figure out
how to properly cable the RQDX3 to the drives without a
BA chassis.

Dave
-- 
David C. Jenner
djenner at earthlink.net

[pups] Progress on 2.11BSD kernel

[David Evans]

On Wed, Mar 19, 2003 at 11:09:58AM -0800, Steven M. Schultz wrote:
> 	It really doesn't - not having UMRs to deal with is a Nice Thing about 
> 	the Qbus ;)   The kernel (and the standalone utilities of course)
> 	need to know if they're on a U or Q-bus system but once a Q system
> 	is found then the UMR handling is bypassed.
> 

  OK.  From what I recall (that turned-off machine again...) the entire
discussion on tuning MAXUSERS and friends is based on allocation of UMRs.
Might be a good idea to slip in a note about what to do when you don't have
them.

-- 
David Evans          (NeXTMail/MIME OK)             dfevans at bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie     http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo         "Default is the value selected by the composer
Ontario, Canada           overridden by your command." - Roland TR-707 Manual

[pups] Progress on 2.11BSD kernel

[David Evans]

On Wed, Mar 19, 2003 at 11:06:30AM -0800, Carl Lowenstein wrote:
> > From: David Evans <dfevans at bbcr.uwaterloo.ca>
> >   I was thinking of a SCSI adapter that plugged into the bulkhead somehow.
> > This is plainly rediculous, but a nifty idea nontheless.
> 
> You could put your SCSI drive into one of those pull-out
> "mobile adapter" things.  But you probably should not pull
> it out without idling the SCSI bus first.
> 

  True.  I'm not actually dying to do this, BTW, but was just wondering
whether anyone in the past chose to take advantage of the controls.

-- 
David Evans          (NeXTMail/MIME OK)             dfevans at bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie     http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo         "Default is the value selected by the composer
Ontario, Canada           overridden by your command." - Roland TR-707 Manual

[pups] Progress on 2.11BSD kernel

[Steven M. Schultz]

Hi -

> From: David Evans <dfevans at bbcr.uwaterloo.ca>
>   I recall cranking MAXUSERS up a little, though I can't remember to

	Good Idea because the default is only suitable for single user mode
	and building a new/custom kernel.   Quite a few kernel tables
	are sized based on 'maxusers' - in particular the coremap and swapmap
	tables (which track the fragments of memory and swap space) will be
	exhausted easily if you bring up a network'd kernel and start up
	the various daemons.

> what and my PDP-11 is turned off at the monent.  A clarification of
> how the whole Unibus map register business effects Qbus-based systems
> would be nice.

	It really doesn't - not having UMRs to deal with is a Nice Thing about 
	the Qbus ;)   The kernel (and the standalone utilities of course)
	need to know if they're on a U or Q-bus system but once a Q system
	is found then the UMR handling is bypassed.

	Cheers,
	Steven Schultz

[pups] Progress on 2.11BSD kernel

[Carl Lowenstein]

> From: David Evans <dfevans at bbcr.uwaterloo.ca>
> To: "Steven M. Schultz" <sms at 2BSD.COM>
> Cc: pups at minnie.tuhs.org
> Subject: Re: [pups] Progress on 2.11BSD kernel
> Date: Wed, 19 Mar 2003 13:08:16 -0500
> 
> On Wed, Mar 19, 2003 at 09:51:10AM -0800, Steven M. Schultz wrote:
> > Howdy -
> > 
> > > From: David Evans <dfevans at bbcr.uwaterloo.ca>
> > > This came in handy for me too when I went the route of messed up MAXUSERS 
> > > screwage.
> > 
> > 	That'll do it too ;)
> > 
> 
>   Fortunately /vmunix & /oldvmunix is a familiar procedure from back in
> my PMAX device driver hacking days.
> 
> > >   On another note, were there any SCSI adapters that made use of the BA23/
> > > BA123 RD disk control buttons?  Would be nifty to swap in a new ra0 by
> > > simply taking a disk offline/online.
> > 
> > 	Hmmm, those buttons/cabling are for RD/MSCP devices - not sure if it's
> > 	possible to use them with SCSI devices.
> > 
> 
>   I was thinking of a SCSI adapter that plugged into the bulkhead somehow.
> This is plainly rediculous, but a nifty idea nontheless.

You could put your SCSI drive into one of those pull-out
"mobile adapter" things.  But you probably should not pull
it out without idling the SCSI bus first.

    carl
-- 
    carl lowenstein         marine physical lab     u.c. san diego
                                                 clowenst at ucsd.edu

[pups] Progress on 2.11BSD kernel

[David Evans]

On Wed, Mar 19, 2003 at 10:24:22AM -0800, Ian King wrote:
> My MAXUSERS is most modest (the default 4) as is my number of ttys.

  I recall cranking MAXUSERS up a little, though I can't remember to
what and my PDP-11 is turned off at the monent.  A clarification of
how the whole Unibus map register business effects Qbus-based systems
would be nice.

-- 
David Evans          (NeXTMail/MIME OK)             dfevans at bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie     http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo         "Default is the value selected by the composer
Ontario, Canada           overridden by your command." - Roland TR-707 Manual

[pups] Progress on 2.11BSD kernel

[Ian King]

My MAXUSERS is most modest (the default 4) as is my number of ttys.  I
followed your advice on this, as the overall size of unix.o wasn't excessive
but I still got the 'type 431' error; after shuffling some pieces out,
unix.o linked and the build continued.  Maybe it's FM....  -- Ian

----- Original Message -----
From: "Steven M. Schultz" <sms@2BSD.COM>
To: <pups at minnie.tuhs.org>
Sent: Wednesday, March 19, 2003 9:36 AM
Subject: Re: [pups] Progress on 2.11BSD kernel


> Hi -
>
> > From: "Ian King" <iking at killthewabbit.org>
> > Well, given the excellent advice I received here (especially from Steven
> > Schultz), I got the networking kernel to build after moving a few
modules
> > around between overlays.  It was indeed the overage on DATA/BSS that was
>
> Hmmm, if it was an overage on the DATA/BSS (which is hard to do unless
> you overdeclare MAXUSERS or the number of tty devices) then
> shuffling overlays wouldn't have made any difference since overlays
> affect only code and not data allocation.
>
[snip]

[pups] Progress on 2.11BSD kernel

[David Evans]

On Wed, Mar 19, 2003 at 09:51:10AM -0800, Steven M. Schultz wrote:
> Howdy -
> 
> > From: David Evans <dfevans at bbcr.uwaterloo.ca>
> > This came in handy for me too when I went the route of messed up MAXUSERS 
> > screwage.
> 
> 	That'll do it too ;)
> 

  Fortunately /vmunix & /oldvmunix is a familiar procedure from back in
my PMAX device driver hacking days.

> >   On another note, were there any SCSI adapters that made use of the BA23/
> > BA123 RD disk control buttons?  Would be nifty to swap in a new ra0 by
> > simply taking a disk offline/online.
> 
> 	Hmmm, those buttons/cabling are for RD/MSCP devices - not sure if it's
> 	possible to use them with SCSI devices.
> 

  I was thinking of a SCSI adapter that plugged into the bulkhead somehow.
This is plainly rediculous, but a nifty idea nontheless.

-- 
David Evans          (NeXTMail/MIME OK)             dfevans at bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie     http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo         "Default is the value selected by the composer
Ontario, Canada           overridden by your command." - Roland TR-707 Manual

[pups] Progress on 2.11BSD kernel

[Steven M. Schultz]

Howdy -

> From: David Evans <dfevans at bbcr.uwaterloo.ca>
> This came in handy for me too when I went the route of messed up MAXUSERS 
> screwage.

	That'll do it too ;)

>   I should track down the half-bezel so that I can mount this SCSI Zip drive I
> have in my BA123.  That would look so weird...

	It is tight on space but I can get a complete 2.11 system (with sources)
	and a small swap partition on a 96MB Zip disk.   Not suitable really
	for going multi-user but as a single user mode system for fixing
	up /etc/init or building a kernel it's nice.

	Might not look too weird - different of course, who knows but what
	you might like the new look ;)

>   On another note, were there any SCSI adapters that made use of the BA23/
> BA123 RD disk control buttons?  Would be nifty to swap in a new ra0 by
> simply taking a disk offline/online.

	Hmmm, those buttons/cabling are for RD/MSCP devices - not sure if it's
	possible to use them with SCSI devices.

	Steven Schultz

[pups] Progress on 2.11BSD kernel

[David Evans]

On Wed, Mar 19, 2003 at 09:36:58AM -0800, Steven M. Schultz wrote:
> > PS: I'm really glad I followed the advice to copy my old (GENERIC) kernel
> > image to 'oldunix' - so I can still boot!
> 
> 	Ah, glad to hear that the advice came in handy.

  This came in handy for me too when I went the route of messed up MAXUSERS
screwage.

> The other thing
> 	that comes in useful is a bootable Zip disk (complete 2BSD system
> 	fits on a Zip disk if one has a SCSI adaptor around) - came in handy
> 	when I corrupted/broke 'init' ...
> 

  I should track down the half-bezel so that I can mount this SCSI Zip drive I
have in my BA123.  That would look so weird...

  On another note, were there any SCSI adapters that made use of the BA23/
BA123 RD disk control buttons?  Would be nifty to swap in a new ra0 by
simply taking a disk offline/online.

-- 
David Evans          (NeXTMail/MIME OK)             dfevans at bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie     http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo         "Default is the value selected by the composer
Ontario, Canada           overridden by your command." - Roland TR-707 Manual

[pups] Progress on 2.11BSD kernel

[Steven M. Schultz]

Hi -

> From: "Ian King" <iking at killthewabbit.org>
> Well, given the excellent advice I received here (especially from Steven
> Schultz), I got the networking kernel to build after moving a few modules
> around between overlays.  It was indeed the overage on DATA/BSS that was

	Hmmm, if it was an overage on the DATA/BSS (which is hard to do unless
	you overdeclare MAXUSERS or the number of tty devices) then
	shuffling overlays wouldn't have made any difference since overlays
	affect only code and not data allocation.

> Now, when I respond to the boot prompt with 'ra(0,0)unix', I'm getting the
> following:
> 
> <banner for the image, date, time, etc.>
> panic: iinit
> no fs on 5/0

	That says the kernel was not able to mount the root filesystem.  The
	earlier messages about the kernel build date, etc appear because 
	the kernel prints those directly from internal strings  (and the
	kernel is loaded by /boot who doesn't "mount" the root filesystem).

> I'm booting from an RD54, and checking both 'ls -l /dev/ra*' and
> /dev/MAKEDEV, it sure looks to me that the major device number for this
> drive is 5 - am I missing anything yet?  That's what I called out as the

	You're not missing anything so far ;)

	Are there other devices/controllers on the system?   That should work
	(works on my system) but I'm trying to get a handle on what might be
	confusing the kernel.

> for ra.)  Note that this is exactly the same device as I have been using all
> along with the GENERIC kernel, so I know there's really a filesystem there.

	That's the puzzling part - why the old one works but the new one
	doesn't.   

> (FWIW, I didn't define an autoboot device.)  In ufs_subr.c, I see where this
> message is apparently generated in the getfs() function, but I can't really

	mountfs() calls getfs().   mountfs() is called out of main() in
	init_main.c

	The panic "iinit" is in init_main.c after mountfs() has returned
	NULL

	The times I have seen the 'iinit' panic it's meant that the disklabel
	was either missing _or_ that the root ('a') partition was not of
	type FS_V71K.   I SUPPOSE it's far fetched, but possible, that the
	old kernel predates the check for the filesystem type, thus it ignores
	the type of partition 'a' and assumes it's a valid filesystem.  

	If you have a copy of the standalone 'disklabel' program installed
	in / you can boot that with

		ra(0,0)disklabel

	and examine the label that way.   Or boot the tape and load the
	utility that way.   Using the old kernel and running disklabel
	would work too.   If the 'type' for the 'a' partition is not 'FS_V71K'
	that's the problem.

> PS: I'm really glad I followed the advice to copy my old (GENERIC) kernel
> image to 'oldunix' - so I can still boot!

	Ah, glad to hear that the advice came in handy.   The other thing
	that comes in useful is a bootable Zip disk (complete 2BSD system
	fits on a Zip disk if one has a SCSI adaptor around) - came in handy
	when I corrupted/broke 'init' ...

	Steve