After updating to udev-132 and rebooting afterwards, udev renamed eth0 to eth1 for no apparent reasons. Luckily, it was just my workstation being affected (I simply had to change config_eth0 etc. to config_eth1), if it had been a remote computer the problem would be quite severe! tower init.d # dmesg | grep eth0 skge eth0: addr 00:0e:a6:68:af:0b udev: renamed network interface eth0 to eth1 Reproducible: Always Steps to Reproduce: 1. emerge =sys-fs/udev-132 2. reboot 3. Actual Results: No network (since eth0 is eth1) tower init.d # emerge --info Portage 2.2_rc14 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r0, 2.6.27-gentoo-r2 x86_64) ================================================================= System uname: Linux-2.6.27-gentoo-r2-x86_64-AMD_Athlon-tm-_64_Processor_3000+-with-glibc2.2.5 Timestamp of tree: Sat, 15 Nov 2008 14:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.5.2-r8 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo " LANG="de_DE.UTF-8" LC_ALL="de_DE.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X a52 aac acl acli acpi aim alsa amd64 apm audiofile bash-completion berkdb bluetooth branding bzip2 cairo calendar cdb cddb cdparanoia cdr clamav cli cracklib crypt css ctype cups dbus dri dv dvb dvd dvdr dvdread emacs encode exif expat fam ffmpeg flac fontconfig fortran ftp gdbm gif gimp glut gnuplot gphoto2 gpm gps graphviz hal htmlhandbook iconv icq imagemagick innodb ipv6 irc isdnlog jabber java java6 joystick jpeg jpeg2k kde lame latex lcms libnotify libwww lm_sensors logitech-mouse loop-aes maildir man mhash midi mime mmap mmx mng mp3 mpegmplay msn mudflap multilib musepack musicbrainz mysql ncurses nls nntp nptl nptlonly nspluginntpl offensive ogg openexr opengl openmp pam pcre pda pdf perl png pppd python qt3 qt3supportqt4 readline reflection rss scanner sdl session sox spl sqlite sse sse2 ssl startup-notification subversion suid svg sysfs syslog taglib tcpd themes theora threads tiff timidity truetype unicode usb v4l v4l2 vcd vnc vorbis wavpack webkit wmf x264 xattr xine xml xorg xosd xpn xscreensaver xulrunner xv xvid yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3trident 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 mmap_emul mulawmulti null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="fglrx" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I have this bug also.
Looks like sys-fs/udev-132 has multiple issues wich can lead to breaking network or mounting local filesystems during boot up. See also bugs #246849 and #246938. So I suggest masking sys-fs/udev-132 until this issue is resolved/
Same here, except that I had no network at all (forcedeth as a module). Had to revert to udev-125-r1 to get things working again. Do indeed mask udev-132. I'll be happy to receive betas for testing.
Same bug? I get a segfault (~amd64) and repeated (at about 1 second intervals) complaints on the console. Reverting back to 130-r1 works. Nov 16 08:36:56 xxx [ 46.843671] udevd[2189]: segfault at 0 ip 409678 sp 7fff759d5b78 error 4 in udevd[400000+14000] I am not going to worry much about this since -132 seems to have several other problems.
udev-132 is masked for now until we know what is going on here.
(In reply to comment #4) > I get a segfault (~amd64) and repeated (at about 1 second intervals) > complaints on the console. Reverting back to 130-r1 works. > > Nov 16 08:36:56 xxx [ 46.843671] udevd[2189]: segfault at 0 ip 409678 sp > 7fff759d5b78 error 4 in udevd[400000+14000] Felix, if possible, can you provide the output of: addr2line -e /sbin/udevd 7fff759d5b78 ? Maybe you need to leave the debug info in the binary, and not strip it.
(In reply to comment #0) > After updating to udev-132 and rebooting afterwards, udev renamed eth0 to eth1 > for no apparent reasons. What's the content of: /etc/udev/rules.d/70-persistent-net.rules
(In reply to comment #7) > What's the content of: > /etc/udev/rules.d/70-persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # PCI device 0x10b7:0x1700 (skge) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0e:a6:68:af:0b", NAME="eth0" # PCI device 0x10b7:0000:00:0a.0 (skge) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0e:a6:68:af:0b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
> (In reply to comment #7) > DRIVERS=="?*", ATTRS{address}=="00:0e:a6:68:af:0b", NAME="eth0" Thanks! DRIVERS and ATTRS are not the same device, which is likely the reason the rule does not match, and a new rule is created. Maybe an older rule generator used ATTRS instead of ATTR here, the current one uses ATTR. I think, we should s/ATTRS{address}/ATTR{address}/ in the udev generated rules file on udev update, to update older rules to the current format.
(In reply to comment #6) > (In reply to comment #4) > > I get a segfault (~amd64) and repeated (at about 1 second intervals) > > complaints on the console. Reverting back to 130-r1 works. > > > > Nov 16 08:36:56 xxx [ 46.843671] udevd[2189]: segfault at 0 ip 409678 sp > > 7fff759d5b78 error 4 in udevd[400000+14000] > > Felix, if possible, can you provide the output of: > addr2line -e /sbin/udevd 7fff759d5b78 > ? I remerged -132 and tried that, but it only gave me the perlish ??:0. How do I emerge -132 and keep the debug info? I guess I don't need to reboot, right? Just emerge -132, addr2line, and emerge -130, no restarts, no reboot?
(In reply to comment #10) > I remerged -132 and tried that, but it only gave me the perlish ??:0. How do I > emerge -132 and keep the debug info? I guess I don't need to reboot, right? > Just emerge -132, addr2line, and emerge -130, no restarts, no reboot? According to: http://wren.gentoo.org/doc/en/bugzilla-howto.xml#doc_chap2 passing: FEATURES="nostrip" should preserve the debug info.
(In reply to comment #11) > (In reply to comment #10) > > > I remerged -132 and tried that, but it only gave me the perlish ??:0. How do I > > emerge -132 and keep the debug info? I guess I don't need to reboot, right? > > Just emerge -132, addr2line, and emerge -130, no restarts, no reboot? > > According to: > http://wren.gentoo.org/doc/en/bugzilla-howto.xml#doc_chap2 > passing: > FEATURES="nostrip" > should preserve the debug info. Didn't seem to do squat. I still got ??:0. But it did change the file size from 88840 (-130-r1) and 84608 (-132) to 101782 (-132 nostrip).
(In reply to comment #9) > I think, we should s/ATTRS{address}/ATTR{address}/ in the udev generated rules > file on udev update, to update older rules to the current format. I think so as well. Changed the rule manually, so for me downgrading after the masking would probably break things again. The name "ATTR" comes from /lib/udev/write_net_rules but this only gets invoked via /lib/udev/rules.d/75-persistent-net-generator.rules if the old rule doesn't match. Maybe one could modify write_net_rules to do the migration, but that seems somewhat unclean. Having the ebuild do it looks better to me. I guess with the cause of the problem identified, there is not much need to get debug-enabled udev builds, is there?
(In reply to comment #13) > (In reply to comment #9) > > I think, we should s/ATTRS{address}/ATTR{address}/ in the udev > > generated rules file on udev update, to update older rules to > > the current format. > > I think so as well. Changed the rule manually, so for me downgrading > after the masking would probably break things again. ATTR instead of ATTRS should work on older versions just fine. > The name "ATTR" comes from /lib/udev/write_net_rules but this only > gets invoked via /lib/udev/rules.d/75-persistent-net-generator.rules > if the old rule doesn't match. Maybe one could modify write_net_rules > to do the migration, but that seems somewhat unclean. Having the > ebuild do it looks better to me. Yeah, other distros "sed" some rules on update too. > I guess with the cause of the problem identified, there is not much need > to get debug-enabled udev builds, is there? No, not for that bug. The debug build was about the segfault Felix was seeing. We found a bug, which is likely the cause of that, and hopefully fixed in the just released udev 133.
The migration suggested by Kay (ATTRS -> ATTR) is implemented in udev-133. As this is unmasked now, please test if this version works.
(In reply to comment #15) > The migration suggested by Kay (ATTRS -> ATTR) is implemented in udev-133. > As this is unmasked now, please test if this version works. > Well, I did test it - and got *exactly* the same problem, after rebooting eth0 was being renamed to eth1. I solved this problem by deleting 70-persistent-net.rules and rebooting (deleting the file and using udevadm had resulted in a persisent eth1 rule - without an eth0 entry, though). After that, everything worked fine. This is what 70-persistent-net.rules looked after rebooting the first time: -------------------8<------------------------------------------------------ # This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # PCI device 0x10b7:0x1700 (skge) SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0e:a6:68:af:0b", KERNEL=="et h*", NAME="eth0" # PCI device 0x10b7:0000:00:0a.0 (skge) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0e:a6:68:af:0 b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" --------------------------->8---------------------------------------------- (Note that ATTRS has been renamed to ATTR) This is what 70-persistent-net.rules looks after deleting it and rebooting: --------------------------------8<-------------------------------------- # This file was automatically generated by the /lib64/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key. # PCI device 0x10b7:0x1700 (skge) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0e:a6:68:af:0 b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" ------------------------>8-------------------------------------------------- So I guess the easiest way to upgrade is simply deleting 70-persistent-net.rules (and maybe recreating it using udevadm... otherwise it's being created at reboot).
(In reply to comment #16) > Well, I did test it - and got *exactly* the same problem, after rebooting eth0 > was being renamed to eth1. I solved this problem by deleting > 70-persistent-net.rules and rebooting Hmm, it should work, as least it works for me here. > (deleting the file and using udevadm had > resulted in a persisent eth1 rule - without an eth0 entry, though). That is expected, deleting the file and running "trigger" immediately after that will make the _current_ names persistent again. Because at that time the interface was already eth1, eth1 will be written to the file. Only a reboot or a module unload/load would create an eth0 entry. The comment printed at update is a bit misleading, it will likely _not_ change any interface name. And running "trigger" that time is probably exactly not what people want, if the interfaces are already named differently from what people like them in this moment. > After that, everything worked fine. Yeah, that should work of course, but is not exactly what we want. > This is what 70-persistent-net.rules looked after rebooting the first time: > > -------------------8<------------------------------------------------------ > # This file was automatically generated by the /lib/udev/write_net_rules > # program, probably run by the persistent-net-generator.rules rules file. > # > # You can modify it, as long as you keep each rule on a single line. > > # PCI device 0x10b7:0x1700 (skge) > SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0e:a6:68:af:0b", > KERNEL=="et > h*", NAME="eth0" > > # PCI device 0x10b7:0000:00:0a.0 (skge) > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", > ATTR{address}=="00:0e:a6:68:af:0 > b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" That's weird. The rule should match and prevent the rule-generator from running and add another one, and it works fine if I copy your rules to my box, only with the address replaced. Before the update, the file did not already contain the duplicate entries from the earlier package? If it didn't, can it be that something has triggered events during the update, while the new udev was running, but _before_ the rules got the ATTRS/ATTR replacement? > So I guess the easiest way to upgrade is simply deleting > 70-persistent-net.rules (and maybe recreating it using udevadm... otherwise > it's being created at reboot). We should preserve the file, it should work, or we need to make it work.
udev-132 is gone now. This should no longer happen, because udev-130-r1 DOES work with the older rules format, and udev-133 ebuild will fix the rules as soon as it gets installed.
(In reply to comment #17) > Before the update, the file did not already contain the duplicate entries from > the earlier package? Uhh - might be, I haven't touched this file myself since 132. So it's quite probable that the eth1 entry was present. Regards, Mark
udev-133 still results in no ethernet for me. reverting to udev-130-r1 continues to work fine
Please attach /etc/udev/rules.d/70-persistent-net.rules. I likely contains duplicate entries from the earlier 131/132 versions, which must be removed.
I've never altered or deleted this file. My only network interface should be eth0. # This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # PCI device 0x10de:0x0066 (forcedeth) SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0b:6a:f3:5b:98", KERNEL=="eth*", NAME="eth0" # PCI device 0x10de:0000:00:04.0 (forcedeth) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0b:6a:f3:5b:98", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
(In reply to comment #22) > I've never altered or deleted this file. But the earlier version of udev 131/132 added the second entry which causes the error now. The current version should not add entries like this. > My only network interface should be eth0. If you delete the "eth1" rule, or the whole file, and reboot, all should be fine. And do _not_ run "udevadm trigger" before you reboot.
Deleted the file and let it be recreated at boot, now everything works fine. Thanks for the advice.
I copied 70-persistent-net to a local directory which is safe from emerge and reboot, upgraded to -133, deleted 70-persistent-net (which I only realized after deleting it had the current time, as if the new emerge had rewritten it even without it being deleted), rebooted, and things seem to be working fine so far. There currently is NO 70-persistent-net file. I am tempted to remerge -133 and see if it regenerates 70-persistent-net and what it might put in it, but frankly, I am tired of this bug and I think I will just leave it be. It seems to be working without a 70-persistent-net, and no doubt there will be another udev upgrade someday.
udev-133 seems to be working just fine here. No real anomalies seen yet. Using hibernate though. Not sure if I've done a full reboot yet.
Marking as fixed, as nobody seems to still have this problem. Btw. the persistent-rules are generated when the device appears (most likely at reboot), and not at emerge time of udev.
cr*p. just did a cold boot and found net.eth0 not starting. Probably still renaming to eth1?
(In reply to comment #28) > just did a cold boot and found net.eth0 not starting. Probably still > renaming to eth1? Please attach: /etc/udev/rules.d/70-persistent-net.rules and ls /sys/class/net Maybe you still need to remove duplicate entry which was added by the earlier release, which is now fixed.
/etc/udev/rules.d/70-persistent-net.rules: # PCI device 0x8086:0x1229 (e100) SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:90:27:c6:b1:08", KERNEL=="eth*", NAME="eth0" # PCI device 0x8086:0000:00:14.0 (e100) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:90:27:c6:b1:08", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" ls -alh /sys/class/net total 0 drwxr-xr-x 6 root root 0 Nov 29 17:47 . drwxr-xr-x 44 root root 0 Nov 30 02:47 .. drwxr-xr-x 4 root root 0 Nov 29 17:47 dummy0 drwxr-xr-x 4 root root 0 Nov 29 17:47 eth1 drwxr-xr-x 4 root root 0 Nov 29 17:47 lo drwxr-xr-x 4 root root 0 Nov 29 17:47 tunl0 Yup. removed the second "eth1" entry from the 70-persistent-net.rules file. Reboot and/or udevadm trigger results showing fixed now.
