#2214 Issue `closed`: Boot delay after attempting to start DHCP client daemon¶

Labels: support / question, no-issue-activity

adatum opened issue at 2019-08-13 21:25:¶

ReaR version ("/usr/sbin/rear -V"): 2.5 rpm built from git
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): Fedora 30
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

PROGS=( "${PROGS[@]}" /home/test/Downloads/borg-linux64 locale )

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR): PC
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): x86_64
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): UEFI, GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): local SSD
Description of the issue (ideally so that others can reproduce it):

Booting the ReaR rescue media (ISO output put onto USB flash drive) on a laptop has a long delay at the following point of the boot process:

running 58-start-dhclient.sh...
Attempting to start the DHCP client daemon

It stays at this message for about a minute, and then arrives at the login prompt.

After that everything seems normal. ifconfig shows the ethernet, wifi, and lo devices. The ethernet device has an IP if the network cable is plugged in.

The same rescue ISO boots much more quickly in a VM without such a delay.

I tried booting the laptop with and without an ethernet cable plugged in, and it made no difference.

I also tried with the WiFi disabled via the keyboard hotkey and again it made no difference in boot time except that the following message also printed on the boot screen:

RTNETLINK answers: Operation not possible due to RF-kill

Is there any diagnostic or log to check in the booted recovery environment?

jsmeix commented at 2019-08-14 12:02:¶

@adatum
when you boot the ReaR recovery system in its bootloader menue
you can add the kernel command line parameter ' debug'.

This way the recovery system startup scripts are run one by one
(you need to press Enter to run each one) with the bash 'set -x' option set
so that you get the commands of each script printed on the terminal.

This should help to find out in which script the delay
happens at or after which command.

The recovery system setup scripts are in etc/scripts/system-setup.d

The main networking setup script is
/etc/scripts/system-setup.d/60-network-devices.sh
that is generated during "rear mkrescue/mkbackup" by
https://github.com/rear/rear/blob/master/usr/share/rear/rescue/GNU/Linux/310_network_devices.sh

See the usr/share/rear/rescue/GNU/Linux/310_network_devices.sh script
for details how networking setup happens in the recovery system.

adatum commented at 2019-08-16 04:34:¶

With the ReaR recovery system booted with the debug kernel parameter, I could see the delay at each of these commands:

dhclient -lf /var/lib/dhclient/dhclient.leases.eno1 -pf /var/run/dhclient.eno1.pid -cf /etc/dhclient.conf eno1

and

dhclient -lf /var/lib/dhclient/dhclient.leases.wlp2s0 -pf /var/run/dhclient.wlp2s0.pid -cf /etc/dhclient.conf wlp2s0

After the delays, it's fine. ps aux | grep dhclient shows both running, and the system gets an IP if a network connection is up.

jsmeix commented at 2019-08-16 09:30:¶

I know basically nothing about dhclient internals so I cannot provide actual furher help
but I can provide some generic hint how to further debug the actual cause of the delay:

Add whatever debugging commands you need
to your recovery system startup script
usr/share/rear/skel/default/etc/scripts/system-setup.d/58-start-dhclient.sh
https://github.com/rear/rear/blob/master/usr/share/rear/skel/default/etc/scripts/system-setup.d/58-start-dhclient.sh
e.g. adding the '-v' option to the dhclient command for verbose logging
may already show why there is the delay while dhclient runs.

adatum commented at 2019-08-18 02:16:¶

I added -v to the two dhclient commands in /usr/share/rear/skel/default/etc/scripts/system-setupd.d/58-start-dhclient.sh on the host system. Then I re-created the rescue media. But when I boot into the recovery system (including with the debug kernel parameter) the command does not have the -v when it runs.

Did I miss something?

github-actions commented at 2020-06-27 01:33:¶

Stale issue message

[Export of Github issue for rear/rear.]

#2214 Issue closed: Boot delay after attempting to start DHCP client daemon¶