ZFS drives show UNAVAIL when using Proxmox Debug

[lampbearer]

I have zpools defined by-id. They work fine when proxmox is installed and loading.
But they show UNAVAIL when using the install disk in debug mode (debug - CTL-D - abort).
Even an apt-get update/apt-get upgrade doesn't work (so it isn't something as simple as a newer zfs package).
Can anyone explain what is going on?

 

[fabian]

I have zpools defined by-id. They work fine when proxmox is installed and loading.
But they show UNAVAIL when using the install disk in debug mode (debug - CTL-D - abort).
Even an apt-get update/apt-get upgrade doesn't work (so it isn't something as simple as a newer zfs package).
Can anyone explain what is going on?

the installer environment does not support ZFS with /dev/disk/FOO paths.

 

[lampbearer]

the installer environment does not support ZFS with /dev/disk/FOO paths.

I appreciate the confirmation of what I am seeing. I like to learn -- can you provide any information as to WHY it does not work? I appreciate you are saying that it is "by design", but I'm looking for the technical reasons why. Is zfs a different version in the installer environment? Are there configurations on it that make it behave this way?

It appears as if the installer environment includes zfs support in some way -- it can create zfs root drives and such. Other postings on these forums indicate ways to change the zfs config file to import "by-id". So the issue then is that once someone has converted their system to "by-id" there is no way to do rescue work on it.

Perhaps some other linux folks out there could help someone like me understand how to make my own rescue boot disk that properly supports the environment I have. Is there a way to show the version of zfs that is running and to build a live environment that completely supports zfs the same way and with the same features as the proxmox running environment?

Thanks.

 

[fabian]

I appreciate the confirmation of what I am seeing. I like to learn -- can you provide any information as to WHY it does not work? I appreciate you are saying that it is "by design", but I'm looking for the technical reasons why. Is zfs a different version in the installer environment? Are there configurations on it that make it behave this way?

it's not by design, but a strange side effect of the fact that the installer environment is loaded by very small, custom initrd and chrooted. the device links are there, but ZFS cannot use them. I spent some time investigating the actual cause without results, and there are other issues that are more important.

It appears as if the installer environment includes zfs support in some way -- it can create zfs root drives and such. Other postings on these forums indicate ways to change the zfs config file to import "by-id". So the issue then is that once someone has converted their system to "by-id" there is no way to do rescue work on it.

Perhaps some other linux folks out there could help someone like me understand how to make my own rescue boot disk that properly supports the environment I have. Is there a way to show the version of zfs that is running and to build a live environment that completely supports zfs the same way and with the same features as the proxmox running environment?

Thanks.

for most rescue operations, you can use a Debian buster/sid live iso, its ZFS is usually only one or two minor releases behind which is not a problem. you do need to install the ZFS packages and compile modules though, so you might want to build a CD with the compiled modules included (or install a non-live version on a (virtual) USB stick or the like).