Urban75 Home About Offline BrixtonBuzz Contact

Linux Tutorial?

Jonti said:
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)?

No unfortunately its large files of recorded data, EEG and ECG data, I'm not sure exactly what the files would be, as this is in fact data recorded back in the early 90s, previous to me, and about 3 newer systems installed..

Data recovery is seriously expensive though :eek:

And also, this is only on one diskette, I am going to try others with the hexdump command, I don't believe that all the disks can be corrupted...
 
Unixware 2.1 could have a VxFS filesystem and many did by default, normally we would first establish we had a VxFS filesystem. What has been posted so far didn't make me think that you were going to need to run off with vxtools to be honest but it is worth a try if your not getting anywhere with the other routes.

sudo apt-get install vxtools will get this tool for you if you think you need it.

VxFS doesn't have a DOS/trad partition table and I would not expect a fdisk -l to report a partition table structure on a VxFS disk.

Unixware 2.1 also often came with s5fs (sysv to linux) formatting and the partition table entry you posted sort of supported that line of reasoning. Could all be a red herring though if the structure fdisk read as a part table isn't one it could be a VxFS structure that just happens to look a bit like a DOS table – odd but not impossible I guess.
 
Code:
sleep@standalone:~$ sudo hexdump -C /dev/sda4|head
Password:
00000000  cf 23 cf 23 cf 23 cf 23  cf 23 cf 23 cf 23 cf 23  |.#.#.#.#.#.#.#.#|
*
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  38 02 00 00 40 00 00 00  |        8...@...|
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  |................|
sleep@standalone:~$ sudo hexdump -c /dev/sda4|head
0000000 317   # 317   # 317   # 317   # 317   # 317   # 317   # 317   #
*
0003a00  \0  \0  \0  \0  \r   `   ^ 312 004  \0  \0  \0
0003a10                                   8 002  \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


does this look any better?
 
blaa said:
No unfortunately its large files of recorded data, EEG and ECG data, I'm not sure exactly what the files would be, as this is in fact data recorded back in the early 90s, previous to me, and about 3 newer systems installed..

Data recovery is seriously expensive though :eek:

And also, this is only on one diskette, I am going to try others with the hexdump command, I don't believe that all the disks can be corrupted...

The thing is, it looks to me as if fdisk identified the disk as the sysv type, as you expected. The mount command definitely supports sysv (man mount, of course) so I wonder if that particular disk hadn't been formatted?

Yes, try the others!
 
Jonti said:
The thing is, it looks to me as if fdisk identified the disk as the sysv type, as you expected. The mount command definitely supports sysv (man mount, of course) so I wonder if that particular disk hadn't been formatted?

Yes, try the others!


It says 'pre-formatted' but I wonder if connecting that disk to windows XP may have messed it up. Or perhaps its one of those things when you find a disk that has been sitting in a collegues cupboard for a while :)
 
blaa said:
does this look any better?
sudo dd if=/dev/sda of=sda.mbr bs=512 count=1 2>/dev/null
this will dump your master boot recordx to a file called sda.mdr in the folder you are currently in.

hexdump -C sda.mbr|grep -A4 -E '^0+1b0'
This will dump the file in hex and then search for the line 00001b0 in the hex dump which will be the first line of the partition table if there is one. and then it will print out the next four lines.

How are you getting along with vxtools?
 
sorry was distracted breifly trying to get this too

Code:
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: 595 MB, 595628544 bytes
64 heads, 32 sectors/track, 568 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda4   *           1         568      581616   63  GNU HURD or SysV

apt-get needed configuring, 'dpkg --configure -a'

so I'm just waiting on that, then running vxtools, then doing as asked.. bare with
 
blaa said:
Code:
sleep@standalone:~$ sudo hexdump -C /dev/sda4|head
00000000  cf 23 cf 23 cf 23 cf 23  cf 23 cf 23 cf 23 cf 23  |.#.#.#.#.#.#.#.#|
*
00003a00  00 00 00 00 0d 60 5e ca  04 00 00 00 20 20 20 20  |.....`^.....    |
does this look any better?
The reason you didn't get back the mdr in this was you referenced /dev/sda4 which is a partition on the disk rather than /dev/sda which is the disk itself. What you are looking at there as /dev/sda4 is content of the drive and what we are seeing is that the drive isn't blank which is a good start after all.
 
