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> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | csimonut, mholzer, viz |
Priority: | High | ||
Version: | 1.3 | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic.php?t=14623&highlight=gentoor9 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Charles Mauch
2002-09-10 12:29:17 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)? 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? 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 havoc.. 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 addition: 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 over. 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 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 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. 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 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-2.4.19.10_pre2 has the latest grsecurity in it, I'm closing this... re-open it if you hate me. |