# ntfs-3g mount problem



## SkymanScott (Jun 17, 2011)

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 (Jun 17, 2011)

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 (Jun 17, 2011)

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 (Jun 17, 2011)

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 (Jun 17, 2011)

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 (Jun 17, 2011)

SkymanScott said:
			
		

> 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 (Jun 17, 2011)

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 (Jun 17, 2011)

SkymanScott said:
			
		

> 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 (Jun 17, 2011)

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 (Jun 17, 2011)

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


----------



## SkymanScott (Jun 18, 2011)

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 (Jun 19, 2011)

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>--
```



			
				SkymanScott said:
			
		

> 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 (Jun 20, 2011)

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 (Jun 20, 2011)

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 (Jun 20, 2011)

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 (Jun 20, 2011)

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 (Jun 21, 2011)

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 (Jun 21, 2011)

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 (Jun 21, 2011)

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 (Jun 21, 2011)

SkymanScott said:
			
		

> 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.



			
				SkymanScott said:
			
		

> 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 (Jun 22, 2011)

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 (Jun 22, 2011)

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 (Jun 22, 2011)

*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 (Jun 22, 2011)

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 (Jun 22, 2011)

*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


----------



## _martin (Jun 22, 2011)

I thought that disk was originally attached to that machine, that's why it was strange to me. 

You can set the root before booting kernel (escape the bootloader to prompt - option # 6) and do the following: 


```
OK set vfs.root.mountfrom=/dev/adXs1a
OK boot
```

But yes, removing those disks and trying to recreate the original state is better.

Boot behavior you've described is actually logical - system detected wrong partition layout and had to stop to avoid any damage. Indeed you have a /bin/sh to check what's wrong and fix it on fly if possible. ^D or exit would start an attempt to continue booting.

Good luck with the recovery.


----------



## SkymanScott (Jun 23, 2011)

*data recovery (was ntfs-3g mount problem)*

I have configured a different hardware system, upping the memory to 1GB from 128MB and have installed all three disks.  The master drive is /dev/ad0 and the two RAID drives are /dev/ad1 and /dev/ad2.

The system will not auto boot successfully and has difficulty with slice 3 (/dev/ad0s3). Here is the latter portion of the output of /sbin/dmesg.


```
...
vinum: loaded
ad0s3: slice extends beyond end of data, truncating
vinum0.p0.s2 is crashed
vinum0.p0 is degraded
vinum0.p0.s0 is crashed
vinum0.p0 is degraded
vinum0.p0,s2 is crashed
vinum0.p0 is corrupt
Mounting root from ufs:/dev/ad0s1a
ad0s3: slice extends beyond ... (previously posted)
as0s3: raw partition size != slice size
ad0s3: start xxx, end yyy, size zzz (previously posted)
ad0s3: truncating raw port
WARNING: R/W mount of / denied.  Filesystem is not clean - run fsck.
```

Attempting to /sbin/fsck obviously fails with the SUPERBLOCK errors previously posted. It leaves me in the /bin/sh state and is read only. I'm not able to mount my USB drive nor configure it because of this. bsdlabel or sysinstall are not accessible in this state either, understandably.

Any thought on an approach here?

Thank you,
Scott


----------



## richardpl (Jun 23, 2011)

Use *bsdlabel -e* to edit slice size to match partition size, or use *gpart resize ...* to resize partition to match slice size, choice is yours.


----------



## _martin (Jun 23, 2011)

I would suggest you to boot the new FreeBSD and load the geom_vinum and try to recover the vinum volumes now (as there is no NTFS partition). I'm not sure if new gvinum can work with older vinum - again, you need to crosscheck with handbook or maybe somebody else can confirm this. 

But if the newer hardware still sees the 80GB disk as ~30GB, something might be wrong with that disk itself. Maybe jumper settings on the disk? I vaguely remember there was a jumper that limited the size of the IDE disk - worth checking.

As you have a dd backup of the disk, you can try to run those recovery tools I've mentioned on it (configured via mdconfig). Other than that it seems it will be a trial-error approach.


----------



## SkymanScott (Jun 28, 2011)

*data recovery (was ntfs-3g mount problem)*

matoatlantis,

Your guidance to double check the disk was helpful.  I found jumper settings causing the problem.  I am now able to get the full GB storage recognized from the disk.  Progress!

I made new backup copies of the data from ad2 and ad3 as 'oldbsd_boot' and 'oldbsd_data' on the external USB drive.  I can successfully *fsck* slice one of both copies but run into SUPERBLOCK errors on ad3s3 where the data is.  Not sure if it's a command issue or a vinum issue.  Do you think I can get at that slice 3 data without vinum?

Also, booting on the new BSD setup, vinum isn't there but gvinum is.  I have not spent much time with that since I was working on getting the full disk configuration in order over the weekend.

Here is the new fdisk and gpart results.  Do you see anything noteworthy?  Thank you.  Scott


```
******* Working on device /dev/ad2 *******
parameters extracted from in-core disklabel are:
cylinders=159560 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=159560 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 254/ head 15/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 257040, size 64260 (31 Meg), flag 80 (active)
	beg: cyl 255/ head 0/ sector 1;
	end: cyl 318/ head 11/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 321300, size 159702165 (77979 Meg), flag 80 (active)
	beg: cyl 318/ head 12/ sector 1;
	end: cyl 1023/ head 6/ sector 63
