ZFS Key load error: Failed to open key material file: No such file or directory

[geole0]

Hello
The message is

Key load error: Failed to open key material file: No such file or directory

Command: mount -o zfsutil -t zfs rpool/ROOT/ubuntu_ui69ph /root// Message: filesystem 'rpool/ROOT/ubuntu_ui69ph' can not be mounted: Permission denied
filesystem 'rpool/ROOT/ubuntu_ui69ph' can not be mounted: Permission denied

Hello
I recently installed an encrypted ZFS 22.04 version.
She boots well.
I can do the updates and reboot except that now the reboot is impossible because of the message above.
I suspect that access to the encryption keys has become impossible.

The reason could be a borrowing of these keys by another O.S. with poor quality playback. For example forget to free the key file
because the incident is systematic

have a good day

[geole0 (geole0)]

Helle

Hello
Here is the access sequence to the encrypted partition from another O.S.

zpool import -N -R /ZFS rpool && sleep 10
if [ -e /dev/zvol/rpool/keystore ] ; then
    cryptsetup -v open /dev/zvol/rpool/keystore keystore-rpool && sleep 10
    mkdir -p /run/keystore/rpool
    mount -v /dev/mapper/keystore-rpool /run/keystore/rpool && sleep 10
fi

Here is an encrypted partition release sequence from another O.S. which prevents the boot of the encrypted partition
 shutdown or crash of O.S.

Another
zpool export rpool && shutdown

Antoher
umount -v /run/keystore/rpool && sleep 5
cryptsetup -v close /dev/mapper/keystore-rpool && sleep 5
zpool export rpool
shutdown

Here is the correct sequence of freeing encrypted partition from another O.S. which allows the boot of the encrypted partition.
But first you have to go through the recovery option.
There's probably a better solution.
umount -v /run/keystore/rpool && sleep 5
cryptsetup -v luksClose /dev/mapper/keystore-rpool && sleep 5
zpool export rpool && zpool list
shutdown

[geole0 (geole0)]

Hello.
To advance this problem, I decided to redo a brand new installation without using encryption.

I can also boot several times without any difficulty.

With another O.S. in version 22.04 installed in an EXT4 partition, I launched the script to access this ZFS partition.
The problem is reproduced in a simpler way. The boot does not finish despite waiting about an hour.
I took a screenshot which I am attaching.
I know the problem is systematic.

Using the quoted script, I can access the log. But I see that the log has not yet been created.

I am only allowed to boot into recovery mode. It's a little better. The boot hangs less
I am attaching the errors encountered and the entire trace of the log.
All this is obtained by the aforementioned script.

I'm willing to admit that my script isn't up to snuff. however this should absolutely not prevent ZFS from booting.

I don't know whether to do another bug report or if it can stay in this one.

Good research and good editing.

[geole0 (geole0)]

The little script that makes ZFS booting impossible.
sudo -i

#1) Montage des partitions contenant le logiciel
rmdir /ZFS
zpool import -N -R /ZFS rpool && sleep 5
zfs set canmount=on rpool && zfs mount -v rpool
for var in $(zfs list | grep ROOT/ubuntu|cut -d" " -f1)
do
     echo $var
     zfs set canmount=on $var && zfs mount -v $var
     sleep 1
done

#2) On récupère la séquence de boot. Mais c'est celle obtenue en mode recovery et pas la dernière !!!
journalctl -b -p err -D /ZFS/var/log/journal >/home/a/boot-ERR.txt
journalctl -b -D /ZFS/var/log/journal >/home/a/boot-TOT.txt

#3) On démonte le root
for var in $(zfs list | tac | grep ROOT/ubuntu|cut -d" " -f1)
do
     echo $var
     zfs unmount $var && zfs set canmount=off $var && sleep 1
done
zfs unmount rpool && zfs set canmount=off rpool && sleep 1
umount -v --recursive /ZFS
zpool export rpool
zpool list

[geole0 (geole0)]

Hello
SOLVED with new Daily
jammy-desktop-amd64.iso 2022-02-26 08:21

[geole0 (geole0)]

Hello

This version is now good. jammy-desktop-amd64.iso 2022-03-21 08:38