Replace Disk in RAID-1 ZFS Pool

[macamba]

I have a BIOS/ UEFI with the following Proxmox storage configuration:
- 1 NVM storage for Proxmox OS (unencrypted);
- 1 SSD for caching and logging (unencrypted);
- 2 HDD's for data only in Raid-1 ZFS configuration with one unencrypted and one encrypted file system.

When I boot the system cold the UEFI detects a disk it can't use and prompts for a password. When I hit the reset and the (warm boot) the message is not show.
I disabled all security options for disks in the BIOS setup but the problem persists. I have no clue what causes this. I would say UEFI would not recognize a ZFS file system, but somehow it sees something. Interesting fact is that only 1 of the 2 HDD's of the ZFS RAID show up in the BIOS, which basically cannot have something to do with this issue since the encrypted filesystem is spread across both disks as well.

Some pointer where to look for? Since my Root is not on ZFS this article seems not to apply:
https://pve.proxmox.com/wiki/ZFS:_Switch_Legacy-Boot_to_Proxmox_Boot_Tool

Macamba

 

[leesteken]

It's probably the actualy drive (not the filesystem or the UEFI/BIOS) that is encrypted. The UEFI detects that the drive is encrypted, because it's a standard feature of the disk drive interface, and asks for a unlock password which is saved by the drive itself (until power loss or shutdown, which explains why a reboot works).
There is probably a way to disable the whole disk encryption (or change the password to empty), but it may erase the disk (which you can recover from because of the ZFS mirror). I have no experience with this but maybe there is something in the motherboard manual about how to do this? Or maybe you need specific software from the drive manufacturer to change/remove the password?

 

[macamba]

It's probably the actualy drive (not the filesystem or the UEFI/BIOS) that is encrypted. The UEFI detects that the drive is encrypted, because it's a standard feature of the disk drive interface, and asks for a unlock password which is saved by the drive itself (until power loss or shutdown, which explains why a reboot works).
There is probably a way to disable the whole disk encryption (or change the password to empty), but it may erase the disk (which you can recover from because of the ZFS mirror). I have no experience with this but maybe there is something in the motherboard manual about how to do this? Or maybe you need specific software from the drive manufacturer to change/remove the password?

I will check this evening, but I already switched of all Self-Encrypting Drive features in the BIOS and the harddisks themself do not have SED...
It's a Asrock Z390M-ITX/ac motherboard. Strange thing is that this behavior just 'popped' up out of the blue and was not always the case.

 

[macamba]

Considering below info would that rule out a software error? If not what's the best way to revive the disk?

lsblk -f gives


zpool status -v zpool gives

 

[macamba]

In case a disk is broken it occurs that UEFI/ BIOS thinks it's an encrypted disk then. I ordered a new disk as replacement in my pool.
Useful links in this regard:
https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J/index.html
https://jordanelver.co.uk/blog/2018/11/26/how-to-replace-a-failed-disk-in-a-zfs-mirror/

I will post my replacement steps as a follow-up.

 

[macamba]

For others needing some support with this a well. I replaced the disk in the 'zpool' as follow:
- Find the identifier of the old unavailable disk: zpool status (result in my case: 927291685244328713)
- Find the identifier of the new disk: ls -l /dev/disk/by-id (result ata-TOSHIBA_HDWQ140_Y0OEK46WFBJG (sdb) or wwn-0x5000039a6bd80fb0 (sdb))
- To replace the 'unavailable disk': zpool replace -f 927291685244328713 /dev/disk/by-id/ata-TOSHIBA_HDWQ140_Y0OEK46WFBJG

Other useful command: lsblk -f