panic: iinit: how configuring works

Chris Torek chris at umcp-cs.UUCP
Sun Jul 27 00:09:57 AEST 1986


In article <972 at dicome.UUCP> salmi at dicome.UUCP (john salmi) writes:
>1)	decided to have a backup root filesystem, 'just in case'
>2)	i ran /etc/newfs on /dev/ra2a 
>3)	dump(8)'ed /dev/ra0a (root) to tape, then restore -r'ed the
>	tape to /dev/ra2a
>4)	attempt to boot from /dev/ra2a
>5)	system gets to the point of single user mode prompt, and gets
>	a  ``panic: iinit''

`panic: iinit' occurs when a kernel cannot mount the root file
system during booting.  This is usually caused by disk errors.  In
this particular case it was probably due to the lack of a file
system on ra0a.  Except in 4.3BSD, each bootable kernel (/vmunix)
file has a variable that dictates just where the root file system
is to be found (by major/minor block device number).  (In 4.3,
the variable is still there, but is normally overridden by the
actual parameters to the boot command.)

There are actually several such variables.  The most important
are `rootdev', `swdevt', and `argdev' (and `pipedev' in 4.1).
You can examine and alter these variables with `adb'.  (In the
script below, I have put a `:' in front of lines you type;
unmarked lines are the responses.)

:	% adb -w /backup_root/vmunix
:	rootdev?X
	_rootdev:
	_rootdev:	900

This is major device nine (UDA50/RAxx driver), minor device 0
(drive 0, partition a); the numbers are all in hex, and devices
are coded as two one-byte values mashed together.  To change
this to ra2a:

:	rootdev?W 0910
	_rootdev:
	_rootdev:	900		=	910

(0910 => ra2a: 0x0900 (RAxx) + 2*8 (2) + 0 (a) = 0x0910.)

`rootdev' specifies the root file system device; `argdev' gives
the device for holding exec() arguments, and is normally one of
the swap devices.  `pipedev' is again a file system, usually the
same as `rootdev'.  `swdevt' is an array.  Each entry is three
longwords (two in 4.1); the first is the device, and the other
two are `untouchable' (`MBZ' in DEC notataion).  The first entry
is the important one; the other two are not used until you issue
a `swapon' call (via /etc/swapon).

:	argdev?W 0911
	_argdev:
	_argdev:	901		=	911
:	swdevt?W 0911
	_swdevt:
	_swdevt:	901		=	911

This changes both `argdev' and the primary swap device from ra0b
(09 01) to ra2b (09 11).  ra1b would be 0909 (0900 + 1*8 + 0.)

There is one left, `dumpdev', for crash dumps:

:	_dumpdev?W 0911
	_dumpdev:
	_dumpdev:	901		=	911
:	$q
	%

These files are normally built by config, from the specifications

	root on ra0a		# rootdev
	args on ra0b		# argdev
	swap on ra0b and ra1b and ra2b	# swdevt[]
	dumps on ra0b		# dumpdev

Practically everyone uses `root on xx0a args on xx0b swap on xx0b
dumps on xx0b', so config has some built-in defaults.  Writing

	root on ra0

suffices to specify all of that.  If you have multiple swap disks,

	root on ra0 swap on ra0b and ra1b

suffices.

If you look closely at your present configuration file, you will
note that it actually says something like this:

	config	vmunix		root on ra0

What is that `vmunix' doing there?  Well, you can add other lines:

	config	alt_vmunix	root on ra2

After doing `config PICKLE; cd ../PICKLE; make depend', you can
say either `make' or `make vmunix' to make the one with root on
ra0a etc., or `make alt_vmunix' to make the one with root on ra2a
etc.  If you have lots of strange ways you might boot your machine,
you can make any number of vmunixes (vmunii?) for each one.

Of course, it is by far easier to use the unit plugs on the drive
units whenever possible.  Currently, all of the vaxen in the CS
department here have a spare root file system on the second drive
on the same controller from which we normally boot (got that?).
All these drives have unit number plugs, or switches, or dials, or
what-have-you.  If we lose a root file system, we simply change
the drive numbers and boot to single user mode.  (I have yet to
install the new 4.3 code that guesses from what drive you in fact
booted.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu



More information about the Comp.unix mailing list