From: crash@ckctpa.UUCP (Frank "Crash" Edwards)
Subject: Re: Amix Boot Problems
Date: Thu, 8 Oct 1992 01:36:17 GMT
Distribution: usa
Reply-To: crash%ckctpa@tct.com (Frank "Crash" Edwards)
Organization: Edwards & Edwards Consulting

I deemed this to be of general interest, so I'm posting the reply as
well as mailing it.

riesterb@fe844.cc.purdue.edu (Brett Riester) writes:
>But what if the 200-block tmp fs just wrote over something non-essential?
>Besides, I don't think any physical writing was actually done; the 200-block
>tmp fs was just ALLOCATED; the data previously there is still physically there,
>just the links to it are gone.  And if anything is physically gone, it's
>not more than that 200-blocks; isn't there a way to get back at least SOME
>of the data that WASN'T overwritten?

Er, it would be very likely that it wrote over something *essential*
instead of non-essential.  The filesystem(s) are laid out like this:

	+--- beginning of disk space
	|           +-- beginning of free space in the filesystem
	|           |               +-- next disk partition
	|           |               |
	v           v               v
	bbffffiiiiiiddddddddddd...  bbffffiii...
	^ ^   ^
	| |   |
	| |   +-- begining of array of all available inodes
	| +-- beginning of filesystem-specific overhead-type information
	+-- boot block(s) describing boot ability, filesystem type, etc

>I'm willing to lose SOME data; I expect that; but that allocated fs shouldn't
>cause the loss of all the data (the 1,000+ root fs files + my personal ones).

If you look at the diagram you'll see that the section labeled 'ffff' is
described as "filesystem-specific" data.  Things like which inodes are
used, which data blocks are used, which are free, etc. is stored in
that section.  The Berkeley FFS, called "ufs" under SVR4, is organized
differently -- repair is described below.

>What about trying to repair Amix from the Amiga DOS side, using e.g.
>HDToolbox or something?  When I go to the 'Advanced Options' of the
>Boot Screen, it shows that UNIX_Boot is Disabled but clicking on the
>Enable Toggle Button has no effect.

Forget it.  Won't be possible anytime soon.

>Eventually I may have to reinstall Amix2.1 but I'm not giving up yet.

Not necessarily.  Have you tried booting the install floppies and
choosing the "repair" option?  If the filesystem was "s5", try running
"fsck_s5" with the "-n" option and see what you get.  Boot your install
floppies, and continue to press ^D at each prompt until you get a "#"
prompt.  Then type,

    fsck_s5 -n /dev/dsk/c?d?s?

If it fails, and the filesystem was "s5", then you're SOL.  Re-install.

If the filesystem was "ufs", there's a chance that you may be able to
recover *some* of the data.  Basically, you need to run "fsck_ufs" on
the disk partition that was trashed.  To do this on a "ufs" partition,
you'll need a number to specify after the "b" option.  This tells fsck
where to find an area which is a duplicate of the "ffff" from the above
diagram.  Maybe the rest of the partition can be deduced from that... 
First, run the command that'll give you the "b" option value.  Boot your
install floppies, and continue to press ^D at each prompt until you get
a "#" prompt.  Then type,

    mkfs_ufs -o N /dev/dsk/c?d?s? <b>

The "-o N" says to not actually do anything, just print out the
numbers...  That's exactly what you want.  You should get something
like this:

    # mkfs_ufs -o N /dev/dsk/fd0 1760
    /dev/dsk/fd0:	1760 sectors in 11 cylinders of 9 tracks, 18 sectors
	0.9Mb in 1 cyl groups (16 c/g, 1.33Mb/g, 320 i/g)
    super-block backups (for fsck -b#) at:
     32,

As you can see, I ran it on the floppy ("/dev/dsk/fd0") and gave it a
size of "1760".  You would use your device name for the partition, and
the length of the partition in 512-byte blocks (from the output of the
"rdb" command if necessary).

Now you have the info for the "b" option, so go ahead and try it -- you
don't have anything to lose.  (Although you might want to wait a day
or two and see if anyone posts a followup to this that has additional
information.)  Here's how you run fsck with the "no write" option so
that it doesn't actually modify the partition:

    fsck_ufs -n -o b=32 /dev/dsk/c?d?s?
             ^^
	     Notice the "no write" option!

You'll probably get reams of output, but hopefully nothing fatal.  If
there's nothing fatal, try it for real by removing the "-n" option.
On my floppy I get the following output:

    # fsck_ufs -o b=32 /dev/dsk/fd0
    Alternate super block location: 32
    ** /dev/dsk/fd0
    ** Last Mounted on 
    ** Phase 1 - Check Blocks and Sizes
    ** Phase 2 - Check Pathnames
    ** Phase 3 - Check Connectivity
    ** Phase 4 - Check Reference Counts
    ** Phase 5 - Check Cyl groups
    2 files, 9 used, 734 free (14 frags, 90 blocks, 1.9% fragmentation)

If it said that it worked and it modified the filesystem, you can try
mounting it:

    mount /dev/dsk/c?d?s? /mnt 1 ufs
			       ^
			       |
			       +-- mount is done read-only; use 0 for
				   read-write mount.

Copy your important files off of that partition before you try booting
it.  During the boot process, files are created, written to, and
removed.  If it didn't work 100% then booting that partition will
*really* mess it up!  MAKE SURE YOU COPY YOUR FILES!

After you're done copying, unmount the filesystem and reboot.  Read
the above paragraph again before you do so!

    cd /
    umount /mnt
    exec uadmin 2 0

That should stop your system so you can remove the floppy and do the
three-finger salute.

Good luck!

>Brett
>riesterb@feserve.cc.purdue.edu
>bjr@expert.cc.purdue.edu
>-- 
>Brett Riester (riesterb@feserve.cc.purdue.edu, bjr@expert.cc.purdue.edu)

-- 
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.]
Newsgroups: comp.unix.amiga