(posting to list with previous messages to see if anyone else has better ideas than mine) > > On 7/1/06, Carl Lindholm <clindholm at bigfoot.com> wrote: > >> I have a zip drive that mounted fine until i rebooted now i a get "it's > >> not a block device" is there a way to recover and mount the drive?. > >> last backup was mid May :>( . any help greatly appreciated. > > > > I have > > several old zip drives in my basement if you wanted to try another > > drive to see if that made a difference. I *think* they're all Zip100s, > > but one may be a Zip250, all parallel. Let me know and we can try to > > arrange an exchange. On 7/4/06, Carl Lindholm <clindholm at bigfoot.com> wrote: > John T. Hoffoss wrote: > > On 7/3/06, Carl Lindholm <clindholm at bigfoot.com> wrote: > > > >> thanks for the device. I can mount other disks 100's but not this one. I > >> was wondering if using vi or some linux editor or some other program > >> that I don't now about if there is a way to recover the information on > >> the disk? > > > > Well, the old standard `dd` may yield some data, but that block device > > error may interfere with dd. There's also a chance that utilities from > > the sleuthkit will help. Again though, if you can't read *something* > > off the disk with dd, these won't help much. The Sleuthkit Informer > > newsletter has some basic info on dd usage and flags, etc. and some > > other articles on basics of sleuthkit/autopsy, if you must go that > > route. > > > > If you can read other disks with your drive, have you tried to read > > this disk on a different drive or under Windows (if formatted with > > FAT16/32 or NTFS)? > > > > -John > > > I haven't tried windows. the disk is formated in linux. > I can read other disks and have tried other drives. I think what has > happened is the boot sector got hosed. If I could figure out the address > and what to write I could maybe do a low level write to the the device > at the boot sector but I don't know were to look of that info. It's not quite the boot sector that will concern you, unless you're trying to boot off this zip disk. The boot sector would only interfere in that he BIOS won't know where to jump on the disk to boot the OS. If you're just accessing the disk as a storage drive, the boot sector should not matter. Assuming you're using ext2/3, it might be a corrupt inode (similar to a FAT, file allocation table, in FAT16/13). Have you tried running fsck against it? You may have to specify the file system type if you're not using ext2/3. If you're using ext3, you could attempt to mount the disk, specifying ext2, as it is backwards compatible that way. This document: http://web.mit.edu/tytso/www/linux/ext2intro.html contains the official intro by the creator of ext2. This at the least will explain why some messed up inodes could hose things. I'm not certain it would actually yield an "invalid block device" error though.