The data for partition 4 is:
<UNUSED>

******* Working on device /dev/ad3 *******
parameters extracted from in-core disklabel are:
cylinders=159560 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=159560 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 254/ head 15/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 257040, size 64260 (31 Meg), flag 80 (active)
	beg: cyl 255/ head 0/ sector 1;
	end: cyl 318/ head 11/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 321300, size 159702165 (77979 Meg), flag 80 (active)
	beg: cyl 318/ head 12/ sector 1;
	end: cyl 1023/ head 6/ sector 63
The data for partition 4 is:
<UNUSED>

gpart show
=>      63  12594897  ad0  MBR  (6.0G)
        63    204057    1  freebsd  (100M)
    204120  12390840    2  freebsd  [active]  (5.9G)

=>     63  6346305  ad1  MBR  (3.0G)
       63  6346305    1  freebsd  [active]  (3.0G)

=>     0  204057  ad0s1  BSD  (100M)
       0  204057      2  freebsd-swap  (100M)

=>       0  12390840  ad0s2  BSD  (5.9G)
         0  12390840      1  freebsd-ufs  (5.9G)

=>      0  6346305  ad1s1  BSD  (3.0G)
        0  6346305      4  freebsd-ufs  (3.0G)

=>       63  160836417  ad3  MBR  (77G)
         63     256977    1  freebsd  [active]  (125M)
     257040      64260    2  freebsd  [active]  (31M)
     321300  159702165    3  freebsd  [active]  (76G)
  160023465     813015       - free -  (397M)

=>     0  256977  ad3s1  BSD  (125M)
       0  256977      1  freebsd-ufs  (125M)

=>    0  64260  ad3s2  BSD  (31M)
      0  64260      2  freebsd-vinum  (31M)

=>        0  159702165  ad3s3  BSD  (76G)
          0  159702165      1  freebsd-vinum  (76G)

=>       63  160836417  ad2  MBR  (77G)
         63     256977    1  freebsd  [active]  (125M)
     257040      64260    2  freebsd  [active]  (31M)
     321300  159702165    3  freebsd  [active]  (76G)
  160023465     813015       - free -  (397M)

=>     0  256977  ad2s1  BSD  (125M)
       0  256977      1  freebsd-ufs  (125M)

=>    0  64260  ad2s2  BSD  (31M)
      0  64260      2  freebsd-vinum  (31M)

=>        0  159702165  ad2s3  BSD  (76G)
          0  159702165      1  freebsd-vinum  (76G)

