HELP! Upgrade from FreeNAS 11.3-U5 to TrueNAS 12.0-U2.1, attempted to upgrade GELI encrypted pool, it failed. Cannot unlock nor import pool

rfang9524

Cadet
Joined
Jan 3, 2019
Messages
3
The issue I had was the encryption on my new drives did not finish prior to a shutdown. I was able to use the recovery key to decrypt the existing drives and use the encryption key to decrypt the new drives that didn't finish encrypting. See https://www.truenas.com/community/t...rtitions-gone-on-all-drives.82261/post-635413

  • What does it show when you run "geli status" after you use "geli attach..." all of the drives? Are they showing up as "ACTIVE"? I didn't need to specify the encryption passphrase in the command. It's either the recovery key or the encryption key.
  • Are you able to "geli attach" all of the drives? I couldn't tell since some of the commands you posted only had three drives "attach".

Also, I just ran "zpool import -a" after all of the drives are decrypted and "attach".
 

Voltrix

Dabbler
Joined
Dec 29, 2016
Messages
12
I'm unsure if geli init on a disk that already has been initialized with geli wipes the existing metadata which means you could have potentially caused the corruption by simply running that command. :frown:

Anyways, we keep a backup of the geli key that is used to initialize the disks in /data/geli/. If you have that key you can try the following.

If you originally setup the zpool with a passphrase then run this:
geli attach -j <your-passphrase> -k /data/geli/<the-key> /dev/gptid/<the-guid-for-the-disk>.eli

If you didn't setup the zpool with a passphrase then run:
geli attach -p -k /data/geli/<your-key> /dev/gpid/<the-guid-for-the-disk>.eli

@calebbsd, thank you for your reply.

You may be right that the geli init command may have cause the corruption.
However, I am still able to attach\decrypt the drives. (See another reply below).

Regarding the geli attach commands you suggested: yes, they work. I am able to decrypt\attach the disks. Just not able to import the pool, by any means. Please see further up in this thread where I successfully attach the disks.
 
Last edited:

Voltrix

Dabbler
Joined
Dec 29, 2016
Messages
12
The issue I had was the encryption on my new drives did not finish prior to a shutdown. I was able to use the recovery key to decrypt the existing drives and use the encryption key to decrypt the new drives that didn't finish encrypting. See https://www.truenas.com/community/t...rtitions-gone-on-all-drives.82261/post-635413

  • What does it show when you run "geli status" after you use "geli attach..." all of the drives? Are they showing up as "ACTIVE"? I didn't need to specify the encryption passphrase in the command. It's either the recovery key or the encryption key.
  • Are you able to "geli attach" all of the drives? I couldn't tell since some of the commands you posted only had three drives "attach".

Also, I just ran "zpool import -a" after all of the drives are decrypted and "attach".

@rfang9524, thank you for your interest as well.
Yes, I am able to attach (decrypt) all of the drives. Please note that I have been "attaching" just the freebsd-zfs GPTIDs that correspond to /dev/adaXp2 partitions while trying to zpool import.
But I am also able to attach the freebsd-swap GPTIDs that correspond to /dev/ada0p1 and to /dev/ada1p1. It's also worth noting that /dev/ada2p1 and /dev/ada3p1 don't seem to have corresponding GPTIDs in /dev/gptid.
Does anyone know if I should also geli attach the freebsd-swap GPTIDs before trying zpool import. I have tried doing so but to no avail.

Here are the results of the following command after attaching all of the freebsd-zfs and freebsd-swap GPTIDs:
Code:
root@vtxnas1:/dev/gptid # geli status
                                          Name  Status  Components
                              mirror/swap0.eli  ACTIVE  mirror/swap0
gptid/18b9c2bc-ac53-11ea-a0dd-ac1f6b17114e.eli  ACTIVE  gptid/18b9c2bc-ac53-11ea-a0dd-ac1f6b17114e
gptid/141a4ce3-60d4-11e8-a658-ac1f6b17114e.eli  ACTIVE  gptid/141a4ce3-60d4-11e8-a658-ac1f6b17114e
gptid/14cb9361-60d4-11e8-a658-ac1f6b17114e.eli  ACTIVE  gptid/14cb9361-60d4-11e8-a658-ac1f6b17114e
gptid/157d13bd-60d4-11e8-a658-ac1f6b17114e.eli  ACTIVE  gptid/157d13bd-60d4-11e8-a658-ac1f6b17114e
gptid/140a8240-60d4-11e8-a658-ac1f6b17114e.eli  ACTIVE  gptid/140a8240-60d4-11e8-a658-ac1f6b17114e
gptid/189999a0-ac53-11ea-a0dd-ac1f6b17114e.eli  ACTIVE  gptid/189999a0-ac53-11ea-a0dd-ac1f6b17114e
root@vtxnas1:/dev/gptid #
 

csj

iXsystems
iXsystems
Joined
Oct 20, 2017
Messages
18
@calebbsd, thank you for your reply.

You may be right that the geli init command may have cause the corruption.
However, I am still able to attach\decrypt the drives. (See another reply below).

Regarding the geli attach commands you suggested: yes, they work. I am able to decrypt\attach the disks. Just not able to import the pool, by any means. Please see further up in this thread where I successfully attach the disks.

Right, you're able to attach the geli providers because you initialized them with a new key. It's unfortunate but I fear the original zfs metadata has been lost because of this :frown:
 
Top