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 2.6.14.6
- 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 2.6.16.15? The official
patches
still only exist for 2.6.14.6.
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 2.6.14.6 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)
http://www.grsecurity.net/~spender/grsecurity-2.1.9-2.6.16.19-200606041421.patch
(I haven't used this one, I already took a risk with the newer kernel
source)
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
Warren
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
