Just updated to gentoo-sources-2.4.20-r9 to catch up with the do_brk fix. It has also changed the cryptoapi setup to be "2.6 like" which makes it unusable for me as I have existing cryptoloop filesystems. I've read lots in bugs and forums and I seemed to be OK with 2.4.20-r8 and util-linux-2.11z-r7. 2.4.22 and 2.6 were nfu as they don't have 256bit aes. I can't even rebuild 2.4.20-r8 as that seems to get the same patches as -r9. I really hope I'm doing something stupid here as the only way back I can see is to restore from backup (I'm not _that_ stupid) but I can't update my kernel at all and it could really do with it by now.
I've worked out some more here but I'm beyond my comfort zone so I hope this isn't utter rubbish. It isn't the do_brk patch. Looking at my distfiles, I see I have gone from patches-2.4.20-gentoo-r2 to r5. Looking further I think that the offending patch is "patch-int". I've discovered KERNEL_EXCLUDE so I tried excluding patch-int but this then broke freeswan. As I'm not using freeswan, I excluded that patch too. The kernel unpacked then but I had no access to crypto algorithms from make menuconfig. I'm looking into vanilla-sources now but haven't succeeded there either. I don't expect this will help the dev(s) but it may help others...
More news. I've found util-linux-2.12-r1. The crypto patch lets me specify a key size but the kernel still won't give me the cipher I need. 2.4.20-gentoo-r9 can't handle 256 bit keys (as it says in config but I thought I'd check anyway). I dunno if it copes with 128 bit keys even, cos losetup fails anyway with ioctl: LOOP_SET_STATUS: Invalid argument
1) Can you try FreeS/WAN 1.99.8? 2) What's the actual problem? Do file systems not mount? Is anything for use of debugging produced?
The problem was that I couldn't mount an existing cryptoloop filesystem. I forget the original kernel I created the filesystem under but I think it was crypto-sources-2.4.19. As I've already said I ended up where I didn't even have a kernel config option to get the same crypto as I used before (AES256). Looking at other bugs and forum messages it seemed obvious that crypto was a low priority so I started looking around at all the options that I could both find and understand. I decided that there was no chance I would get a kernel compatible with my filesystem in the short term so I decided to try out a 2.6 kernel on the basis that at least I wouldn't have to rebuild my cryptoloop filesystem twice that way (once for whatever else I went to - 2.4 with different crypto patch or loop-aes - and then again when I eventually moved to 2.6). By the time I got here, 2.6 had an option for AES256 so there was obviously action on this part of the kernel as well. To cut to the chase I'm now running 2.6 and I had to recreate my cryptoloop filesystem so I can't really test how things are now with 2.4. I guess that I was unlucky in trying to update when the crypto patches were in flux. I have read since that AES256 didn't work right in the earlier kernels, so it may well have been that my cryptoloop wasn't even encrypted as it should have been, so I probably had no chance of keeping my original loopback file anyway. I guess we can drop this unless somebody else is having similar problems cos any fix would be too late for me anyway. PS for anyone browsing: this is an object lesson in why it's a good idea to have an unencrypted backup!
Thanks - shame that the crypto patches got out of sync or were broken. Anyway, as this seems to be long gone I shall now close this as NEEDINFO.
*** Bug 37657 has been marked as a duplicate of this bug. ***
