Other How to mount an old BSD filesystem - partition type 0x63

M

Mmako

Hi,

recently I had to recover an old dying SCSI HDD ( unknown original machine ) via dd ...
I was able to write it into a raw ile without any problem.
But now I am not able to access the internal filesystem.

With a direct file mount I get the error : not a block device but after some internet searching I was able to use mdconfig and "transform" it into a block device...

Nonetheless I get to the point where I am able to read a the partition table ( via fdisk ) where only the 4th slice has a filesystem.
I have /dev/md0 and the system reports a valid /dev/md0s4 "slice" ( partition) ...

But trying to mount it is where I have the problem :
Partition type reports as : 0x63 ( GNU HURD or SysV )

calling: "mount -t ufs /dev/md0s4 /mnt/yyy " gives me : unknown filesystem ...

How can I mount such "slice" or partition ?

Some context :
Using the latest FreeBSD 14.0 default kernel and only added fusefs to access the external NTFS drives ...
 
What does -s "file /dev/md0s4" say? What is the content of that slice?

EDIT: As cracauer said, you should use -s, I forgot that earlier.
 
If it was "dangerously dedicated" there is no partition table.
If it was ZFS, zdb -d might be helpful.
Maybe directly mounting as UFS etc works? Just to remember that there are a gazillion of UFS variants... what do you get if you mount /dev/md0?
 
If it is a vxfs (like T-Aoki suggested) maybe you can use vxtools to access it? Either way, you don't need to mount a filesystem to get access to the files if you have a utility that can work on the image directly instead (like vxtools for vxfs or mtools for fat as examples). Just throwing this out as an alternative to finding a way to mount it.
 
junkyalleycat said:
If it is a vxfs (like T-Aoki suggested) maybe you can use vxtools to access it?
Click to expand...
Ah, I've overlooked the case. Actually, I don't have anything to try with it, so I cannot say whether it works or not.

The most important thing for this kind of trial is, that NOT TO EVEN ATTEMPT TO WRITE THE PARTITION, EVEN WITH ATIME UPDATE.
If the target partition/drive is NOT as intended to try, ANY WRITES TO IT SHOULD FATALLY MISS THE OPPORTUNITY TO SALVAGE ANYTHING WITH CORRECT TOOLS IN THE FUTURE.

You are warned.;)
 
Hi,
Giving some more details :
I am using an imagefile as the original SCSI is already dead ...
This is one of my first experiences with FreeBSD and UFS filesystem ...

Replying some more details : calling file -s unixa5.raw I get:
unix5a.raw: DOS/MBR boot sector; partition 4 : ID=0x63, active, start-CHS (0x0,0,2), end-CHS (0x27c,63,32), startsector 1, 1304575 sectors

Using mdconfig -a unix5a.raw it makes a /dev/md0 device with a "s4" valid slice ...

