ntfs-3g mount problem

[SkymanScott]

I've pulled a FreeBSD disc from an old First Alliance NAS dead-motherboard system and am trying to read the data from it. I'm told that years ago, a hardware tech ran a Windows XP 'convert' statement on drive F: (one partition of the FreeBSD disc) to make it NTFS and the system ran this way successfully for an extended time.

When I run a post-config sysinstall and just look at the drive, both partitions show as FreeBSD. I can mount partition 1 (ad3s1) and look at the BSD operating system. I am unable to mount the second partition (ad3s2), and I've tried setting /etc/fstab for this partition to ufs, ext2fs, ntfs, and ntfs-3g to no avail.

Trying mount_ntfs on the partition, I get

NTFS signature is missing, GEOM: geometry does not match label (255h,63s != 16h,63s)

device doesn't seem to have a valid NTFS.

A mount -a results in

operation not supported by device

/etc/fstab is

/dev/ad3s2   /cresc  ntfs-3g  ro  0  0

Any ideas on getting at this important data?

Thanks,
Scott

 

[_martin]

Can you paste the output from the following commands:

# fdisk /dev/ad3

and if you are running newer version of the FreeBSD (8.x for sure, not sure about 7.x) also:

# gpart show /dev/ad3

 

[SkymanScott]

Running FreeBSD 8.2 x86 GENERIC.

fdisk /dev/ad3

