Recover FreeNas Configuration From OS Drive

[BoogaBooga]

Hi,

Ive had freenas running for about a year without any problems, but now it won't boot and I suspect that the USB drive is wonky:

shared object "libedit.so.7" not found, required by sh.

Is it possible to mount the drive on a different computer to recover the FreeNas configuration?

Also can anyone recommend a reliable USB flash drive?

 

[jgreco]

Seen that happen. It is like the USB device slowly rots. There are some unexplained things that seem to happen with writes, etc. that were made somewhat better when /data got the noatime flag added. Quite frankly I think many USB keys are meant for a total of a dozen writes cycles.

Assuming the file is still intact, it should be recoverable. Here's basically what ought to work (please let me know either way, this is off-the-top-of-my-head)

1) Install FreeNAS on a new flash. You need the SAME revision, etc., you were running. This avoids "upgrade" complications.

2) Boot into it and don't do any configuration.

3) On the console, select the option to go to shell.

4) Insert your old USB key in a second USB port.

You will probably get a kernel message indicating that a new device has been added, and it'll probably tell you that it is "da1" or something like that. You need that information. If it doesn't, try running "camcontrol devlist" to see if two USB keys are shown. The first one will be the running OS.

So now here's the tricky part. The configuration is stored on slice 4. So if you have "da1", then it is on "da1s4".

5) Make a temporary mountpoint: "mkdir /var/tmp/cfgmount"

6) Mount it. "mount -o ro /dev/da1s4 /var/tmp/cfgmount"

7) Now if you're feeling daring, what you can do next is to just do "cp /var/tmp/cfgmount/freenas_v1.db /data/freenas_v1.db" and then reboot. Remember to pull the old USB key to eliminate boot order confusion.

 

[BoogaBooga]

Thanks jgreco!

That did it! I guess I have to start backing up the configuration somewhere else more often in case the USB drive fails all together.

For those wondering, the failed USB flash was an 8gb Kingston Data Traveler 2.0.

 

[jgreco]

There are scripts available that will back it up to your pool.

forums.freenas.org/showthread.php?10735-How-to-automate-FreeNAS-configuration-database-backup

 

[Tram]

Seen that happen. It is like the USB device slowly rots. There are some unexplained things that seem to happen with writes, etc. that were made somewhat better when /data got the noatime flag added. Quite frankly I think many USB keys are meant for a total of a dozen writes cycles.

Assuming the file is still intact, it should be recoverable. Here's basically what ought to work (please let me know either way, this is off-the-top-of-my-head)

1) Install FreeNAS on a new flash. You need the SAME revision, etc., you were running. This avoids "upgrade" complications.

2) Boot into it and don't do any configuration.

3) On the console, select the option to go to shell.

4) Insert your old USB key in a second USB port.

You will probably get a kernel message indicating that a new device has been added, and it'll probably tell you that it is "da1" or something like that. You need that information. If it doesn't, try running "camcontrol devlist" to see if two USB keys are shown. The first one will be the running OS.

So now here's the tricky part. The configuration is stored on slice 4. So if you have "da1", then it is on "da1s4".

5) Make a temporary mountpoint: "mkdir /var/tmp/cfgmount"

6) Mount it. "mount -o ro /dev/da1s4 /var/tmp/cfgmount"

7) Now if you're feeling daring, what you can do next is to just do "cp /var/tmp/cfgmount/freenas_v1.db /data/freenas_v1.db" and then reboot. Remember to pull the old USB key to eliminate boot order confusion.

Thanks jgreco for this, saved me hours of re-configuration after my USB drive started failing and wouldn't boot any longer.
Worked perfectly after the reboot. All plugins besides one recovered and working too!

 

[jgreco]

Great to hear it. That advice may predate jails but the overall strategy is still correct.

 

[Dagwood08]

Thanks jgreco. I too used this procedure to get things back up and running after a power outage seemed to kill my USB stick. Definitely going to take precautions going forward to make sure I have a backup available, or perhaps get a UPS - or both.

 

[bigshow]

I am trying to do the same thing, but I get the following error when trying to mount da1s4 no such file or directory. I am trying to recover a 9.3 configuration. Any help to recover a 9.3 config would be much appreciated. I see /dev/da1, /dev/da1p1, and /dev/da1p2.

 

[bigshow]

I assume the issue might be that the OS is using zfs. Is there a way to mount the old zfs OS usb to copy freenas_v1.db?

 

[Bidule0hm]

Yes, look at this thread: https://forums.freenas.org/index.php?threads/recover-configure-from-failing-boot-device.28032/ ;)

 

[bigshow]

Thanks for the help. I am able to import and mount the old zfs usb, but nothing is in the mount directory. I get no errors after mounting and I am able to unmount just fine, but the directory is empty where I mount. The zpool list command shows the oldboot allocation so there should be files there. Could there be a permissions issue on why I cant see the files?

 

[Bidule0hm]

Interresting...

You've mounted it with another name than freenas-boot, right?

Also, are you connected with the root user?

 

[bigshow]

Yes, its named oldboot and as root.

 

[Bidule0hm]

I'm puzzled...

If you go to /mnt/oldboot and do a ls -la what's the result?

 

