Your message dated Thu, 21 Jul 2022 20:23:37 +0200
with message-id <[email protected]>
and subject line Re: Bug#1015810: dropbear-initramfs: dropbear runs for quite a
while after boot if network fails to start
has caused the Debian Bug report #1015810,
regarding dropbear-initramfs: dropbear runs for quite a while after boot if
network fails to start
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1015810: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015810
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dropbear-initramfs
Version: 2022.82-3
Severity: minor
While experimenting with the kernel 'ip=' parameter (see Bug#1015287),
I have been seeing strange errors on screen during bootup. Note that
these are cases in which the kernel networking initialisation fails but,
as I don't actually need initramfs dropbear access for the boot itself,
the system continues to boot anyway.
As an example of the strange error: part way through the main system boot
(at least a minute AFTER initramfs is over and the main startup is
running) I get this message:
/scripts/init-premount/dropbear: line 384: can't open '/run/net-*.conf': No
such file or directory
Other messages and errors occur - in some circumstances I have seen many,
many screenfuls of errors complaining that many basic system utilities are
missing (although startup works despite the messages)! I assume the
initramfs busybox files have disappeared from the filesystem but has left
some script running.
I am guessing main issue is the one documented in "wait_for_dropbear" in
/usr/share/initramfs-tools/scripts/init-bottom/dropbear. wait_for_dropbear
seems to be waiting for a long time (longer than the initramfs takes to run
and well into the main system startup), before giving up and returning.
By the time it returns, the initramfs context has disappeared and the rest of
init-bottom/dropbear (and also /scripts/init-premount/dropbear ??) are
running in an environment where the initramfs is no longer available.
I assume that this will occur on any system which does not require user
interaction during initramfs but has dropbear-initramfs and an invalid 'ip='
specification.
I am setting the priority to minor because it seems the only impact is that
the console loses a load of startup messages because of the spurious messages
from the initramfs scripts still running after main boot is underway.
Graham
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_IE.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dropbear-initramfs depends on:
ii busybox 1:1.35.0-1
ii dropbear-bin 2022.82-3
ii initramfs-tools 0.142
ii udev 251.2-7
Versions of packages dropbear-initramfs recommends:
ii cryptsetup-initramfs 2:2.4.3-1
dropbear-initramfs suggests no packages.
-- debconf-show failed
--- End Message ---
--- Begin Message ---
Version: 2020.81-2
On Thu, 21 Jul 2022 at 18:14:13 +0100, Graham Cobb wrote:
> I am guessing main issue is the one documented in "wait_for_dropbear" in
> /usr/share/initramfs-tools/scripts/init-bottom/dropbear. wait_for_dropbear
> seems to be waiting for a long time (longer than the initramfs takes to run
> and well into the main system startup), before giving up and returning.
> By the time it returns, the initramfs context has disappeared and the rest of
> init-bottom/dropbear (and also /scripts/init-premount/dropbear ??) are
> running in an environment where the initramfs is no longer available.
wait_for_dropbear() runs synchronously and the init binary won't start
until /usr/share/initramfs-tools/scripts/init-bottom/dropbear execution
is over, see
https://manpages.debian.org/unstable/initramfs-tools-core/initramfs-tools.7.en.html#Subdirectories
.
However if you don't have BOOT=nfs then initramfs-tools-core's
configure_networking() runs asynchronously starting from init-premount
stage and might not give up before the execution is handed over to the
normal system. dropbear-initramfs' init-bottom scripts only wait for
60s by default but configure_networking() might take much longer (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).
Since 2020.81-2 the init-bottom timeout is configurable with
DROPBEAR_SHUTDOWN_TIMEOUT and you can set it to a value that exceeds the
typical configure_networking() duration on your system to be sure that
there is leftover process passed init-bottom stage. See #964187.
--
Guilhem.
signature.asc
Description: PGP signature
--- End Message ---
