chris@umcp-cs.UUCP (Chris Torek) (07/26/86)
In article <972@dicome.UUCP> salmi@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@umcp-cs ARPA: chris@mimsy.umd.edu
wesommer@mit-trillian.MIT.EDU (William Sommerfeld) (07/27/86)
In article <2621@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: >you can make any number of vmunixes (vmunii?) for each one. How about "vmunices"?
setha@teklds.UUCP (Seth D. Alford) (07/31/86)
When you change your unit plugs to boot from a "spare" root on a different drive, you should very definitely modify /etc/fstab or not go into multiple user. Otherwise, depending on how your system is configured, you may lose data. If you are swapping on a non-b partition on one of your disks, you may find yourself swapping on a non-b partition on another disk. Your data on the file system on that partition will be wiped out. Even if you only swap on b partitions you make life much easier for yourself if you fix /etc/fstab. -- --Seth Alford Tektronix Walker Road PO Box 4600 MS 92-823 Beaverton OR 97075 tektronix!teklds!setha (503)-629-1145
mangler@cit-vax.Caltech.Edu (System Mangler) (08/04/86)
In article <2395@teklds.UUCP>, setha@teklds.UUCP (Seth D. Alford) writes: > When you change your unit plugs ... > ... depending on how your system is configured, > you may lose data. If you are swapping on a non-b partition on one of > your disks, you may find yourself swapping on a non-b partition on another > disk. Your data on the file system on that partition will be wiped out. On 4.2/4.3 BSD, if you wildcard the unit numbers in the config file, this can happen even without changing the unit plugs - if a paging disk is missing or not powered up, the wildcarding substitutes some other disk, and you wipe out any filesystem that crosses that area. (I still remember spending my 21st birthday reconstructing an RT11 directory that got swapped on. It taught me the value of backups). Unit number wildcards seem to be quite dangerous without really giving you anything. I don't use them any more. Don Speck speck@vlsi.caltech.edu seismo!cit-vax!speck