On a ShuttleX box with built-in RTL8139 ethernet, and genkernel-3.4.4 used to compile linux-2.6.18-gentoo with its default .config, booting with the resulting initrd and kernel, the Intel PRO/1000 Network Driver is loaded, which precludes the correct RealTek 8139too driver from being loaded (or even attempted), which means the box has no ethernet. Needless to say there's no Intel PRO/1000 in the box. Booting with a stock Ubuntu kernel correctly finds the 8139 and loads the driver for it. Here's how emerge --info looks when chrooted from Ubuntu (some stuff is less than current since I'm moving an existing system over from older hardware): System uname: 2.6.17-10-386 i686 AMD Athlon(tm) XP 1800+ Gentoo Base System version 1.6.14 Last Sync: Tue, 02 Jan 2007 03:00:01 +0000 dev-lang/python: 2.2.3-r6, 2.3.5-r2, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.4.19-r1, 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -fprefetch-loop-arrays -funroll-loops -fstack-protector -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/X11/xkb /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -fprefetch-loop-arrays -funroll-loops -fstack-protector -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_ZW.UTF-8" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm arts berkdb bitmap-fonts cli cracklib crypt cups dlloader dri eds emboss encode esd foomaticdb fortran gdbm gif gpm gstreamer gtk gtk2 iconv imlib ipv6 isdnlog jpeg kde libg++ libwww mad mbox mikmod motif mp3 mpeg ncurses nls nptl ogg opengl oss pam pcre perl png pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev vorbis x86 xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" USERLAND="GNU" VIDEO_CARDS="apm ark ati chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mga neomagic nsc nv rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
We really can't guess, reopen once you've posted the relevant part of dmesg output. Also try w/ gentoo-sources-2.6.18-r6 or newer. Thanks.
This is with gentoo-sources-2.6.18-r6. Sorry I wasn't that specific. Here's all that appears pertinent from dmesg: Intel(R) PRO/1000 Network Driver - version 7.1.9-k4 Copyright (c) 1999-2006 Intel Corporation. I have no idea why that's loading. But shortly after it loads other logs show failures of anything that depends on eth0 being there - there is no eth* device created at all. All that follows in dmesg is: ieee1394: Host added: ID:BUS[0-00:1023] GUID[00301bab0000f274] Adding 987988k swap on /dev/hdd2. Priority:-1 extents:1 across:987988k Real Time Clock Driver v1.12ac So it's not even trying to load the correct driver. The question would be what the code is that's reading the onboard RealTek ethernet adaptor as the Intel device instead - and also why it doesn't recognize that loading the Intel device driver isn't effective (with Ubuntu, it tries a different RealTek driver first, recognizes that it fails, then goes to the one that works). Guess this is what I get for trying to be lazy for once and use genkernel.
Found the solution, which has a couple of layers. Updating baselayout resulted in the right driver being found - but being assigned to eth1 since the Intel PRO/1000 is evidently part of the support for "ethernet over firewire," and that was taking eth0 - despite there being no firewire hardware in the box for ethernet to go over. So there's still a "wrong driver" problem; but the right driver is found if the baselayout version dependency (which genkernel doesn't know about) is met. So maybe the bug is resolved. But these things might be considered: Should there be a baselayout version dependency enforced by the genkernel ebuild? And is there a bug in the hotplug stuff that sees a box as having firewire - and thus installs a driver for it - when there's not? Another genkernel question: why does it even includes obscure stuff like ethernet over firewire, when doesn't have even the most basic iptables support by default, even as a module? At the least the genkernel docs might mention that the firewire stuff needs to be turned off to prevent eth0 being needlessly taken in some systems (which I see in the forums has tripped up many people), that baselayout should be the latest version first, even though genkernel doesn't consider it a dependency, and that anyone wanting even the most basic firewall needs to enable iptables. Maybe promoting genkernel as an "easier" option in the general docs is also a bug. Working around this stuff is at least as much trouble as just building a custom kernel, isn't it?
The intel driver is nothing to do with eth1394, but the following question does remain: - why is e100 being loaded? (probably because it's built into kernel, i.e. this doesnt matter at all) the other considerations are unrelated to this "bug" but may be valid - I suggest you raise them on the releng mailing list and then file bugs for each one if no reasonable explanation for the current behavior is provided.
Uhh... genkernel does load network drivers for the e1000 cards, but that has nothing to do with them binding to your card, which they aren't, judging from your output. I'm not really sure what you're looking for, since genkernel adds all of the drivers as modules. If you're having an issue with network drivers being loaded/not loaded, then you need to look at hotplug/coldplug/udev/whatever. It isn't genkernel doing it. It sounds to me like you aren't loading the module for your hardware, which genkernel isn't responsible for doing. It's up to you to use either coldplug or a newer udev that does coldplugging, or to include your drivers in /etc/modules.autoload.d/kernel-2.6 for yourself.
Daniel, Good suggestions. If I find time I'll get involved in the releng list. Meanwhile there's one specific genkernel bug revealed in this complex experience that really should be addressed: Chris, I'm reopening this because you're judging it without carefully reading what I've already submitted. After updating baselayout, the correct ethernet driver is loaded - although prior to that the invalid-for-this-system firewire driver is loaded, which takes eth0. I haven't yet posted the logs showing that - the logs shown are from before updating the baselayout package. It is specifically, as I said a couple of times, a bug in genkernel that it does not enforce a dependency on a compatible version of baselayout. Because it does not do that, it results in a kernel which will not - as I've discovered - load the correct ethernet driver - or the incorrect one. If the genkernel ebuild were to require an adequate baselayout, then yes the proper driver loads without any extra fussing with hotplug/coldplug/udev. That the damn firewire driver has also loaded by then is probably a separate bug to file against hotplug/udev. But meanwhile there's a specific bug in the lack of dependency awareness of the genkernal ebuild that should be fixed. (If someone's going to make a "won't fix" judgment about that bug, then it's a documentation bug not to mention that this unfixed dependency bug is being left in genkernel. So either please plan to fix the bug, or transfer this current report to the genkernel documentation crew.)
No. A genkernel-created kernel does *not* require *any* version of baselayout. In fact, it doesn't require baselayout, at all. It can (and is) used to create kernel images by Release Engineering that don't use baselayout. I already told you that the problem *is* baselayout/udev/coldplug/etc, which is beyond the scope of genkernel. As for documentation, the Handbook[1] already has that covered. Specifically, look at code listing 20. [1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7#doc_chap4 What you have reported is not a bug in genkernel, at all. It is a misconfiguration on your system. It is not a dependency issue, either. Anyway, I'm marking this as INVALID, rather than WONTFIX, because there's no bug in genkernel, whatsoever. You had nothing configured to load the modules before, and were expecting them to be loaded for you when the system wasn't configured that way. Since your upgrades, something *is* setup to load the modules, which is why the upgrade seemed to have "fixed" the problem, which was really a configuration issue to begin with.
Sorry if that didn't make much sense... basically, you had nothing autoloading modules, and now you do (likely thanks to a udev upgrade, rather than baselayout)...
For the record, I didn't upgrade udev. The upgrade that resulted in the proper module loading was specifically and only baselayout. And as for emerging coldplug, I did no fresh upgrade or emerge on that either. This is a baselayout dependency. I don't know the internals of it to specify why and how - that's frankly your job. The system was failing as I documented above. At that point I updated baselayout - and only baselayout. Then it worked. This is a direct, experimental proof of dependency. Not, granted, a dependency necessary to compile a genkernel, but a dependency necessary to use the result. As for Release Engineering, I don't know their product or its environment. I have to suspect they achieve in some way the equivalent of what baselayout does (whatever it is that's pertinent here). But since we're talking Gentoo here, and since all (or 99+%) Gentoo installs involve a baselayout as part of the core of the system, then for, then genkernel - if the kernel it is producing is to work in the context of a Gentoo system - should insist on a current-enough baselayout. If that gets in the way of Release Engineering's use, they can always override the dependency. The goal with ebuild dependencies should be to serve the vast majority of users, not the rare exceptions, right?
OK. I'm going to explain this as *simply* as I can. GENKERNEL DOES NOT REQUIRE BASELAYOUT Period. It has *NO* dependency on *ANY* version of baselayout being present to function. Hell, genkernel works on non-Gentoo. Now, if there was something funky going on with *your* system, then it was something system-specific. I will say this again. GENKERNEL DOES NOT REQUIRE BASELAYOUT I am not, and will not, add an artificial dependency to genkernel that is not required in any way. DO NOT REOPEN THIS BUG. I don't really know how much simpler I can make this.
