From: rhealey@ub.d.umn.edu (Rob Healey)
Newsgroups: comp.unix.amiga
Subject: Re: Problems Booting Amix2.1
Date: 9 Oct 1992 13:25:30 -0500
Organization: University of Minnesota, Duluth
Distribution: usa
NNTP-Posting-Host: ub.d.umn.edu
Keywords: fsck, mkfs, s5, ufs, value of b in fsck

In article <BvtxIG.AG3@mentor.cc.purdue.edu> bjr@expert.cc.purdue.edu (Brett Riester) writes:
=When I do this, I get:
=	s5 fsck:  /dev/dsk/c0d0s0 not an s5 file system
=Does this mean I have a "ufs" filesytem instead?
=
	No, it means you tried to fsck the rdb partiton... B^(. The first
	UNIX partition would be c0d0s1, c0d0s0 refers to the whole disk.

=I don't really know how you determine what the value of b should be.
=I understand your example, when b=1760 for a floppy, because 1760 512-byte
=blocks = 880 K (same a floppy double density disk), but what is it for
=a hard drive?
=
	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.

=	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

Use:    mk_ufs -o N /dev/dsk/c0d0s0 163840

=and got:
=
=Warning:  inode blocks/cyl group (42) >= data blocks (34) in last
=cylinder group.
=This implies 544 sector(s) cannot be allocated.
=/dev/dsk/c0d0s0:  163296 sectors in 1008 cylinders of 9 tracks, 18 sectors
=83.6 Mb in 63 cyl groups (16 c/g, 1.33 Mb/g, 512 i/g)
=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.

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

=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.


=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?

=	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 mk_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.

	   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.

=	3) What does the output I got (above) mean?
	   
	   It's bogus output because you started from the start of the disk, i.e.
	   the rdb area rather than the start of the actual UNIX_Root partition.
	   Also, I assume you pressed return on all the original installation
	   questions and so you used s5 rather than ufs as the filesystem.
	   System defaults aren't always good people... B^(.

	   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.

	   Again, this will NOT work if you default answered on the
	   original installation and thus used the s5 filesystem instead of
	   the ufs filesystem.

=	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.


	Again, I can't say enough about a tape drive on UNIX isn't a
	luxery it is a REQUIREMENT. It would have taken you 2-3 hours
	to recover from this if you had a tape drive and did regular
	backups. Instead you'll waste days and go through much grief
	because you don't have one. I hope the others will learn from
	your misfortune and get tape drives 'el pronto.

	When things go wrong on UNIX things go VERY wrong and the only
	thing saving your keister is a tape backup, no cutesy ADOS
	or Norton utility can get your data back under UNIX. The backup
	tapes are the only way. By the way, those UNIX "unremove"
	utilities work by assigning blocks to special files, if the file system
	get's nuked so to the special files that let you "unremove" things.

	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
Xref: sparky comp.unix.amiga:2238 comp.sys.amiga.hardware:16673