Linux Tutorial?

[blaa]

sudo mount -t sysv -o ro /dev/sda4 /mnt/mo

this code has the same problem as the above

"wrong fs type..."

 

[blaa]

I'm just guessing to be honest from his fdisk output, it is kind of unlikely to be GNU hurd though but I am surprised it didn't auto-detect.

and I guessed wrongly I see.

so try the same code with GNU hurd instead?

 

[Kameron]

"wrong fs type, bad option, bad superblock on /dev/sda4, missing codepage or other error. In some cases useful info is found in syslog - try dmesg ¦ tail or so"

Ick.
Can you post the output of:
sudo hexdump -C /dev/sda4|head

This is the output from one of my test machines. From it we may be able to better identify the filesystem in use on the disk and therefore get the mount command right.

broadsword:~# hexdump -C  /dev/ida/c0d0p1|head
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00010000  70 26 5d 00 57 9b 57 00  48 80 00 00 12 00 00 00  |p&].W.W.H.......|
00010010  00 00 00 00 00 20 00 00  00 04 00 00 d2 83 b7 3f  |..... ......Ò.·?|
00010020  84 03 00 00 1e 00 00 00  00 00 00 00 00 10 cc 03  |..............Ì.|
00010030  04 00 02 00 52 65 49 73  45 72 32 46 73 00 00 00  |....ReIsEr2Fs...|
00010040  03 00 00 00 04 00 bb 00  02 00 00 00 f9 28 01 00  |......».....ù(..|
00010050  01 00 00 00 94 9d 4e 34  a6 2b 45 24 8b 44 54 61  |......N4¦+E$.DTa|
00010060  d7 9c 64 16 72 6f 6f 74  66 73 00 00 00 00 00 00  |×.d.rootfs......|
00010070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

If it isn't installed you may need to type the line below first.
sudo apt-get install hexdump

I don't know what Unbuntu's normal hex utilty is.

 

[blaa]

Ack.

I am not actually on that machine, and its not networked. Going to have to figure out how to c'n'p this onto something.. or take a pic on my mobile...

 

[blaa]

phew my USB drive works!!

pmsl. I was worried i might have to start a new thread asking how to set that up!!

 

[blaa]

sleep@standalone:~$ sudo hexdump -c /dev/sda4|head
0000000 " " " " " " " " " " " " " " " "
*
0003a00 \0 \0 \0 \0 \r ` ^ 312 004 \0 \0 \0
0003a10 H 004 \0 \0 @ \0 \0 \0
0003a20 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 \0
0003a30 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0003a50 \0 \0 \0 \0 234 : \0 \0 < 001 \0 \0 \0 < \0 \0
0003a60 \0 \b \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0003a70 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0

icccccccccccck the formatting has gone awry

 

[Kameron]

hmmm. There isn't enough information there to swing a cat with.
try.
sudo hexdump -C /dev/sda4|head -n 20


note the capital -C, it will make nicer output. you can also put [code] [/code] tags around it.

 

[blaa]

is there anyway of keeping the formatting?

or are you ok, with this weird spluging?

 

[jæd]

is there anyway of keeping the formatting?

or are you ok, with this weird spluging?

[code]codetags

[/code]

 

[blaa]

ah no, its the convertion from unbuntu text editor, to win XP note pad, it comes out in a straight line of code in notepad.

 

[Kameron]

something like this of course with the correct location of your USB device after the redirect (>)

hexdump -C /dev/sda4|head -n 20|unix2dos >
/media/<USBdevice>/hexdump-output.txt

if you have unix2dos (I think it comes as part of the dostools set). the text editor you use in Unbuntu my have the abilty to save in dos format as well.

 

[blaa]

for some reason I can not get the txt to actually save onto the USB device. It moves onto there ok, but as soon as I disconnect the device and reconnect it the files disappear?

its driving me insane!!!

 

[Kameron]

Sounds like the device isn't syncing before you remove it.

Close the editor and anything else accesing the drive. Then type
umount /media/<USBdevice>
except pointed where the device is mounted of course

 

[blaa]

unmount command not found?

 

[blaa]

unmount command not found?

grief I am an idiot. umount, not unmount.

 

[blaa]

sleep@standalone:~$ sudo hexdump -c /dev/sda4|head
0000000   "   "   "   "   "   "   "   "   "   "   "   "   "   "   "   "
*
0003a00  \0  \0  \0  \0  \r   `   ^ 312 004  \0  \0  \0
0003a10                                   H 004  \0  \0   @  \0  \0  \0
0003a20      \0  \0  \0  \0 002  \0  \0      \0  \0  \0  \0  \0  \0  \0
0003a30  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0003a50  \0  \0  \0  \0 234   :  \0  \0   < 001  \0  \0  \0   <  \0  \0
0003a60  \0  \b  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0003a70  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
sleep@standalone:~$ sudo hexdump -C /dev/sda4|head -n 20
Password:
00000000  22 22 22 22 22 22 22 22  22 22 22 22 22 22 22 22  |""""""""""""""""|
*
00003a00  00 00 00 00 0d 60 5e ca  04 00 00 00 20 20 20 20  |.....`^.....    |
00003a10  20 20 20 20 20 20 20 20  48 04 00 00 40 00 00 00  |        H...@...|
00003a20  20 00 00 00 00 02 00 00  20 00 00 00 00 00 00 00  | ....... .......|
00003a30  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00003a50  00 00 00 00 9c 3a 00 00  3c 01 00 00 00 3c 00 00  |.....:..<....<..|
00003a60  00 08 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00003a70  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00003a90  00 00 00 00 00 00 00 00  00 00 00 00 ee de 0d 60  |...............`|
00003aa0  04 00 00 00 2f 64 65 76  2f 72 64 73 09 00 00 00  |..../dev/rds....|
00003ab0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00003ad0  00 00 00 00 00 00 00 00  05 00 01 02 20 00 00 00  |............ ...|
00003ae0  e0 3f 22 00 04 00 00 02  00 08 00 00 00 38 22 00  |.?"..........8".|
00003af0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00003b20  00 00 00 00 00 00 00 00  00 00 00 00 01 00 01 02  |................|

ahhhh bliss... working stuff

 

[Kameron]

ahhhh bliss... working stuff

fuck. doesn't look like any file system I know. Looks fucked on some level.

Either the partition table is screwed or part of the data is. What sort of data are you looking to recover from this drive? There may be other ways or you might consider be they partition recovery, file analysis or string recovery depending on what you want back.

Something doesn't strike me as quite right about the other fdisk command you posted.

Could you just post the output from:
sudo sfdisk -l

The fact that mount kicked it out when -t wasn't specified surprised me if it was sysv. I wonder if your controller in misinterpreting the disk. Is the sector, cylinder and head/track counts reported tally with what the BIOS and the outside of the disk reports?

sfdisk -V /dev/sda
will do a bunch of checks as well and either as 'OK' or produced lists of errors.

You might try

cat /proc/filesystems
this is a list of the filesystems supported by your installation which may or may not explain things.

I think you have reached the poke it with a stick stage and it is really hard for me to simulate that by telling you what to type if you see what I mean. If I have any flashes of inspiration though....

 

[blaa]

sleep@standalone:~$ sudo fdisk -l
Password:

Disk /dev/hdc: 20.4 GB, 20411080704 bytes
16 heads, 63 sectors/track, 39549 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1               1       12118     6107440+   7  HPFS/NTFS
/dev/hdc2           12119       39541    13821129+   f  W95 Ext'd (LBA)
Partition 2 does not end on cylinder boundary.
/dev/hdc5           12119       18350     3140896+   b  W95 FAT32
/dev/hdc6           18361       19285      465853+  82  Linux swap / Solaris
/dev/hdc7           21612       28401     3421813+  83  Linux
/dev/hdc8           28401       39541     5614686   83  Linux
/dev/hdc9           19285       21612     1172713+  83  Linux

Partition table entries are not in disk order

Disk /dev/sda: 1149 MB, 1149418496 bytes
64 heads, 32 sectors/track, 1096 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda4   *           1        1096     1122288   63  GNU HURD or SysV
sleep@standalone:~$ sfdisk -V /dev/sda
Warning: partition 4 extends past end of disk

There is nothing on this disk currently, I was using a blank one just for safeness... it is formatted though in whatever format the others are in. I've tried looking up what the formatting is, but I can't see anything on the diskettes other than:

Verbatim 512 bytes/sector - vbr5e2 (seems to come up with alot of russian sites on google) I can't seem to find anything that would give any indication of what it was pre formatted in..? - the 1.2Gb variety

sudo fdisk -V /dev/sda:
partition 4 extends past end of disk

cat /proc/filesytems:
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev sockfs
no dev pipefs
nodev futexfs
nodev tmpfs
nodev inotiyfs
nodev eventpollfs
nodev devpts
         ext2
         cramfs
nodev  ramfs
nodev devfs
nodev mqueue
nodev usbfs
         ext3
         sysv
         v7
         vfat
         ntfs

nodev on sysfs - this is bad no?

 

[blaa]

Yeah, I am basically trying to do this as cheaply as possible. The other way would be to set the old unix network back up

hoping to make one machine do the job of 3.

so close... so close...

 

[lobster]

I think thats cool how Kameron can recognise a filesystem by looking at it through hex.

i usually find out the filesystem via df, ie

allix@allix:~$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda6 reiserfs 47G 12G 36G 25% /
/dev/sda7 reiserfs 68G 4.5G 63G 7% /mnt/allix
allix@allix:~$

but through fdisk/cfdisk is fine

 

[jæd]

Yeah, I am basically trying to do this as cheaply as possible. The other way would be to set the old unix network back up

hoping to make one machine do the job of 3.

so close... so close...

Well... In theory it could probably be done... But if your a linux newbie then it would probably take more time than its worth...

 

[jæd]

nodev on sysfs - this is bad no?

Well... Next job is making this work... I would be asking questions at ubuntuforums.org as they would know a lot more than here...

 

[Kameron]

I think thats cool how Kameron can recognise a filesystem by looking at it through hex.

i usually find out the filesystem via df, ie

That is true for all of us but it doesn't work on unmounted disks and disks you can't mount like this one and there really isn't all that much to it, look at [post=4480524]this post[/post] where I did the first ten lines of HEX for my partition 1 (ignore the /dev/ida mount point that is just confusing, it could say /dev/sda1 just as easly) right in the middle of line six you have |....ReIsEr2Fs...| which is a bit of a give away in any money, the vast majority of all filesystems have this sort of glaring clue lying around.

sfdisk -l -d would be my command of choice though.

 

[blaa]

Well... Next job is making this work... I would be asking questions at ubuntuforums.org as they would know a lot more than here...

Ah, could I ask what you would ask them?
I am looking to find out how to install a new filesystem?

Will they be as helpful as you guys that's the true test

I feel like I've just been dumped!
Should I keep posted on the result?

 

[Jonti]

Blaa, I'm a tad confused. What do you get when you type

ls -l /mnt

?

 

[Kameron]

going back to blaa's problem

I really think that the drive is not being interpreted correctly. The partition table entries do not match the physical disk on the basis of what you have posted, while it is possible for partition tables to get a bit fucked up and still work what we've seen so far is beyond that, I have no idea why slot 4 should be filled with a partition that extends beyond the end of the disk and I only see this in cases of incorrectly identifed hard drives. I suspect that this situation has arisen through drive misdetection possibly in software but more likely in firmware/BIOS. It may be possible to correct these setting manually in the SCSI controller from settings printed on the outside of the drive. I think a comparison of detected and real settings reported by the system at various stages is your next obvious step.

If the drive is being correctly detected then the partition table is bollixed but you can't check this FIRST because if drive detection is wrong then it may be showing the wrong part of the drive as the partition table which will probably look like a dog's breakfast.

This is my partition table in hex and its sfdisk dump for example.

broadsword:~# dd if=/dev/ida/c0d0 bs=512 count=1 2>/dev/null |hexdump -C|grep -A4 -E '^0+1b0'
000001b0  00 00 00 00 00 00 00 00  91 c3 0d 00 00 00 80 01  |.........Ã......|
000001c0  01 00 83 fe e0 ff 20 00  00 00 c0 33 e9 02 00 fe  |...þàÿ ...À3é..þ|
000001d0  e0 ff 82 fe e0 ff e0 33  e9 02 a0 22 3d 00 00 fe  |àÿ.þàÿà3é. "=..þ|
000001e0  e0 ff 83 fe e0 ff 80 56  26 03 a0 22 3d 00 00 fe  |àÿ.þàÿ.V&. "=..þ|
000001f0  e0 ff 83 fe e0 ff 20 79  63 03 e0 03 17 05 55 aa  |àÿ.þàÿ yc.à...Uª|
broadsword:~# sfdisk -l -d /dev/ida/c0d0
# partition table of /dev/ida/c0d0
unit: sectors

/dev/ida/c0d0p1 : start=       32, size= 48837568, Id=83, bootable
/dev/ida/c0d0p2 : start= 48837600, size=  4006560, Id=82
/dev/ida/c0d0p3 : start= 52844160, size=  4006560, Id=83
/dev/ida/c0d0p4 : start= 56850720, size= 85394400, Id=83

 

[blaa]

Blaa, I'm a tad confused. What do you get when you type

ls -l /mnt

?

A total of two;
drwxr-xr-x 2 root root 1024 2006-04-26 13:00 mo
drwxr-xr-x 2 root root 1024 2006-04-26 13:13 sda4

but, those are just folders that I created yesterday, not actual mount points

 

[blaa]

I really think that the drive is not being interpreted correctly. The partition table entries do not match the physical disk on the basis of what you have posted, while it is possible for partition tables to get a bit fucked up and still work what we've seen so far is beyond that, I have no idea why slot 4 should be filled with a partition that extends beyond the end of the disk and I only see this in cases of incorrectly identifed hard drives. I suspect that this situation has arisen through drive misdetection possibly in software but more likely in firmware/BIOS. It may be possible to correct these setting manually in the SCSI controller from settings printed on the outside of the drive. I think a comparison of detected and real settings reported by the system at various stages is your next obvious step.

If the drive is being correctly detected then the partition table is bollixed but you can't check this FIRST because if drive detection is wrong then it may be showing the wrong part of the drive as the partition table which will probably look like a dog's breakfast.

This is my partition table in hex and its sfdisk dump for example.

broadsword:~# dd if=/dev/ida/c0d0 bs=512 count=1 2>/dev/null |hexdump -C|grep -A4 -E '^0+1b0'
000001b0  00 00 00 00 00 00 00 00  91 c3 0d 00 00 00 80 01  |.........Ã......|
000001c0  01 00 83 fe e0 ff 20 00  00 00 c0 33 e9 02 00 fe  |...þàÿ ...À3é..þ|
000001d0  e0 ff 82 fe e0 ff e0 33  e9 02 a0 22 3d 00 00 fe  |àÿ.þàÿà3é. "=..þ|
000001e0  e0 ff 83 fe e0 ff 80 56  26 03 a0 22 3d 00 00 fe  |àÿ.þàÿ.V&. "=..þ|
000001f0  e0 ff 83 fe e0 ff 20 79  63 03 e0 03 17 05 55 aa  |àÿ.þàÿ yc.à...Uª|
broadsword:~# sfdisk -l -d /dev/ida/c0d0
# partition table of /dev/ida/c0d0
unit: sectors

/dev/ida/c0d0p1 : start=       32, size= 48837568, Id=83, bootable
/dev/ida/c0d0p2 : start= 48837600, size=  4006560, Id=82
/dev/ida/c0d0p3 : start= 52844160, size=  4006560, Id=83
/dev/ida/c0d0p4 : start= 56850720, size= 85394400, Id=83

ok, so I need to have a look at the installation of the hardware - problem - there is no information on the side of the drive

am going to to search for some manuals.

 

[blaa]

ok.. hold on.

I've been pointed towards this

"Unixware v7 is based on SVR5, earlier versions on SVR4.2.
File System supported:

* VxFS [Veritas File System - VxFS1, VxFS2 & VxFS4] and UFS File system.
Also seems to use BFS.

Looks like you need to use Vxtools

I hope this applies to MO disks as well."

good idea, or do I open the casing up?

 

[Jonti]

A total of two;
drwxr-xr-x 2 root root 1024 2006-04-26 13:00 mo
drwxr-xr-x 2 root root 1024 2006-04-26 13:13 sda4

Just checking. Looks to me like Kameron's right. "Either the partition table is screwed or part of the data is."

If the disk cannot be mounted, I think one will have to use data-recovery techniques. Can you tell us a little about the kind of data that you want to pull off the disks. Is it just a few large plain text files, perhaps (here's hoping)?