daveb@uunet.uu.net (David Collier-Brown) (12/09/88)
I just had a local site fail to reboot, and then to fsck after someone
made a bit of extra space by moving some files from / to /usr.
Regrettably, one of the files was /boot. (This made it a **bit** hard to
reboot)
Unfortunately, replacing /boot, /vmunix and /etc/fsck didn't do a thing
for the subsequent problem, in which fsck run from the sd0a partition
looped forever. (From mini-unix on sd0b it ran fine).
Does anyone know if the physical position of /boot on the disk is
critical? I'm wondering if the roms find boot at a fixed offset (or by
the same technique used for coredumps during boot?), or if they know about
the filesystem organization. Can anyone dilute my ignorance?
--dave (I'm intensely curious: this is just too wonderfull to pass
up) c-b
--
David Collier-Brown. | yunexus!lethe!dave
Interleaf Canada Inc. |
1550 Enterprise Rd. | HE's so smart he's dumb.
Mississauga, Ontario | --Joyce C-Bbr@uunet.uu.net (Billy Ross) (12/20/88)
David Collier-Brown writes: >Does anyone know if the physical position of /boot on the disk is >critical? Yes, unlike other 4.3 systems, Sun 4.0 requires that the bootblock know the location of the /boot binary. From the installboot(8) manual page: The boot(8S) program is loaded from disk by bootblock code which resides in the bootblock area of a disk partition. In order for the bootblock code to read the boot program (usu- ally /boot) it is necessary for it to know the block numbers occupied by the boot program. Previous versions of the bootblock code could find /boot by interpreting the file system on the partition from which it was being booted, but this is no longer so. Bill Ross Washington University ECL, St. Louis 314-889-5894 INTERNET: br@wucs1.wustl.edu UUCP: br@wucs1.UUCP or ..!{mcdchg,uunet}!wucs1!br
guy@uunet.uu.net (Guy Harris) (12/20/88)
>Does anyone know if the physical position of /boot on the disk is >critical? I'm wondering if the roms find boot at a fixed offset... The ROMS do not find "/boot" at all; they find the boot block, and do not know anything about the filesystem organization. Prior to SunOS 4.0, the boot block knew enough about the way the 4.2BSD file system worked that they could find the blocks of "/boot". The 4.0 version (and possibly the Sys4-3.2 version) has had a lobotomy, so it no longer knows much at all about the way the 4.2BSD file system works (I think this was done because the program was getting too big to fit in the boot block, at least on a SPARC machine); there is a program "installboot" (see INSTALLBOOT(8S)) that, when used to install a new version of "/boot", jams the physical addresses of the blocks of "/boot" into a table in the boot block.
dlc@vetch.c3.lanl.gov (Dale Carstensen) (12/20/88)
Read the 4.0 man page for installboot. The boot program that is place on sector 1-whatever of your boot disk does have sector addresses for the /boot program. It is patched by the installboot program, which is not a "dd" script as the 3.5 installboot program was. In response to your later message, this knowledge is probably makes you think that setup (I thought it's name is now suninstall) is smart.
celeste@coherent.com (Celeste C. Stokely) (12/20/88)
Yes, as it turns out, /boot is in a VERY particular spot. something like
starting at disk block 15 or some such voodoo. The only way you can get it
back in the right place is by running "/usr/etc/mdec/installboot xx yyyy",
(under 3.x, anyway), which of course isn't documented.
Say it's a server with xy disks. You do:
installboot bootxy xy0a
(at least, I think you'd say xy0a. try it. if you can then boot, you did
it right.)
installboot is a shell script which does a dd of the bootfile to a spot on
the disk. Installing bootblocks is all /usr/mdec is used for, I believe.
..Celeste Stokely
Coherent Thought Inc.
UUCP: ...!{ames,sun,uunet}!coherent!celeste Domain: celeste@coherent.com
Internet: coherent!celeste@ames.arpa or ...@sun.com or ...@uunet.uu.net
VOX: 415-493-8805
SNAIL:3350 W. Bayshore Rd. #205, Palo Alto CA 94303dlc@vetch.c3.lanl.gov (Dale Carstensen) (12/21/88)
(I think this is a better reply than the first one I sent to sun-spots.) The question was whether the physical placement of /boot makes a difference. The answer, for SunOS 4.0, is yes. You need to know this for restoring a lost /boot, and to set up local disk drives that have boot capability. Read the 4.0 man page for installboot. The boot program that is placed on sector 1-whatever of your boot disk does have block addresses for the /boot program. It is patched by the installboot program, which is not a "dd" script as the 3.5 installboot program was. In response to your later message, this knowledge is probably makes you think that setup (I thought it's name is now suninstall) is smart. You also need to know where the two boot programs are. Bootfile is in /usr/stand/boot.<arch>, where <arch> is the architecture (sun3, for instance), or /export/exec/<arch>/stand/boot.<arch> for heterogeneous servers, typically. Protobootblock is in /usr/mdec/boot<xx>, where <xx> is the disk type, or /export/exec/<arch>/mdec/boot<xx> for heterogeneous servers, typically. Two other directories that suninstall and setup_client use are (for heterogeneous servers these may be /export/exec/<arch> instead of /usr): /usr/etc/install/proto (most of the / file-system) /usr/boot (the /sbin directory and /vmunix)