******* Working on device /dev/ad3 *******
parameters extracted from in-core disklabel are:
cylinders=65531 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=65531 heads=16 sectors/track=63 (1008 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 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 256977 (125 Meg), flag 80 (active)
	beg: cyl 0/ head 1/ sector 1;
	end: cyl 15/ head 254/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 257040, size 64260 (31 Meg), flag 0
	beg: cyl 16/ head 0/ sector 1;
	end: cyl 19/ head 254/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 321300, size 159702165 (77979 Meg), flag 0
	beg: cyl 20/ head 0/ sector 1;
	end: cyl 744/ head 254/ sector 63
The data for partition 4 is:
<UNUSED>

gpart show /dev/ad3

=>      63  66055185  ad3  MBR  (31G)
        63    256977    1  freebsd  [active]  (125M)
    257040     64260    2  freebsd  (31M)
    321300  159702165    3  freebsd  (76G)

(Note - on sysinstall, partition 3 (76G) shows as unused and not as FreeBSD).

Thank you,
Scott

 

[_martin]

Hm - seems your partition table is messed up. gpart sees the whole disk smaller than one of its partitions. You've mentioned you can mount slice #1 - can you also boot off it? It might be a good idea to do a dd copy of the whole disk and work on that copy (to be on a safe side). It might get more interesting how to recover this partition table if you don't have a backup ..

 

[SkymanScott]

Good idea, MatoAtlantis. Thank you for the suggestion. I have not done this before so I ask, if I go into sysinstall and change the partition type, will that destroy the data? I see number 165 for FreeBSD but cannot locate the type for NTFS.

Thanks again,
Scott

 

[_martin]

I have not done this before so I ask, if I go into sysinstall and change the partition type, will that destroy the data?

Technically, you'll rewrite the partition information only, not the data itself. But I would not suggest you to do it - not before you figure out why the partition layout seems to be messed up.

Your disk is using MBR scheme, you can do a backup of the MBR by:

# dd if=/dev/ad3 of=mbrbackup.dsk bs=512 count=1

But I would suggest you to work with the whole dd backup only. When you have that backup, you can use it on FreeBSD with:

# mdconfig -a -t vnode -f /path/to/disk.dsk

md0

You can check it with:
# mdconfig -lv

md0     vnode    1024M  /backup/disk.dsk

Now you can use the /dev/md0 - that would behave just like your actual disk (I used the 1024M file I've created for test).

 

[SkymanScott]

Your reply is appreciated.

I have 5GB of free space available and I am running out of space trying to to the dd command, so I am unable to get a backup to work with. I tried to reboot with the rw option but the system didn't like that. I share the same concern about working with a copy of the data.

In order to boot from this disk, is it simply a matter of going in to sysinstall and 'S'etting the partition as bootable? How to avoid booting from the other partition?

Regards,
Scott

 

[_martin]

In order to boot from this disk, is it simply a matter of going in to sysinstall and 'S'etting the partition as bootable? How to avoid booting from the other partition?

Definitely NOT - don't do that.

If you don't have a space for a full disk backup, do a MBR backup at least - that's better than nothing.

What is the system you are using to read this disk ? If you are using typical x86 system you have to set it as a primary boot disk in BIOS. From what you've pasted there was an older FreeBSD on the disk before, it might be good to have a look on it.

 

[SkymanScott]

MatoAtlantis,

An additional note -

You previously said "Technically, you'll rewrite the partition information only, not the data itself. But I would not suggest you to do it - not before you figure out why the partition layout seems to be messed up. "

I am guessing that the partition data is messed up because I was told a hardware tech ran an NTFS conversion on the FreeBSD partition (ad3s2).

I agree that I should work with a backup copy as a safety net. I am unable to make that copy as file space fills up. No tape drive or other backup device to use unless I try to configure something across a network, limited availability there.

I thought about removing the system data from partition 1 (ad3s1) since I don't care about that information, however when I changed read-only to rw, the system would not mount and the boot stopped early.

 

[SkymanScott]

Yes, thank you. I was so deep into the OS, I didn't think about BIOS. I can try that.

 

[SkymanScott]

The disk in question started to boot into FreeBSD 4.1 but then failed at the mountroot> prompt with a message

mount error: 22

I was not able to manually mount the /dev/ad0s1a.

Is my only option now to attempt to change the partition 2 type to NTFS, #135, through sysinstall?

And to get the master boot record back if necessary, do I do a reverse of the "if" and "of" on the dd command?

Whew,

Thanks.

 

[_martin]

Ok, so you were able to boot the disk. mountroot> stopped you because it was not able to find /, which might changed as you have two disks there now (/etc/fstab entry for / points to bad location on old FreeBSD).

There is a text that shows you root "candidates" you can mount from:

# ? will list them again. To mount a root from, for example, UFS /dev/da0p2 you can use the following commands:

# ufs:/dev/da0p2

Trying to mount root from ufs:/dev/da0p2

--< OS boot continues>--

I was told a hardware tech ran an NTFS conversion on the FreeBSD partition (ad3s2)

Ok, but you said it did work afterwards. So we can assume this was not a problem.

My opinion is that changing types won't help you mount the partition. As the FreeBSD 4.x is the last time it really worked (if I understand you correctly), I would try to boot it and start from there.

This might sound little bit stupid, but did you try to mount /dev/ad3s3 ?

# mount -t ntfs /dev/ad3s3 /ntfs

 

[SkymanScott]

Thank you for your response.

I tried the command [CMD=""]mount -t ntfs /dev/ad3s3 /ntfs[/CMD] and got the response

fuse4BSD; version 0.3.9-pre1, FUSE ABI 7.8
NTFS signature is mission
The device '/dev/ad3s3' doesn't seem to have a valid NTFS

At the mountroot> prompt, I entered UFS:/dev/ad3s1 and got the response

/dev/ad3s1: BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
/dev/ad3s1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
R/W mount of / denied.
Mounting of /etc/fstab filesystems failed, startup aborted.
Enter location of shell or RETURN for /bin/sh.

/etc/fstab shows

/dev/ad0s1a / ufs

Trying to mount other variations, such as /dev/ad0s2, ad3s2, ad3s3, etc. returns

incorrect superblock.

I did configure an external USB drive and get a complete 33GB backup of the device to /dev/da0p2

Not sure where to go from here. Thank you again.

Scott

 

[_martin]

Strange that you can't mount / during boot but you were able to mount it under FreeBSD 8.x without problem (did you umount this filesystem correctly last time it was mounted?)

Good, complete dd copy of the disk would be very handy. Actually, all your tests should be done on this copy from now on.
What is the actual size of the disk of which you made copy?

As mentioned already, I assume you have messed up partition table (though I would try to find out why - who made what to that disk). You can try to change the partition type and try to mount it, but I would not put money on it. I would focus on its recovery. But as you don't have a backup, this might be tricky.

There are some tools you can try, e.g. sysutils/magicrescue. Try to search the forums too - there are some threads where people were trying to recover partitions (note: not slices), like this one.

 

[SkymanScott]

I was able to mount the root file system of the "old" disk under the FreeBSD 8.x using a separate mount point /olddisk but not able to complete the boot and process startup when booting on its own, with FreeBSD 4.x.

I can mount /olddisk as ro but cannot mount it as rw, as I get the message:

file system is not clean, run fsck
geometry does not match label
(255h,63s != 16h,63s)

The size of the disk for the complete copy was 33GB.

Read and Write permissions are odd on the dd copy of the disk. I can
mount /dev/da0p2 /mnt/usb
as rw and successfully touch a file to verify write privileges, but testdisk shows it as read only and will not allow changes.

Also, testdisk shows 3 rows of data statistics but 1 partition on the first row and "No Partition" on the 2nd and 3rd row. I am verifying the dd command to make sure I copied ad3 and not ad3s1, but I am quite sure I did.

I will try magicrescue after this additional copy.

Thank you.

 

[_martin]

Error message regarding geometry is the sad old thing. You can search these forums and get more information regarding it; this is why I suggested you to boot the original 4.x FreeBSD. But anyway, partition table should not be messed up like this (specially the ID of them).

I'm not sure why you are using /dev/da0p2 as a backup. I thought you made a backup to a file, e.g.:

# dd if=/dev/ad3 of=/my/mounted/usb/ad3-backup.dsk

where /my/mounted/usb is your mounted USB disk. ad3-backup.dsk should be mounted via mdconfig then.

If the size of the disk is ~33G, it's very strange that fdisk shows you partition #3 as ~77GB.

Once attached with mdconfig, I would try to repair /dev/md0s1 first with fsck - to see what it has to say.

 

[SkymanScott]

Clarification, I was using /dev/da0p2 to analyze the partitions, as testdisk did not recognize the ad3-backup.dsk as a real disk. Thank you for directing me to the mdconfig command.

Here is what I have done:
mdconfig -a -f /mnt/usb/ad3-backup.dsk
and the device mounted fine.
fsck -t ufs /dev/md0s1
and the backup file system errors were then fixed when I responded 'y' to the prompts.

file system clean

After these results, I then proceeded to umount the physical disk and run the file systems check on it.

file system clean

And now the file system can be mounted as read only or read write.

However, attempting to boot from it produced errors about SUPER BLOCK as follows:

BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
/dev/ad3s1: UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY
/dev/ad3s1: CANNOT WRITE: BLK 2016
/dev/ad3s1: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 256977
mount: /dev/ad3s1 on /: specified device does not match mounted device
mounting /etc/fstab filesystems failed, startup aborted
ad3s3: slice extends beyond end of disk; truncating from 159702165 to 65733948 sectors
ad3s3: raw partition size != slice size
ad3s3: start 321300, end 66055247, size 65733948
ad3s3: start 321300, end 160023464, size 159702165
ad3s3: truncating raw partition
ad3s3: rejecting partition in BSD label: it isn't entirely within the slice

You have already pointed out the disc should be 76+GB and partition/size shows 33GB.
Referring to prior system messages about (255n,63s != 16h,63s), I looked at the disc and physical label on it.

HD-Label  82GB  16383/16/63

So the 255 expectation conflicts with the physical label of '16' on the disc.

Back to the fsck results, because of the truncation, should I restore the backup to the physical disk?

Also, while the boot attempt makes reference to /dev/ad3s3 (ad3s2 is the /proc file system), /etc/fstab on the physical disk does not have an entry and doesn't make reference to any data partition, such as /dev/ad0s3. Am I missing something here? Our main objective, obviously is to find the data.

One last note - I have just become involved here with my friend's disk problem so I don't know the history nor configuration of the system and what was done to it. However, there are two other physical disks available that were set up on a RAID 5 configuration. Perhaps we have some options with them.

Thank you,
Scott

 

[_martin]

Try to run bsdlabel on the /dev/md0s1, i.e.:

# bsdlabel /dev/md0s1

I would expect slices insides this partition. As you don't know the past configuration, check and paste /etc/fstab from the old FreeBSD. Not that it's necessary but I would expect root to be on /dev/md0s1a or /dev/ad3s1a during old system boot.

I don't understand why the dd backup is so small - I would expect it to be ~80GB - as it doesn't care about the filesystem and raw copy is done. Btw. you should have stuck to the copy - don't do any changes to original.

Also /proc is not mounted by default in FreeBSD, you should check DSF (device special file) under /dev

Not sure if the other disks are any good. If it was me who has this kind of problem, I would probably use dd copy and tried to repair it in VMware (easier to manage reboots, manage rollbacks, etc.)

 

[SkymanScott]

Your prior post said "If it goes OK, I would try to run fsck on the actual disk and boot from it". That is what I did, since a boot on the copy on a USB mounted disk would not happen.

I do have Virtual Box from Oracle, which is similar to VMware. I will take the USB drive to the Mac that has Virtual Box.

Are the the repair commands you suggest bsdlabel, fsck, magicrescue, testdisk? Others?

Thanks,
Scott

 

[_martin]

Your prior post said "If it goes OK, I would try to run fsck on the actual disk and boot from it".

You were really quick - I did paste it and edit/remove it seconds later to not to confuse you.

Are the the repair commands you suggest bsdlabel, fsck, magicrescue, testdisk? Others?

You should look into FreeBSD handbook and check the difference between partition and slice in FreeBSD. bsdlabel(8) is a tool to read/write BSD labels.

To recap: Your disk seems to have a messed up partition table. Strange thing is that dd didn't do a full disk backup but only ~33G. To avoid data damage, it's better to work with a copy. You can always create another copy and start over.

As the FreeBSD 4.x was the last time it all worked ok, booting to it is a good starting point. Check /etc/fstab entries in the old FreeBSD - it will give some picture of how the disk was organized.

You can't (or at least so I think) access data if the partition table is not valid. There are some tools and threads on these forums people tried to use and recover. You should check these tools and test them on the copy you've made - so, if something goes wrong, you can start over.

I'm not sure if VirtualBox can map physical disks to a virtual machine as VMware Workstation does for example.

 

[SkymanScott]

I've run bsdlabel with the non-write option to see the different slices.

bsdlabel -n /dev/md0s1

# /dev/md0s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:   256977        0    4.2BSD        0     0     0 
  c:   256977        0    unused        0     0         # "raw" part, don't edit

bsdlabel -n /dev/md0s2

# /dev/md0s2:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  b:    64260        0     vinum                    
  c:    64260        0    unused        0     0         # "raw" part, don't edit

bsdlabel -n /dev/md0s3

# /dev/md0s3:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a: 159702165        0     vinum                    
  c: 159702165        0    unused        0     0         # "raw" part, don't edit

Does anything appear odd in this output?

Thank you.
Scott

 

[_martin]

Aha - now we're getting somewhere. Look at this - vinum(8). It seems those partitions were part of the volume manager. In this case, though, there is indeed no NTFS partiton on that disk. vinum became obsolete and was superseded by geom(8).

I came around to FreeBSD world when 4.x was new. I didn't use the vinum myself - you need to browse the older man pages to get familiar with it.

The question is - how was that volume set? If it was RAID5 no wonder you can't read anything - 2 out of 3 disks are needed to do so (on 3-disk RAID5).

Try to boot the old FreeBSD and mount root from (assuming /dev/ad3 is your disk):

# ufs:/dev/ad3s1a

You didn't paste the output from /etc/fstab - again, this might give you a better picture of how the layout was done.

Are you 100% sure that there is actually any NTFS partition on that disk?

 

[SkymanScott]

data recovery (was ntfs mount problem)

In this case, though, there is indeed no NTFS partiton on that disk... Are you 100% sure that there is actually any NTFS partition on that disk?

From this, I don't believe there is an NTFS partition on the disk(s). I'm told the tech ran the NTFS convert command on a mapped F: drive, but we know it was a mounted ufs mirrored partition at the time, so we should stay with that premise from your diagnosis here. The subject of this thread is not accurate.

you need to browse the older man pages to get familiar with (vinum).

Yes, will do. I worked with the AIX LVM for disk mirroring in the 1990's and would believe the concepts are similar.

The question is - how was that volume set? If it was raid5 no wonder you can't read anything - 2 out of 3 disks are needed to do so (on 3-disk radi5).

I'm not sure how it was set as I was not around this environment nor configuration, just getting involved a couple weeks ago to try and help with this disaster recovery. I will get the additional disks later today and add to the hardware tomorrow.

You didn't paste output from /etc/fstab - again, this might give you better picture how the layout was done.

I'm sorry, I thought I had made prior reference to /etc/fstab showing only two filesystems, / and /proc. Here it is.

# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/ad0s1a		/		ufs	rw		1	1
proc			/proc		procfs	rw		0	0

Try to boot the old FreeBSD as mount root from (assuming /dev/ad3 is your disk): # ufs:/dev/ad3s1a

I have done this and had several different results, which concerns me, not being predictable nor repeatable. One result was a hang at the ethernet message. I'll call that temporary insanity as it didn't happen a second time, but something to watch. Another result was a failed mountroot> with error code 22. The third result was a proper boot but with the SUPER BLOCK error message I published previously.

Below are the results shown in the rc.d/dmesg file.

Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD 4.1-20000812-STABLE #0: Tue Sep  3 15:28:33 CST 2002
    root@image.synology.com:/syno10/bsd41/compile/SynoConfig
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (349.41-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x652  Stepping = 2
  Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR>
real memory  = 134152192 (131008K bytes)
Ignoring invalid memory size of '(null)'
Ignoring invalid memory size of '(null)'
sio1: gdb debugging port
avail memory = 124948480 (122020K bytes)
Preloaded elf kernel "kernel" at 0xc0411000.
Pentium Pro MTRR support enabled
md0: Malloc disk
apm_probe start
apm flags: 0x00000007
apm0: <APM BIOS> on motherboard
apm_attach start
apm: found APM BIOS v1.2, connected at v1.2
apm:SynoBios Disable 0x0000
T:0 E:0 B:0 H:0 A:0 F:0
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
isab0: <Intel 82371AB PCI to ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 ATA33 controller> port 0xf000-0xf00f at device 7.1 on pci0
timeout:0 status0:0x00000050 status1:0x00000050
ata0: at 0x1f0 irq 14 on atapci0
timeout:0 status0:0x00000000 status1:0x00000050
ata1: at 0x170 irq 15 on atapci0
pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 7.2 irq 11
chip1: <Intel 82371AB Power management controller> port 0x5000-0x500f at device 7.3 on pci0
pci0: <S3 ViRGE graphics accelerator> at 8.0 irq 10
fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xe400-0xe43f mem 0xea000000-0xea0fffff,0xea100000-0xea100fff irq 5 at device 9.0 on pci0
fxp0: Ethernet address 00:90:27:7b:1e:9f
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1: configured irq 3 not in bitmap of probed irqs 0
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable
ATA: ad0: 6149MB <WDC AC26400R> [13328/15/63] at ata0-master using UDMA33
SYNO:GEOMETRY:ad0:13328:15:63
ATA: ad1: 3098MB <IBM-DAQA-33240> [6296/16/63] at ata0-slave using WDMA2
SYNO:GEOMETRY:ad1:6296:16:63
ATA: ad3: 32253MB <IC35L080AVVA07-0> [65531/16/63] at ata1-slave using UDMA33
SYNO:GEOMETRY:ad3:65531:16:63
vinum: loaded
SYNO:DRIVE:3:/dev/ad0 /dev/ad1 /dev/ad3
ad3s3: slice extends beyond end of disk: truncating from 159702165 to 65733948 sectors
ad3s3: raw partition size != slice size
ad3s3: start 321300, end 66055247, size 65733948
ad3s3c: start 321300, end 160023464, size 159702165
ad3s3: truncating raw partition
ad3s3: rejecting partition in BSD label: it isn't entirely within the slice
ad3s3: start 321300, end 66055247, size 65733948
ad3s3a: start 321300, end 160023464, size 159702165
vinum: no drives found
Mounting root from ufs:/dev/ad0s1a
Root mount failed: 22
Mounting root from ufs:wd0s1a
Root mount failed: 22
Mounting root from ufs:wd0a
Root mount failed: 22

Manual root filesystem specification:
  <fstype>:<device>  Mount <device> using filesystem <fstype>
                       eg. ufs:/dev/da0s1a
  ?                  List valid disk boot devices
  <empty line>       Abort manual input

mountroot> ufs:/dev/ad3s1a
Mounting root from ufs:/dev/ad3s1a
ad3s3: slice extends beyond end of disk: truncating from 159702165 to 65733948 sectors
ad3s3: raw partition size != slice size
ad3s3: start 321300, end 66055247, size 65733948
ad3s3c: start 321300, end 160023464, size 159702165
ad3s3: truncating raw partition
ad3s3: rejecting partition in BSD label: it isn't entirely within the slice
ad3s3: start 321300, end 66055247, size 65733948
ad3s3a: start 321300, end 160023464, size 159702165

As stated earlier, I will obtain the other disks later today and research vinum to see about combining them as a read only system.

Thank you for your continued attention helping to put these pieces together,
Scott

 

[_martin]

I'm confused why your 80GB disk is seen as 32253MB. Whether it is due to the older hardware/BIOS or older FreeBSD (or both). Or if you are hitting some hardware limitation. But if I assume this disk was working ok on this server, there should be no problem.

Your /etc/fstab shows that root was indeed one slice. I see you have 128MB RAM on this server. If I make an assumption that swap size was the same size as RAM, it would fit the fdisk output you showed before, that is:

/        - one slice on first partition
swap     - second partition, size 128MB

Which would leave the third partition for vinum volume. I'm not sure what are those other disks - it might be worth removing them and using only this disk seated as primary master. I also assume you did instruct bios to boot from disk as a first choice.

Are you able to get to the login prompt or rescue shell?

I see vinum didn't find any volumes. I would expect it would be able to read the label on /dev/ad3s3 regardless of the missing disks. But I think that's where size of the partition issues come into game.

 

[SkymanScott]

data recovery (was ntfs-3g mount problem)

... why your 80GB disk is seen as 32253MB. Whether it is due to the older hardware/BIOS or older FreeBSD (or both). Or if you are hitting some hardware limitation.

I think you've identified it, with older hardware perhaps having a 32MB limitation. I will see about attaching the disk to new hardware.

... Which would leave the third partition for vinum volume. I'm not sure what are those other disks - it might be worth removing them and using only this disk seated as primary master. I also assume you did instruct bios to boot from disk as a first choice.

The other disks are both for the 8.2 version of FreeBSD. Yes, I will have the "old" disk set up as primary so ad0 coincides with what it is expecting, along with a second RAID disk. And yes, I did configure BIOS to boot from the old disk as ad3, and therefore had to mountroot the ufs:ad3s1.

Are you able to get to the login prompt or rescue shell?

I have been able to get it predictable and repeatable, operator error (!) I was attempting to mountroot ufs:/dev/ad3s1a instead of ad3s1 in one case and another had tried to mount ad1s1a. A slight brain cramp I guess. I can get to the*beep*bin/sh default when mountroot does not completely bring up the system. I presume that is termed the 'rescue shell'.

I see vinum didn't find any volumes. I would expect it would be able to read the label on /dev/ad3s3 regardless of the missing disks. But I think that's where this size of the partition issues come into game.

After I reconfigure the disks in their expected and logical order, I will be able to explore more with vinum, hopefully.

Thanks,
Scott