wipwap19 at hotmail.com
Wed Jun 28 04:33:16 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 188.8.131.52
>- 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
>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
>the patch (but with grsec patch) there are tons of nasty error messages
>comes up (paging fault etc.), but the system comes up(!). However, since
>a central part of HLFS (the arc4random patch for glibc depends on it), I
>willing to skip frandom. Also initrd is a lot easier to use since you
>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
>if initramfs becomes too big (my initrd is ~45MB in size when it is
>it contains gnupg, lvm2 etc.).
>BTW: Which grsec patch are you using for kernel 184.108.40.206? The official
>still only exist for 220.127.116.11.
>Hope this helps! Please ask if you have problems.
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
( 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
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 18.104.22.168 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
Dont just search. Find. Check out the new MSN Search!
More information about the hlfs-dev