|Summary:||boot dependencies not created in kernel-2.4.19-gentoo-r9|
|Product:||Gentoo Linux||Reporter:||Charles Mauch <cmauch>|
|Component:||[OLD] Core system||Assignee:||Brandon Low (RETIRED) <lostlogic>|
|Severity:||major||CC:||csimonut, mholzer, viz|
|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) 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 havoc..
Comment 5 Brandon Low (RETIRED) 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
addition: 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 over.
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) 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 gentoo.org). Following problems occur with grsec: - modules in modules.autoload are not loaded - init-script procparam (see seruity-guide) gives error messages (permission denied) - 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, Simon
Comment 14 Brandon Low (RETIRED) 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
Heya, 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. tobias
Comment 16 Brandon Low (RETIRED) 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) 2002-09-21 17:35:53 UTC
ok, please try lolo-sources-184.108.40.206_pre2 has the latest grsecurity in it, I'm closing this... re-open it if you hate me.