[Bug 2064926] Re: dhcpcd stuck for 5 Minutes (300 Seconds) during Boot Process (LUKS/Clevis Autounlock)
Stefano
2064926 at bugs.launchpad.net
Fri May 10 13:15:22 UTC 2024
Hello Timo.
Sure, I just tested it and I get to the (same) Result I was getting
while performing preliminary Investigations. The boot time is around 22
Seconds (down from the Original 300 Seconds).
So it's Good, from what I can tell :).
# 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 DHCPCD Packages with Maximum Priority
create /etc/apt/preferences.d/dhcpcd-proposed
###########################################################################
Package: dhcpcd dhcpcd-base dhcpcd5 dhcpcd-base-dbgsym
Pin: release a=noble-proposed
Pin-Priority: 1000
###########################################################################
# View Pinning Policy
apt policy dhcpcd-base
# Priority is higher on noble-proposed, so that's good
# This means that a Package Upgrade will be performed
```
dhcpcd-base:
Installed: 1:10.0.6-1ubuntu3
Candidate: 1:10.0.6-1ubuntu3.1
Version table:
1:10.0.6-3 1
1 http://ftp.dk.debian.org/debian testing/main amd64 Packages
1:10.0.6-1ubuntu3.1 1000
400 http://archive.ubuntu.com/ubuntu noble-proposed/main amd64 Packages
*** 1:10.0.6-1ubuntu3 500
500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages
100 /var/lib/dpkg/status
1:10.0.2-3ubuntu3 1
1 http://archive.ubuntu.com/ubuntu mantic/main amd64 Packages
9.4.1-24~deb12u3 1
1 http://ftp.dk.debian.org/debian bookworm/main amd64 Packages
```
# Update Repositories
apt update
# Print Current Date
date
2024-05-10T13:32:00 CEST
# Before Upgrade
ls -l /usr/lib/dhcpcd/dhcpcd-hooks/30-hostname
-rw-r--r-- 1 root root 3764 May 9 09:42 /usr/lib/dhcpcd/dhcpcd-hooks/30-hostname
# Upgrade Package
apt dist-upgrade
# After Upgrade
ls -l /usr/lib/dhcpcd/dhcpcd-hooks/30-hostname
-rw-r--r-- 1 root root 3764 May 7 12:12 /usr/lib/dhcpcd/dhcpcd-hooks/30-hostname
# After Upgrade - Excerpt of the File Contents
```
set_hostname()
{
hfqdn=false
hshort=false
case "$hostname_fqdn" in
[Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|1) hfqdn=true;;
""|[Ss][Ee][Rr][Vv][Ee][Rr]) ;;
*) hshort=true;;
esac
need_hostname || return 0
```
# Final Remarks
The last line looks Good (it reflects the correct Fix, i.e. the `|| return` got modified into `|| return 0`).
Not sure why the File has a timestamp "so old" though (May 7 12:12), probably this is the time when the patch was written (https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2064926/comments/32).
# 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 22.809s (kernel) + 53.824s (userspace) = 1min 16.634s
graphical.target reached after 53.811s in userspace.
--
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/2064926
Title:
dhcpcd stuck for 5 Minutes (300 Seconds) during Boot Process
(LUKS/Clevis Autounlock)
Status in dhcpcd package in Ubuntu:
Fix Committed
Status in initramfs-tools package in Ubuntu:
Invalid
Status in dhcpcd source package in Noble:
Fix Committed
Status in initramfs-tools source package in Noble:
Invalid
Bug description:
[ Impact ]
Systems that use clevis will have a 5 minutes boot delay, because
dhcpcd fails and retries until the retry loop exits.
[ Test Plan ]
Use a system with clevis and zfs where /etc/hostname is set and
differs from the hostname reported by the DHCP server. Install the
update and measure the boot time. It should be way shorter than five
minutes.
I'll add a test case for initramfs-tools in oracular to cover this
case.
[ Where problems could occur ]
The fix only touches a dhcpcd hook.
[ Original report ]
This is a long-lingering issue, probably affecting Ubuntu 23.04,
surely Ubuntu 23.10 and now surely Ubuntu 24.04.
Due to other Priorities I kept having my PC on Standby/Sleep instead
of turning it off all the time, since I would incur in 5 Minutes (300
Seconds) Boot being frozen.
I also thought it was due to Clevis LUKS Autounlock at first:
https://github.com/latchset/clevis/issues/289#issuecomment-1322633750
But according to the messages I see on the Screen during boot (if I
see them !), it seems this is purely a dhcpcd Issue.
On one workstation the Screen is completely frozen, but boot Process
continues normally after 5 Minutes have elapsed.
This BUG Report is based on the Machine that shows *some* Output while
being Stuck.
Looks Similar to this one, but I do NOT have aoetools installed
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2062501
List of Initramfs Scripts Installed in the system:
/usr/share/initramfs-tools/scripts/init-bottom/udev
/usr/share/initramfs-tools/scripts/init-bottom/lvm2
/usr/share/initramfs-tools/scripts/init-bottom/plymouth
/usr/share/initramfs-tools/scripts/panic/console_setup
/usr/share/initramfs-tools/scripts/panic/plymouth
/usr/share/initramfs-tools/scripts/nfs
/usr/share/initramfs-tools/scripts/functions
/usr/share/initramfs-tools/scripts/zfs
/usr/share/initramfs-tools/scripts/init-premount/brltty
/usr/share/initramfs-tools/scripts/init-premount/plymouth
/usr/share/initramfs-tools/scripts/local-bottom/cryptgnupg-sc
/usr/share/initramfs-tools/scripts/local-bottom/ntfs_3g
/usr/share/initramfs-tools/scripts/local-bottom/clevis
/usr/share/initramfs-tools/scripts/local-bottom/cryptroot
/usr/share/initramfs-tools/scripts/local-bottom/cryptopensc
/usr/share/initramfs-tools/scripts/local-premount/fixrtc
/usr/share/initramfs-tools/scripts/local-premount/resume
/usr/share/initramfs-tools/scripts/local-premount/ntfs_3g
/usr/share/initramfs-tools/scripts/local
/usr/share/initramfs-tools/scripts/local-block/cryptroot
/usr/share/initramfs-tools/scripts/local-top/cryptopensc
/usr/share/initramfs-tools/scripts/local-top/clevis
/usr/share/initramfs-tools/scripts/local-top/cryptroot
/usr/share/initramfs-tools/scripts/local-top/zfs
/usr/share/initramfs-tools/scripts/init-top/all_generic_ide
/usr/share/initramfs-tools/scripts/init-top/brltty
/usr/share/initramfs-tools/scripts/init-top/udev
/usr/share/initramfs-tools/scripts/init-top/framebuffer
/usr/share/initramfs-tools/scripts/init-top/console_setup
/usr/share/initramfs-tools/scripts/init-top/blacklist
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 15 15 15 15; do`
However it's really a last resort Workaround.
Any hope of a proper Fix ?
Possible mentions based on the logs output:
```
enp0s25: ignoring offer of 192.168.3.61 from 192.168.1.8
enp0s25: probing address 192.168.3.61/20
```
This might be due to High-Availability Configured in my OPNSense
Router. There is a Master (192.168.1.7) and a Slave (192.168.1.8).
VLAN should be ENABLED, but right now ALL traffic flows on VLAN 1 /
default VLAN (untagged), so this shouldn't be an issue IMHO. Didn't
have time to setup VLANs yet.
Why does dhcpcd exit like this? What is the Error ?
```
script_status: /usr/lib/dhcpcd/dhcpcd-run-hooks: WEXITSTATUS 1
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dhcpcd/+bug/2064926/+subscriptions
More information about the foundations-bugs
mailing list