Both times I have installed Gentoo the eth1394 ethernet-over-firewire driver has been autoloaded at some point and apparently prevented the network from functioning. In searching for a similar bug I noticed lots of reports of other bugs that mentioned the module being loaded, and surely none of them were actually running ethernet-over-firewire, so I assume this is some personal hell designed just for me. Still, as it has happened twice now on entirely different hardware I thought i'd better file a bug to make the point that this can happen. The first time was the Gentoo 2004.1 installer on an Athlon XP system with an nForce2 board (Abit NF7-S). This was a show-stopper as I couldn't continue with the install until I learned to take the network down, rmmod eth1394, and bring it back up. That system isn't running Gentoo at the moment, for unrelated reasons, so I can't offer any more info than that (such as whether it was just grabbing eth0 and the other driver was happily functioning as eth1). About a week ago I used the 2005.1 minimal install CD to do a network install on my new Asus Z71v laptop. There was no problem during the install, but after the first reboot, the network failed to function until I again brought it down, removed eth1394, and brought it back up. A little testing shows that if eth1394 is loaded before skge, it apparently functions as eth0 and skge is eth1, but of course I hadn't had a reason to create /etc/init.d/net.eth1. Anyway, the fix is easy, at least if you're not actually doing ethernet-over-firewire: "alias eth1394 off" in /etc/modules.d/local or something. I guess you could just use eth1 as your ethernet device as well. I I listed it as a minor bug, because it is if you understand what is happening, but for someone trying to install Gentoo for the first time it could make the difference between installing Gentoo or not. I'm not sure whether there is a better fix--maybe a few people actually do an ethernet-over-firewire install, unlikely as that seems, so it can't be blacklisted in the installer or something. But perhaps you could ensure it is loaded after any regular NIC drivers so that if a regular NIC is available it is eth0? Also, a note in the install manual at the appropriate point might save someone a lot of trouble. I'd offer a patch for the manual, but I don't know the format you use. Dustin Reproducible: Always Steps to Reproduce: 1. /etc/init.d/net.eth0 stop 2. rmmod skge 3. modprobe eth1394 4. modprobe skge Actual Results: laurence@lindy ~ $ ping gateway PING gateway (72.25.87.1) 56(84) bytes of data. From lindy.laurences.net (72.25.87.158) icmp_seq=1 Destination Host Unreachable From lindy.laurences.net (72.25.87.158) icmp_seq=2 Destination Host Unreachable From lindy.laurences.net (72.25.87.158) icmp_seq=3 Destination Host Unreachable --- gateway ping statistics --- 5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4000ms , pipe 3 laurence@lindy ~ $ Expected Results: laurence@lindy ~ $ ping gateway PING gateway (72.25.87.1) 56(84) bytes of data. 64 bytes from gateway (72.25.87.1): icmp_seq=1 ttl=64 time=25.6 ms 64 bytes from gateway (72.25.87.1): icmp_seq=2 ttl=64 time=8.04 ms 64 bytes from gateway (72.25.87.1): icmp_seq=3 ttl=64 time=7.16 ms --- gateway ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 7.161/13.613/25.632/8.506 ms laurence@lindy ~ $ Here is 'emerge info' on the laptop as requested, but the problem initially arose right after the install, before I had done more than a bare minimum of fiddling with the USE flags. lindy init.d # emerge info Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.13-suspend2-r4-basic-05.11.28-01 i686) ================================================================= System uname: 2.6.13-suspend2-r4-basic-05.11.28-01 i686 Intel(R) Pentium(R) M processor 1.73GHz Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 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.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac aalib acl acpi alsa apache2 audiofile avi berkdb bitmap-fonts bzip2 cdparanoia cdr crypt cups doc dvd dvdr eds emboss encode exif expat fam ffmpeg fftw foomaticdb fortran gcj gd gdbm gif glut gnome gpm gstreamer gtk gtk2 hal howl ieee1394 imagemagick imap imlib ipv6 jack jpeg ladcca lcms ldap libg++ libwww mad maildir mikmod mng mozilla mp3 mpeg ncurses nls nsplugins ogg oggvorbis opengl pam pcmcia pcre pdflib perl png postfix python quicktime readline scanner sdl speex spell ssl svg tcpd theora tiff truetype truetype-fonts type1-fonts udev usb v4l vcd vhosts vorbis wifi win32codecs wmf xine xml2 xmms xpm xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY lindy init.d #
Erm, nofirewire option does not work?
Not a problem with the release media... sending to the docs-team to see what they want to do with it (if anything)
(In reply to comment #2) > Not a problem with the release media... sending to the docs-team to see what > they want to do with it (if anything) Maintaining a list of every possible way to break your box? I don't think so.
Upstream bug http://bugzilla.kernel.org/show_bug.cgi?id=7793 was closed, fix went into mainline for 2.6.22-rc1. Note, after that fix ieee1394 will still generate a hotplug event to let userspace load eth1394 if it detects an external IP-over-1394 capable device.
Well, if there's anything that needs changing in the docs, please let us know, otherwise thanks for info :).
