chris@umcp-cs.UUCP (Chris Torek) (11/12/85)
One of the most, er, `interesting' things that can happen to a root file system is to lose /dev (have it turn into an ordinary file or soemthing). If you have lost /dev, *and nothing else*, it would seem perfectly reasonable that /etc/init could come up single user by creating a new console device. Of course, it will not, and one is forced to recover with standalone programs or a 4.2-style minifs. Here is an *untested* change to init that should be easy enough to install in a 4.2 system to do this. *** /usr/src/etc/init.c Wed Sep 18 21:40:02 1985 --- init.c Tue Nov 12 05:11:46 1985 *************** *** 193,197 **** signal(SIGALRM, SIG_DFL); signal(SIGTSTP, SIG_IGN); ! (void) open(ctty, O_RDWR); dup2(0, 1); dup2(0, 2); --- 193,197 ---- signal(SIGALRM, SIG_DFL); signal(SIGTSTP, SIG_IGN); ! get_console(); dup2(0, 1); dup2(0, 2); *************** *** 203,206 **** --- 203,221 ---- break; } while (xpid == -1); + } + + /* + * Open the console, and if it fails make a last ditch attempt to + * create a new one. Assumes fd 0 is not currently open. + */ + get_console() + { + + if (open(ctty, O_RDWR) == 0) + return; + (void) strcpy(ctty, "/#console"); + (void) mknod(ctty, S_IFCHR|0644, 0); + (void) open(ctty, O_RDWR); + (void) write(0, "WARNING: /dev/console gone, made /#console\n", 43); } -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
larry@geowhiz.UUCP (Larry McVoy) (11/13/85)
In article <2200@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >One of the most, er, `interesting' things that can happen to a root >file system is to lose /dev (have it turn into an ordinary file or >soemthing). If you have lost /dev, *and nothing else*, it would >seem perfectly reasonable that /etc/init could come up single user >by creating a new console device. Of course, it will not, and one >is forced to recover with standalone programs or a 4.2-style minifs. Er, ahum, I, well, I did this a while ago via an otherwise useful utility called nu (it ended up doing a rm -rf on /, I eventually figured out that something was wrong when "No rmdir" was repeatedly shouted at me). I was out /dev & /bin, but still had /etc and /usr. Using /etc/mknod, I was able to put back a /dev/rmt0 back and do a dump before doing the standalone restor. Very useful as I had done a fair bit of work that day.... -- Larry McVoy +----------------+ | Slower traffic | Arpa: mcvoy@rsch.wisc.edu | keep right | Uucp: {seismo, ihnp4}!uwvax!geowhiz!geophiz!larry +----------------+
mike@whuxl.UUCP (BALDWIN) (11/15/85)
> + /* > + * Open the console, and if it fails make a last ditch attempt to > + * create a new one. Assumes fd 0 is not currently open. > + */ > + get_console() > + { > + > + if (open(ctty, O_RDWR) == 0) > + return; > + (void) strcpy(ctty, "/#console"); > + (void) mknod(ctty, S_IFCHR|0644, 0); > + (void) open(ctty, O_RDWR); > + (void) write(0, "WARNING: /dev/console gone, made /#console\n", 43); > } > > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) Er, um, what if your console isn't maj,min 0,0? On my 7300, /dev/console is 7,0 and the root file system is 0,0 -- writing WARNING over the boot block would be, like, disastrous. The only way to *know* what major dev console is (minor 0 seems OK to assume) is to dig through cdevsw[] -- a decicedly non-trivial task, and you don't even know that /unix is the one you booted from anyway. Oh well. -- Michael Baldwin {at&t}!whuxl!mike
chris@umcp-cs.UUCP (Chris Torek) (11/16/85)
I did say `4.2BSD'! % ls -l /dev/console crw--w--w- 1 root 0, 0 Nov 15 16:40 /dev/console A better solution to the destroyed-root-file-system problem, if you can afford it, is to keep a spare root. We make a copy of our root file system every two weeks, and in emergencies merely switch the unit plugs in the disk drives. But <2968@sun.uucp> triggered some neurons, and I thought I would describe the init hack we had implemented long ago under 4.1BSD. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/17/85)
In article <2200@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >One of the most, er, `interesting' things that can happen to a root >file system is to lose /dev (have it turn into an ordinary file or >soemthing). If you have lost /dev, *and nothing else*, it would >seem perfectly reasonable that /etc/init could come up single user >by creating a new console device. Of course, it will not, and one >is forced to recover with standalone programs or a 4.2-style minifs. The r e a s o n it will not, is that to do so means changing the root file system. Quite possibly, this will destroy some vital data that would have let you fix the file system easily enough. I had a disk drive go bad once and write one bad block in the root file system. It happened to be the one containing the inodes for /bin, /etc, /dev, ... . After the drive was repaired, I sat down with a volcopy'd backup and copied the one block back. Presto, a perfect file system. IF I HAD CREATED /#console, I NEVER COULD HAVE. The hard part of the above, of course, was tracing the symptoms back to finding that there was one bad block...... -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}