In this section there are a few content issues: 6. Reinstalling external modules <snip> To ensure these packages will build against the source tree at /usr/src/linux, first uninstall the packages, then re-emerge them. --------- Why uninstall then re-emerge them? Re-emerge-ing will uninstall the old versions anyways.. --------- If old sources for these packages are kept by portage, this uninstall/re-emerge procedure will make sure that they are rebuilt to work with the new kernel. --------- What old sources? The only sources portage will keep is the kernel ones. It never keeps module sources. I'm really not sure on the direction of this statement. ---------
Daniel, any suggestions?
Chris' comments are correct, the content he highlights is wrong. I just checked the original submission of the document and this content have been added since then (i.e. I did not author this part of the content). You should probably go over the logs and confirm with whoever committed it.
bug #93289 was the commit with the new information.
Created attachment 78661 [details, diff] kernel-upgrade.xml.patch Took out the totally bogus uninstall/reinstall stuff. :)
There is another content problem in that section: We provide you with an easy tool (sys-kernel/module-rebuild) which rebuilds all the kernel modules you have installed using separate ebuilds (for the currently running kernel, not necessarily the one in /usr/src/linux). The part in brackets is incorrect, it builds against the kernel at /usr/src/linux. This came from bug #118060. CCing original contributor.
Personally, I would do away with anything that references kernel module rebuids other than a little comment saying "Not all modules might honour this system, and as such a bug should be logged and the module merged manually using 'emerge -1 <mymodulehere>'" after a section about module-rebuild. Furthermore, I would say this: "We provide you with an easy tool (sys-kernel/module-rebuild) to re-compile any kernel module that portage has tracked as being installed (using the linux-mod eclass) against the kernel sources which exist in /usr/src/linux. For more information please see 'module-rebuild -h'."
(In reply to comment #5) > There is another content problem in that section: > > We provide you with an easy tool (sys-kernel/module-rebuild) > which rebuilds all the kernel modules you have installed using > separate ebuilds (for the currently running kernel, not > necessarily the one in /usr/src/linux). > > The part in brackets is incorrect, it builds against the kernel at > /usr/src/linux. This came from bug #118060. CCing original contributor. It seems you're correct; I did some alternative kernel compiling and switching, and this is indeed the case. However, when I first added this section, I took the text straight from the output of module-rebuild (w/no args): populate - Populate the database with any packages which currently install drivers into the running kernel. Granted, this is for populate, not rebuild, but they go hand in hand. The help page itself is misleading, it seems. Will correct this in the guide at once. Oh, and I took myself off the CC list, as I'm already on the docs-team alias. (Thanks, though, DSD :). )
Created attachment 78729 [details, diff] kernel-upgrade.xml.patch Fixed module-rebuild description as promised in the above comment. Also removed "after you reboot" from the end of the paragraph. After all, these are modules we are building, so they are usable right away, i.e. without rebooting :). @johnm: none of that is necessary. The eclass is irrelevant for the purposes of this doc. So is the "ebuilds don't honor this" section--I've yet to find modules that require recompilation for each kernel tweak that do *not* get rebuilt by module-rebuild (point me at one if I'm wrong, though.) As it is, the note is straightforward and to the point. Oh, and "module-rebuild -h" is an invalid command. So is module-rebuild --help, -H --H, or anything else. It really can only be run without any arguments to get the info screen. :)
Fixed in CVS. Thanks for reporting.
