ZFS partition lost UUID / PARTUUID

Question

I have a NAS with a 4TB HDD with 2 partitions: one swap and other ZFS. The second partition has disappeared from the NAS, and isn't listed in blkid or /dev/*. gparted recognizes the partition as /dev/sdb2, but it has no UUID, and so zpool can't import it.

I have tried cloning the start of the HDD to a smaller one (dd to copy the first 40GB, sgdisk to copy the partition table). The second partition now shows up under /dev/sdc2 and has an UUID (the expected one), but it doesn't have a PARTUUID. zpool import can now recognize this second cloned drive, but it throws an I/O error when I try to import it.

zdb -l /dev/sdc2 shows 'path: /dev/gptid/db7d4921-d920-1le4-9dd6-00138f6f9938', which should be the partition PARTUUID, but blkid doesn't show a PARTUUID on /dev/sdc2.

Is there any way I can set the partition's UUID / PARTUUID of the first drive to the expected one?

Answer 1

You can view and manipulate GUIDs (what many Linux tools call "PARTUUIDs") with gdisk and sgdisk. For instance:

$ sudo sgdisk -i 1 /dev/sde
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: C697EE49-9430-46C5-B090-0423DA7A6FFF
First sector: 40 (at 20.0 KiB)
Last sector: 409639 (at 200.0 MiB)
Partition size: 409600 sectors (200.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'EFI System Partition'

This example shows the partition's GUID (Partition unique GUID) as C697EE49-9430-46C5-B090-0423DA7A6FFF. The i option in gdisk shows the same information. You can set it to a particular value with sgdisk's -u option, as in:

$ sudo sgdisk -u 1:BB193EE0-3544-449A-935A-41B215819992 /dev/sde

The 1: leading the GUID is the partition number. You can do the same thing in gdisk by using the c option on the experts' menu.

Answer 2

1. try import -a. If it fails, check your cache file.

2. Check your zpool.cache file if you have one, you might be able to make out some text on it, to see if it contains info on your pool. lending hope here.

3. Now, see if it has the device information for each drive, this can help you in your hunt for the drives.

4. Check your partition tables, make sure they are good, use fdisk -l and or gdisk.

If you imported the drives using device names, ive even seen it where the device letters switch under some configuration changes(or not?) on reboot. For e.g. /dev/sda may become /dev/sdb and vice versa. This would kill the entire array if one of those drives differ, until the boot order changes back, or the letters are swapped in the zfs configuration (For this reason it may not be good to create pools using device names, e.g. /dev/sda for this reason).

One thing you can do is back up partition tables, especially if they state they are bad. You can use testdisk, or allow gdisk to recover the partition, by letting it select what it thinks is correct.

By restoring/updating your partition tables, your zpool.cache will then again recognize your array, then be able to once again re import it, where after reboot of updating the partition tables, you would then simply import the correct way zpool import <poolname>

Suggestion1:

(for future comers) If you have a dataset, never assume the data is in jeopardy until you can get the pool back online where a scrub can be ran.

ZFS is an extremely robust file system. At worse case, you can use a dev mod of zfs, and disable the importing checks, to get your pool imported, in some cases.

Suggestion2:

(for future comers) When creating pools, try to use the disk-by-id when importing. /dev/disk/by-id/. You can also use /dev/disk/by-partuuid/ or /dev/disk/by-uuid/