droms@PURDUE.ARPA (Ralph E Droms) (05/25/85)
Is it possible to use /etc/reboot (4.2BSD) to cause a 780 to load a kernel from a file other than /vmunix? I'm doing kernel hacking, and would like to reboot a new kernel but revert to the old kernel if (when?) the new kernel crashes. If I could put the new kernel in /vmunix.new and use reboot to load this new kernel, a crash would revert to the old /vmunix. Any suggestions would be greatly appreciated... - Ralph === Ralph Droms ihnp4!purdue!droms 445 MATH droms@purdue.arpa Dept. of Computer Science droms@purdue.csnet Purdue University West Lafayette, IN 47906 ----------
ed@mtxinu.UUCP (Ed Gould) (06/18/85)
In article <11030@brl-tgr.ARPA> droms@PURDUE.ARPA (Ralph E Droms) writes: >Is it possible to use /etc/reboot (4.2BSD) to cause a 780 to load a kernel >from a file other than /vmunix? Nope, not without hacking, anyway. The string "xx(0,0)vmunix" is compiled into the boot program (which is loaded off the floppy on a 780 by defboo.cmd). The "xx" is replaced by the right drive-type code based on flags in registers. See ???boo.cmd for details. It should be possible to hack boot and the kernel to pass the right flags along to boot so that something else could be done, but that probably won't work either. Many programs (e.g., ps, w) use the namelist in /vmunix to find things in the kernel's memory. They won't know about your alternate kernel. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146
boyd@basser.oz (Boyd Roberts) (06/19/85)
>In article <11030@brl-tgr.ARPA> droms@PURDUE.ARPA (Ralph E Droms) writes: >>Is it possible to use /etc/reboot (4.2BSD) to cause a 780 to load a kernel >>from a file other than /vmunix? > It's trivial. Just link the new kernel to /vmunix. Hack the source to reboot (if you have it) or make reboot a shell script to do the link and then call the real reboot. Recently we've written BSD lookalike auto-reboot for our 32V kernel. To boot a new kernel it's just: # reboot /newunix For a long time we've linked the current kernel to /unix so as not to confuse stuff that digs into /unix's namelist. Boyd Roberts ...!decvax!mulga!basser.oz!boyd ...!seismo!munnari!basser.oz!boyd <- faster ->
jdb@mordor.UUCP (John Bruner) (06/19/85)
A long time ago, on a PDP-11 far, far away, I had a version of "boot", a minor kernel mod, and a change to the (at that time) very few programs which read "/unix" that provided the functionality you seek. The boot program held the name of its default file [my version of the V7 "/boot" had a timeout and default file so that it could be used for "hands off" auto-reboots] in a char array. A trivial program could be used to patch "/boot" so that it would default to any desired filename (from any desired device, unit, starting block). The kernel contained a char array that the boot program filled with the boot filename. [The boot program also provided an (optional) interactive memory patching facility, principally so that "rootdev" "swapdev", "swplo", and "nswap" could be changed if necessary.] A fixed location (I seem to recall using the word at 042) held the address of the boot-file-name array in the kernel. Programs like "ps" which read the namelist would first open "/dev/kmem" (which they usually did anyway), seek to 042 and read one word, seek to that address, and read the boot filename. That string would then be used as the namelist filename (instead of always using "/unix"). I implemented all of this (including mods to some programs such as "ps") on "my" 11/45 and it worked well. I could cause "/boot" to load any kernel file without having to move it into "/unix" first. (This was especially handy for switching back and forth between kernels with different swap devices, since we had a very flakey swap disc). However, while the other mods to the "boot" program are (I believe) still in use, the automatic namelist selection was not accepted on the other machines, and (for compatbility) I eventually pulled it out of "mine". I've always wanted to put the features of my PDP-11 boot program into the 4.nBSD "/boot". Of course, these days there are a lot of things that want to open "/vmunix". Someday when I have a spare afternoon.... -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
chris@umcp-cs.UUCP (Chris Torek) (06/19/85)
Uh, I think the idea was to boot from something other than /vmunix so that if the machine crashed immediately, it would re-reboot the old kernel. Useful if you're doing things from home, or any other reason that the console is physically distant. Perhaps what we should do is make /boot try to read /newvmunix first, then if that fails read /vmunix (or to make the code smaller how about /vmnuxi? :-) ). -- 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@maryland
jack@boring.UUCP (06/22/85)
In article <2331@mordor.UUCP> jdb@mordor.UUCP (John Bruner) writes
about his /boot, that, among other things, puts the name of the
kernel it booted into a string in that kernel.
In my opinion, this *can* be used on 4.2 *without* modifying
every program that reads /vmunix. Just run a program during
an early phase of startup that grabs the kernel name from /dev/kmem,
and have it setup a symbolic link in /vmunix.......
(Of course, /boot should default boot from, for instance, real-vmunix,
and not vmunix. Unless you want to build symbolic links into /boot.....)
--
Jack Jansen, jack@mcvax.UUCP
The shell is my oyster.chris@umcp-cs.UUCP (Chris Torek) (06/23/85)
> From: andy@cheviot.UUCP (Andy Linton) > > Try looking at Section 6.1 in "Installing/Operating 4.2BSD" > - Section 62 in Volume 2 of the system manual. > It suggests that when at the console command level you can > say:- > >>> B ANY Yes, that happens to be wonderful and we use it all the time WHEN WE ARE IN THE MACHINE ROOM. What I was suggesting was a way to boot from an alternate file while you're dialed in or logged in from across campus, or across country, or whatever. (Sorry about the shouting.) By the way, some 750 boot ROMs have a bug that loses the flags if you don't specify the device name, so we generally do B/3 DUA0 to come up single user from something other than ra(0,6)vmunix. (Yes, our root file system on our 750s is on /dev/ra0g.) You can also use B/2 to come up single user from /vmunix, or B/1 to come up multi-user from some other file. For 780s, use B HPS to come up single user from hp(0,0)vmunix, or type Halt Unjam Init LOad BOOT Deposit R10 0 ! boot from hp (2=up, 3=hk, 9=ra, 10=ut, 11=rb, 14=rl) Deposit R11 1 ! or D R11 2, which is what HPSBOO.CMD does STart 2 (The UPPercase stuff is the required parts of the full commands---or at least the part I type; load might be abbreviable to "L"....) At one point we were using R9 for the disk and partition numbers so that we could boot off of hp(9,0)vmunix (MBA1 drive 1 partition 0), but that's nonstandard and we got rid of it later. (I was going to move the extension into the upper halfword of R10, since it's normally zero, but we haven't needed it since then. . . .) -- 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@maryland
ed@mtxinu.UUCP (Ed Gould) (06/27/85)
In article <405@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >By the way, some 750 boot ROMs have a bug that loses the flags >if you don't specify the device name, so we generally do > > B/3 DUA0 > >to come up single user from something other than ra(0,6)vmunix. >(Yes, our root file system on our 750s is on /dev/ra0g.) That's true on older 750s. Current ones don't have the problem. DEC fixed that one at least a year and a half ago, since that's when we got our 750. A 750 I used that was new about 3 years ago did have the bug. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
andy@cheviot.UUCP (Andy Linton) (06/29/85)
Try looking at Section 6.1 in "Installing/Operating 4.2BSD" - Section 62 in Volume 2 of the system manual. It suggests that when at the console command level you can say:- >>> B ANY or, on a 750 >>> B/3 and that these commands boot and ask for the name of the system to be booted. If you use /newvmunix as the name of your new system and things go wrong /vmunix will be rebooted when/if your new system falls over. If all goes well you can link /newvmunix to /vmunix so that 'ps' and co. work O.K. We have two 750's and use this when trying out new things.