From: crash@ckctpa.UUCP (Frank "Crash" Edwards)
Subject: Re: Problems Booting Amix2.1
Date: Sat, 10 Oct 1992 15:05:12 GMT
Distribution: usa
Reply-To: crash%ckctpa@tct.com (Frank "Crash" Edwards)
Organization: Edwards & Edwards Consulting

rhealey@ub.d.umn.edu (Rob Healey) writes:
>In article <BvtxIG.AG3@mentor.cc.purdue.edu> bjr@expert.cc.purdue.edu (Brett Riester) writes:
>	b means the relative block from the start of the partition where
>	a backup superblock is. Since the first 200 blocks are bogus
>	on your partition my GUESS for a first try is 8*32=256. Try
>	-b 256. The only way to know for sure is to run the mkfs -N and
>	note what superblock backup block is > 200.

Errr, see below.

>=	1	UNIX_Root	   128	163840	80 MB
>=	2	UNIX_Swap	163968	 36864	18 MB
>=	3	UNIX_Boot	200832	  4096	 2 MB
>=
>=For a total of 100 MB = 204800 512-byte blocks, right?
>=
>	Correct.
>
>=But, figuring that c0d0s0 is the 80 MB UNIX_Root partition, I typed:
>=	mk_ufs -o N /dev/dsk/c0d0s0 163840

No!  Use
	mkfs_ufs -o N /dev/dsk/c0d0s1 163840
			       ^^^^^^
That filename means to use scsi id #0 (c0), drive 0 (d0; really means
scsi adapter 0), and slice #1 (s1; slice means the same as partition).

Your output (shown above) was the result of running rdb.  If I need disk
information I don't hesitate to run "rdb -H /dev/dsk/c0d0s0" since
this reads the RDB information (as Rob pointed out, "slice 0" means the
whole disk as opposed to a single partition).

> [some deleted...]
>
>=super-block backups (for fsck -b#) at:
>=32, 28896, 5280, 7904, 10528, 13152, 15776, 18400, 21024, 23648, 26272,
>=...
>	In this case you'd probably want to use -b5280 for fsck.

Not until he runs the correct command above; but the algorithm used
for calculating where the superblocks are put should result in the
same list of numbers...

>=Am I using the wrong number/partition name for mk_ufs?
>=
>	Yes, you should be using c?d0s1 for your particular setup.

Right.

>=What does rdb do? How do you use it?  I thought that rdb removes/repartions
>=disk blocks, so I didn't want to experiment with it.
>=
>	rdb handles the exec ROM idea of a partition. ADOS and UNIX then
>	add their respective ideas of a filesystem on TOP of that. I
>	think you are being confused by the use of the word partition to
>	mean multiple things. B^(.
>
>	When you get the system running again do a man on rdb, by the looks
>	of things your rdb layout is fine so don't fix it, the trouble
>	lies elsewhere.

Good advice!

>=Before I experiment further, I would like to know:
>=	1) Do I in fact have the ufs or s5 filesys?
>
>	   Only you would know, how did you answer the original installation
>	   question? s5 or ufs?

I would hope ufs, although s5 is the default.  When you created this
other partition and wiped out 200 blocks, it is quite possible that
enough information was destroyed that the "fsck_s5" command had no way
to determine the actual filesystem type and gave up.  If your root
filesystem really is s5, and 200 blocks were overwritten, there is no
chance of getting your data back.  The s5 filesystem does not store
duplicate filesystem superblocks, and most of it's overhead storage is
at the beginning of the partition so your root partition -- the one
that was accidentally overwritten -- will be unrecoverable.  If I were
feeling masochistic *and* this happened to me *and* I had very important
data on that drive *and* I _didn't_ have a backup (huh?) then I might
be desparate enough to try to use a sector editor and locate the
individual disk blocks, but that'd take me days, possibly weeks, to
obtain even a single file.

>=	2) What value should I use for b? How can I get this from rdb?
>	
>	   If you used s5 on the original installation your data is GONE,
>	   period, end of discussion, restore from scratch. If you used
>	   ufs then do the fsck_ufs as Frank suggested on the c?d0s1 device and
>	   try the first backup superblock over 200 and see if that restores
>	   the filesystem enough to mount and backup your data.

Right; see above dissertation on s5.  :-)

>	   No matter what, the filesystem is in questionable state so
>	   reinstall the OS and use UFS as the filesystem. If you get
>	   squeeky on disk space, use tunefs and set the overhead
>	   percentage to 1% from the default 10%. This will impact
>	   filesystem performance but it will give you more disk space.

