Xref: utzoo comp.sys.att:9126 unix-pc.general:5116 Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!hybrid!robohack!eci386!clewis From: clewis@eci386.uucp (Chris Lewis) Newsgroups: comp.sys.att,unix-pc.general Subject: Re: Zapped /etc,/bin,/dev ... how to recover user files? Message-ID: <1990Mar27.204812.729@eci386.uucp> Date: 27 Mar 90 20:48:12 GMT References: <28295@cup.portal.com> Reply-To: clewis@eci386.UUCP (Chris Lewis) Organization: Elegant Communications Inc., Toronto, Canada Lines: 90 In article <28295@cup.portal.com> thad@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