phil@amd70.UUCP (Phil Ngai) (04/01/84)
I am posting this article to ask "what's your favorite way to hack init"?
How does one recover if the new version of init is so damaged that Unix
won't even boot? When I work on unix, I can tell boot which file to
run, whether it be "unix" or "nunix". But I don't see how to do that
easily for init.
--
Phil Ngai (408) 988-7777 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!philwls@astrovax.UUCP (William L. Sebok) (04/01/84)
Playing with init is one of the scarier things one might do to unix. I keep
a backup root on another disk just in case something horrible happens to the
normal root, such as the death of init. Another thing I try to do is to make
a "disaster recovery" tape, which is a distribution format tape but containing
the current system (or at the very least containing disk drivers that recognize
the present locations of the disk partition boundaries).
There are in fact some changes I would like to see in init. There should be
a better way of communicating with init than the sledgehammer approach of
editing /etc/ttys and sending it a hangup signal. For one thing one gets no
notification when init has reacted to the hangup signal and enabled/disabled
logins on the changed line. This can either happen very quickly or can take
quite a while if init has to be swapped in on a loaded system.
I play this game to use the same lines for dialing in and dialing out.
<FLAME ON> I think that there is no excuse that the distributed Unices (either
USG or Berkeley) do not already provide this. <FLAME OFF>. Because of the above
problem it is hard to impossible to turn on/off logins cleanly. The best one
can do is to put in long sleeps and hope they are enough.
On BSD 4.2 it would be nice for init to have some socket to be used to
communicate with the outside world. That, I believe, would be the correct,
non-hacky way to handle it. Otherwise, a possible hacky change one could make
to init would be to let it understand + and - in the positions of /etc/ttys
normally occupied by 1 (login enabled) or 0 (login disabled). If one placed
a + on the /etc/ttys entry for a terminal and sent a hangup to init, it would
enable login on that terminal and replace the + in /etc/ttys with 1 when it
finished. Likewise a - in /etc/ttys would cause init to disable the line and
replace it with a 0 when finished.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton,vax135}!astrovax!wlsrpw3@fortune.UUCP (04/02/84)
#R:amd70:-448100:fortune:26900036:000:640
fortune!rpw3 Apr 2 02:51:00 1984
The simplest way I know of to test a new "init" without your filesystem
disappearing down the rabbit hole in case said "init" is broken, is:
Make a corresponding test kernel, for which the hardwired code
(which exec's "/etc/init") instead exec's "/etc/init.test". Call
this kernel "/unix.test.init" (or something). Boot it. If it dies
a horrible death (probably in "init.test"), re-boot "/unix" and
breath a sigh of relief!
Is that what you wanted to know?
Rob Warnock
UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065naftoli@aecom.UUCP (04/03/84)
>> I am posting this article to ask "what's your favorite way to hack init"? >> How does one recover if the new version of init is so damaged that Unix >> won't even boot? When I work on unix, I can tell boot which file to >> run, whether it be "unix" or "nunix". But I don't see how to do that >> easily for init. The best thing to do is keep a separate root filesystem charged up for such emergencies. Then you can boot the alternate root up with a separate and hopefully undamaged init. -- Robert Berlinger ...{philabs,cucard,pegasus}!aecom!naftoli "If you're not where you are, you're nowhere"
smk@axiom.UUCP (Steven M. Kramer) (04/03/84)
Ah, hacking init! Since init is the only program known to the kernel,
when you mung it, all kernels will be in the same trap.
The way I saw around it was to make a /tiniunix that invoked not /etc/init
but /etc/tini (a backwards init). You have to simply reorder the `init'
in the kernel's icode for that. Even if u don't have source for the kernel,
you can run it thru a filter (or edit it with an editor that doesn't
munge non-printables and nulls).
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)guy@UCLA-LOCUS.ARPA (04/05/84)
From: Richard Guy <guy@UCLA-LOCUS.ARPA> There are two ways, but both require hacking the kernel a bit to produce a maintenance version you'll always need around, but "never" use. First, change the hardwired "init" reference to something else, say "inis". When you want to install a new "init", mv the existing "init" to "inis" first. You then have something to fall back on if your great fix bombed. Second, hack the kernel to accept input from the console, and use a printf() to prompt for a "init" pathname to use. This is clearly NOT what you want to use for your normal kernel, unless you hack in some timeout code to continue after two minutes on no response. This method is not nearly as simple as the first; people who do a lot of kernel mods may find it useful for other things as well. richard
guyton@Rand-Unix.ARPA (04/05/84)
My favorite method is to have another bootable root filesystem available (online), so that if *anything* goes wrong with the real root, you can quickly rebuild it. -- Jim
geoff@callan.UUCP (Geoff Kuenning) (04/05/84)
My approach to hacking init (and also inittab) is based on the fact that we have a bootable floppy for our workstation. This floppy contains just enough of a system to be able to mount a winchester. I can then use the editor on the winnie to fix inittab, or use mv to replace my hacked init with the original (which is available from the floppy, if nowhere else).