[BlazeStar]

Seen that happen. It is like the USB device slowly rots. There are some unexplained things that seem to happen with writes, etc. that were made somewhat better when /data got the noatime flag added. Quite frankly I think many USB keys are meant for a total of a dozen writes cycles.

Assuming the file is still intact, it should be recoverable. Here's basically what ought to work (please let me know either way, this is off-the-top-of-my-head)

1) Install FreeNAS on a new flash. You need the SAME revision, etc., you were running. This avoids "upgrade" complications.

2) Boot into it and don't do any configuration.

3) On the console, select the option to go to shell.

4) Insert your old USB key in a second USB port.

You will probably get a kernel message indicating that a new device has been added, and it'll probably tell you that it is "da1" or something like that. You need that information. If it doesn't, try running "camcontrol devlist" to see if two USB keys are shown. The first one will be the running OS.

So now here's the tricky part. The configuration is stored on slice 4. So if you have "da1", then it is on "da1s4".

5) Make a temporary mountpoint: "mkdir /var/tmp/cfgmount"

6) Mount it. "mount -o ro /dev/da1s4 /var/tmp/cfgmount"

7) Now if you're feeling daring, what you can do next is to just do "cp /var/tmp/cfgmount/freenas_v1.db /data/freenas_v1.db" and then reboot. Remember to pull the old USB key to eliminate boot order confusion.

I've been trying that.

I've started a thread here:
https://forums.freenas.org/index.php?threads/cant-reboot-after-power-loss.28530/

I don't mean to "crosspost" or anything but I'm quite panicking with my USB key giving up on me :S

I'm on 9.2.1.9 x64

My USB key is:

Code:

[root@freenas] /var/tmp/cfgmount# camcontrol devlist
<Kingston DataTraveler G3 PMAP>    at scbus9 target 0 lun 0 (pass8,da5)

Then:

Code:

[root@freenas] /var/tmp/cfgmount# mount -o ro /dev/da5s4 /var/tmp/cfgmount
mount: /dev/da5s4: Invalid argument

Does this mean my USB key is dead ?

At this point I don't know what to do and, OF COURSE, I don't have a recent config file.

I guess the config doesn't get transfered up with replication right?

Because I do have a very recent replication on a different system.

 

[jgreco]

What does "fdisk da5" show? This dumps the partition table.

Code:

# fdisk da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=287 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=287 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:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 1930257 (942 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 890/ head 15/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 1930383, size 1930257 (942 Meg), flag 0
        beg: cyl 891/ head 1/ sector 1;
        end: cyl 757/ head 15/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 3860640, size 3024 (1 Meg), flag 0
        beg: cyl 758/ head 0/ sector 1;
        end: cyl 760/ head 15/ sector 63
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 3863664, size 41328 (20 Meg), flag 0
        beg: cyl 761/ head 0/ sector 1;
        end: cyl 801/ head 15/ sector 63

Should look something like that.

 

[cyberjock]

I think the problem with ZFS and USB is that ZFS expects writes to occur within a specific time frame. USB drives routinely have random write speeds measured in single digit MB/sec. A system like mine (32GB of RAM) could easily queue up 1GB of writes in a second or two for the USB stick. Guess what happens when you have to write 1GB of data to a a USB stick at 2MB/sec.

I saw a post a few days ago about the fastest random-write USB stick that could be found. It was something like 4MB, with dozens of USB sticks not even able to do 1MB/sec.

I'm of the opinion that USB sticks as boot devices is coming to an end without something changing. (preferably the performance of USB!)

 

[BlazeStar]

What does "fdisk da5" show? This dumps the partition table.

Code:

# fdisk da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=287 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=287 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:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 1930257 (942 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 890/ head 15/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 1930383, size 1930257 (942 Meg), flag 0
        beg: cyl 891/ head 1/ sector 1;
        end: cyl 757/ head 15/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 3860640, size 3024 (1 Meg), flag 0
        beg: cyl 758/ head 0/ sector 1;
        end: cyl 760/ head 15/ sector 63
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 3863664, size 41328 (20 Meg), flag 0
        beg: cyl 761/ head 0/ sector 1;
        end: cyl 801/ head 15/ sector 63

Should look something like that.

Here goes:

Code:

fdisk /dev/disk5
Disk: /dev/disk5    geometry: 970/128/63 [7826688 sectors]
Signature: 0xAA55
         Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
*1: A5    0   1   1 -  890  15  63 [        63 -    1930257] FreeBSD    
2: A5  891   1   1 -  757  15  63 [   1930383 -    1930257] FreeBSD    
3: A5  758   0   1 -  760  15  63 [   3860640 -       3024] FreeBSD    
4: A5  761   0   1 -  801  15  63 [   3863664 -      41328] FreeBSD  

 

[jgreco]

It'd be better to do it from another FreeNAS image. Looks like the partition's there though. A "df /dev/da5s4" would be interesting too, see if it's vaguely readable.

 

[Bert Rolston]

This worked for me too.
I was looking for a solution to another problem on
https://forums.freenas.org/index.ph...-errors-after-restart-bad-marshal-data.28609/

This made it easy for me to decide on a clean install and restore the config from the old USB drive. :)

Thanks
Bert