Corrupted OS

youshi10 at youshi10 at
Fri Mar 16 21:37:58 UTC 2007

On Fri, 16 Mar 2007, Drew Jenkins wrote:

> I believe you misunderstand. I have 3 disks:
> 2 are SCSI RAID and are 80 GB each
> 1 is not and is 500 GB
> I don't actually need the 500 GB now. I haven't even used up the 80 GB HD's. So I can wipe the 500 GB clean. I don't have to keep data on it at all. But...can I do that remotely, and run those commands remotely, with that disk being unmounted, and if
> The problem *is* a corrupt OS. I currently don't have any data on that 500 GB HD. And the problems persist. Sorry to have confused you. Are things clearer now?
> TIA,
> Drew2
> Jerry McAllister <jerrymc at> wrote: On Fri, Mar 16, 2007 at 09:12:02AM -0700, Drew Jenkins wrote:
>> Jerry McAllister  wrote: On Fri, Mar 16, 2007 at 07:16:33AM -0700, Drew Jenkins wrote:
>>> 2Kevin Kinsey  wrote:> > synch your source to 6.2
>>> > >
>>> > > How? And is this necessary since it's already at 6.2?
>>> >
>>> > The command below, "cvsup -g -L 2 supfile".  Assuming, of > course, that
>>> > the supfile is valid.  Is it necessary?  Depends; if you're convinced
>>> > that something is wrong with your current installation, then you might
>>> > not need to, because you can rebuild exactly the system that you
>>> > *should* have (for example, perhaps you fat-fingered a chmod or rm
>>> > call?).
>>> Can you finally learn to break you lines at about 70 characters in length.
>>> Having them run on long makes it much more difficult to make responses.
>>> Most Email clients allow you to configure it to break lines.  If yours
>>> does not, just hit a a RETURN/ENTER about there each time.
>> Yahoo's new beta must be the problem. Let's see if the old yahoo system works. Just switched back. Let me know.
>>> That I don't quite get.  If you are just adding a disk to your machine,
>>> it is not likely to corript the rest of the system unless you execute
>>> something on that disk.
>> Which I did. Trust me. I've ruled everything else out. It's the HD.
>>> When you fdisk, bsdlabel and newfs it, it is
>>> wiped and the previous contents are gone.  If you precede that with
>>> a nice dd to overwrite initial sectors with zeros, then it is even
>>> more wiped before you even get to the fdisk.
>> Can I bsdlabel, newfs and fdisk that disk without wiping the other disks, and do it remotely?
>>> Or are you trying to add this disk to a mirror in such a way that
>>> the raid controller thinks it is the good disk and the other is
>>> corrupt and tries to rebuild the mirror with the contents of the
>>> added disk?   That you don't want to do.
>> That I am not doing. There are two other disks in the box that are SCSIs.
>>> My thoughts are that something is happening that you haven't declared
>>> yet.   An HD does not go out and zap files.   That is like saying one
>>> book on a shelf skipped over and trashed the contents of another book
>>> on a shelf.
>> You misread. The files were on the new HD. The "action scripts", or s/w
>> that calls those dbase files, are on the SCSI drives.
> That is a much bigger problem then.  You can't just go and rebuild
> stuff and expect to keep the files on that disk.  You might be able
> to used fdisk if the slice table got smuched and if you put back
> exactly what was originally there.  You might even be able to use
> bsdlabel to fix a partition table, again if the new was exactly the
> same as the old, but I am not sure of that.   You must not attempt
> to build filesystems on the disk with newfs or then all will be
> gone and beyond recovery except by those very expensive spy type
> folk that try to get secret information from overwritten storage.
> But, what you are describing is not a corrupt OS.  It is a problem
> with reading information from a disk.    I have responded to several
> different people lately on similar issues and can't remember which
> is which.   If it is a bad space on disk, then you are going to have
> to reconstruct the date by reading as much as you can and putting
> it together the hard way.  If it is some incompatibilty the file system
> versions between how it written and being read, you need to track down
> just how it was written and try to bridge the difference.
> ////jerry
>> TIA,
>> Drew

As long as the disk isn't in use, yes you can do this type of thing anytime you like.

So unless I'm missing the boat here, why in the world has this thread gone on so long if it was this trivial of an issue?


More information about the freebsd-questions mailing list