ntfs-3g mount problem

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:

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

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

Code: 
******* 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)
 
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'
Click to expand...

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).
 
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
 
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
Code: 
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).
 
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.

Code: 
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
 
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:
Code: 
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?
 
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
 
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
Code: 
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
Code: 
vinum0.p0
vinum1.p0
ls -l /dev/vinum/sd
Code: 
vinum0.p0.s0
vinum0.p0.s1
vinum0.p0.s2
vinum1.p0.s0
vinum1.p0.s1
vinum1.p0.s2
ls -l /dev/vinum/vol
Code: 
vinum0.plex
vinum1.plex

Going into vinum and trying the command
start
Code: 
 device busy

Three various attempts, three strikes against.

Any other thoughts on getting at this data?

Thank you.
Scott
 
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.
 
You must log in or register to reply here.
Back
Top