Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 165134 - /sbin/modules-update fails when /etc/init.d/modules starts and /usr/src is on a separate partition than /
Summary: /sbin/modules-update fails when /etc/init.d/modules starts and /usr/src is on...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 167798 168157 171658 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-02-03 15:10 UTC by Lloeki
Modified: 2007-04-14 03:19 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
modules-update.diff (modules-update.diff,749 bytes, patch)
2007-02-04 10:31 UTC, Jakub Moc (RETIRED)
Details | Diff
Patch for /sbin/modules-update (modules-update.diff,1.29 KB, patch)
2007-02-27 20:53 UTC, Wolfram Schlich (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lloeki 2007-02-03 15:10:01 UTC
Modules-update needs System.map matching the current kernel version, and looks for it in /lib/modules/${KV}/build, which is a symlink to the linux source tree in /usr/src/ which served to build the matching kernel.
However, it is common practice to have /usr being a separate partition than /. 
Unfortunately, upon booting the system, /etc/init.d/modules has to be started before non-root partitions are mounted (e.g for cryptoloop, filesystem modules, etc...). This triggers the current bug, where System.map is obviously non-existent at the time /etc/init.d/modules is started.

bug present using: sys-apps/baselayout-1.12.6

possible solutions:
- System.map from /boot should be used (problematic for separate /boot partitions, but nice for genkernel users since it copies it to /boot already)
- System.map should be copied to /lib/modules/${KV}, not symlinked nor accessible via a symlink
- The three solutions at once (current one plus the two above), sequentially testing for each System.map existence and using the first available one.

Please note that this is not a dupe of bug #104288 which concerns using the correct System.map via /lib/modules/${KV}/build instead of trusting blindly the /usr/src/linux symlink)

Reproducible: Always

Steps to Reproduce:
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-02-03 18:02:41 UTC
(In reply to comment #0)
> possible solutions:
> - System.map from /boot should be used (problematic for separate /boot
> partitions, but nice for genkernel users since it copies it to /boot already)
> - System.map should be copied to /lib/modules/${KV}, not symlinked nor
> accessible via a symlink
> - The three solutions at once (current one plus the two above), sequentially
> testing for each System.map existence and using the first available one.

<snip>
if [[ -d ${depfile%/*} ]] ; then
	if [[ ${CFG_NEW_FILE} -nt ${depfile} ]] ; then
		ebegin "Updating modules.dep"
		for cfg in /lib/modules/${KV}/build /usr/src/linux-${KV} \
		           /boot /usr/src/linux ""
		do
			cfg="${cfg}/System.map"
			[[ -f ${cfg} ]] && break
		done
		[[ -n ${cfg} ]] && cfg="-F ${cfg}"
		depmod -a ${cfg} ${KV}
		eend $?
	fi
else
	vewarn "The dir '${depfile}' does not exist, skipping call to depmod"
fi
</snip>

Relevant part of /sbin/modules-update from sys-apps/module-init-tools-3.2.2-r2 above. 

I really don't see what are you trying to fix there. If you can't live with the completely harmless warning about a completely useless file, then copy it to one of the 3 locations. For the rest of users that have better things to do than to stare at the screen during boot, I don't see why they should have 3 redundant copies of System.map scattered across their system for every single kernel version they have installed. Really sounds like some kind of obsession.
Comment 2 SpanKY gentoo-dev 2007-02-03 21:34:57 UTC
added to 2.6.9-r2, thanks for the report !
Comment 3 SpanKY gentoo-dev 2007-02-03 21:35:16 UTC
erm wrong bug
Comment 4 SpanKY gentoo-dev 2007-02-03 21:38:01 UTC
yeah, just copy your System.map to /boot

the kernel `make install` does this for you
Comment 5 Lloeki 2007-02-03 22:47:00 UTC
1. I don't know what's System.map role exactly, but when a service fails to start ([!!] state) with a file not found error, it's not exactly reassuring.
2. I would suspect files having vastly different content would bring up different results...
3. genkernel is a gentoo supported tool (which I use), and gives a /boot/System.map-genkernel-${KV} file, so I'd suppose modules-update could have support for that naming scheme.
Comment 6 SpanKY gentoo-dev 2007-02-03 23:24:14 UTC
considering the purpose of the script (to update module dependencies), it only makes sense to display that when the script failed

easy enough to add suffix searching, so modules-update now searches for:
System.map{-{genkernel-$KV,$KV},}
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2007-02-04 10:31:43 UTC
Created attachment 109082 [details, diff]
modules-update.diff

(In reply to comment #6)
> easy enough to add suffix searching, so modules-update now searches for:
> System.map{-{genkernel-$KV,$KV},}

genkernel copies this as e.g. System.map-genkernel-x86-2.6.19-gentoo-r5 (see /usr/share/genkernel/gen_arch.sh) so the above won't match. Getting more PITA than it's worth.
Comment 8 SpanKY gentoo-dev 2007-02-05 00:11:55 UTC
tweaked the code a little to check $(uname -m) followed by a glob

if someone complains that they're using genkernel and so they have multiple arches in /boot/, well their answer is too bad
Comment 9 Lloeki 2007-02-05 08:51:34 UTC
I 'm reporting it works for me (separate /usr, but /boot on /). people having separate /, /boot and /usr will have to cp it to /.

now, if you take a look at some page (cached by google):
http://209.85.135.104/search?q=cache:BrB5aYHpacMJ:dirac.org/linux/system.map/
that does not seem a useless file to me, at least in some certain interesting circumstances.

I may seem obsessive, but I like my computer to be ticking like a swiss clock.
whatever, thanks for having provided a fix. 
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2007-02-21 01:53:53 UTC
*** Bug 167798 has been marked as a duplicate of this bug. ***
Comment 11 Martin Väth 2007-02-21 08:20:10 UTC
It is not some kind of obsession: If System.map is not found then depmod -a is not executed which means that the system will fail to load modules (unless modules-update --force was executed after the module installation and before the reboot which however might easily be forgotten. Recently, I was simply lucky that I could enter a rudimentary system despite the missing modules.)

Similarly, it is also easily forgotten to copy System.map to / (I am one of the people who have /boot and /usr/src/linux on separate partitions, but in the German forums there were also other complaining). Moreover, having several copies of System.map just because of a broken boot-order is IMHO not an appropriate solution.

As remarked in #167798, the problem is that baselayout does not provide a way to mount something (i.e. /boot) before /etc/init.d/modules (calling modules-update) is executed.

Of course, the user must know what he is doing if he interferes here manually (e.g. anything required to mount /boot and to check the filesystems must be compiled into the kernel) but IMHO there should be some "cleaner" mechanism to allow such interference than just hacking the baselayout scripts (because such hacking is lost or has to be done again at the next baselayout update).
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2007-02-23 17:00:34 UTC
*** Bug 168157 has been marked as a duplicate of this bug. ***
Comment 13 Wolfram Schlich (RETIRED) gentoo-dev 2007-02-27 20:50:38 UTC
It should be noted that /sbin/modules-update from the latest
module-init-tools (3.2.2-r2) runs "depmod -a -F /System.map ${KV}"
even if /System.map does not exist!
This should be fixed -- if it cannot find any System.map, it
must not tell depmod to use a non-existant one, resulting
in a line prefixed with "FATAL"...

Next comes a patch that fixes the broken depmod call.
Comment 14 Wolfram Schlich (RETIRED) gentoo-dev 2007-02-27 20:53:29 UTC
Created attachment 111474 [details, diff]
Patch for /sbin/modules-update

Only passes -F /path/to/System.map to depmod if it actually exists.
Comment 15 SpanKY gentoo-dev 2007-03-03 05:41:30 UTC
it's hard to see what all those changes are for when you say you just want to prevent calling depmod on a non-existent System.map ...

by your description, it could be fixed with this one line:
                 [[ -f ${scfg} ]] && cfg=${scfg} && break 2
             done
+            cfg=""
         done
         [[ -n ${cfg} ]] && cfg="-F ${cfg}"
Comment 16 Jakub Moc (RETIRED) gentoo-dev 2007-03-21 10:38:31 UTC
*** Bug 171658 has been marked as a duplicate of this bug. ***
Comment 17 Wolfram Schlich (RETIRED) gentoo-dev 2007-03-23 23:25:46 UTC
(In reply to comment #15)
> it's hard to see what all those changes are for when you say you just want to
> prevent calling depmod on a non-existent System.map ...
> 
> by your description, it could be fixed with this one line:
>                  [[ -f ${scfg} ]] && cfg=${scfg} && break 2
>              done
> +            cfg=""
>          done
>          [[ -n ${cfg} ]] && cfg="-F ${cfg}"
> 

True, although IMHO, this just makes horrible code worse, from
a style point of view.
But I agree that my changes aren't *that* elegant either, so
just add that cfg="" and make us happy ;)
Comment 18 Jimmy.Jazz 2007-03-24 00:11:18 UTC
(In reply to comment #16)
> *** Bug 171658 has been marked as a duplicate of this bug. ***
> 

@Jakub

sorry if i didn't searched well, but that what just an other simple "elegant" solution not just a dumb bug report. :)

Comment 19 SpanKY gentoo-dev 2007-03-24 09:18:12 UTC
added the cfg="" then
Comment 20 Gordon Malm (RETIRED) gentoo-dev 2007-04-07 05:44:53 UTC
I am sorry if I should not be posting to a closed bug but I thought I should try my inquiry here first to see if I could get a response before troubling anyone with a new bug.

I'd like to propose adding /lib/modules/${KV}/ to the search directories for System.map

Rationale being:
-/usr and /boot could be on different partitions at boot time.
-Copying System.map to / doesn't really go very well with multiple kernel versions.

Adding /lib/modules/${KV}/ to the search directories would be trivial and allow individual System.map files for each kernel version, in a reasonable place that is guaranteed to be there at boot.

Or perhaps someone could fill me in as to why this should not be done?  Thank you for your time all.
Comment 21 Gordon Malm (RETIRED) gentoo-dev 2007-04-07 06:14:41 UTC
I remerged module-init-tools to get the latest modules-update and err.. it appears it doesn't matter?  It looks like depmod creates modules.dep even if I remove all System.map files.  Sorry for wasting your time.
Comment 22 SpanKY gentoo-dev 2007-04-07 09:20:19 UTC
added to cvs, cheers