initramfs ip network overrides /etc/network settings

Tobias Dussa (SCC) tobias.dussa at kit.edu
Sun Nov 18 09:03:09 WST 2012


Hi,

On Sat, Nov 17, 2012 at 04:29:37PM -0800, Paul Horn wrote:
[...]
> What I can't figure out, and haven't found a post anywhere that
> addresses this, is that once this process completes and the server
> continues to boot, the network remains somehow under "control" of
> initramfs. Boot process stops for several minutes "waiting for network
> configuration" in spite of the static IP settings for both initramfs and
> /etc/network/interfaces. Once it finally starts, any settings in
> /etc/network/interfaces are ignored. If the IP addresses don't match, I
> end up with the one in initramfs. If initramfs uses dhcp, I get that
> address once the server fully boots.
> 
>     * "service networking restart" changes nothing.
>     * "ifdown eth0" says that eth0 is not configured.
>     * "ifup eth0" returns "RTNETLINK answers: File exists. Failed to
> bring up eth0."
>     * /run/network has only the loopback entries. There are no longer
> entries for eth0 or the static network directory.
> 
> Am I missing a script in the /scripts/init-bottom or local-bottom where
> dropbear shuts down? Or is this expected behavior when initramfs uses
> the network at boot?

I have run into this very problem myself lately.  What happens is
this:
 + In the initramfs, the interface is set up statically and directly.
   In particular, the ifup mechanism is not used (it is not available
   yet).
 + When the booting continues, the hardware autodetection process
   detects eth0 and tries to configure it with "ifup eth0".
   However, as you mentioned, the "File exists" error message, which
   is somewhat obscure, is returned.
 + When googling the error message, most hits suggest that this error
   message is caused by a route being already defined.  This is not
   the problem in our case (at least not the only problem); deleting
   all routes does not help.  So there are other entities already
   defined that the ifup mechanism would like to define on its own.
   I have been unable to figure out what exactly is going wrong, but I
   suspect that this is a fundamental flaw in the boot process
   design.
 + What helps, though, is telling the ifup system to first flush all
   eth0-related network configuration items before doing its magic.
   This way, ifup can then happily proceed to configure the interface.

So, essentially, what will work around the problem is adding the line
---
pre-up ip addr flush dev eth0
---
to the proper stanza in /etc/network/interfaces.  (This line assumes
that eth0 is the interface you'd like to set up, but I guess that is
correct.)

HTH.  Works like a charm in my case.

Cheers,
Toby.
-- 
Honk if you love peace and quiet!

----

Karlsruhe Institute of Technology (KIT)
Steinbuch Centre for Computing (SCC)
KIT-CERT

Tobias Dussa
CERT Manager, CA Manager

Zirkel 2
Building 20.21
76131 Karlsruhe, Germany

Phone: +49 721 608-42479
Fax: +49 721 608-9-42479
Email: tobias.dussa at kit.edu
Web: http://www.kit.edu/

KIT – University of the State of Baden-Wuerttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5500 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20121118/55b54b38/attachment.bin 


More information about the Dropbear mailing list