CentOS o pânico do kernel do OpenVZ ao montar o volume do truecrypt do ext4 no modo nokernelcrypto

Question

Estou experimentando o kernel panic ao tentar montar um sistema de arquivos ext4 que reside em um volume TrueCrypt montado usando a opção -m nokernelcrypto .

O sistema é o CentOS 6.3, OpenVZ Kernel 2.6.32-042stab074.10 O disco é um disco virtual (um volume TrueCrypt montado com --filesystem=none ), e o pânico real do kernel que aciona o comando é:

mount -o loop -t ext4 /tmp/.truecrypt_aux_mnt2/volume /mnt/storage

Observe que:

1. Ele é montado corretamente no modo somente leitura, i. e. usando -m ro
2. Também monta perfeitamente bem se eu inicializar no kernel "normal" (não-OpenVZ), que é 2.6.32-279.22.1.el6.x86_64
3. Novamente, monta perfeitamente quando não está usando -m nokernelcrypto (qualquer kernel)
4. Eu tenho que usar -m nokernelcrypto porque um disco de 3TB que eu tenho só pode ser montado usando essa opção - senão o truecrypt se recusa a montar dizendo "Kernel cryptographic service test failed" e sugere atualizar o kernel para 2.6.33. Não usar -m nokernelcrypto vai bem com discos de 2TB, mas não com 3TB
5. Os recursos de mensagem de pânico "Kernel panic - não sincronizando: Exceção fatal" e "kernel BUG em fs / fuse / file.c: 1110!"
6. Eu não tive esse problema quando estava usando o Debian OpenVZ - consegui montar o 3TB usando -m nokernelcrypto facilmente

Não tenho certeza exatamente onde está o problema: CentOS, OpenVZ, biblioteca de fusíveis ou descriptografia não-kernel. Qualquer pista será muito apreciada.

    

Answer 1

Eu tenho um problema semelhante usando o Proxmox (veja pve.proxmox.com, é um derivado do Debian). Eu tenho uma imagem de disco do sistema de arquivos ext4 que reside em um compartilhamento glusterfs (que é baseado em fusível). Assim que montei a imagem do disco, recebo a mensagem sobre o erro do kernel em fs / fuse / file.c: 1110.

Isso tudo funcionou bem com o pve-kernel-2.6.32-11-pve. Eu corri para o problema depois de atualizar o kernel para pve-kernel-2.6.32-19-pve.

Então eu acho que o problema pode ocorrer sempre que montarmos imagens de disco hospedadas em um sistema de arquivos baseado em fusível em um kernel 2.6.32 recente (o que quer que isso signifique).