thad@cup.portal.com (Thad P Floryan) (03/26/90)
{Looks like PORTAL's posting-eater has been vanquished :-) }
Following is one of the strangest tales of woe I've been privy to in a long
while. I spent several hours on the phone Friday with the person whose 3B1
succumbed to this malady. If you ask me, with friends like this person's,
who needs enemies. In any event ...
The BACKGROUND: the person HAS a service contract with AT&T for which
$66/month is paid. The HotLine has also been contacted, but so far nothing
on the ticket except "reload the HD"; additional info will be at the rate of
$120/hr to speak with a technician. Sheesh.
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.
The SYSTEM: is a 3B1 (aka UNIXPC, aka PC7300)
The STORY: as related to me, this person and his alleged-UNIX-guru friend
(fiend? :-) spent an entire evening attempting to mount a floppy. No, this
is not some kinky sex story, they were "simply" trying to figure out (without
docs?) how to tell the system a mountable floppy disk was in the floppy
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).
After talking to this person for awhile, I managed to convince him to boot
with the floppy boot-/filesystem-disk and look around on the HD. There was
no way I could see to recreate a "simple" /dev directory and transfer out his
files on the serial port to another system. Yes, it appears this person has
NOT backed up his personal files in awhile.
From that person's description of the state of the system, my GUESS is that
somehow the superblock became clobbered; what else could so alter the state
of a directory? From his description of the previous evening's "fun & games",
it became clear they powered-down the system multiple times without a
"shutdown" during the course of trying to mount a floppy disk.
At this stage, he's willing to re-load the system software IF he can somehow
get his personal files off safely. I suggested he wait until I could post
this message and see if anyone else could offer other suggestions.
It seems to me that if somehow he could boot from HD he could reload the
files for /etc, /bin and /dev, but I'm at a loss as to suggest HOW. If a new
boot floppy could be created with tool(s) to "fix" the HD to the point where
it would boot, he could get his files off onto floppies.
If anyone has ideas how to solve the above problem, please either contact me
with the info or a contact phone number so the guy can call you; he WILL be
at the AT&T Users' Group meeting this Wednesday with his machine (in case
you're in Silicon Valley).
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]kls@ditka.UUCP (Karl Swartz) (03/27/90)
In article <28295@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >The BACKGROUND: the person HAS a service contract with AT&T for which >$66/month is paid. The HotLine has also been contacted ... Based on my experience with the people at the front door I wouldn't have a service contract with them if they *paid me* %66/month. (Of course the folks around back working on the fix disks are good ...) >The SYMPTOMS: /etc, /bin and /dev on this person's system are no longer >directories, they are files. Yes, files. What do the contents of those files look like? Do they look like what you'd expect to see if you 'cat /dev' (or od or whatever you like)? If so it may simply be a matter of rewriting the inodes with the proper bits set in the file mode. I don't know of any nice easy way to do it -- you'd have to write some code to do it on another machine, but it shouldn't be that hard. Alternately, a sequence like this might get you closer: mv /dev /dev.bad mkdir /dev cat </dev.bad >dev Creating new files on that disk may not be a terribly bright idea though so I'd certainly try the first route if I could. Have you tried running fsck on the disk? What happens? Yes, I know you can't get to /etc and the stock floppy boot filesystem doesn't have fsck, but that's easy to deal with. >From that person's description of the state of the system, my >GUESS is that somehow the superblock became clobbered; what else >could so alter the state of a directory? I don't see how the superblock has anything to do with it -- the filemode for a file is stored in the inode. -- Karl Swartz |UUCP uunet!apple!zygot!ditka!kls 1-408/223-1308 |INet zygot!ditka!kls@apple.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148
gh@S5000.UUCP (Sys Admin) (03/27/90)
I haven't done this in a long time but if i remember right you boot off of 2 of 12 then put in 3 of 12 which is the file system then mount /dev/fp002 then try cp to copy the files from the floppy to hard disk mounted on say /mnt if i remember right you may have to use cpio to copy /dev files to hard disk good luck Glen
clewis@eci386.uucp (Chris Lewis) (03/28/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
kirkaas@oahu.cs.ucla.edu (paul kirkaas) (03/28/90)
I am posting this instead of e-mailing it, so if what I suggest is certain disaster, someone reading this who knows better can save my potential victim from harm. With that disclaimer, I think that all you have to do is "update" your operating system by reloading the system disks. You will be asked if you are installing a new system or upgrading an old one. Tell your 3b1 that you are just upgrading to a newer os and you want to save all old user files. (Before you do that, you should probably rename or delete the spurious /etc, /bin, ... files/directories. I bet that will work. Take a chance. Paul Kirkaas kirkaas@cs.ucla.edu
thad@cup.portal.com (Thad P Floryan) (03/29/90)
Just a quick note (before I forget all the details (since I'm about to fall
asleep at the keyboard)) re: the zapped HD's /dev, /bin, and /etc.
After looking at his system during the Users' Group meeting, several fsck's
cleared up the anomaly. The cause of the problem was interesting: apparently
he mounted the HD onto a directory of the same HD, then wrote a cpio archive
into it ... three directories (/etc, /bin, /dev) became files.
On a "stock" UNIXPC/3B1/PC7300 hard disk, there are three partitions:
/dev/{r}fp000 -- boot loader
/dev/{r}fp001 -- swap area
/dev/{r}fp002 -- first (or only) filesystem area
The person who actually did the dirty deed was an ex-Motorola FE (Field
Engineer) running su'd (capability needed on a stock Moto 6300, 6350, 6600 to
mount a floppy) who entered the command (after being given an incorrect
device name due to having no docs):
mount /dev/fp002 /mnt
then pumped a cpio archive out to it, then unmounted /dev/fp002. "/mnt" was
already a directory on /dev/fp002, so you can imagine what this did to the
filesystem. As one can NOW see, one shouldn't mount a device onto a portion
of itself, and this shows one need for the proper docs for any given computer
system.
For the record, the correct way to mount a floppy on the UNIXPC (or the Moto
6300, for that matter) is:
mount /dev/fp021 /mnt
Also for the record: after the fsck's (and it showing circular directory links
and 968MB files and other oddities), only the /dev, /mnt and /etc directories
were clobbered, and those we initially restored from the floppy systems and
will (shortly) be restored in their entirety from the Foundation Set disks
(since now the HD boots again). No "user" files were lost (to everyone's
relief!). One of the important "clues" came from using df (and fsck) which
had to be copied onto a special floppy-filesystem disk we created during the
User Group meeting.
After all the above, I'm still amazed at the robustness of the UNIX filesystem.
Thanks to everyone for their postings and e-mail offering guidance and moral
support; another example of the Usenet community helping others!
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]john@banzai.PCC.COM (John Canning) (04/09/90)
In article <23092@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: > >>The SYMPTOMS: /etc, /bin and /dev on this person's system are no longer >>directories, they are files. Yes, files. > >What do the contents of those files look like? Do they look like >what you'd expect to see if you 'cat /dev' (or od or whatever you >like)? If so it may simply be a matter of rewriting the inodes >with the proper bits set in the file mode. I don't know of any >nice easy way to do it -- you'd have to write some code to do it >on another machine, but it shouldn't be that hard. > A very easy way to do this is using ls -il and then fsdb. You use the ls -il command to find out the inode of the file in question. Then run fsdb /dev/rfp002 (you have to be super user). fsdb is one of those friendly unix programs, so it's prompt is non-existent. Issue the command xxxi, where xxx is the inode number. This will give you a little printout of the contents of that indoe, which includes the permissions, size, owner, time stamps, and so on. To set the permissions for a directory such as /etc, issue the command md=040755. To get out of fsdb type in the command q. To check your handy work, type in the comand xxxi again, and you should get a new look at the file, with the proper permissions this time around. Please understand that fsdb allows you byte by byte access to your disk drive. Once you change something, it's changed. So be careful. -- The only problem with what I've outlined above, is that you will need to create a bootable floppy file system with fsdb on it. I say this, because fsdb is located in /etc, which is one of the trashed directories. This is easy to do if you have another 3b1... Good luck. John Canning ...uunet!uvm-gen!banzai!john The People's Computer Company ...attmail!banzai!john Williston, Vermont john@banzai.pcc.com 802-864-0747