Presence of new kernel prevents ecryptfs remounts - SOLVED

Question

This is a minor annoyance, but I wonder if someone can explain the reason it occurs and perhaps suggest a way round it?  I have a couple of ecryptfs encrypted directories which have fstab entries as recommended so that I can normally mount / remount with "mount -i ~/foo".  Now I do not always reboot immediately on the arrival of a new kernel after my daily pacman -Syu.  The reboot is usually some days later.  The presence of the new kernel seems, however, to prevent the remounting of the ecryptfs directories.  kernel.log:
neutron kernel: [260668.601290] Unable to allocate crypto cipher with name [ecb(aes)]; rc = [-2]
neutron kernel: [260668.601295] Error attempting to initialize key TFM cipher with name = [aes]; rc = [-2]
neutron kernel: [260668.601298] Error attempting to initialize cipher with name = [aes] and key size = [16]; rc = [-2]
neutron kernel: [260668.601301] Error parsing options; rc = [-22]
Rebooting fixes the problem.
Will a moderator please move this post if you think I am in the wrong forum.
Last edited by perseus (2013-08-27 19:53:50)

Answer 1

qinohe - about the versioned module directories, if you look in /usr/lib/modules you will find a directory 3.10.9-1-ARCH. That is, in fact, a versioned module directory which matches the current installed kernel (try "uname -r").  It seems that in some distros old kernels (and their matching module directories), are not removed by the command equivalent to 'pacman -Syu'. This means that the old modules remain available until a new kernel becomes operational by rebooting.  I had not appreciated that Arch removes the existing module directory after the -Syu installs the new kernel.  At least I think this is what happens.  I should pay more attention to the structure of my system. As I said, Arch has made me lazy.
Last edited by perseus (2013-08-27 19:02:24)