Crash on boot

[korrupto77]

Hi Gents,

i'm facing up with a serious issue with Freenas 11, on boot up it crash on "Beginning ZFS volume imports . I really appreciate your help in order to solve this issue. My family is suffering like stone age due to lack of multimedia .

Thanks

 

[dlavigne]

Try installing the same version on a different USB stick. If that boots, you can restore a copy of your previously saved config.

 

[rs225]

If that doesn't work, the pool may have some kind of corruption. A memtest should be run on the system. After that, the next step would be attempting to import the pool in readonly mode.

 

[korrupto77]

Thanks for replies, i tried to import from another system as Dlavigne said but same it reboot during importation ... i ll try men test

 

[korrupto77]

If that doesn't work, the pool may have some kind of corruption. A memtest should be run on the system. After that, the next step would be attempting to import the pool in readonly mode.

Thanks for reply, I've done memtest for many hours and no errors have been highlighted; what can happened ?? how do i recover the pool ?

 

[rs225]

The crash error you posted showed an assertion failure. (0 does not equal 16)

That can indicate that a single bit flip happened and went into the metadata. Was the RAM ECC? In any case, the data doesn't make sense and this generates a panic.

You want the drives in a system that will not try to import the pool on boot. Once you have a system that boots up without trying to access the pool, you can try a read-only import from the command line/shell. Readonly avoids some areas of the pool metadata; maybe it will avoid this problem.

zpool import -o readonly=on poolName

If it says the pool was imported on another system, try zpool import -f -o readonly=on poolName

If that succeeds, then you should be able to get the data off the pool before you destroy it and create a new one.

 

[korrupto77]

The crash error you posted showed an assertion failure. (0 does not equal 16)

That can indicate that a single bit flip happened and went into the metadata. Was the RAM ECC? In any case, the data doesn't make sense and this generates a panic.

You want the drives in a system that will not try to import the pool on boot. Once you have a system that boots up without trying to access the pool, you can try a read-only import from the command line/shell. Readonly avoids some areas of the pool metadata; maybe it will avoid this problem.

zpool import -o readonly=on poolName

If it says the pool was imported on another system, try zpool import -f -o readonly=on poolName

If that succeeds, then you should be able to get the data off the pool before you destroy it and create a new one.

no i'm not using ECC RAM, i'm trying right now the procedure you suggested... i hope it will work ..

 

[korrupto77]

The crash error you posted showed an assertion failure. (0 does not equal 16)

That can indicate that a single bit flip happened and went into the metadata. Was the RAM ECC? In any case, the data doesn't make sense and this generates a panic.

You want the drives in a system that will not try to import the pool on boot. Once you have a system that boots up without trying to access the pool, you can try a read-only import from the command line/shell. Readonly avoids some areas of the pool metadata; maybe it will avoid this problem.

zpool import -o readonly=on poolName

If it says the pool was imported on another system, try zpool import -f -o readonly=on poolName

If that succeeds, then you should be able to get the data off the pool before you destroy it and create a new one.

No way it says "Cannot mount / ...." i think my pool is gone

 

[rs225]

Try zpool import -o readonly=on -R /mnt poolName or the -f variant if needed.

If those errors don't occur, look in the /mnt directory to see if data is there.

 

[korrupto77]

The crash error you posted showed an assertion failure. (0 does not equal 16)

That can indicate that a single bit flip happened and went into the metadata. Was the RAM ECC? In any case, the data doesn't make sense and this generates a panic.

You want the drives in a system that will not try to import the pool on boot. Once you have a system that boots up without trying to access the pool, you can try a read-only import from the command line/shell. Readonly avoids some areas of the pool metadata; maybe it will avoid this problem.

zpool import -o readonly=on poolName

If it says the pool was imported on another system, try zpool import -f -o readonly=on poolName

If that succeeds, then you should be able to get the data off the pool before you destroy it and create a new one.

Try zpool import -o readonly=on -R /mnt poolName or the -f variant if needed.

If those errors don't occur, look in the /mnt directory to see if data is there.

No way i got in both case errors, luckly i have an exact copy of pool and i've already restored data. How do i prevent this kind of errors, my MB doesn't support ECC ?

 

[MrToddsFriends]

No way i got in both case errors, luckly i have an exact copy of pool and i've already restored data. How do i prevent this kind of errors, my MB doesn't support ECC ?

1) Try to use less demanding memory timings
2) Try to re-seat the RAM modules
3) Use less than four memory modules and swap them once in a while to find out which of the modules (or motherboard sockets) is the offending one
4) Swap the CPU to see if this is the culprit
5) Use recommended hardware

Acting out options 1), 2), 3) and 4) as a whole may be time-consuming and cumbersome as --- if I understand it correctly --- the problem occurs sporadically. On memtest: If memtest reports an error you can be sure that there is a hardware problem. On the other hand if memtest doesn't report anything this does not mean that there will never occur any related problems (that may depend on memory access patterns or whatsoever).