Zapped /etc,/bin,/dev ... how to recover user files?

[Chris Lewis]

In article <28295 at cup.portal.com> thad at cup.portal.com (Thad P Floryan) writes:

> The SYMPTOMS: /etc, /bin and /dev on this person's system are no longer
> directories, they are files.  Yes, files.  Consequently, the system doesn't
> boot.

No kidding...

No, it's not likely to be a superblock clobber per-se, chances are that
inodes were being updated with a write when the power failed or
a reset clobbered the controller.  Or, whatever they were using as a mount
command clobbered a couple of inodes in the disk.  A superblock clobber would 
probably totally destroy the disk so that *nothing* was readable.  If
/etc, /bin and /dev being files are the *only* problem, then flipping
a couple of bits in their inodes is all that's necessary.

I'm not sure if this is really feasible in this case, but this might
help from single-user booted off the floppy...  Chances are that this
is too much work or the person likely to be doing it doesn't have the
experience...

Do *not* try to run fsck yet....  (perhaps fortunately, fsck couldn't
be found because /etc became a file)

Check to see if /etc, /bin and /dev are "complete" except for the directory
mode bits in the inode.  In particular that as *files*, they have multiple
16 character records, where the first 14 is a reasonable file name and
the last two are shorts containing what appears to be an inode.  If this
is the case, you may be able to zap the inode for the directory so that
they *are* directories.

To do this, they'd need another 3b1 within "compiling" distance.  Find the
inode number (via ls -lid from floppy-boot) of the busted directories.
Write a C program on the other 3b1 to:

	- read an entire block of inodes including the ones you need via
	  the appropriate disk device (their root disk).
	- or ("|") in the S_IFDIR bits in the mode field of the on-disk
	  inode (di_mode in dinode struct in ino.h)
	- write the whole inode block out again.

filsys.h and ino.h will help you figure out where things are.

Write this program on a *copy* of the second floppy in the floppy boot
sequence.

If the above is all they need, they may be able to simply reboot afterwards
*without* attempting to sync (eg: sync first, run the zapper and reset/
floppy boot *immediately*).  Then run "fsck -n" and see how badly damaged
the disk is.  If they're *really* lucky, they may have no further damage
whatsoever...

For testing, they can probably use mkfs to create a filesystem in a
UNIX file (eg: specify an existing writable file instead of a disk
device) on the compile 3b1 and try it there.  But be careful.  For safety,
try not to run it as root on the compile machine.

If they had fsdb on the boot floppy, they wouldn't have to write a program
to do the zapping, but I rather doubt there is one for 3b1's.  Another
approach would be to use adb on the disk device, but that might not fit on the 
second floppy and you don't have any of those ino.h/filsys.h structures
to help you find the inode mode fields.

I've done such things many times over the past, but never issue any
guarantees that it will not make the problem worse let alone solve it.
(my batting average is pretty good actually... ;-)

> drive.  Whatever they did (instead of "mount /dev/fp021 /mnt [-r]"), they
> caused some extreme weirdness to occur on that person's system such that 3
> directories in the root filesystem became files (/dev, /bin, /etc).

They probably wrote on the hard disk somehow.

If fsck managed to run after the directories were converted to files, all
of the files in those directories are probably in /lost+found.  If that
were the case, you could remove/mkdir the directories and put things
back where they're supposed to be.  Good luck figuring out which files
are which though....

Incidentally,

I had a similar experience a couple weeks ago on my 3b1 - a group of
8 or so sequential inodes were splattered.  Including su, stty, init
etc.  Fortunately *those* were easy to replace without reloading the
disk.  Interestingly enough, this occured without the system crashing.
Just couldn't reboot the HD.
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list