Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am experiencing kernel panic when trying to mount a ext4 filesystem which itself resides on a truecrypt volume mounted using -m nokernelcrypto option.

The system is CentOS 6.3, OpenVZ Kernel 2.6.32-042stab074.10 The disk is a virtual disk (a truecrypt volume mounted with --filesystem=none), and the actual command triggering kernel panic is:

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

Note that:

  1. It mounts fine in read-only mode, i. e. using -m ro
  2. It also mounts perfectly fine if I boot in "normal" kernel (non-OpenVZ), which is 2.6.32-279.22.1.el6.x86_64
  3. Again, it mounts perfectly fine when not using -m nokernelcrypto (either kernel)
  4. I have to use -m nokernelcrypto because a 3TB disk that I have can only be mounted using that option — otherwise truecrypt refuses to mount saying "Kernel cryptographic service test failed" and suggests to upgrade kernel to 2.6.33. Not using -m nokernelcrypto goes OK with 2TB disks, but not with 3TB
  5. The panic message features "Kernel panic - not syncing: Fatal exception" and "kernel BUG at fs/fuse/file.c:1110!"
  6. I did not have this problem when I was using Debian OpenVZ — was able to mount the 3TB using -m nokernelcrypto easily

I am just not sure where exactly the problem is: CentOS, OpenVZ, fuse library or the non-kernel decryption. Any clues will be much appreciated.

share|improve this question

I have a similar problem using Proxmox (see, it's a Debian derivative). I have an ext4 file system disk image residing on a glusterfs share (which is fuse-based). As soon as I mount the disk image, I get the message about the kernel bug at fs/fuse/file.c:1110.

This all worked fine with pve-kernel-2.6.32-11-pve. I ran into the problem after upgrading the kernel to pve-kernel-2.6.32-19-pve.

So I guess the problem might occur whenever we mount a disk images that is hosted on a fuse-based file system on a recent (whatever that means) 2.6.32 kernel.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.