Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.