Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!not-for-mail From: burgess@hrd769.brooks.af.mil (Dave Burgess) Newsgroups: comp.os.386bsd.questions Subject: After tar restore; unable to reboot... Date: 27 Mar 1993 20:51:15 -0600 Organization: Armstrong Lab MIS, Brooks AFB TX Lines: 55 Message-ID: <1p33r3INN1ad@hrd769.brooks.af.mil> NNTP-Posting-Host: hrd769.brooks.af.mil I did a stupid thing last night, and just finished recovering from it. I thought I would relate the story and the solution I ended up using, and will make a suggestion for a possible change. First, I tarred the entire file system onto a network mounted DAT tape drive on the Sun here in the cluster. Actually, the 386bsd system was mounted as an NFS from the Sun and I tarred the /mnt directory. Everything went well, and the 350Meg partition dutifully went out onto the tape in about 20 minutes. About 15 minutes in, my wife walked in. Since I was now in a hurry, I finished up the tar and rewound the tape. From there, I tested to make sure the tape actually had files on it. When I tested it, though, I made a mistake. Instead of 'tar -tf /dev/rst0' I did a 'tar -xf /dev/rst0'. Without even thinking, I ^Ced the output and shutdown and went out for pizza. When I got home, I dialed back into the 386bsd system. No one was home. What had happened was that when I extracted the files and ^Ced, it either truncated the system file (386bsd) or left its permissions set to rw-r--r--. I came back this morning, thinking it was one of those transitory disk problems that dumps you into single user mode. No problem, I thought, I'll just load the file onto a floppy, boot from the fixit disk, and dd the file in. Problem 1: Anytime I tried to write a /386bsd file on the hard drive file system, the system would lock up. I ended up writing a file called 'dave' and 'mv'ing it. Even then, the system would lock up shortly if I didn't sync and halt. Problem 2: Unix gurus know that tar doesn't set file protections unless specifically told to. I didn't. This caused an interesting error (which flashed by so quickly I couldn't have HOPED to see it) before the system reset and reboot. Problem 1 is not really readily solvable. I have had this same problem when copying cp with cp, and install with install. It has to do with Copy On Write, or was it Demand Paging. Either way, life gets ugly when you try to do anything to a file that is been executed... Problem 2 is very solvable. Rather than check to see if the OS file has the correct mode, just check its magic number and execute it if it is an executable. After trying for about 6 hours today, I got all of the pieces together and synced before the system crashed. I guess the bottom line is that, with the system the way it is, these two problems are possible and will cause the average clueless newbie a great deal of consternation. Trust me :-). -- ------ TSgt Dave Burgess NCOIC AL/Management Information Systems Office Brooks AFB, TX