"Leonard den Ottolander" <[EMAIL PROTECTED]> writes:

> Hi Alan,
> 
> > Downsizing has taken it toll in my company and now I've got the job of
> > recovering the files from a couple of projects off a couple of drives
> > a co-worker was using on a FreeBSD OS box.  With all the other
> > filesystems addressed by kernel modules, I was sure I'd be able to
> > scan the drive.  Now I'm not so sure.  What can be done to make the
> > filesystem available on my RedHat Linux box?
> 
>  man mount. Or more specifically
> mount -t ufs -o ufstype=44bsd /dev/hdx /mnt/BSD
> 

Yup, tried that..  more specifically:

  mount -t ufs -o ufstype=44bsd /dev/sdb[5-8] /mnt/BSD

meaning, for each of the entries under the extended partition entry
each rendering the generic and not too helpful message:

mount: wrong fs type, bad option, bad superblock on /dev/hda[5-8],
       or too many mounted file systems

The dmesg indicates:

Partition check:
 sdb: <sdb1>
   sdb1: <sdb5 sdb6 sdb7 sdb8>

I even tried mount with -v with absolutely not change to the return
message.  Also, as a last resort, I added the lilo.conf entry to dual
boot the system which found all the file systems (except /usr) but
since the drive offset has changed in my machine from it previous one,
the /etc/fstab is pointing the device addresses to the wrong drive.
Checking with the BSD fsck indicates the last directory each was
linked to and this can be done by hand but I'm not familiar enough
with BSD to get the job done right.  Also vi, for editing the
/etc/fstab to correct it, appears missing from /bin directory.  Is the
make up of BSD so backward that only having the root filesystem
doesn't give you enough tools to recover things?  No wonder I never
chose FreeBSD.



-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to