Thanks to Mike Kail, Stevenm Ruby, Valeriy, Steve OBrien, scb1, Jay Lessert, Brooke King, Zaigui Wang, Dennis Martens, Rick McKinney, Sergey Tsyganenko, Marco, Johan Hartzenberg, and Osama Ahmed. Well after many emails and trying various commands I still have not been able to mount the slices. Almost everyone pointed me to 'fstyp' which is exactly what I was looking for except that it reported the slice as unknown. BTW 'fstyp' tells what the filesystem type if for known filesystems in case that isn't obvious. Another suggestion was to try 'newfs -Nv' and 'mkfs -m' which would report to me what the command line used to create the filesystem was but both reported the filesystem type as ufs. mkfs does report 'not currently a valid filesystem - bad superblock'. After doing some searching I found that the superblock is stored in multiple locations on the slice so I can use 'newfs -N' on the raw device (/dev/rdsk) and determine what the other locations for the superblock are and then use 'fsck -F ufs -o b=#', where # is an alternate location for the superblock as reported by newfs -N, to restore the superblock. I tried this with all the locations for the superblock and I got the same message each time. BAD SUPER BLOCK: MAGIC NUMBER WRONG USE AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; I did find something about this error being either because no filesystem had been created or an weird unknown filesystem is there, which puts me right back where I started. I went ahead and did a newfs on the slice and as expected it works just fine, except that I lost all data that might have been there. Also others suggested that maybe these slices were part of some volume management like veritas of SDS. I was told that there wouldn't be a slice 0 (s0) if these drives were part of veritas volume but I've looked at partition table info while in format and I'm relatively certain there is an s0 as well as s1, s2, and s6. s2 of course representing the entire disk but none of the other slices overlap or anything strange. Also for more research into the volume mgmt theory I ran 'prtvtoc' which is used to report info on disk geometry and partitioning. I was told that a tag of 14 or 15 on any of the slices would indicate previous involvement with volume mgmt but none of the slices on any of the drives had these tags. here is the output of that command in case anyone sees something I'm missing. ---------------------------------------------------------------------------- ------- # prtvtoc /dev/rdsk/c2t8d0s2 * /dev/rdsk/c2t8d0s2 partition map * * Dimensions: * 512 bytes/sector * 107 sectors/track * 27 tracks/cylinder * 2889 sectors/cylinder * 24622 cylinders * 24620 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 0 262899 262898 1 3 01 262899 262899 525797 2 5 01 0 71127180 71127179 6 4 00 525798 70601382 71127179 ---------------------------------------------------------------------------- ------- I believe at this point I'm just going to repartition these drives and newfs them and be done with it. I would have liked to mounted them and checked them out but it looks like that is not going to happen. Thanks to everyone who replied and the rest of the list for your help. Brett > -----Original Message----- > From: Brett Lanham [mailto:blanham@cleartrack.com] > Sent: Wednesday, November 13, 2002 4:01 PM > To: Sunmanagers (E-mail) > Subject: determining filesystem type > > > I've got a D1000 storage device that I'd like to be able to > mount the slices > and see what is on them but I keep getting the message: > > # mount /dev/dsk/c2t9d0s0 /mnt/tmp > mount: /dev/dsk/c2t9d0s0 is not this fstype. > > I've tried mount with -F pcfs thinking maybe these drives > were formatted > with a pc filesystem but that gives me the same message. I've > also tried > with -F ufs but that is what should be happening by default. > Is there any > way to determine what the filesystem used on those slices > are? or get them > mount some way? Thanks. > > Brett Lanham > _______________________________________________ > sunmanagers mailing list > sunmanagers@sunmanagers.org > http://www.sunmanagers.org/mailman/listinfo/sunmanagers _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Nov 14 10:45:12 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:58 EST