/etc/init.d/modules doesn't depend() on enough. It calls /sbin/modules-update at boot, but /sbin/modules-update uses some programs (tail, id) from /usr/bin. /etc/init.d/modules does NOT depend on localmount, and thus it is possible to lose in /sbin/modules-update because the script can't find /usr/bin/tail and such. However, /etc/init.d/localmount depend()s on "checkfs", and "checkfs" depend()s on "modules"... We have vicious cycle, no? The only solution that I can see is two different module loops - one to load up any BADLY needed modules for disk access, fsck & mount the disks, and then go through the standard update-modules procedure. Of course, all of this is only a real problem if you put /usr on its own partition... but that is not an uncommon practice. I only noticed this because i was experiencing weirdness with /etc/modules.conf being overwritten with junk after a bad boot. That "bug" (if it is one) is not covered here. This bug: http://bugs.gentoo.org/show_bug.cgi?id=19495 is somewhat similar to my original problem, but I don't seem to have an /sbin/generate-modprobe.conf, and i also don't have an /etc/modprobe.conf - just /etc/modules.conf. In my system, I have no modules required to bring disks online, so I have commented out the depend() in checkfs on the modules script, and then my modules script has an added depend for localmount. This works on my machine, but for those who have raid systems running with modules it wouldn't. Reproducible: Always Steps to Reproduce: 1. Have system that keeps /usr on its own partition 2. edit /etc/init.d/modules and remove the redirection to /dev/null that follows /sbin/update-modules (so we can see errors at boot) 3. Boot system normally, note the command failures during the "Calculating dependencies" phase of the init scripts. in some instances, this causes the "modules" script to fail and break other things that depend on it. Actual Results: System init scripts can get derailed because "modules" may not complete successfully. If /etc/modules.conf is PROPER & functional, the "modules" script seems to run fine. However, I have seen it fail and thus screw up the rest of the boot process. /sbin/modules-update attempts to use files that it can't access in either case, but it only fouls up the initscript sometimes, and I'm not quite sure why. Expected Results: Expected system to understand that /usr needs to be mounted before a bootscript could use files from it. Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.20-wolk4.0s-rc4 i686 Pentium III (Katmai) GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://csociety- ftp.ecn.purdue.edu/pub/gentoo/ http://csociety-ftp.ecn.purdue.edu/pub/gentoo/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://www.ibiblio.org/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/conf ig /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/usr/tmp" PORTDIR_OVERLAY="" USE="x86 3dnow apm arts avi encode gif gpm imlib jpeg libg++ libwww mikmod motif ncurses oggvorbis opengl pdflib png sdl svga truetype xml2 xv gdbm berkdb readline tcpd pam ssl perl python xfs slang crypt mmx sse java maildir zlib mbox samba spell -kde -X -gtk -gnome -alsa -nls -esd -qt -quicktime - mozilla -mpeg -xmms -oss -cups" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer" CXXFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j 10" AUTOCLEAN="yes" SYNC="rsync://rsync2.us.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
Right. Wonder why nobody caught it until now. Switching to coreutils should also fix this issue, as most of those tools (if not all) moved to /bin ...
Coreutils is in stable profile.
Great to see it fixed. :) Gentoo rules.
