Hi Stephan,

the first time we had this problem was on SL_6.2_X86 machines with full 
packages installation. After update to a kernel with "279" we had this 
error. On 64bit systems the error never happened - not on SL_6.2 an not 
SL_6.3. Then we tried it on SL_6.3 32bit with new installed systems. On 
systems with a lot of installed RPMs the problem occured and on servers 
with just a few packages everthing worked fine. Now we work since about 
2 weeks with an new compiled kmod-openafs without any problems.

Bye Thomas

Am 30.08.2012 13:13, schrieb Stephan Wiesand:
> Hi All,
>
> still trying to find out what's going on. Pat told me he's unable to reproduce the problem. There are no further reports. But it clearly was happening at TU Chemnitz and on my test VM.
>
> To make things even weirder: I can't reproduce it any more either. After reformatting the cache as ext4, all combinations of modules and kernels (old/new, new/old) work for me. Thus it seems the history of the cache filesystem is important. And I'm beginning to wonder whether it's simply a bug in   earlier ext4, e2fsprogs, openafs, whatever.
>
> My test VM was last installed on February 16th, with the then brand new SL6 and the openafs-1.6.0 coming with it, and the cache fs was created by the installer. OpenAFS was updated to 1.6.1 on April 1st. I'll now try to recreate this history as accurately as possible.
>
> Thomas&  Thomas, you reported that some of your systems didn't fail either (those with few RPMs installed, as opposed to those with a richer installation). Is it possible that those have a different history as well? Cache fs created manually instead of with anaconda? Installed with openafs-1.6.1 in the first place, not updated from 1.6.0? Anything else you can think of?
>
> Thanks a lot for any input.
>
> Best regards,
> 	Stephan
>