=>     0  256977  ufsid/3a2e446437e784ab  BSD  (125M)
       0  256977                       1  freebsd-ufs  (125M)

=>       34  975400893  da0  GPT  (465G)
         34          6       - free -  (3.0K)
         40     409600    1  efi  (200M)
     409640  974729136    2  apple-hfs  (465G)
  975138776     262151       - free -  (128M)
```


----------



## _martin (Jul 7, 2011)

Perfect, glad to see a progress on this issue. 

As I mentioned earlier, vinum was rewritten and it might be that vinum and gvinum are not compatible. 

In your case I would stick to old vinum - that means either boot old FreeBSD or install a fresh copy of 4.x FreeBSD if you can't get working the old one. I'd say vinum checks have to be first, then you can perform a check on LV (logical volume). So no, I don't think you can get to the data without vinum up first.

How does the old FreeBSD boot behave now, with the correct jumper settings? Point is to get to the system and do the vinum checks within.



			
				SkymanScott said:
			
		

> I made new backup copies of the data from ad2 and ad3 as 'oldbsd_boot' and 'oldbsd_data'



I don't think you have "boot" on ad2 and "data" on ad3 - they are part of the vinum - either mirror or RAID5 (or something in that sense).


----------



## SkymanScott (Jul 7, 2011)

While I can now boot the old disk, the hardware tech and the user do not remember the root password.  I will load a new 4.11 version on the spare disk and then attach the old disks to see if I can get vinum operating in that fashion, since the 8.2 install made some progress this way.

More details to follow.

Thank you,
Scott


----------



## _martin (Jul 7, 2011)

If the root password is the show stopper, you can actually change it. Or at least try as it depends how the system was configured (should be possible by default). 
Reboot the system and escape to the boot prompt and/or press "3" to boot to single mode. If you escape to prompt (#6), you can boot to single mode with: 

`# boot -s`

Press enter to get to the /bin/sh. Note that minimal PATH is set. You can either extend it or use full path when executing commands. 

You will see that / is mounted read-only. Remount it to read-write. Then set new password for root and reboot again. To sum up:

1) reboot
2) boot to single mode (#3 or #6 to prompt)
3) remount, change the password

`# /sbin/mount -o rw /`
`# /usr/bin/passwd`

```
Changing local password for root
New Password:
Retype new Password:
```
4) type exit to continue booting or reboot

Note I'm assuming / is one big filesystem, i.e. /usr is the same filesystem as / (which seems so).


----------



## wblock@ (Jul 7, 2011)

`# mount -u /`
is a little shorter.


----------



## SkymanScott (Jul 24, 2011)

Thank you.  I am working further on this after being detained for a couple weeks.

Scott


----------



## SkymanScott (Jul 26, 2011)

*Data Recovery (was ntfs-3g mount problem)*

Here is the next chapter of this endeavor, but first, thanks for your ongoing assistance.   

No menu appears on the boot process, so the task of hitting any key and typing /kernel -s at the boot prompt got me to single user, no problem.  And no problem doing an /sbin/mount -o rw / to mount the file system as writable.  

But...  there is no /usr/bin/passwd file to execute in order to change the root password.  Doing a find / -name 'passwd' -print shows only /etc/passwd.  Substituting 'p*' for 'passwd' shows the file /usr/bin/perl and /usr is populated with other commands also.  

This configuration appears non-standard, since it was in a customized First Alliance network server when it was operational.  Booting on the newly established disk and copying the file over does not work out with various /usr/lib libraries missing.  Maybe there's another reason that the passwd command is not located.

On another note, when booting in single user mode, the following messages appear, perhaps because the full system is not booted.


```
vinum: loaded
SYNO:DRIVE:3:/dev/ad0 /dev/ad1 /dev/ad2
vinum:no drives found
Mounting root from ufs:ad0s1a
enter full pathname of shell or RETURN for /bin/ksh
```

which is not necessarily an issue compared to the inability to login.

