Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 23653 - install procedure won't work when a kernel is chosen that doesn't have nic module bundled with it
Summary: install procedure won't work when a kernel is chosen that doesn't have nic mo...
Alias: None
Product: [OLD] Docs-user
Classification: Unclassified
Component: Gentoo Linux x86 Installation Guide (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Docs Team
Depends on:
Reported: 2003-06-28 13:05 UTC by Peter Lietz
Modified: 2003-06-29 07:00 UTC (History)
0 users

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


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Lietz 2003-06-28 13:05:08 UTC
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?
Comment 1 Andrew Bevitt 2003-06-28 18:24:12 UTC
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.
Comment 2 Sven Vermeulen (RETIRED) gentoo-dev 2003-06-29 03:00:27 UTC
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. 
Comment 3 Peter Lietz 2003-06-29 04:47:44 UTC
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.
Comment 4 Sven Vermeulen (RETIRED) gentoo-dev 2003-06-29 04:54:00 UTC
yeah, the bcm4400 ebuild is broken then, the use of check_kv and ${KV} should be propagated.
Comment 5 Peter Lietz 2003-06-29 05:13:26 UTC
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.
Comment 6 Sven Vermeulen (RETIRED) gentoo-dev 2003-06-29 06:50:09 UTC
I'll open for reconsideration...
Comment 7 Sven Vermeulen (RETIRED) gentoo-dev 2003-06-29 07:00:11 UTC
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?".