[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: initramfs loopaes Warren Wilder Wed Jun 28 07:37:11 2006

Sebastian Faulborn schreef:

> There are problems with "early user space" a.k. initramfs - it causes
> kernel panics. I was just busy setting this up, when I read that. Can you explain a bit
more about your kernel version, loop-aes version and specific kernel oops?

I am using the following setup:
- current HLFS (SVN-20060510)
- kernel
- all PAX/GRSec options enabled, except EMUTRAMP, privileged io
- current LOOP-AES (V3.1d) with current ciphers extension (see http://loop-aes.sourceforge.net)
- raid1 (software md raid) -> use mdadm to set it up
- gnupg
- lvm2

loop-aes with cipher AES crashes (it causes a kernel oops which you can

Its much easier to just have one encrypted partition and use lvm2 to create as many partitions as you need (with the option to resize a partition as you need it) on
top of it.

Initramfs: The kernel panics when ever I use a kernel with the frandom patch. Without the patch (but with grsec patch) there are tons of nasty error messages when initramfs comes up (paging fault etc.), but the system comes up(!). However, since frandom is a central part of HLFS (the arc4random patch for glibc depends on it), I was not willing to skip frandom. Also initrd is a lot easier to use since you already have a completly sane system when it comes up while initramfs seems to cause problems since not everything is yet initialized in the kernel. There also seem to be problems if initramfs becomes too big (my initrd is ~45MB in size when it is unpacked since
it contains gnupg, lvm2 etc.).

BTW: Which grsec patch are you using for kernel The official patches
still only exist for

Hope this helps! Please ask if you have problems.

Sebastian Faulborn
Homepage: http://www.secure-slinux.org

Yes, this helps :-)
As far as I can predict, vaguely, I think this is going to work for me,
because I am neither using RAID, nor using encrypted root(yet). I
*think* your initramfs problems are mainly about them. I am also not
using the frandom patch, because I have a hardware based random
generator; hrandom.
( I am now wondering whether I am missing anything, due to your comment:
(the arc4random patch for glibc depends on it) )

O well, I am just going to walk the plank to see what's lurking in the
deep :-)
This is going to be a tricky road with lots of testing, but that's okay
because I am not using this in any kind of production environment, yet.
HLFS is mostly a hobby for me.
Therefore I took the gamble and opted for a newer kernel, which was
required by HAL. I applied the normal patches and sofar they
seem to work just as before. I haven't done any extensive testing
though, because I don't have testcases beyond the HLFS-book.

There is a newer patch in the pipeline, but it's unofficial: (dated June  4)
(I haven't used this one, I already took a risk with the newer kernel

So I am going to take three steps:
1 initrd   encrypted swap
2 initramfs   encrypted swap
3 initramfs   encrypted swap&root

I am using one of those Via multimedia boards with addon security
hardware. The cipher created by Joan Daemen and Vincent Rijmen is
hardware accelerated, but no others, therefore I don't have the luxury
of switching to serpent, nor do I feel like using it; the Via cpu itself
isn't very fast.
I'll just have to chat with loop-aes creator Jarin Ruusu when I get the
kernel oops in my log file.

But not for the coming month, I am going for a three week seminar in The
States, woohoo :-)

Thanks, and I'll get back to you


Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/