in intramfs dropbear starts before NIC is ready

Bug #363958 reported by Brian Pitts on 2009-04-20
This bug affects 5 people
Affects Status Importance Assigned to Milestone
dropbear (Ubuntu)

Bug Description

Binary package hint: dropbear

Initramfs integration doesn't work because dropbear tries to configure the network before the NIC is ready.

On my Inspiron 1420 running the latest Jaunty I installed dropbear and rebooted with ip=:::::eth0:dhcp on the kernel cmdline. After "Begin: Starting dropbear ..." appears, ipconfig complains that eth0 doesn't exist. A few lines later, messages about tg3 and eth0 appear.

Brian Pitts (bpitts) wrote :
mrsteveman1 (mrsteveman1) wrote :

Exact same problem. Perhaps a prereq needs to be entered into the dropbear init-premount script to require networking?

Joke de Buhr (joke) wrote :

The dropbear init-premount sript should not start configure_network in background.

In "/usr/share/initramfs-tools/scripts/init-premount/dropbear" replace:
    configure_networking &

This way the networking script has time to configure everything before the dropbear daemons gets started.

Changed in dropbear (Ubuntu):
status: New → Confirmed


I had the same problem. Did you try to put the driver of your NIC in /etc/initramfs-tools/modules ? It worked for me.


I also have to had that the new syntax for th ip kernel option seems to be ip=dhcp and not ip=:::::eth0:dhcp

The problem (at least in 12.04) is that udev is called in /scripts/init-top and dropbear is called right away in /scripts/init-premount/dropbear. There's no time for udev to load the network module and the card to be probed and recognized before dropbear tries to initialize the network.

A quick & dirty solution is to add a "sleep 10" inside /scripts/init-premout/dropbear, right after the "Starting dropbear" line. A not so quick and dirty solution is to create another script that adds the sleep after udev. The proper solution is to add logic to udev and make it wait until all the modules have been loaded. This has do be done by canonical or upstream (don't really know who.)

Note that this bug only happens when the FRAMEBUFFER variable is set to "n" (my case, since plymouth makes it really hard to unlock the drive remotely and I can't afford that just for a cute graphical screen.)

BTW, I'm surprised that a simple problem like this hasn't been fixed since 2010, which is the date of the last post.

tobby (tobby88) wrote :

Hm, the bug still persists. I'm using Ubuntu 12.04.2 but can't ssh into dropbear because of this bug.

Removing the "&" after "configure_networking" ends in a non booting system. Adding sleep 10 does not really change anything either. The system stops for 10 seconds, and then again tries to initializie the network interface at the same time as gathering an ip.

tobby (tobby88) on 2013-06-13
tags: added: precise

Started to get this problem.

I recently installed a second network interface controller (NIC). The first one is on-board [RTL8111C] and the second NIC is PCI [RTL8169], however, both use the r8169 module. Only the on-board (eth0) is connected to the network and the computer is not a DHCP server.

Now when I boot I see the following messages in dmesg (exact time blanked):

[ 0.XXXXXX] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 0.XXXXXX] r8169 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 0.XXXXXX] r8169 0000:04:00.0: irq 44 for MSI/MSI-X
[ 0.XXXXXX] r8169 0000:04:00.0 eth0: RTL8168c/8111c at 0xffffc90000c66000, XX:XX:XX:XX:XX:XX, XID 1c4000c0 IRQ 44
[ 0.XXXXXX] r8169 0000:04:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
[ 0.XXXXXX] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 0.XXXXXX] r8169 0000:05:01.0 (unregistered net_device): not PCI Express
[ 0.XXXXXX] r8169 0000:05:01.0 eth1: RTL8169sb/8110sb at 0xffffc90000c68000, XX:XX:XX:XX:XX:XX, XID 10000000 IRQ 19
[ 0.XXXXXX] r8169 0000:05:01.0 eth1: jumbo features [frames: 7152 bytes, tx checksumming: ok]
[ 3.XXXXXX] r8169 0000:04:00.0 eth0: link down
[ 3.XXXXXX] r8169 0000:04:00.0 eth0: link down
[ 3.XXXXXX] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 3.XXXXXX] r8169 0000:05:01.0 eth1: link down
[ 3.XXXXXX] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 5.XXXXXX] r8169 0000:04:00.0 eth0: link up
[ 5.XXXXXX] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

So there is a considerable delay from when the cards are recognized to when eth0 gets an IP. During that time, dropbear is loaded but not bound to an interface.

It seems like an easy solution is to just add a loop in /usr/share/initramfs/init-premount/dropbear to check the current interfaces every second (while ignoring lo) and wait for at least one to show an UP state before continuing.

tags: added: saucy
Margarita Manterola (marga-9) wrote :

I have fixed this by adding a call to "wait_for_udev" before calling configure_networking

Margarita Manterola (marga-9) wrote :

I'm attaching a patch that fixes this issue and two others.

The attachment "Patch to make dropbear wait for udev before configuring the network" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dropbear - 2013.60-1ubuntu2

dropbear (2013.60-1ubuntu2) trusty; urgency=medium

  * Fix initramfs hooks so that the network configuration happens before
    dropbear takes hold of the network card. (LP: #363958)
  * Drop premount-devpts script, this is handled by initramfs-tools.
    (LP: #1070992)
  * Do not install dropbear in the initramfs if there's no uncommented line in
 -- Margarita Manterola <email address hidden> Wed, 19 Feb 2014 16:26:26 +0000

Changed in dropbear (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers