Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

Woke up to drive pool not found this morning. At a loss as to what to do? Any suggestions would be welcomed!

Quazione

Newbie
Joined
Jan 2, 2019
Messages
3
I was having issues keeping the system running. So turned the system off, and ran a memory test, and replaced memory. When I rebooted the pool is unknown, and this is in the log file. Could booting from a CD and Running a memory test mess with the Headers on each drive???? How is that possible.



Jul 7 05:59:04 CSS-NAS-12TB Trying to mount root from zfs:freenas-boot/ROOT/11.3-U5 []...
Jul 7 05:59:04 CSS-NAS-12TB GEOM: ada1: the secondary GPT header is not in the last LBA.
Jul 7 05:59:04 CSS-NAS-12TB GEOM_PART: integrity check failed (ada1, GPT)
Jul 7 05:59:04 CSS-NAS-12TB GEOM: ada2: the secondary GPT header is not in the last LBA.
Jul 7 05:59:04 CSS-NAS-12TB GEOM_PART: integrity check failed (ada2, GPT)
Jul 7 05:59:04 CSS-NAS-12TB GEOM: ada3: the secondary GPT header is not in the last LBA.
Jul 7 05:59:04 CSS-NAS-12TB GEOM_PART: integrity check failed (ada3, GPT)
Jul 7 05:59:04 CSS-NAS-12TB GEOM: ada4: the secondary GPT header is not in the last LBA.
Jul 7 05:59:04 CSS-NAS-12TB GEOM_PART: integrity check failed (ada4, GPT)


I have attached the log file, and yes I know there are some bad sectors on ada3 but it has been that way since I built it, and has worked fine for over 11 months.

I also just read that if you boot off a windows device which is what I did to run a memory test it can disturb the drives in the pool, That just seems ridiculous that would even be allowed to happen. but I did boot off a windows CD to run a memory test. After reading some of the posts I am now totally freaking out!!!! hope someone can calm my nerves.
 

Attachments

John Digital

Neophyte Sage
Joined
Jan 7, 2015
Messages
949
From the gpart manpage

RECOVERING
The GEOM PART class supports recovering of partition tables only for GPT. The GPT primary metadata is stored at the beginning of the device. For redundancy, a secondary (backup) copy of the metadata is stored at the end of the device. As a result of having two copies, some corruption of metadata is not fatal to the working of GPT. When the kernel detects corrupt metadata, it marks this table as corrupt and reports the problem. destroy and recover are the only operations allowed on corrupt tables.
If one GPT header appears to be corrupt but the other copy remains intact, the kernel will log the following:

GEOM: provider: the primary GPT table is corrupt or invalid.
GEOM: provider: using the secondary instead -- recovery strongly advised.
or

GEOM: provider: the secondary GPT table is corrupt or invalid.
GEOM: provider: using the primary only -- recovery suggested.
Also gpart commands such as show, status and list will report about corrupt tables.

If the size of the device has changed (e.g., volume expansion) the secondary GPT header will no longer be located in the last sector. This is not a metadata corruption, but it is dangerous because any corruption of the primary GPT will lead to loss of the partition table. This problem is reported by the kernel with the message:

GEOM: provider: the secondary GPT header is not in the last LBA.
This situation can be recovered with the recover command. This command reconstructs the corrupt metadata using known valid metadata and relocates the secondary GPT to the end of the device.

NOTE: The GEOM PART class can detect the same partition table visible through different GEOM providers, and some of them will be marked as corrupt. Be careful when choosing a provider for recovery. If you choose incorrectly you can destroy the metadata of another GEOM class, e.g., GEOM MIRROR or GEOM LABEL.
This seems like what you should be exploring. Ive heard of accidentally booting Windows has borked things before..
 

Patrick M. Hausen

Dedicated Sage
Joined
Nov 25, 2013
Messages
3,376
Please post the output of these commands:
Code:
camcontrol devlist
gpart list
zpool import
 

Quazione

Newbie
Joined
Jan 2, 2019
Messages
3
root@CSS-NAS-12TB[~]# camcontrol devlist
<OCZ-VERTEX3 2.15> at scbus0 target 0 lun 0 (pass0,ada0)
<ASUS DRW-2014L1T 1.02> at scbus1 target 0 lun 0 (pass1,cd0)
<WDC WD30EZRX-32D8PB0 80.00A80> at scbus10 target 0 lun 0 (pass2,ada1)
<WDC WD30EZRX-32D8PB0 80.00A80> at scbus11 target 0 lun 0 (pass3,ada2)
<WDC WD30EZRX-00SPEB0 80.00A80> at scbus12 target 0 lun 0 (pass4,ada3)
<WDC WD30EZRX-00SPEB0 80.00A80> at scbus13 target 0 lun 0 (pass5,ada4)
<AHCI SGPIO Enclosure 2.00 0001> at scbus16 target 0 lun 0 (pass6,ses0)
root@CSS-NAS-12TB[~]#

root@CSS-NAS-12TB[~]# gpart list
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 234441607
first: 40
entries: 128
scheme: GPT
Providers:
1. Name: ada0p1
Mediasize: 524288 (512K)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0
efimedia: HD(1,GPT,a9b0816e-0c77-11e9-b7a8-c860000a8a4e,0x28,0x400)
rawuuid: a9b0816e-0c77-11e9-b7a8-c860000a8a4e
rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
label: (null)
length: 524288
offset: 20480
type: freebsd-boot
index: 1
end: 1063
start: 40
2. Name: ada0p2
Mediasize: 120033558528 (112G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1
efimedia: HD(2,GPT,a9b18990-0c77-11e9-b7a8-c860000a8a4e,0x428,0xdf94760)
rawuuid: a9b18990-0c77-11e9-b7a8-c860000a8a4e
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 120033558528
offset: 544768
type: freebsd-zfs
index: 2
end: 234441607
start: 1064
Consumers:
1. Name: ada0
Mediasize: 120034123776 (112G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e2

root@CSS-NAS-12TB[~]#zpool import
root@CSS-NAS-12TB[~]
 

Patrick M. Hausen

Dedicated Sage
Joined
Nov 25, 2013
Messages
3,376
So you somehow wiped the partition tables from all your disks - ada1 to ada4. I am not sure if this is recoverable.
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
2,801
Try @John Digital's suggestion of gpart recover on all your drives ada1-4. This may be able to restore the partition table at least. It's likely the ZFS partitions are still there, but the GPT partition table has been lost. If that doesn't work, then you may need to use gparted on Linux to reconstruct your GPT.
 
Top