Control: tag -1 moreinfo Hi,
On Wed, 08 Apr 2026 at 07:02:34 +0000, Till Backhaus wrote: > I am reporting an issue where the backgrounded network configuration > loop in `dropbear-initramfs` survives the transition to the real root > filesystem (switch_root), causing infinite console spam and resource > leakage. This suggests that dropbear's init-bottom is run before configure_networking() is terminated. The former waits for up to 60s by default, but the latter might take much longer in some cases (180s timeout for the device, up to 10s waiting time for udev to settle, then exponential backoff of 2+3+4+6+9+16+25+36+64+100=265s for the network configuration). The 60s timeout is a deliberate trade-off, but this is configurable using DROPBEAR_SHUTDOWN_TIMEOUT, see #964187. Does setting DROPBEAR_SHUTDOWN_TIMEOUT to a large value in /etc/dropbear/initramfs/dropbear.conf fix the issue? Of course, it'll delay the boot if configure_networking() keeps trying to bring the network up without success. > The `run_dropbear` function calls `configure_networking`. When no > `ip=` parameter is provided via the kernel command line, > `configure_networking` (from `/scripts/functions`) enters a > long-running or infinite loop waiting for network initialization. configure_networking() (which don't belong to src:dropbear) has no interface to let boot script know that the function has terminated, so all we have is the timeout. That “long-running or infinite loop waiting for network initialization” is not a dropbear-initramfs issue. -- Guilhem.