Definately!!!  If fsck_ufs works, backup the files you want and then
reinstall.  DO NOT MODIFY THE PARTITION AFTER ITS BEEN MOUNTED!  If
there is even the slightest problem with the rebuild operation,
modifying the filesystem by deleting a file, editing a file, copying a
file, etc. *WILL* put you back at square one, doing all of this over
again!  Copy your data to floppy or tape (using cpio or tar or bru)
and then reinstall.  (Do not use the compression option of BRU since
that creates a temp file in /tmp and you don't have the space on the
floppy or the time required to bother with it.)

>=	3) What does the output I got (above) mean?
>	   Now, IF you used ufs on the original install, this has to be
>	   typed in to override the default use of s5 by the way, THEN
>	   if you do Frank's command on the c?d0s1 partition you should
>	   get a slew of numbers after the (fsck -b#) comment. Use the
>	   first number over 200 as an option to the real fsck -b to
>	   attempt to recover part of the old filesystem.

Actually, I would be more likely to use the last number displayed,
just for safety's sake.

>=	4) Do I proceed as in your last posting?
>	   Yes, Frank gave a VERY good summary of how to attempt to recover
>	   a ufs filesystem from the dead. Anything on the first 200 blocks
>	   is lost, gone, finis. Depending on what actually happened and IFF
>	   you used ufs originally, you might get access to a part of your
>	   data.

Actually, this isn't *exactly* true, but it's damn near close 'nuf for a
novice.  If you want a description of how s5 allocates disk space,
read on.  Otherwise, "skip a little brother".

The s5 filesystem creates a linked list of free blocks when you do the
mkfs command.  That list has to be stored somewhere, and so data blocks
from the filesystem are allocated for that job.  They are normally
located right after the inodes which are located right after the superblock.

The mkfs command does not go through the entire partition and zero it
out, but it does READ every block to make sure there aren't any
errors on the disk.  It is quite possible that running fsck_s5 on your
root filesystem (assuming that it was, in fact, an s5 filesystem)
MIGHT recover some data, if you could find a way to force fsck_s5 to
complete even though it thinks the filesystem is trashed.  For
instance, try creating a 80MB partition in your 18MB swap space.  If
the command you give to mkfs_s5 told it that the FS was 80MB it would
build an inode list and superblock for that size.  It would fail, of
course, when it tried to read all of the data blocks though.  Then you
could use "dd" to read the first few blocks from the swap space and
write them *on top of* the damaged root filesystem.  THIS WOULD BE A
LAST RESORT (I've actually had to do this in the past -- it's tedious
work, but it can be done).  Here's why there may still be some data
to recover:

    200 - 8 = 192 blocks of non-reserved fs space.
    192 / 4 = 48 inodes, 8 inodes to a block, for a total of 6 blocks.
	      192 - 6 = 186 free blocks remaining.
    186 * 4 = 744 bytes required to record the free list.
	      744 bytes will require 2 blocks to store; only 400 bytes
	      per block are actually used when recording the free list.

So the total number of blocks that would have been destroyed by the
mkfs process for a filesystem of 200 blocks is approximately:

     8 (reserved)
     6 (for inodes)
     2 (for free list storage)
    --------------------------
    16 total blocks

So the first 16 blocks (minimum -- I may have left something out) of
your root partition were destroyed.  Your root partition was 80MB and
so it's inode table would've had (163840 - 8) / 4 = 40958 entries,
requiring 5120 blocks to store.  The 8 reserved blocks would be the
same size.  Therefore, the first 8 blocks of the root partition's
inode table were blown away.  Unfortunately, the mkfs command
allocates the "/" directory first, so it's inode #1, and as files were
loaded off the install tape, they would get sequentially assigned
inode numbers, so the files in "/etc" would be the lowest numbered
inodes and they would've been the ones to be lost.  (I think the
"/etc" directory is still the first one on the tape?)

>	Again, I can't say enough about a tape drive on UNIX isn't a
>	luxury it is a REQUIREMENT.

Amen.

>	I'll stop preaching now but now you all know why I shake my head
>	when people get excited about UNIX on floppy distribution...
>
>		-Rob

Yeah, anyone who's been there knows that you dont' run a multi-user,
multi-tasking OS with lots of complex interactions without a backup
medium.  A network, a tape drive of some kind, ... something!

Once again I'll recommend the SA Guide as an introduction to how the
filesystem is laid out.  There are reasonably good descriptions of the
physical organization of both the s5 and ufs filesystems.  Although
the damn blue books refer to the 3B2 too often!  (They're the older
books now, but the new version of the SA Guide has been published yet.)

Good luck, and let us know what happens...
-- 
Frank "Crash" Edwards            Perceptual Technologies, Inc.
Fax:  813/786-6526               [Our office is moving; watch this space
Home: 813/786-3675               for the new phone number.]
    "I am returning this otherwise good typing paper to you because someone
    has printed gibberish all over it and put your name at the top."
	    -- English Professor, Ohio University