Presence of new kernel prevents ecryptfs remounts - SOLVED

perseus · 2013-08-27 08:25:17

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)

qinohe · 2013-08-27 14:22:15

Hi, as far as I know too, the new kernel is going to be loaded when you restart.
So, you should be able to work on until you reboot, I'm at least curious,why this is not the case.
I guess you could try to modprobe your module again, I found this, but I bet you did too

perseus · 2013-08-27 15:40:23

Thanks. Doh .... of course I should have tried that. I will do so next time. It does seem very odd that I should need to though.

alphaniner · 2013-08-27 16:11:59

There have always been issues mounting after a kernel update. As I understand, it has to do with the fact that modules from the running kernel are no longer available, having been replaced by modules from the new kernel.

Maybe it should be different for remounts though, IDK.

perseus · 2013-08-27 16:28:07

Thanks alphaniner - it all feels rather un-linuxy. I suppose there is a good reason for it though.

qinohe · 2013-08-27 16:44:44

I think I found something that makes it clearer, thanks for the answer alphaniner.
Found this thread from last year.

perseus · 2013-08-27 17:19:23

That is a helpful thread qinohe. I will google around to find out why. I have been on Arch for more than 6 years and on SuSE, LFS, Slackware going back at least another 7 years. I seem to recall that In the days when I compiled kernels there were versioned module directories to match them and problem like the one that thread and mine did not arise. Maybe I am wrong - or maybe things just changed. Arch is so good that I stopped following some developments, and ceased doing a variety of things for myself.

alphaniner · 2013-08-27 18:30:27

perseus wrote:

Maybe I am wrong - or maybe things just changed.

No, I think you're spot on. The problem wouldn't occur in a distro that kept old kernels installed. But in Arch, everything installed by the old kernel is removed/overwritten upon a kernel upgrade.

Last edited by alphaniner (2013-08-27 18:31:14)

qinohe · 2013-08-27 18:33:34

Yes, you go way back I can see;), LFS lies ready to start with here, but at the moment, I'm doing a little 'C' first, to be better prepared.
Now, I have never done with kernels what you did, I compiled a few for freeBSD, years ago that's it, I think I have never compiled a linux kernel myself, not sure though
So I really don't know anything about that versioned module dirs you talk about, but still, if the kernel works that way they say in the thread, not much left that can be done, other than reboot,( I use Arch for almost two years now, I have plans to stay a while...

perseus · 2013-08-27 18:59:08

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)

qinohe · 2013-08-27 19:55:09

Perseus, thanks for that clear reply, I understand it a lot better now.
If Arch removes the old kernel and it's module directories, couldn't that be , just because of Arch rolling nature.
Am just trying to get perspective here, like you I guess, thanks.

Arch Linux

#1 2013-08-27 08:25:17

Presence of new kernel prevents ecryptfs remounts - SOLVED

#2 2013-08-27 14:22:15

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#3 2013-08-27 15:40:23

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#4 2013-08-27 16:11:59

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#5 2013-08-27 16:28:07

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#6 2013-08-27 16:44:44

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#7 2013-08-27 17:19:23

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#8 2013-08-27 18:30:27

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#9 2013-08-27 18:33:34

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#10 2013-08-27 18:59:08

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

#11 2013-08-27 19:55:09

Re: Presence of new kernel prevents ecryptfs remounts - SOLVED

Board footer