initramfs loopaes

Warren Wilder wipwap19 at
Wed Jun 28 01:45:23 PDT 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 
>- 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 
>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 
>still only exist for
>Hope this helps! Please ask if you have problems.
>Sebastian Faulborn

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


FREE pop-up blocking with the new MSN Toolbar – get it now!

More information about the hlfs-dev mailing list