I was hoping to get at a slice or partition to access the 'lost' data without being constrained to vinum  operations and have some way to get around the partial corruption of some of the other partitions.

Any further ideas or thoughts as I appear to reach the end of the road on this recovery attempt?

Regards,
Scott


----------



## _martin (Jul 31, 2011)

Strange that passwd is missing. Try to use vipw(8) and remove the root's password completely (2nd column, ":" is a separator) in the single mode. You should be able to login as root without password then. If you still have a problem, it might be worth installing fresh 4.x FreeBSD. 

But what is more to your concern is: 

```
vinum: loaded
SYNO:DRIVE:3:/dev/ad0 /dev/ad1 /dev/ad2
[color="Red"][B]vinum:no drives found[/B][/color]
Mounting root from ufs:ad0s1a
enter full pathname of shell or RETURN for /bin/ksh
```

Judging from your previous posts this was not a problem - vinum did detect volumes before. Did you change something?


----------



## SkymanScott (Aug 1, 2011)

*Re: Data Recover (was ntfs-3g mount problem)*

Nothing changed on the original disks.  Your reference to vinum being detected in a prior post was from the new BSD boot disk with gvinum recognizing them, not the original boot disk.  And the other reference was from a file called ExistVinum showing prior status with the related corruption, apparently from a lightning strike, I'm told.  :\  This 'new' message output is what happens on trying to boot the original disks, not related to the prior posting. 

I did try to edit the passwd file with vi but the terminal settings in single user mode are invalid.  I will try the vipw command to see if it works any better.  but this does not deal with the subsequent problem.  I can try to boot from the new disk, but it appears as though I'm going in circles with this.

Thank you.
Scott


----------



## SkymanScott (Aug 12, 2011)

*Data Recovery (was ntfs-3g mount problem)*

Back to another round of trying to get at vinum data.  The newer 8.2 FreeBSD environment did recognize the vinum partitions but various incompatibilities of using gvinum on a 4.11 FreeBSD vinum environment brought us back to 4.11.  As we've seen, that new boot configuration of 4.11 does not recognize ad0, ad1, or ad2.  It's a "catch 22". 

Mounting /dev/ad0s1a or /dev/ad0s1c (plus ad1, ad2, etc) on each of the three disks to olddisk0, olddisk1, olddisk2, I can look at the /etc/fstab of the old system.  There I find /dev/vinum/vinum1  /  ufs

I've taken the approach to try and mount this file system to another file system directory in the newly installed 4.11 FreeBSD.
`mount  -t ufs  /olddisk0/dev/vinum/vinum1  /tmpmnt` 

```
device busy, invalid ioctl from process XXX
```

Researching this, I find that this is potentially caused by vinum being compiled without the -DVINUMDEBUG option in both /usr/src/sbin/vinum/Makefile  and /usr/src/sys/modules/vinum/Makefile  Compiling these two items and rebooting the system still produces the same ioctl error message.  I'm at a standstill on this. 

Looking at the directories for vinum configuration, I see the following:

`ls -l /dev/vinum/plex`

```
vinum0.p0
vinum1.p0
```
`ls -l /dev/vinum/sd`

```
vinum0.p0.s0
vinum0.p0.s1
vinum0.p0.s2
vinum1.p0.s0
vinum1.p0.s1
vinum1.p0.s2
```
`ls -l /dev/vinum/vol`

```
vinum0.plex
vinum1.plex
```

Going into vinum and trying the command
`start`

```
device busy
```

Three various attempts, three strikes against.

Any other thoughts on getting at this data?

Thank you.
Scott


----------



## _martin (Aug 17, 2011)

I must say I'm little bit confused - I thought those disks were used on 4.x - I would expect it to recognize them then (original boot disk). 

By the look of it, I would say gvinum recognized volumes but can't work with old vinum devices - hence the ioctl error (as mentioned earlier, old/new versions are not compatible).

I don't have any experience with old vinum, I'm afraid I can't help you more.


----------

