[Bug 2065037] Re: dhcpcd is called before interfaces have carrier causing a 29 seconds boot delay
Stefano
2065037 at bugs.launchpad.net
Fri May 10 20:35:05 UTC 2024
Hello Timo.
Sure, I just tested it and I get relatively good Results.
See my Conclusion below. Maybe some extra discussions needed about the
`--noarp` NOT being included in the patch, which causes the Boot time to
go from approx. 22s (with `--noarp`) to approx. 28s (without `-noarp`,
i.e. the `noble-proposed` Version of the Package).
# Test Procedure & Log
# Pin noble-proposed Packages with Lower Priority by Default
create /etc/apt/preferences.d/proposed-updates if it doesn't exist yet
###########################################################################
# Configure apt to allow selective installs of packages from proposed
Package: *
Pin: release a=noble-proposed
Pin-Priority: 400
###########################################################################
# Pin Initramfs Packages with Maximum Priority
create /etc/apt/preferences.d/initramfs-proposed
###########################################################################
Package: initramfs-tools initramfs-tools-bin initramfs-tools-core initramfs-tools-bin-dbgsym
Pin: release a=noble-proposed
Pin-Priority: 1000
###########################################################################
# Update Sources
apt update
# View Pinning Policy
apt policy initramfs-tools
# Priority is higher on noble-proposed, so that's good
# This means that a Package Upgrade will be performed
```
initramfs-tools:
Installed: 0.142ubuntu25
Candidate: 0.142ubuntu25.1
Version table:
0.142ubuntu25.1 1000
400 http://archive.ubuntu.com/ubuntu noble-proposed/main amd64 Packages
*** 0.142ubuntu25 500
500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages
100 /var/lib/dpkg/status
0.142ubuntu15.1 1
1 http://archive.ubuntu.com/ubuntu mantic-updates/main amd64 Packages
0.142ubuntu15 1
1 http://archive.ubuntu.com/ubuntu mantic/main amd64 Packages
0.142 1
1 http://ftp.dk.debian.org/debian bookworm/main amd64 Packages
1 http://ftp.dk.debian.org/debian testing/main amd64 Packages
1 http://ftp.dk.debian.org/debian testing/main i386 Packages
```
# Update Repositories
apt update
# Print Current Date
date
2024-05-10T21:59:53 CEST
# Before Upgrade
ls -l /usr/share/initramfs-tools/scripts/functions
-rw-r--r-- 1 root root 23227 May 9 09:43 /usr/share/initramfs-tools/scripts/functions
# Upgrade Package
apt dist-upgrade
# After Upgrade
ls -l /usr/share/initramfs-tools/scripts/functions
-rw-r--r-- 1 root root 22383 May 10 15:03 /usr/share/initramfs-tools/scripts/functions
# After Upgrade - Excerpt of the File Contents
```
case ${IP} in
none|done|off)
# Do nothing
IP="done"
;;
""|on|any|dhcp|bootp|both)
dhcpcd -1KL -t $ROUNDTTT -4 ${DEVICE:+"${DEVICE}"}
;;
*)
ipconfig -t ${ROUNDTTT} -d "$IP"
;;
esac
case ${IP6} in
""|none|done|off)
# Do nothing
IP6="done"
;;
*)
# check the content of IP6 and if it is not on/dhcp/any use it as
# a device name. Otherwise all devices will be tried (unless
# BOOTIF was set, see above).
case "${IP6}" in
on|dhcp|any)
;;
*)
DEVICE6="$IP6" ;;
esac
dhcpcd -1KL -t $ROUNDTTT -6 ${DEVICE6:+"${DEVICE6}"}
;;
esac
```
This matches what I had during my initial testing:
```
dhcpcd -1K --noipv4ll -t $ROUNDTTT -4 ${DEVICE:+"${DEVICE}
```
However it does NOT include the `--noarp` I had during the latest tests (the advantage gained by `--noarp` is probably not huge, that's probably why it wasn't included, using it probably also has some drawbacks).
I could see a "good" result using `--noarp` though. See comments by bdrung: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2065037/comments/49.
# Final Remarks
The impact of the lack of `--noarp` will be evaluated during the test.
The comparison will be done against https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2065037/comments/54 on the Main Workstation with Intel Xeon E3-1231 v3 CPU, with the same "Benchmark" to compare "Apples against Apples" (minus the `--noarp` part).
# Reboot
update-initramfs -k all -u; update-grub; update-initramfs -k all; update-grub; reboot
# Save dmesg
dmesg
# Save initramfs debug log
cat /run/initramfs/initramfs.debug
# Save systemd-analze
systemd-analyze
Startup finished in 28.632s (kernel) + 54.452s (userspace) = 1min 23.084s
graphical.target reached after 54.437s in userspace.
# Conclusion
The boot time is higher than the test https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2065037/comments/54 using `--noarp`.
systemd-analyze states 22.5 s (see comment #54 with `--noarp`) versus
the 28.6 s obtained during testing of the patch currently in `noble-
proposed` (`initramfs-tools 0.142ubuntu25.1`).
Whether that difference is significant or not can be debated.
Personally, I'm already happy that we went from 300s (previous DHCPCD
BUG Report: https://bugs.launchpad.net/ubuntu/+source/initramfs-
tools/+bug/2064926) to 45s (beginning of this BUG Report) to now approx.
28 s.
This matches what was observed on the Secondary Laptop WITHOUT `--noarp`
at https://bugs.launchpad.net/ubuntu/+source/initramfs-
tools/+bug/2065037/comments/46 (and based on my testing there is NOT a
huge difference in terms of initramfs waiting for Networking between the
2 Systems, i.e. NOT much CPU dependent).
# Further Testing required ?
In case you need further testing, I can also try to compare on the Secondary Laptop, where we have more recorded data in this BUG Report (v1, ..., v9, extras, etc).
But it would probably be better that also somebody else testes this.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/2065037
Title:
dhcpcd is called before interfaces have carrier causing a 29 seconds
boot delay
Status in initramfs-tools package in Ubuntu:
Fix Committed
Status in initramfs-tools source package in Noble:
Fix Committed
Bug description:
[ Impact ]
The boot time can be longer on system that configure their network in
the initrd.
[ Test Plan ]
The affected systems show "Sleeping $time seconds before retrying
getting a DHCP lease" in their boot log. Once applying the fix, this
message should not be found any more and "dhcpcd-10.0.6 starting"
should be only logged once (at most once for IPv4 and once for IPv6
depending on the boot parameters).
There are qemu-net and qemu-net-dnsmasq autopkgtests for this area of
code.
[ Where problems could occur ]
The DHCP code in the initrd are touched. So the boot can be affected.
Also updating initramfs-tools will regenerate the initrd and can cause
issues there (like full disks, etc).
[ Original report ]
In automatically encrypted Clevis+Tang unlock of LUKS encrypted device
(dmcrypt/cryptsetup) - on top of which the ZFS Pool for / resides,
dhcpcd is used in order to obtain automatically an IP address during
initramfs boot.
During this phase, dhcpcd is called before interfaces have carrier
causing a 29 seconds boot delay.
Boot delay is currently 45 seconds, instead of the 15 seconds that it
should.
BUG Initially reported in:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2064926
Relevant Logs:
```
dhcpcd-10.0.6 starting
[...]
no interfaces have a carrier
exiting due to oneshot
dhcpcd exited
Sleeping 29 seconds before retrying getting a DHCP lease
dhcpcd-10.0.6 starting
```
A possible workaround would be to manually edit /usr/share/initramfs-tools/scripts/functions
Changing this:
`for ROUNDTTT in 30 60 90 120; do`
To this:
`for ROUNDTTT in 5 5 5 5; do`
But the proper solution would be to continuously "scan" the state of
the Interface (every Second or so), and wait until the interface is
UP, before deciding to call dhcpcd.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2065037/+subscriptions
More information about the foundations-bugs
mailing list