ZFS Primary GPT table is corrupt or invalid.

decuser

decuser

Apparently, I created a zpool mirror on two external usb-sata drives without getting rid of the GPT stuff first and wound up with this:

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

Looking around the forums, I see lots of talk about it having to do with ZFS not using the entire disk, zeroing out the last 34 blocks, that being complicated, don't do it without a backup, yada, yada, yada. I'm just not clear on whether or not it's a real problem. I gather ZFS knows what it's doing and that the geom probing that the kernel does on startup doesn't, in this case (it thinks there's missing gpt partition info).

Is this a real problem or can I safely ignore it until the end of time? If not, I can blow away the mirror and redo things (it's there to test out the ssd's anyway), how do I do it so I don't wind up with this situation in the first place?
 
I think you can destroy the pool (maybe zpool labelclear also), then gpart destroy on both drive. Once done, you can recreate the pool.

But, I believe the best way to make a pool is to use freebsd-zfs partitions inside a GPT scheme. So, any software recognizes a GPT scheme without going into reading zfs stuff (and probably doesn't understand it).
 
decuser said:
I'm just not clear on whether or not it's a real problem.
Click to expand...
decuser said:
Is this a real problem or can I safely ignore it until the end of time?
Click to expand...
In your case, it becomes a real problem if the secondary GPT table also gets corrupted.

As the gpart(8) manual and the error message advises a recover operation can correct the tables.
Code: 
   recover       Recover a corrupt partition's scheme metadata on the geom
                   geom.  See the section entitled RECOVERING below for the
                   additional information.

                   The recover command accepts these options:

                   -f flags    Additional operational flags.  See the section
                               entitled OPERATIONAL FLAGS below for a
                               discussion about its use.
...
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.

I made it a habit of backing up partition tables regularly as well as /var/backups.

The other day I was rearranging the partitions of one system, most of them geli(8) providers. One partition I deleted prematurely, before backing up the content. With the help of the backed up partition table and geli(8) key I could restore access to the content of the encrypted provider.
 
T-Daemon, the question is what GPT partition? There shouldn't be one. I gave ZFS the whole disk. To Emrion 's point, maybe it's better to put ZFS on a partition, but I don't usually...:

Code: 
zpool create segundo mirror da0 da1

or do I get one that's wonk, even without asking for one?
 
If the whole disk was added to a ZFS pool then there shouldn't be a partition table. Both ZFS and GPT partition table write some data at the end of the disk. They keep overwriting each other's meta data (that's why the partition table is marked as "CORRUPT").
Click to expand...
I was accidentally added the whole disk to a zfs pool and i experienced this issue.
 
Emrion said:
Concerning ZFS, whole disk or partition, it's not only my point but also the one of bsdimp:

From: https://discord.com/channels/727023752348434432/757305697527398481/1189601794268082238
Click to expand...
After several "confirm you're human dialogs", try again, and please confirm your date of birth... eventually took me to a register your own discord server or join a channel, when I pasted the URL, it said something about invalid link. I'm sure the link takes you to a post if you're a member of the channel it links to, otherwise, it's worse than a paywall. Let's just say... I'm not a discord fan and this is a big contributor to my view on it...
 
I started experimenting with ZFS last year and from (possibly faulty!) memory yes, you get this message if you confuse geom by giving the whole disk to ZFS.

At that point I redid my set-up with GPT partitions. As you say, it's hard to tell if it's a message you can safely ignore, so using GPT seems to make it (and ZFS) happier.

I don't think you want to try and recover anything - that will just be geom and ZFS fighting over some sectors at the end of your drive. Which does not seem like a good idea.
 
decuser said:
After several "confirm you're human dialogs", try again, and please confirm your date of birth... eventually took me to a register your own discord server or join a channel, when I pasted the URL, it said something about invalid link. I'm sure the link takes you to a post if you're a member of the channel it links to, otherwise, it's worse than a paywall. Let's just say... I'm not a discord fan and this is a big contributor to my view on it...
Click to expand...
I had to register the first time. That leads to the FreeBSD discord and the post I copied. Not fan of discord as well.

To rephrase my point, if you use GPT and create a freebsd-zfs partition that takes all the place left on the disk, you won't have any complaint of geom or whatever software because GPT is a well known standard whereas ZFS isn't. Doing like that, you protect your zfs data inside GPT.
 
bsdimp was responding to me:

1708201062039.png


decuser said:
… if you're a member of the channel …
Click to expand...

Channel membership is not a thing.

If anyone needs help with Discord:

forums.freebsd.org

Solved - The FreeBSD server at discord.com

offers an invitation (to join) that requires acceptance every time: The context menu for the FreeBSD server does not offer a link to the server: Before I add this to the wiki, a question for people who are already members: does the link below take you, reliably, to the lobby? Thanks...
forums.freebsd.org forums.freebsd.org
 
grahamperrin said:
bsdimp was responding to me:

View attachment 18220



Channel membership is not a thing.

If anyone needs help with Discord:

forums.freebsd.org

Solved - The FreeBSD server at discord.com

offers an invitation (to join) that requires acceptance every time: The context menu for the FreeBSD server does not offer a link to the server: Before I add this to the wiki, a question for people who are already members: does the link below take you, reliably, to the lobby? Thanks...
forums.freebsd.org forums.freebsd.org
Click to expand...
Hi Graham,

Well, now it works. Prolly cuz I logged in before I clicked the link from an account that subscribed to FreeBSD.... Hmmm... still not a fan, but at least it took me somewhere rational this time :).

Will
 
I eventually took the advice and rebuilt the mirror, but this time on a ufs partitions taking the whole disk. No more corruption warnings. I don't particularly care one way or the other whether or not it's zfs taking the whole disk or zfs sitting on a partition taking the whole disk. It seems to work for snapshots and restores just fine. It's just kinda weird that zfs and gpt would fight over the last blocks of the disk. Even though, in principle, one shouldn't care about the other, how hard would it be for them to get along?
 
You must log in or register to reply here.
Back
Top