My ASUS motherboard has an onboard broadcom nic. The module needed is in the latest gentoo-sources kernel, but not in the latest vanilla-kernel. When opting for vanilla, one needs the bcm4400 ebuild, and then everything's fine. However, during initial installation, you can't emerge the ebuild *before* the first reboot, as that would install the module in /lib/modules/gentoo-sources... and you can't afterwards because you won't have net, then. It wasn't a problem for me, but might be a stopper for noobs. Also, asus boards are ubiquitus (o.t.o.h., most gentooists won't opt for vanilla, but if they do, the problem arises). Reproducible: Always Steps to Reproduce: 1. follow install proc's choosing a vanilla kernel on, say, a recent ASUS mb with broadcom nic. Actual Results: after reboot ethernet doesn't work Expected Results: it should Or is it maybe not a bug in the doc's but rather in the bcm4400 ebuild? Where should the module be installed? In the modules dir for the running kernel (aka `uname -r`) or in the one that /usr/src/linux points to?
It may be a tad trivial but could you just emerge --fetch bcm440 to download the modules and then fully emerge them after your first reboot. In regards to the detection of the running kernel, there would not be an easy way to determine what kernel is going to be booted after reboot without asking the user, which isnt really ebuild intuitive. We could add a variable such as ALSA_CARDS for the alsa ebuild to tell portage which /lib/modules/ directory to install into but that functionality would be very specific to the install -- something that the user must be aware of, but if we are going to point out little things like that there is the potential for a _long_ list to begin to develop of certain circumstances which isnt really efficient.
First of all, thanks for the feedback! Now, I second Andrew's opinion concerning the fact that listing all possible circumstances would be almost impossible, or at least not efficient. Also, it's trivial that when a kernel doesn't support some hardware, that the hardware won't work :) We (Gentoo) can't do much about that. It's good to know that gentoo-sources does support it, but as I see it, this shouldn't be mentioned.
I agree that the install doc must by no means lose itself in particularities. However, it should be self-contained and cover this not at all uncommon case (b.t.w. it also affects ck-sources). I don't think the statement "it's trivial that when a kernel doesn't support some hardware, that the hardware won't work" applies here. The kernel does support the hardware, provided you install the required module, too. This is what we do with ALSA all the time. So I did a little research: The alsa-driver ebuild for instance uses the KV (kernel version) variable provided by portage, which is extracted from the /usr/src/linux link. This is far more reasonable than using `uname -r`, as done in the bcm4400 ebuild. I'll file this as a bug for bcm4400.ebuild and by the time this is changed, I will propose that the install doc suggests that after kernel compilation, modules are installed if they aren't already in the kernel proper. So for the time being, nothing needs to be changed in the install doc.
yeah, the bcm4400 ebuild is broken then, the use of check_kv and ${KV} should be propagated.
Oops, sorry all. I looked at the bcm4400 ebuild again and I think in principle it should work, don't know what got me confused before. The Makefile of the original source package uses `uname -r` but the ebuild does use a sed command to replace that with $KV! So, given that that actually works, I suggest to add a one line comment after the kernel compile as to emerging the module required for the nic, if it isn't already in the kernel itself.
I'll open for reconsideration...
Sorry, still have to say "no go". For instance, the ebuild you are referring to is not available for x86, only ~x86. There are also very few modules available as ebuild. The installationguide already sais that, if you need it, you should compile your kernel with support for your network card. If you notice that the kernel doesn't support it, you normally don't have any options. You got lucky - there is an ebuild that provides a module. But for 99% of the unsupported hardware, this won't be the case. Mentioning that you should emerge the module if the kernel doesn't provide it will give ppl false hope of support, create more bug reports as in "where do I find the module for XYZ?".
