Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 7760

Summary: boot dependencies not created in kernel-2.4.19-gentoo-r9
Product: Gentoo Linux Reporter: Charles Mauch <cmauch>
Component: [OLD] Core systemAssignee: Brandon Low (RETIRED) <lostlogic>
Severity: major CC: csimonut, mholzer, viz
Priority: High    
Version: 1.3   
Hardware: x86   
OS: Linux   
Package list:
Runtime testing required: ---

Description Charles Mauch 2002-09-10 12:29:17 UTC
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
no luck.
Comment 1 Brandon Low (RETIRED) gentoo-dev 2002-09-11 14:06:58 UTC
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)?
Comment 2 Charles Mauch 2002-09-11 15:14:39 UTC
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
system anymore).

Any ideas on other things I might try?
Comment 3 Tobias Eichert 2002-09-12 18:51:58 UTC
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. 
Comment 4 Tobias Eichert 2002-09-13 11:00:23 UTC
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 
Comment 5 Brandon Low (RETIRED) gentoo-dev 2002-09-13 12:03:38 UTC
AH HAH!  What grsecurity features do you turn on?  Many of the features of
grsecurity have the potential to cause problems of this sort.
Comment 6 Tobias Eichert 2002-09-13 12:50:54 UTC
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
Comment 7 Tobias Eichert 2002-09-13 12:52:33 UTC
I also enabled the same features as described above within my 2.4.18 kernel
sources and this works nice.
Comment 8 Charles Mauch 2002-09-13 13:18:02 UTC
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.
Comment 9 Tobias Eichert 2002-09-13 17:52:54 UTC
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 
Comment 10 Charles Mauch 2002-09-13 18:35:31 UTC
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.
Comment 11 Brandon Low (RETIRED) gentoo-dev 2002-09-13 19:40:32 UTC
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.
Comment 12 Tobias Eichert 2002-09-13 20:51:15 UTC
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.
Comment 13 simon 2002-09-16 14:12:19 UTC
I tried kernel-2.4.19-gentoo-r9 with and without grsec (as mentioned in 
security-guide on 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,
Comment 14 Brandon Low (RETIRED) gentoo-dev 2002-09-18 14:15:48 UTC
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.
Comment 15 Tobias Eichert 2002-09-18 17:15:49 UTC
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 frequently 
since a lot of people hat weird problems when using grsecurity 1.9.6.

Comment 16 Brandon Low (RETIRED) gentoo-dev 2002-09-19 02:44:55 UTC
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.
Comment 17 Brandon Low (RETIRED) gentoo-dev 2002-09-21 17:35:53 UTC
ok, please try lolo-sources- has the latest grsecurity in it, I'm
closing this... re-open it if you hate me.