bmh@unc.cs.unc.edu (Brad Hemminger) (12/02/89)
I'm getting a
panic: iinit
that crashes the system when it's trying to boot. Specifically, I have a Vax
11/730 system that I'm unable to get going. In the boot process it does
Rebooting Unix...
UNIX 4.3 (XXXXXXX) #1: Tue Dec 1 17:15:48 PST 1987
memory...
each of the devices in the config are probed,
etc.
then it does the
panic: iinit
and tries to dump to disk; right before it would start up the rc script.
(i.e. it never gets to the message)
Automatic reboot in progress...
So it's probably in the init process? However, I'm am unable to find "iinit"
in the source code (grep'ed all the kernal source stuff).
Thanks,
Brad Hemminger
Dept of Radiology
bmh@cs.unc.educhris@mimsy.umd.edu (Chris Torek) (12/02/89)
In article <10877@thorin.cs.unc.edu> bmh@unc.cs.unc.edu (Brad Hemminger) writes: >I'm getting a > panic: iinit >that crashes the system when it's trying to boot. Specifically, I have a Vax >11/730 system that I'm unable to get going. In the boot process it does > UNIX 4.3 (XXXXXXX) #1: Tue Dec 1 17:15:48 PST 1987 > memory... > each of the devices in the config are probed, > etc. >then it does the > panic: iinit Time for history to repeat (note date of posting below).... From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.unix,net.unix-wizards Subject: Re: panic: iinit: how configuring works Date: 26 Jul 86 14:09:57 GMT In article [deleted] [someone] writes: >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 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris