Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
I posted about this on the Gentoo forums: http://forums.gentoo.org/viewtopic-t-523904-highlight-.html The symptoms are that net.lo on startup fails, saying: SIOCSIFADDR: File exists SIOCSIFFLAGS: Cannot assign requested address SIOCSIFNETMASK: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address Also, if I try to do a /etc/init.d/net.lo start/stop a couple of times, it turns out that this behaviour only occurs on alternate "net.lo start"s: loki keycodes # /etc/init.d/net.lo stop * WARNING: you are stopping a boot service. * Stopping lo * Bringing down lo * Shutting down lo ... [ ok ] loki keycodes # /etc/init.d/net.lo start * Starting lo * Bringing up lo * 127.0.0.1/8 SIOCSIFADDR: File exists SIOCSIFFLAGS: Cannot assign requested address SIOCSIFNETMASK: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address [ !! ] loki keycodes # /etc/init.d/net.lo stop * WARNING: net.lo has not yet been started. loki keycodes # /etc/init.d/net.lo start * Starting lo * Bringing up lo * 127.0.0.1/8 [ ok ] * Adding routes * 127.0.0.0/8 ... [ ok ] loki keycodes # /etc/init.d/net.lo stop * WARNING: you are stopping a boot service. * Stopping lo * Bringing down lo * Shutting down lo ... [ ok ] loki keycodes # /etc/init.d/net.lo start * Starting lo * Bringing up lo * 127.0.0.1/8 SIOCSIFADDR: File exists SIOCSIFFLAGS: Cannot assign requested address SIOCSIFNETMASK: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address [ !! ] loki keycodes # /etc/init.d/net.lo stop * WARNING: net.lo has not yet been started. loki keycodes # /etc/init.d/net.lo start * Starting lo * Bringing up lo * 127.0.0.1/8 [ ok ] * Adding routes * 127.0.0.0/8 ... [ ok ] I initially thought it might be either dhcpcd 3.0.6, sysvinit-2.86-r6 or baselayout-1.12.7. hiziki_gard had the same problem and the patience to test this through and he ascertained that the problem was with baselayout-1.12.7. I have now downgraded to baselayout-1.12.6 and can confirm that the symptoms I experienced no longer are present. Multiple net.lo start/stops now give the following: loki keycodes # /etc/init.d/net.lo stop * WARNING: you are stopping a boot service. * Stopping lo * Bringing down lo * Shutting down lo ... [ ok ] loki keycodes # /etc/init.d/net.lo start * Starting lo * Bringing up lo * 127.0.0.1/8 [ ok ] * Adding routes * 127.0.0.0/8 ... [ ok ] loki keycodes # /etc/init.d/net.lo stop * WARNING: you are stopping a boot service. * Stopping lo * Bringing down lo * Shutting down lo ... [ ok ] loki keycodes # /etc/init.d/net.lo start * Starting lo * Bringing up lo * 127.0.0.1/8 [ ok ] * Adding routes * 127.0.0.0/8 ... [ ok ] loki keycodes # /etc/init.d/net.lo stop * WARNING: you are stopping a boot service. * Stopping lo * Bringing down lo * Shutting down lo ... [ ok ] loki keycodes # /etc/init.d/net.lo start * Starting lo * Bringing up lo * 127.0.0.1/8 [ ok ] * Adding routes * 127.0.0.0/8 ... [ ok ] I noticed that baselayout-1.12.7 made some changes to the net.lo script, so it's probably there the culprit is to be found. P.S. I see that mbar, editing his posting in the aforementioned thread has another gripe to add: EDIT: And what is worse, for me the / filesystem (ext2) does NOT get unmounted cleanly on reboot/shutdown and this causes long fsck during next boot. Pooooo! I cannot confirm this. Just thought I'd mention it.
Created an attachment (id=103891) [details] emerge --info
same thing here, problem is caused by baselayout-1.12.7.
I am also having the same problems after updating to 1.12.7.
It may or may not be relevant but this is causing all network activity for me to fail. I am still able to start the network manually with ifconfig and route.
Also, in case it's helpful, I lost all internet connectivity from Linux, but I was able to access the internet normally from Windows XP within a VMWare Workstation session! That's got to qualify as one of the oddest bugs I've seen :) Downgrading baselayout to 1.12.6 fixed things for me.
Created an attachment (id=103932) [details] try and fix the problem Try this patch To apply cd /lib/rcscripts/net patch -0 < /path/to/patch
(In reply to comment #6) > Try this patch Not working for me. The way I found to trick this bug is to start this service at boot level. It fails the first time but start normally thereafter. In the fact, the service run fine exactly 50% of the time.
I can confirm this - the change in baselayout 1.12.7 (net.lo init script) causes the problem described. Problem is, the routes aren't being set... Set your default gateway to access the internet by hand (route add default gw <your internet router's ip address>).
(In reply to comment #8) > I can confirm this - the change in baselayout 1.12.7 (net.lo init script) > causes the problem described. The patch I posted tries to fix that - can you confirm if it works or not?
The patch ( http://bugs.gentoo.org/attachment.cgi?id=103932&action=view ) worked for me! Try: route add default gw <your internet router's ipaddress> cd /lib/rcscripts/net patch -p0 < /path/to/patch (it's -p0 not -0 as #6 said)
Tried the patch. First it seemed to work but after executing /etc/init.d/net.lo restart a second time the error came back.
Same problem here. But if I start a second time net.lo, it starts ok.
hum, internet is working now after patching but net.lo is still saying SIOCSIFADDR: File exists SIOCSIFFLAGS: Cannot assign requested address SIOCSIFNETMASK: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address I'm waiting for a new baselayout update now.
Same problem here. Route for default destination gets a genmask of 255.255.255.255 instead of 0.0.0.0 and therefore no external destinations are reachable. Downgrading to 1.12.6 fixes the problem for me.
Fixed in baselayout-1.12.7-r1
This is not fixed by any means.
I also have the same issue on two machines - ~x86 and ~amd64 Both running 1.12.7-r1 - would change the status, but I can't. ~amd64=========================================================================== Portage 2.1.2_rc3-r4 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r2 x86_64) ================================================================= System uname: 2.6.19-gentoo-r2 x86_64 Intel(R) Xeon(TM) CPU 3.20GHz Gentoo Base System version 1.12.7 Last Sync: Wed, 13 Dec 2006 19:00:01 +0000 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.3.5, 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -mtune=nocona" 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/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -mtune=nocona" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" 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" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://192.168.0.160/gentoo-portage" USE="amd64 X a52 aac acl acpi alsa alsa_cards_intel8x0 berkdb bitmap-fonts boost cairo cdr cli cracklib crypt cups daap dbus dlloader dmi dri dts dv dvd dvdr dvdread elibc_glibc exif ffmpeg fortran gdbm gstreamer gtk gtk2 hal iconv ieee1394 imagemagick input_devices_evdev input_devices_keyboard input_devices_mouse input_devices_wacom ipod ipv6 isdnlog jpeg kde kerberos kernel_linux lcms ldap libg++ matroska mime mono motif musicbrainz ncurses nls nptl nptlonly nvidia ode ogg openexr opengl pam pcre pdf perl png postgres ppds pppd python qt3 qt4 quicktime readline reflection sasl sdl session spell spl sql sqlite ssl subversion svg tcpd tetex tga theora threads tiff transcode truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l video_cards_nvidia vorbis x264 xine xorg xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS =============================================================================== ~x86=========================================================================== Portage 2.1.2_rc3-r4 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.3.20040420-r2, 2.6.19-gentoo-r2 i686) ================================================================= System uname: 2.6.19-gentoo-r2 i686 Intel(R) Xeon(TM) CPU 3.20GHz Gentoo Base System version 1.12.7 Last Sync: Wed, 13 Dec 2006 19:00:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.3.6, 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j5" 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" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://192.168.0.160/gentoo-portage" USE="x86 3dnow X a52 aac acl acpi afs alsa alsa_cards_intel8x0 apm berkdb bitmap-fonts cairo cdr cli cracklib crypt cups daap dbus dlloader dmi dri dts dv dvd dvdr dvdread elibc_glibc emboss encode esd exif ffmpeg foomaticdb fortran gdbm gif gstreamer gtk gtk2 iconv ieee1394 imagemagick imlib input_devices_evdev input_devices_keyboard input_devices_mouse input_devices_wacom ipod ipv6 irc isdnlog jpeg kerberos kernel_linux ldap libg++ libwww mad matroska mikmod mime mmx mono motif mp3 mpeg musicbrainz ncurses nls nvidia ode ogg openexr opengl oss pam pcre pdf perl png postgres pppd python qt3 qt3support qt4 quicktime readline real reflection sasl sdl session sms spell spl sql sqlite sse sse2 ssl subversion tcpd tetex theora threads tiff transcode truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l video_cards_nvidia vorbis win32codecs xine xml xorg xosd xv xvid xvmc zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS ===============================================================================
(In reply to comment #16) > This is not fixed by any means. Until someone can tell me something useful I think it is fixed as I cannot replicate any issues here on baselayout-1.12.7-r1 on my test boxes. So if everyone could stop posting useless messages like yours and something interesting like a shutdown log with an error or versions of bash and e2fsprogs installed I'd appreciate it as I've not seen as large a bunch of whinning users in ages.
Or diff the changes between 1.12.6 and 1.12.7 and find the change that's causing the problem for you. The problem with routes having an incorrect -net/-host command when not specified has been fixed, and as far as I can tell that is origonal report.
the bug is NOT fixed. lan/internet is woking, baselayout is updated but net.lo is still showing me therse errors: SIOCSIFADDR: File exists SIOCSIFFLAGS: Cannot assign requested address SIOCSIFNETMASK: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address
did my esync && emerge world yesterday; this morning, my network is broken. I dont know if it's related, but I also have warnings about lo at startup, and LAN does not work properly. After boot, or /etc/init.d/net.eth0 restart I have the same problem. Eth0 is configured with static IP, and has a default route. Problem is that from memory I get this routes: Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 0.0.0.0 U 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo what means in practice: I can ping my gateway, but no go out my LAN. I had to manually delete the route 0.0.0.0 ("route del default" did not work), and create the default route. Just for report; I will keep esync && emerge world silently from now on. I also have the SIOCSIFADDR: File exists SIOCSIFFLAGS: Cannot assign requested address things on lo. Useless to paste them one more time.
*** Bug 158070 has been marked as a duplicate of this bug. ***
(In reply to comment #21) > Problem is that from memory I get this routes: > Destination Gateway Genmask Flags Metric Ref Use Iface > 0.0.0.0 192.168.0.1 0.0.0.0 U 0 0 0 eth0 > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > > what means in practice: I can ping my gateway, but no go out my LAN. I had to > manually delete the route 0.0.0.0 ("route del default" did not work), and > create the default route. This is because your default route is displayed before the route to the network on which is your gateway. In practice: line 1 and 2 have to be swapped. You can delete the 0.0.0.0 route and re-add it to solve this issue. -- Sylvain Garrigues. http://www.sylvaingarrigues.com/
> > I had to > > manually delete the route 0.0.0.0 ("route del default" did not work), and > > create the default route. > > This is because your default route is displayed before the route to the network > on which is your gateway. In practice: line 1 and 2 have to be swapped. You can > delete the 0.0.0.0 route and re-add it to solve this issue. that is exactly what I said I did to get my LAN work !!! Swap is due to newly broken scripts ! thats why I tell about in bug.
The problem still exists here with 1.12.7-r1. I get the messages: SIOCSIFADDR: File exists SIOCSIFFLAGS: Cannot assign requested address and so on (see original bug report) when starting net.lo, and consequently the "lo" interface does not show up in ifconfig. If I comment out the two (identical) lines: interface_exists "${iface}" && interface_up "${iface}" in function iface_start(), the problem disappears. These are the only two lines that have been added to /etc/init.d/net.lo between 1.12.6 and 1.12.7-r1. Could somebody *please* reopen this bug? (And consider increasing its severity.)
(In reply to comment #14) > Route for default destination gets a genmask of 255.255.255.255 instead of > 0.0.0.0 and therefore no external destinations are reachable. This part of the problem seems to be fixed in -r1, however.
I confirm #25 and #26 : sys-apps/baselayout-1.12.7-r1 does solve my eth0/routing problem, but not kernel messages about LO and SIOCSIFFLAGS things. But, I do not understand why Ulrich is asking for increasing severity, because this dioes not cause any hamr to *my* system. It's end user desktop, not server nor router with harsh Qos rules ... but really, I dont see any difference: all services work fine, lo comes up at boot time: X, esd, dbus ... no service seem bothered by this bug. my 2c (euro or USD, you choose).
Problem still exists in 1.12.7-r2. (In reply to comment #27) > But, I do not understand why Ulrich is asking for increasing severity, because > this dioes not cause any hamr to *my* system. I would consider a system with a missing network interface after booting severely broken. But this might be a matter of taste.
Seeing(In reply to comment #25) > If I comment out the two (identical) lines: > interface_exists "${iface}" && interface_up "${iface}" > in function iface_start(), the problem disappears Shame, we need those lines there. Anyway, I've refreshed the patch in portage, so it *may* work now. To verify, edit /usr/portage/sys-apps/baselayout/files/baselayout-1.12.7-ifconfig.patch. If you see this line if [[ ${config[@]} == "127.0.0.1/8 brd 127.255.255.255" ]]; then then you have the refreshed patch and it should work. Someone want to confirm that for me?
(In reply to comment #29) > Anyway, I've refreshed the patch in portage, so it *may* work now. To verify, > edit /usr/portage/sys-apps/baselayout/files/baselayout-1.12.7-ifconfig.patch. > If you see this line > if [[ ${config[@]} == "127.0.0.1/8 brd 127.255.255.255" ]]; then > then you have the refreshed patch and it should work. Yes, that line is present in the patch, and also near the end of /lib/rcscripts/net/ifconfig.sh The behaviour is unchanged, though: there are still the SIOCSIFADDR etc. messages during boot. Please tell me if I can provide you with additional information or help in any other way.
For debugging purposes, I've added a "set -x" to ifconfig.sh. The bad command is ifconfig lo:1 127.0.0.1 netmask 255.0.0.0 broadcast 127.255.255.255 corresponding to the line ifconfig "${iface}" ${config[@]} at the very end of function ifconfig_add_address(). Hope this helps.
Created an attachment (id=104027) [details] Another attempt OK, try this patch - it should replace the current one.
(In reply to comment #32) > Created an attachment (id=104027) [edit] [details] > OK, try this patch - it should replace the current one. Looks good to me, no more error messages, all interfaces present after booting.
Great, fixed in -r3
(In reply to comment #32) Works lovely here. No more error messages when I restart the service.
Created an attachment (id=104058) [details] a somehow different-point-of-view patch Has anyone tested what would happen if the `true' branch of that long (last) `if': if [[ ${config[@]} == "127.0.0.1 netmask 255.0.0.0 broadcast 127.255.255.255" ]]; then is not taken (as if the whole conditional would be missing)? Well, there would still be the error: SIOCSIFADDR: File exists SIOCSIFFLAGS: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address that can be recreated each time one would run, say: # ifconfig lo:0 127.0.0.1 up The problem with `lo' is that it (seems it) cannot be "brought up" with an alias like `lo:0' or `lo:1' etc... (I tried it manually, getting the same error every time). So, what I think actually needs to be done is a condition on adding the suffix ":[0-9]" to "${iface}", so that it does not happen in case `is_loopback' is `true' on it. Doing that, the entire `if' conditional I mentioned above would be unnecessary, because the last `ifconfig', in the "ifconfig_add_address" function we talk about, would work with `lo' (which would be the value of "${real_iface}" but also of "${iface}") also. The patch is for `/lib/rcscripts/net/ifconfig.sh' that is the latest version that comes with "sys-apps/baselayout-1.12.7-r3" (should be patched from within "/lib/rcscripts/net", e.g.: # patch -p1 -i /tmp/ifconfig.sh.patch).
(In reply to comment #36) > Has anyone tested what would happen if the `true' branch of that long (last) > `if': > > if [[ ${config[@]} == "127.0.0.1 netmask 255.0.0.0 broadcast 127.255.255.255" > ]]; then > > is not taken (as if the whole conditional would be missing)? Impossible as net.lo guarantees that 127.0.0.1 is the first address added to lo regardless of user configuration. (grep net.lo for 127.0.0.1 to see) > The problem with `lo' is that it (seems it) cannot be "brought up" with an > alias like `lo:0' or `lo:1' etc... Actually it can be - the address just has to be unique.
(In reply to comment #37) > > The problem with `lo' is that it (seems it) cannot be "brought up" with an > > alias like `lo:0' or `lo:1' etc... > > Actually it can be - the address just has to be unique. > You're right, big mistake here, although I had some doubts...
Created an attachment (id=104263) [details] cause: a subtle behaviour of `lo' In Gentoo, all the "scripting" done to bring up `lo' - or any other interface (base or aliased) for that matter -, must converge towards the success of a SINGLE CONFIGURATION LINE: ifconfig "${iface}" ${config[@]} which happens to appear in 'ifconfig.sh#441@ifconfig_add_address'. In case of `lo': - before any aliased interface (`lo:1' etc), the base interface is configured first; - but before that, the address associated with the base interface is successfully deleted (in 'net.lo#947@run_start'); - then how comes that upon entering `ifconfig_add_address' - proved by the fact that `iface' gets a suffix ":1" - `lo' base interface HAS ALREADY BEEN GIVEN AN ADDRESS, BEFORE REACHING THE SINGLE CONFIGURATION LINE?! This is caused by the subtle behavior of `lo': bringing it up through `ifconfig', without an address, automatically assigns it the "127.0.0.1" address; so this is why the preceding `if'-conditional was necessary (in `ifconfig.sh'); - but the `lo' is "always on", it needs not bringing it up; - now, if `ifconfig lo up' didn't get called, `lo' would remain without an address, so the single configuration line would succeed: these "up" calls are located in 'net.lo#670@iface_start' and 'net.lo#679@iface_start' identical lines: interface_exists "${iface}" && interface_up "${iface}" - the solution is immediately: do not evaluate the line(s) in case of `lo': ! is_loopback "${iface}" && interface_exists "${iface}" && interface_up "${iface}" As a result, there must be only one line to configure ANY interface; besides, "127.0.0.1" is a conventional address for `lo', although a very steady one, and writing code depending on strict conventions (e.g., not comparing equality with patterns, but with exact strings) is something I would personally try to avoid. The patch is for sys-apps/baselayout-1.12.7-r4 (but also works for *-r3); it must be run from root of the VFS ("/") like this: root / # patch -p0 -i /tmp/baselayout-1.12.7-r4.patch
There maybe instances where lo is made up by something else, so no. Patch rejected.
