157965 2006-12-12 13:49 0000 baselayout-1.12.7 causes net.lo malfunction 2006-12-19 02:57:05 0000 1 1 1 Unclassified Gentoo Linux baselayout 2006.1 x86 Linux RESOLVED FIXED P2 normal --- 1 loki_val@gentoo.org base-system@gentoo.org belgix@kern.com.au davidepesa@gmail.com dhp_gentoo@doublehp.org epapegaaij@orange.nl gentoo@stekahelo.de jwbraun@gmail.com njdoyle+bugs@gmail.com sgtphou@fire-eyes.org sylgar@ifrance.com syntaxerrormmm@gmail.com ulm@gentoo.org loki_val@gentoo.org 2006-12-12 13:49:21 0000 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. loki_val@gentoo.org 2006-12-12 14:21:18 0000 Created an attachment (id=103891) emerge --info crono@email.it 2006-12-12 15:02:36 0000 same thing here, problem is caused by baselayout-1.12.7. njdoyle+bugs@gmail.com 2006-12-12 21:24:00 0000 I am also having the same problems after updating to 1.12.7. njdoyle+bugs@gmail.com 2006-12-12 21:25:28 0000 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. rob@cobbleware.com 2006-12-13 00:17:54 0000 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. uberlord@gentoo.org 2006-12-13 03:30:04 0000 Created an attachment (id=103932) try and fix the problem Try this patch To apply cd /lib/rcscripts/net patch -0 < /path/to/patch belgix@kern.com.au 2006-12-13 04:09:26 0000 (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. mail@patrick-nagel.net 2006-12-13 04:15:50 0000 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>). uberlord@gentoo.org 2006-12-13 04:18:19 0000 (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? nico@lifeisabug.com 2006-12-13 05:17:57 0000 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) kramer.martin@gmail.com 2006-12-13 05:42:23 0000 Tried the patch. First it seemed to work but after executing /etc/init.d/net.lo restart a second time the error came back. sylvain.bertrand@gmail.com 2006-12-13 05:55:41 0000 Same problem here. But if I start a second time net.lo, it starts ok. nico@lifeisabug.com 2006-12-13 06:20:10 0000 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. ulm@gentoo.org 2006-12-13 07:57:20 0000 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. uberlord@gentoo.org 2006-12-13 09:17:05 0000 Fixed in baselayout-1.12.7-r1 geekypenguin@gmail.com 2006-12-13 11:35:41 0000 This is not fixed by any means. skyphyr@gmail.com 2006-12-13 11:44:05 0000 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 =============================================================================== uberlord@gentoo.org 2006-12-13 11:59:51 0000 (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. uberlord@gentoo.org 2006-12-13 12:02:04 0000 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. nico@lifeisabug.com 2006-12-13 12:19:22 0000 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 dhp_gentoo@doublehp.org 2006-12-13 13:56:11 0000 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. vapier@gentoo.org 2006-12-13 14:29:20 0000 *** Bug 158070 has been marked as a duplicate of this bug. *** sylgar@ifrance.com 2006-12-13 14:42:26 0000 (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/ dhp_gentoo@doublehp.org 2006-12-13 14:49:45 0000 > > 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. ulm@gentoo.org 2006-12-13 20:40:22 0000 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.) ulm@gentoo.org 2006-12-13 20:44:51 0000 (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. dhp_gentoo@doublehp.org 2006-12-13 23:43:49 0000 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). ulm@gentoo.org 2006-12-14 00:27:58 0000 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. uberlord@gentoo.org 2006-12-14 02:49:02 0000 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? ulm@gentoo.org 2006-12-14 03:23:27 0000 (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. ulm@gentoo.org 2006-12-14 03:35:10 0000 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. uberlord@gentoo.org 2006-12-14 03:45:01 0000 Created an attachment (id=104027) Another attempt OK, try this patch - it should replace the current one. ulm@gentoo.org 2006-12-14 04:11:47 0000 (In reply to comment #32) > Created an attachment (id=104027) [edit] > OK, try this patch - it should replace the current one. Looks good to me, no more error messages, all interfaces present after booting. uberlord@gentoo.org 2006-12-14 04:37:30 0000 Great, fixed in -r3 belgix@kern.com.au 2006-12-14 04:46:04 0000 (In reply to comment #32) Works lovely here. No more error messages when I restart the service. gseba@cs.upt.ro 2006-12-14 12:01:54 0000 Created an attachment (id=104058) 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). uberlord@gentoo.org 2006-12-14 12:11:52 0000 (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. gseba@cs.upt.ro 2006-12-18 02:02:35 0000 (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... gseba@cs.upt.ro 2006-12-18 02:15:55 0000 Created an attachment (id=104263) 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 uberlord@gentoo.org 2006-12-19 02:57:05 0000 There maybe instances where lo is made up by something else, so no. Patch rejected. 103891 2006-12-12 14:21 0000 emerge --info emergeinfo text/plain UG9ydGFnZSAyLjEuMl9yYzMtcjQgKGRlZmF1bHQtbGludXgveDg2LzIwMDYuMSwgZ2NjLTQuMS4x LCBnbGliYy0yLjUtcjAsIDIuNi4xOC1nZW50b28tcjMgaTY4NikKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KU3lzdGVtIHVu YW1lOiAyLjYuMTgtZ2VudG9vLXIzIGk2ODYgQU1EIEF0aGxvbih0bSkgIDI1MDArCkdlbnRvbyBC YXNlIFN5c3RlbSB2ZXJzaW9uIDEuMTIuNgpMYXN0IFN5bmM6IFR1ZSwgMTIgRGVjIDIwMDYgMTg6 MjA6MDEgKzAwMDAKY2NhY2hlIHZlcnNpb24gMi40IFtlbmFibGVkXQpkZXYtamF2YS9qYXZhLWNv bmZpZzogMS4zLjcsIDIuMC4zMApkZXYtbGFuZy9weXRob246ICAgICAyLjQuNApkZXYtcHl0aG9u L3B5Y3J5cHRvOiAyLjAuMS1yNQpkZXYtdXRpbC9jY2FjaGU6ICAgICAyLjQtcjYKc3lzLWFwcHMv c2FuZGJveDogICAgMS4yLjE4LjEKc3lzLWRldmVsL2F1dG9jb25mOiAgMi4xMywgMi42MQpzeXMt ZGV2ZWwvYXV0b21ha2U6ICAxLjRfcDYsIDEuNSwgMS42LjMsIDEuNy45LXIxLCAxLjguNS1yMywg MS45LjYtcjIsIDEuMTAKc3lzLWRldmVsL2JpbnV0aWxzOiAgMi4xNwpzeXMtZGV2ZWwvZ2NjLWNv bmZpZzogMS4zLjE0CnN5cy1kZXZlbC9saWJ0b29sOiAgIDEuNS4yMgp2aXJ0dWFsL29zLWhlYWRl cnM6ICAyLjYuMTctcjIKQUNDRVBUX0tFWVdPUkRTPSJ4ODYgfng4NiIKQVVUT0NMRUFOPSJ5ZXMi CkNCVUlMRD0iaTY4Ni1wYy1saW51eC1nbnUiCkNGTEFHUz0iLU8yIC1tYXJjaD1hdGhsb24teHAg LXBpcGUgLWZvbWl0LWZyYW1lLXBvaW50ZXIiCkNIT1NUPSJpNjg2LXBjLWxpbnV4LWdudSIKQ09O RklHX1BST1RFQ1Q9Ii9ldGMgL3Vzci9rZGUvMy41L2VudiAvdXNyL2tkZS8zLjUvc2hhcmUvY29u ZmlnIC91c3Iva2RlLzMuNS9zaHV0ZG93biAvdXNyL3NoYXJlL1gxMS94a2IgL3Vzci9zaGFyZS9j b25maWciCkNPTkZJR19QUk9URUNUX01BU0s9Ii9ldGMvZW52LmQgL2V0Yy9lbnYuZC9qYXZhLyAv ZXRjL2djb25mIC9ldGMvamF2YS1jb25maWcvdm1zLyAvZXRjL3JldmRlcC1yZWJ1aWxkIC9ldGMv dGVybWluZm8iCkNYWEZMQUdTPSItTzIgLW1hcmNoPWF0aGxvbi14cCAtcGlwZSAtZm9taXQtZnJh bWUtcG9pbnRlciIKRElTVERJUj0iL3Vzci9wb3J0YWdlL2Rpc3RmaWxlcyIKRkVBVFVSRVM9ImF1 dG9jb25maWcgY2NhY2hlIGRpc3Rsb2NrcyBtZXRhZGF0YS10cmFuc2ZlciBzYW5kYm94IHNmcGVy bXMgc3RyaWN0IgpHRU5UT09fTUlSUk9SUz0iaHR0cDovL2Z0cC5iZWxuZXQuYmUvbWlycm9yL3Jz eW5jLmdlbnRvby5vcmcvZ2VudG9vLyBodHRwOi8vcGFuZGVtb25pdW0udGlzY2FsaS5kZS9wdWIv Z2VudG9vLyBodHRwOi8vbWlycm9yLmdlbnRvby5uby8gIgpMQU5HPSJlbl9ESy5VVEYtOCIKTENf QUxMPSJlbl9ESy5VVEYtOCIKTElOR1VBUz0iZW4gZGEiCk1BS0VPUFRTPSItajIiClBLR0RJUj0i L3Vzci9wb3J0YWdlL3BhY2thZ2VzIgpQT1JUQUdFX1JTWU5DX09QVFM9Ii0tcmVjdXJzaXZlIC0t bGlua3MgLS1zYWZlLWxpbmtzIC0tcGVybXMgLS10aW1lcyAtLWNvbXByZXNzIC0tZm9yY2UgLS13 aG9sZS1maWxlIC0tZGVsZXRlIC0tZGVsZXRlLWFmdGVyIC0tc3RhdHMgLS10aW1lb3V0PTE4MCAt LWV4Y2x1ZGU9L2Rpc3RmaWxlcyAtLWV4Y2x1ZGU9L2xvY2FsIC0tZXhjbHVkZT0vcGFja2FnZXMi ClBPUlRBR0VfVE1QRElSPSIvdmFyL3RtcCIKUE9SVERJUj0iL3Vzci9wb3J0YWdlIgpTWU5DPSJy c3luYzovL3JzeW5jLmV1cm9wZS5nZW50b28ub3JnL2dlbnRvby1wb3J0YWdlIgpVU0U9Ing4NiAz ZG5vdyAzZG5vd2V4dCBYIGE1MiBhYWMgYWNwaSBhaW0gYWxzYSBhcnRzIGF1dGhkYWVtb25kIGJh c2gtY29tcGxldGlvbiBiZXJrZGIgYml0bWFwLWZvbnRzIGNhaXJvIGNkciBjamsgY2xpIGNwdWRl dGVjdGlvbiBjcmFja2xpYiBjcnlwdCBjc3MgY3VwcyBkYnVzIGRqYmZmdCBkbGxvYWRlciBkcmkg ZHRzIGR2ZCBkdmRyIGR2ZHJlYWQgZWxpYmNfZ2xpYmMgZXZkZXYgZmFtIGZmbXBlZyBmaXJlZm94 IGZsYWMgZm9ydHJhbiBnaWYgZ251dGxzIGdwbSBoYWwgaGJjaSBpY29udiBpY3EgaW5wdXRfZGV2 aWNlc19ldmRldiBpbnB1dF9kZXZpY2VzX2tleWJvYXJkIGlucHV0X2RldmljZXNfbW91c2UgaXNk bmxvZyBqYWJiZXIgamF2YSBqYXZhc2NyaXB0IGpwZWcga2RlIGtkZWVuYWJsZWZpbmFsIGtlcm5l bF9saW51eCBsaWJnKysgbGluZ3Vhc19kYSBsaW5ndWFzX2VuIGxvZ2l0ZWNoLW1vdXNlIGxvZ3Jv dGF0ZSBsem8gbWFkIG1hdHJvc2thIG1ib3ggbWltZSBtbXggbW14ZXh0IG1vem5vcGFuZ28gbXAz IG1wNCBtcGVnIG1wbGF5ZXIgbXNuIG11c2VwYWNrIG5jdXJzZXMgbmxzIG5vY2QgbnB0bCBucHRs b25seSBvZmZlbnNpdmUgb2dnIG9wZW5hbCBvcGVuZ2wgb3NjYXIgcGFtIHBjcmUgcGRmIHBlcmwg cG5nIHBwZHMgcHBwZCBweXRob24gcXQzIHF0NCBxdWlja3RpbWUgcmVhZGxpbmUgcmVmbGVjdGlv biBzYXNsIHNkbCBzZXNzaW9uIHNob3J0ZW4gc2xhbmcgc3BlZXggc3BlbGwgc3BsIHNzZSBzc2wg c3ZnIHN2Z2EgdGNwZCB0aGVvcmEgdGlmZiB0cnVldHlwZSB0cnVldHlwZS1mb250cyB0eXBlMS1m b250cyB1ZGV2IHVuaWNvZGUgdXNlcmxhbmRfR05VIHZjZCB2aWRlb19jYXJkc19mZ2xyeCB2aWRl b19jYXJkc192ZXNhIHZvcmJpcyB3aW4zMmNvZGVjcyB3bWYgd3h3aW5kb3dzIHhhbmltIHhmYWNl IHhpbmUgeG1sIHhvcmcgeHYgeHZpZCB5YWhvbyB6bGliIgpVbnNldDogIENUQVJHRVQsIEVNRVJH RV9ERUZBVUxUX09QVFMsIElOU1RBTExfTUFTSywgTERGTEFHUywgUE9SVEFHRV9SU1lOQ19FWFRS QV9PUFRTLCBQT1JURElSX09WRVJMQVkKCg== 103932 2006-12-13 03:30 0000 try and fix the problem ifconfig.patch text/plain SW5kZXg6IGlmY29uZmlnLnNoCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGlmY29uZmlnLnNoCShyZXZpc2lvbiAy NDE1KQorKysgaWZjb25maWcuc2gJKHdvcmtpbmcgY29weSkKQEAgLTM2NCw3ICszNjQsNyBAQAog CQkJCXg9Ii1uZXQgJHt4fSIKIAkJCWVsaWYgW1sgJHt5fSA9PSAqLiouKi4qLzMyIF1dIDsgdGhl bgogCQkJCXg9Ii1ob3N0ICR7eH0iCi0JCQllbGlmIFtbICR7eX0gPT0gKi4qLiouKi8qIF1dIDsg dGhlbgorCQkJZWxpZiBbWyAke3l9ID09ICouKi4qLiovKiB8fCAke3l9ID09ICJkZWZhdWx0IiB8 fCAke3l9ID09ICIwLjAuMC4wIiBdXSA7IHRoZW4KIAkJCQl4PSItbmV0ICR7eH0iCiAJCQllbHNl CiAJCQkJIyBHaXZlbiB0aGUgbGFjayBvZiBhIG5ldG1hc2ssIHdlIGFzc3VtZSBhIGhvc3QK 104027 2006-12-14 03:45 0000 Another attempt x text/plain SW5kZXg6IG5ldC9pZmNvbmZpZy5zaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBuZXQvaWZjb25maWcuc2gJKHJl dmlzaW9uIDI0MTgpCisrKyBuZXQvaWZjb25maWcuc2gJKHdvcmtpbmcgY29weSkKQEAgLTM2NCw3 ICszNjQsNyBAQAogCQkJCXg9Ii1uZXQgJHt4fSIKIAkJCWVsaWYgW1sgJHt5fSA9PSAqLiouKi4q LzMyIF1dIDsgdGhlbgogCQkJCXg9Ii1ob3N0ICR7eH0iCi0JCQllbGlmIFtbICR7eX0gPT0gKi4q LiouKi8qIF1dIDsgdGhlbgorCQkJZWxpZiBbWyAke3l9ID09ICouKi4qLiovKiB8fCAke3l9ID09 ICJkZWZhdWx0IiB8fCAke3l9ID09ICIwLjAuMC4wIiBdXSA7IHRoZW4KIAkJCQl4PSItbmV0ICR7 eH0iCiAJCQllbHNlCiAJCQkJIyBHaXZlbiB0aGUgbGFjayBvZiBhIG5ldG1hc2ssIHdlIGFzc3Vt ZSBhIGhvc3QKQEAgLTQzMCwxMiArNDMwLDEyIEBACiAJCWNvbmZpZz0oICIke2NvbmZpZ1tAXS8v cGVlci9wb2ludG9wb2ludH0iICkKIAlmaQogCi0JIyBFbnN1cmUgdGhhdCB0aGUgaW50ZXJmYWNl IGlzIHVwIHNvIHdlIGNhbiBhZGQgSVB2NiBhZGRyZXNzZXMKLQlpbnRlcmZhY2VfdXAgIiR7cmVh bF9pZmFjZX0iCi0KIAkjIFNvbWUga2VybmVscyBsaWtlIHRvIGFwcGx5IGxvIHdpdGggYW4gYWRk cmVzcyB3aGVuIHRoZXkgYXJlIGJyb3VnaHQgdXAKIAlpZiBbWyAke2NvbmZpZ1tAXX0gPT0gIjEy Ny4wLjAuMSBuZXRtYXNrIDI1NS4wLjAuMCBicm9hZGNhc3QgMTI3LjI1NS4yNTUuMjU1IiBdXTsg dGhlbgotCQlpc19sb29wYmFjayAiJHtpZmFjZX0iICYmIGlmY29uZmlnICIke2lmYWNlfSIgMC4w LjAuMAorCQlpZiBpc19sb29wYmFjayAiJHtyZWFsX2lmYWNlfSIgOyB0aGVuCisJCQlpZmNvbmZp ZyAiJHtyZWFsX2lmYWNlfSIgJHtjb25maWdbQF19CisJCQlyZXR1cm4gMAorCQlmaQogCWZpCiAK IAlpZmNvbmZpZyAiJHtpZmFjZX0iICR7Y29uZmlnW0BdfQo= 104058 2006-12-14 12:01 0000 a somehow different-point-of-view patch ifconfig.sh.patch text/plain ZGlmZiAtTmF1ciBvL2lmY29uZmlnLnNoIG4vaWZjb25maWcuc2gKLS0tIG8vaWZjb25maWcuc2gJ MjAwNi0xMi0xNCAyMTozODoxMy4wMDAwMDAwMDAgKzAyMDAKKysrIG4vaWZjb25maWcuc2gJMjAw Ni0xMi0xNCAyMTozOTozMy4wMDAwMDAwMDAgKzAyMDAKQEAgLTQwNyw2ICs0MDcsNyBAQAogCWVs c2UKIAkJIyBJUHY0IGlzIHRyaWNreSAtIGlmY29uZmlnIHJlcXVpcmVzIGFuIGFsaWFzZWQgZGV2 aWNlCiAJCSMgZm9yIG11bHRpcGxlIGFkZHJlc3NlcworCQlpc19sb29wYmFjayAiJHtpZmFjZX0i IHx8CiAJCWlmIGlmY29uZmlnICIke2lmYWNlfSIgfCBncmVwIC1FcSAiXDxpbmV0IGFkZHI6Lioi IDsgdGhlbgogCQkJIyBHZXQgdGhlIGxhc3QgYWxpYXMgbWFkZSBmb3IgdGhlIGludGVyZmFjZSBh bmQgYWRkIDEgdG8gaXQKIAkJCWk9JChpZmNvbmZpZyB8IHRhYyB8IGdyZXAgLW0gMSAtbyAiXiR7 aWZhY2V9OlswLTldKiIgXApAQCAtNDMwLDE0ICs0MzEsNiBAQAogCQljb25maWc9KCAiJHtjb25m aWdbQF0vL3BlZXIvcG9pbnRvcG9pbnR9IiApCiAJZmkKIAotCSMgU29tZSBrZXJuZWxzIGxpa2Ug dG8gYXBwbHkgbG8gd2l0aCBhbiBhZGRyZXNzIHdoZW4gdGhleSBhcmUgYnJvdWdodCB1cAotCWlm IFtbICR7Y29uZmlnW0BdfSA9PSAiMTI3LjAuMC4xIG5ldG1hc2sgMjU1LjAuMC4wIGJyb2FkY2Fz dCAxMjcuMjU1LjI1NS4yNTUiIF1dOyB0aGVuCi0JCWlmIGlzX2xvb3BiYWNrICIke3JlYWxfaWZh Y2V9IiA7IHRoZW4KLQkJCWlmY29uZmlnICIke3JlYWxfaWZhY2V9IiAke2NvbmZpZ1tAXX0KLQkJ CXJldHVybiAwCi0JCWZpCi0JZmkKLQogCWlmY29uZmlnICIke2lmYWNlfSIgJHtjb25maWdbQF19 CiB9CiAK 104263 2006-12-18 02:15 0000 cause: a subtle behaviour of `lo' baselayout-1.12.7-r4.patch text/plain ZGlmZiAtdXIgZXRjL2luaXQuZC9uZXQubG8gZXRjL2luaXQuZC9uZXQubG8KLS0tIGV0Yy9pbml0 LmQvbmV0LmxvCTIwMDYtMTItMTggMTE6MzU6MjUuMDAwMDAwMDAwICswMjAwCisrKyBldGMvaW5p dC5kL25ldC5sbwkyMDA2LTEyLTE4IDExOjM3OjQ3LjAwMDAwMDAwMCArMDIwMApAQCAtNjY3LDcg KzY2Nyw3IEBACiAJbG9jYWwgLWEgY29uZmlnPSgpIGZhbGxiYWNrPSgpIGZhbGxiYWNrX3JvdXRl PSgpIGNvbmY9KCkgYT0oKSBiPSgpCiAJbG9jYWwgaWZ2YXI9JChiYXNoX3ZhcmlhYmxlICIkMSIp IGk9IGo9IG1ldHJpYz0wCiAKLQlpbnRlcmZhY2VfZXhpc3RzICIke2lmYWNlfSIgJiYgaW50ZXJm YWNlX3VwICIke2lmYWNlfSIKKwkhIGlzX2xvb3BiYWNrICIke2lmYWNlfSIgJiYgaW50ZXJmYWNl X2V4aXN0cyAiJHtpZmFjZX0iICYmIGludGVyZmFjZV91cCAiJHtpZmFjZX0iCiAKIAkjIHByZSBT dGFydCBhbnkgbW9kdWxlcyB3aXRoCiAJZm9yIG1vZCBpbiAke01PRFVMRVNbQF19OyBkbwpAQCAt Njc2LDcgKzY3Niw3IEBACiAJCWZpCiAJZG9uZQogCi0JaW50ZXJmYWNlX2V4aXN0cyAiJHtpZmFj ZX0iICYmIGludGVyZmFjZV91cCAiJHtpZmFjZX0iCisJISBpc19sb29wYmFjayAiJHtpZmFjZX0i ICYmIGludGVyZmFjZV9leGlzdHMgIiR7aWZhY2V9IiAmJiBpbnRlcmZhY2VfdXAgIiR7aWZhY2V9 IgogCiAJeD0ibWV0cmljXyR7aWZ2YXJ9IgogCSMgSWYgd2UgZG9uJ3QgaGF2ZSBhIG1ldHJpYyB0 aGVuIGNhbGN1bGF0ZSBvbmUKZGlmZiAtdXIgbGliL3Jjc2NyaXB0cy9uZXQvaWZjb25maWcuc2gg bGliL3Jjc2NyaXB0cy9uZXQvaWZjb25maWcuc2gKLS0tIGxpYi9yY3NjcmlwdHMvbmV0L2lmY29u ZmlnLnNoCTIwMDYtMTItMTggMTE6MzU6MjUuMDAwMDAwMDAwICswMjAwCisrKyBsaWIvcmNzY3Jp cHRzL25ldC9pZmNvbmZpZy5zaAkyMDA2LTEyLTE4IDExOjM3OjExLjAwMDAwMDAwMCArMDIwMApA QCAtNDMwLDE0ICs0MzAsNiBAQAogCQljb25maWc9KCAiJHtjb25maWdbQF0vL3BlZXIvcG9pbnRv cG9pbnR9IiApCiAJZmkKIAotCSMgU29tZSBrZXJuZWxzIGxpa2UgdG8gYXBwbHkgbG8gd2l0aCBh biBhZGRyZXNzIHdoZW4gdGhleSBhcmUgYnJvdWdodCB1cAotCWlmIFtbICR7Y29uZmlnW0BdfSA9 PSAiMTI3LjAuMC4xIG5ldG1hc2sgMjU1LjAuMC4wIGJyb2FkY2FzdCAxMjcuMjU1LjI1NS4yNTUi IF1dOyB0aGVuCi0JCWlmIGlzX2xvb3BiYWNrICIke3JlYWxfaWZhY2V9IiA7IHRoZW4KLQkJCWlm Y29uZmlnICIke3JlYWxfaWZhY2V9IiAke2NvbmZpZ1tAXX0KLQkJCXJldHVybiAwCi0JCWZpCi0J ZmkKLQogCWlmY29uZmlnICIke2lmYWNlfSIgJHtjb25maWdbQF19CiB9CiAK