In addition to what I've described in the forums thread above, This problem
exists on both tmpfs and ramdrive configurations. (I've tried both). I've
also run a make mrproper and reconfigured my kernel from scratch, hoping that
this was a kernel configuration error brought over from the crypto sources with
what I see in the forum is something reminiscent of a bad filesystem type that
the kernel is unable to mount for your /usr/partition, is this possible? did you
use XFS (which isn't supported in gentoo-r9)?
No, I'm using reiserfs for all of my partitions (except of course for my boot
partition, which is ext2fs)
Additional things I've done.
make mrproper and configured 2.4.19-gentoo-r9 kernel sources from scratch.
Figured it might be a kernel misconfiguration. Same symptoms.
Manually turned off tmpfs support and enabled ramdrive support - ramdrive was
sucessfully mounted on /mnt/.init.d/, same symptoms.
Rebooted into single-user mode, unmounted the /mnt/.init.d, deleted .init.d
directory - recreated it - remounted it - rebooted. Same symptoms.
Re-emerged gentoobaselayout. Same symptoms.
Untarred a stage1 tarball from a 1.2 cdrom, replaced init files from it. Same
symptoms. (Afterwords, I restored backup of init files, so they aren't on the
Any ideas on other things I might try?
I can confirm this. After playing around with vanilla-sources-2.4.19 and
gentoo-sources-2.4.19-r9 which is derived from the vanilla tree (i.e. no 2.4.19
patch, just the original linux-2.4.19.tar.bz2 file) I've experienced problems
with autloading modules at startup (hope you're talking about this autoload thing..).
First I didn't recognize but after installing alsa and trying to load the modules I've
got the message that /etc/modules.conf would be more recent then /lib/modules-2.4.19-gentoo-r9/modules.dep .
So I've run a "depmod -a" and my alsa modules have been loaded without any warnings.
But after rebooting no modules will be loaded although /etc/modules.conf, /etc/modules.autoload
and this modules.dep are valid.
After building several kernels I've made the following experience:
A clean unpatched version of linux-2.4.19 will startup the right way.
gentoo-sources-2.4.19-r9 won't. So i patched the vanilla sources with
grsecurity and the latest available preempt patch for 2.4.19, compiled it and
gave it a try. I't also won't calculate modules as expected. So my idea is
that maybe the latest version of grsecurity _or_ the preempt patch causes
AH HAH! What grsecurity features do you turn on? Many of the features of
grsecurity have the potential to cause problems of this sort.
I enabled the following grsecurity features:
- Openwall non-executable stack
- Gcc trampoline support
- Proc restrictions
- Linking restrictions
- Chroot jail restrictions (I also enabled all suboptions )
- Log execs within chroot
- Signal logging
- Fork failure logging
- Time change logging
- Dmesg(8) restriction
- Randomized PIDs
I also enabled the same features as described above within my 2.4.18 kernel
sources and this works nice.
Just FYI: My problem isn't in the modules dependencies, but in the init script
depencencies. On boot, the fourth "colored" item to startup up displays
"Calculating Dependencies", which is where my problems start.
I have no problems with my modules autoloading and loading other modules based
on their depenciences.
In any case, I'll turn off grsecurity here as well (Mine is set to "medium").
Note that in crypto-sources-r7, I have grsecurity set to the same level and I
don't experience *this* problem.
On crypto-sources-2.4.19-r7 I also don't expect those problems I described.
crypto-sources use an older version of grsecurity and a pre 2.4.19 patch of
the linux kernel. gentoo-sources-2.4.19-r9 use the original finished linux
2.4.19 tarball and the latest version of grsecurity (1.9.6). And this is where
the problem starts. I don't know which feature is responsible for not getting
the modules loaded at startup.
Anyways: I won't get to a "Calculating Dependencies" if I use certain options
of grsecurity within gentoo-sources-2.4.19-r9. This part will always be jumped
Removing grsecurity support from the kernel seemed to clear up this problem.
I'll go back in later and toggle individual options on and off and try and nail
down which option(s) are causing the boot dependencies to fail.
Thanks for the help guys.
Looks like either grsecurity changed some of the options' functions, OR I messed
it up when patching it into this kernel, if you are able to track down which
specific option caused the problem do let me know so that I can fix it for the
next gentoo kernel. Thanks.
I don't think you've messed it up since I applied the grsecurity patch onto
the clean vanilla sources manually. Perhaps we have the same patch method. ;)
Will get into this later...I need some sleep now.
I tried kernel-2.4.19-gentoo-r9 with and without grsec (as mentioned in
security-guide on gentoo.org). Following problems occur with grsec:
- modules in modules.autoload are not loaded
- init-script procparam (see seruity-guide) gives error messages (permission
- if I cd into /proc/net (with bash-tab-extension) I get /proc/net and
not /proc/net/ (the last slash is missing)
- on startup, I get an errormessage about /proc/modules ist missing (and it ist
still missing after boot finished)
without grsec it works just fine.
seems to be an vienna-bug ;o)
hope this helps,
Wow, all you guys have been great doing my leg work for me! Keep watching
gentoo kernel development, I'll be keeping up with the latest patches from
preempt and grsec (starting a new lolo-sources pre gentoo-r10 development today)
and hopefully this will clear up so we can use all the nice things in grsec.
Sorry 'bout the late update. I wanted to post my progress in finding a
solution to this grsecurity "bug". But all I can tell is that I didn't get any
further than Simon. I'm still a C newbie but I'm trying to give my best. :)
At least it's a good idea to watch http://forums.grsecurity.net frequently
since a lot of people hat weird problems when using grsecurity 1.9.6.
Ok, new grsecurity is officially on my todo list for gentoo-sources-2.4.19-r10,
which means that -r10 won't be completed until after Brad from grsecurity
releases the 1.9.7 version of their patches for me to play with.
ok, please try lolo-sources-126.96.36.199_pre2 has the latest grsecurity in it, I'm
closing this... re-open it if you hate me.