Calling fdisk /dev/md0 i get :
******* Working on device /dev/md0 *******
Click to expand...
parameters extracted from in-core disklabel are:
cylinders=81 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=81 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 99 (0x63),(System V/386 (such as ISC UNIX), GNU HURD or Mach)
start 1, size 1304575 (636 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector 2;
end: cyl 636/ head 63/ sector 32
Click to expand...

Calling fdisk /dev/md0 i get :

****** Working on device /dev/md0s4 *******
parameters extracted from in-core disklabel are:
cylinders=647 heads=32 sectors/track=63 (2016 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=647 heads=32 sectors/track=63 (2016 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 111 (0x6f),(unknown)
start 1634213998, size 1679844466 (820236 Meg), flag 74
beg: cyl 361/ head 105/ sector 52;
end: cyl 111/ head 110/ sector 32
The data for partition 2 is:
sysid 10 (0x0a),(OS/2 Boot Manager, OPUS or Coherent swap)
start 0, size 1900544 (928 Meg), flag 69
beg: cyl 269/ head 115/ sector 43;
end: cyl 3/ head 0/ sector 0
The data for partition 3 is:
sysid 0 (0000),(unused)
start 983040, size 1966080 (960 Meg), flag 0
beg: cyl 0/ head 0/ sector 0;
end: cyl 0/ head 0/ sector 0
The data for partition 4 is:
sysid 0 (0000),(unused)
start 2425356288, size 3720777872 (1816786 Meg), flag 0
beg: cyl 2/ head 0/ sector 0;
end: cyl 0/ head 0/ sector 0
Click to expand...


Another trick that I tried to use was Testdisk with no partition option which give me :
3 partitions as :

P UFS - Little Endian 10192 167887 157696 [/home2]
P UFS - Little Endian 516096 872447 356353
P UFS - Little Endian 897056 1089567 192512

Testdisk indicates that the is not able to write anything due to "NONE" option


Any more ideas ?
Thanks for the fast reply ...
 
I recommend keeping this image in read only mode. Use -o readonly with your mdconfig.

You should see those slices listed when you use bsdlabel /dev/md0. You could try using dump() on the disk image and restore() to another media instead of directly accessing the slice.
 
cmoerz said:
Sounds like you could have got yourself a xenix disk
Click to expand...

T-Aoki said:
filesystem sco unix partition type 0x63
Click to expand...

Mmako said:
This is one of my first experiences with FreeBSD and UFS filesystem
Click to expand...
First step is to determine what operating system your image comes from. If it is SCO Unix/OpenServer, it will have VxFS, HTFS or EAFS file system, not UFS. As I recall, SCO UnixWare uses UFS, but I wouldn't be surprised if its implementation is incompatible with FreeBSD's UFS. I think the best solution to reading this image is to create a virtual machine with appropriate operating system, and then copy and mount the image there. On Xinuos website, you can download ready-to-run OpenServer virtual machine image.
 
Hi, sorry for the delayed reply ...

Calling "file -s /dev/md0" reports :

/dev/md0: DOS/MBR boot sector; partition 4 : ID=0x63, active, start-CHS (0x0,0,2), end-CHS (0x27c,63,32), startsector 1, 1304575 sectors
Click to expand...

The odd part is that calling "file -s /dev/md0s4" simply reports as :
/dev/md0s4: DOS/MBR boot sector
Click to expand...

Is there any any tool to give any hint of what this filesystem is ?
Any more ideas ?
 
Mmako said:
Calling "file -s /dev/md0" reports :

/dev/md0: DOS/MBR boot sector; partition 4 : ID=0x63, active, start-CHS (0x0,0,2), end-CHS (0x27c,63,32), startsector 1, 1304575 sectors

The odd part is that calling "file -s /dev/md0s4" simply reports as :
/dev/md0s4: DOS/MBR boot sector
Click to expand...
This made me recall that at least some of ancient partitioning tools, like fdisk on OS/2, had the strategy to start partitions from the head of a cylinder, say, CHS(0xnnn,0,0). Not read its source, but if file has the same assumption, it would missingly read from CHS(0x0,0,0) to determine what the filesystem type of partition 4 is.

Another possiblity, what is the worst, is that the top of the partition CHS(0x0,0,2 to 0x0,0,3) is overwritten by MBR. Usually, there should be partition boot code to boot the OS in the partition. PC-(MS-)DOS compatible MBR just kicks the partition boot code of active partition.

Side note:
Some ancient boot managers, such as that of OS/2, abuses cylinder 0x0 after MBR to store itself, with the assumption above (nothing others use there), and MBR part of it just loads remaining part of itself, then run it.
 
I would have suggested sysutils/disktype if file doesn't give you the details you need, but unfortunately the power that be has seen fit to expire it. I don't agree with their decision, but I'm not calling the shots (or doing the work).
 
tingo said:
I would have suggested sysutils/disktype if file doesn't give you the details you need, but unfortunately the power that be has seen fit to expire it. I don't agree with their decision, but I'm not calling the shots (or doing the work).
Click to expand...

I'm really not a friend of kicking out software just because it wasn't changed in a while.

There is such a thing as reasonably complete software that just does its job and has no known security problems.

ETA: debian still has it. So if you boot a live image of debian you can try both automatic detection at mount time and disktype.
 
Just a small update:
Some months ago I tried to mount the mentioned dd raw image with linux with no sucess ...
Because I had the idea that the image was original from a pure Unix machine I started to try it out with FreeBSD...

Nonetheless ( as indicated ) I tried again to mount it via Linux ...
With the previous aproach this time with more knowledge I got to the point where I get in dmesg and with loop setup :

[ 606.934006] JFS: nTxBlock = 8192, nTxLock = 65536
[ 606.954875] NILFS version 2 loaded
[ 607.324936] SGI XFS with ACLs, security attributes, realtime, scrub, repair, quota, no debug enabled
[ 651.201663] loop0: detected capacity change from 0 to 1306458
[ 651.201743] loop0: p4
Click to expand...

So Î get to the same point with mdconfig .
The 4th partition is the only with a valid filesystem ...


Calling mount :
mount /dev/loop0p4 /mnt/mk4
mount.nilfs2: Error while mounting /dev/loop0p4 on /mnt/mk2: Invalid argument
Click to expand...

Can I infere that the filesystem is XFS or NILFS ? If so how can I mount it ?
 
You must log in or register to reply here.
Back
Top