Code:
sleep@standalone:~$ sudo hexdump -c /dev/sda|head
Password:
0000000 372   3 300 214 310 216 320 216 330 216 300 274 374   {  \0  \0
0000010 373 276  \0   |  \0  \0 277  \0 006  \0  \0 271  \0 002  \0  \0
0000020 374 363 244 270   , 006  \0  \0 377 340 213 377   f   g 276 216
0000030  \a  \0  \0 220   3 300   f   g 350 357  \0  \0  \0 264  \b 262
0000040 200 315 023   s  \v   f   g 276   p  \a  \0  \0 353 346 213 377
0000050   3 300 212 301   $   ? 300 351 006 206 351   g 243   B  \a  \0
0000060  \0 376 306   g 210   5   F  \a  \0  \0 366 346   g 243   D  \a
0000070  \0  \0 276 276  \a  \0  \0 271 004  \0  \0  \0 213 376 254   <
0000080 200   t 021 203 306 017   I   u 363   f   g 276   Z  \a  \0  \0
0000090 353 242 213 377 213 367   g   f 213   F  \b   g   f 243   <  \a
sleep@standalone:~$ sudo hexdump -C /dev/sda|head
00000000  fa 33 c0 8c c8 8e d0 8e  d8 8e c0 bc fc 7b 00 00  |.3...........{..|
00000010  fb be 00 7c 00 00 bf 00  06 00 00 b9 00 02 00 00  |...|............|
00000020  fc f3 a4 b8 2c 06 00 00  ff e0 8b ff 66 67 be 8e  |....,.......fg..|
00000030  07 00 00 90 33 c0 66 67  e8 ef 00 00 00 b4 08 b2  |....3.fg........|
00000040  80 cd 13 73 0b 66 67 be  70 07 00 00 eb e6 8b ff  |...s.fg.p.......|
00000050  33 c0 8a c1 24 3f c0 e9  06 86 e9 67 a3 42 07 00  |3...$?.....g.B..|
00000060  00 fe c6 67 88 35 46 07  00 00 f6 e6 67 a3 44 07  |...g.5F.....g.D.|
00000070  00 00 be be 07 00 00 b9  04 00 00 00 8b fe ac 3c  |...............<|
00000080  80 74 11 83 c6 0f 49 75  f3 66 67 be 5a 07 00 00  |.t....Iu.fg.Z...|
00000090  eb a2 8b ff 8b f7 67 66  8b 46 08 67 66 a3 3c 07  |......gf.F.gf.<.|
sleep@standalone:~$ sudo apt-get install vxtools
Reading package lists... Done
Building dependency tree... Done
E: Couldn't find package vxtools
sleep@standalone:~$
 
*sigh*

How do you copy a folder into /usr/src?

the particular folder I have tried:

sudo cp vxtools-0.4 /usr/src
password
ommiting 'vxtools-0.4'

why is it ommiting the one thing I want to move?
 
Jonti said:
But, according to http://vxtools.sourceforge.net/

"Currently vxtools is only tested for powerpc vxworks under x86 linux. Processors which use little endian such as x86 or arm may have endian problem. All comments and contributions are welcomed and encouraged."
not just you who is :confused: either mate I'm sure I used vxtools on a Debian x86 machine. I'll try and find my notes, if I even have any, from that job. Could be I used a HP-UX which would have had its own comercial vxtools but I don't think we had that till later.

There is another tool I use which I just found called disktype that tells you what format and partition your hard drives are which is quite cool, might give you and answer or at least exclude a lot of obvious stuff.

sudo apt-get install disktype will get it for you and then you just type sudo disktype /dev/sda
 
ok its in there, but now I can't open the folder. Says I don't have permission, and I can't use 'sudo cd /vxtools' :confused:
 
Jonti said:
"Currently vxtools is only tested for powerpc vxworks under x86 linux. Processors which use little endian such as x86 or arm may have endian problem. All comments and contributions are welcomed and encouraged."
:o

modprobe freevxfs

:o

my notes say :o

but that is only the beginning of a tail of woe, I feel sorry for myself just reading my notes knowing what I know now.

You see while there is read only support for the filesystem UnixWare didn't use DOS/traditional partition tables, I can hear you thinking that is just yummy, so what you have to do is figure out where the partition actually starts and then use losetup -o which is a toy that you use to manipulate and control unix loop back drivers. the -o allows you to specify an offset within the device where reading starts which then allows you to mount your pseudo device. I can tell from my notes that this was a learning process that hurt.

(The above paragraph is a ramble by the way, we don't know what sort or partition table blaa is dealing with, hopefully disktype might shed some light on that for him.)
 
blaa said:
ok its in there, but now I can't open the folder. Says I don't have permission, and I can't use 'sudo cd /vxtools' :confused:
this sudo stuff must be getting very boring for you.

type
su -

then your password and become a super user permanently. Of course you can trash everything but you can do that with sudo as well and you can do everything faster this way. sudo is ok for one off commands but when your whole job revolves around being root and you are on what is at least nominally a non-production machine, as you are currently it makes life easier.

sorry for the vxtools blind alley, brain not engaged. :rolleyes:

When you have done modprobe freevxfs you can then do cat /proc/filesystems and you will see a new entry at the end.
 
ok god, now I really feel like I am taking the piss, I don't have disktype in my apt-get?
So I went looking on sourceforge

'No precompiled binaries are available at this time. Compiling disktype is simple and straightforward, so I don't see this as a great loss.'

'GNU make is required to build disktype. The Makefile is set up to use GCC, but disktype should compile with any C compiler. To change the compiler, you can edit the Makefile or set the standard variables CC, CPPFLAGS, CFLAGS, LDFLAGS, and LIBS from the make command line.

The Makefile uses uname to determine the system type and enables certain system-dependent features based on that. If you run into problems, you can disable all system-dependent features by setting the variable NOSYS, as in make NOSYS=1.

Running make results in the binary disktype. Copy it to a bin directory of your choice, optionally stripping it on the way. That's all. '

Ok, I am completely lost...
 
Kameron said:
this sudo stuff must be getting very boring for you.

type
su -

then your password and become a super user permanently. Of course you can trash everything but you can do that with sudo as well and you can do everything faster this way. sudo is ok for one off commands but when your whole job revolves around being root and you are on what is at least nominally a non-production machine, as you are currently it makes life easier.

sorry for the vxtools blind alley, brain not engaged. :rolleyes:

When you have done modprobe freevxfs you can then do cat /proc/filesystems and you will see a new entry at the end.

Eek!
sleep@standalone:~$ su -
Password:
su: Authentication failure
Sorry.
sleep@standalone:~$

using the same password I would use for sudo...

Please tell me that I am not alone on finding this linux business an extremely steep learning curve, I SO appreicate your help guys.

Ok, so my plan of action is;

1. install disk get. run previous commands
2. modprobe freevxfs
 
blaa said:
Eek!
sleep@standalone:~$ su -
Password:
su: Authentication failure
Sorry.
sleep@standalone:~$
It's an Ubuntu thing. You need ...

john@advent:~$ sudo su -
Password:
root@advent:~#
 
Kameron said:
http://packages.ubuntulinux.org/breezy/utils/disktype

You should have it in your apt tree, if not download it and do what even the advised way is to load deb in ubuntu is :confused:

this would be dpkg --install foo_ver-rel.deb in my world and I think that will work for you but I think there might be a clicky gui as well.

puts hand up ::: that'll be System>Administration>Synaptic Package Manager. :)


*quickly grabs hoody and goes to the naughty step on the Beach. :o
 
blaa said:
using the same password I would use for sudo...

https://wiki.ubuntu.com/RootSudo

or in other words - Kameron is wrong and you can't do it like that in Ubuntu unless you want to do a lot of messing around with things. Your handling this very well, I'd be throwing my toys out the pram if I were in your position.

e2a: I see Jonti ha sbeaten me to it :)
 
sleep@standalone:~$ sudo disktype /dev/sda

--- /dev/sda
Block device, size 568.0 MiB (595628544 bytes)
DOS partition map
Partition 4: 568.0 MiB (595574784 bytes, 1163232 sectors from 32, bootable)
Type 0x63 (GNU HURD or SysV)
 
Kameron said:
https://wiki.ubuntu.com/RootSudo

or in other words - Kameron is wrong and you can't do that in Ubuntu unless you want to do a lot of messing around with things. Your handling this very well, I'd be throwing my toys out the pram if I were in your position.
Steady!

It's just that the "su -" bit needs to be preceded by "sudo " as by default there is no root in Ubuntu. Instead, every system command is allowed by /etc/sudoers* -- and that includes su itself!


* but (default settings) only for the person who installed the system, the PC owner. This has actually simplified blaa's life so far -- albeit at the cost of complicating yours!
 
Jonti said:
* but (default settings) only for the person who installed the system, the PC owner. This has actually simplified blaa's life so far -- albeit at the cost of complicating yours!

:D
 
blaa said:
sleep@standalone:~$ sudo disktype /dev/sda

--- /dev/sda
Block device, size 568.0 MiB (595628544 bytes)
DOS partition map
Partition 4: 568.0 MiB (595574784 bytes, 1163232 sectors from 32, bootable)
Type 0x63 (GNU HURD or SysV)
:(

OK, how it stands for you at the moment.

1. You do have a normal DOS partition. In a sense this is a good thing because you won't have to learn losetup -o
2. It reconfirms that you have a single partition, the same size as the disk sitting in slot 4 which is odd and normally a sign that hardware detection is screwed or that the disk got seriously messed up at sometime in the past or some really crap partition tool was used

3. It finds the disk to be labelled type 0x63 which is what fdisk told us before that information is read from the partition table.

BUT
4. It didn't find and identify the file system inside partition 4. Normally there would be a whole block of information under that a'la:
Code:
broadsword:/# !disktype
disktype /dev/ida/c0d0p4

--- /dev/ida/c0d0p4
Block device, size 40.72 GiB (43721932800 bytes)
ReiserFS file system (new 3.6 format, standard journal, starts at 64 KiB)
  Volume name "/home"
  UUID B9F374B7-D5DD-4A79-B09E-A269A6A7CEDD (DCE, v4)
  Volume size 40.72 GiB (43721883648 bytes, 10674288 blocks of 4 KiB)

This is a problem and means that it isn't anything that disktype knows.

Obviously this is version dependent but we know that the file system isn't any of the one that disktype detects :( you can see a list in the man page. man disktype

There are some sysv filesystems that aren't detected but you already tried that mount and it failed so even if it is sysv it is an unsupported one. Try running disktype against you system disk to see what the output should really look like, every file system has different meta-data that disktype will spit out, ever it only spits out a name and version number.

Look on the bright side - you know lots more about Unix. :D
 
Back
Top Bottom