dhcpcd is called before interfaces have carrier causing a 29 seconds boot delay

[Stefano]

[ 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.

[Benjamin Drung (bdrung)]

Can you add following function to /usr/share/initramfs-tools/scripts/functions:

```
log_flags() {
    for device in /sys/class/net/*; do
        echo "*** flags for $device";
        if [ -f "${device}/flags" ]; then
            cat "${device}/flags";
        fi;
    done
}
```

Please call this function in configure_networking at several places:
* at the beginning of configure_networking
* before the _update_ip_param call
* after the "wait_for_udev 10" call
* after "for ROUNDTTT in 30 60 90 120; do" (so at the beginning of the loop)

[Stefano (luckylinux777)]

Here it's the result

[Benjamin Drung (bdrung)]

Thanks. Next iteration. Here is the updated logging function:

```
log_flags() {
 echo "*******************"
 for device in /sys/class/net/*; do
  if [ ! -f "${device}/flags" ]; then
   echo "*** ${device}/flags missing"
   continue
  fi
  flags="$(cat "${device}/flags")"
  echo "*** ${device}/flags = $flags";
  if [ "$((flags & 1))" -ne 0 ]; then
   printf "*** ${device}/carrier = "
   cat "${device}/carrier"
  fi;
 done
}
```

Can you call log_flags before and after the _set_available_devices_to_up call and also directly before the dhcpcd call?

Once you collected the logs, can you add a "wait_for_udev 10" call after the _set_available_devices_to_up and collect the logs again?

[Stefano (luckylinux777)]

Sure. Here is the result. Before (v6a) and After (v6b) adding the "wait_for_udev 10" call after the _set_available_devices_to_up call.

[Stefano (luckylinux777)]

Also the updated /usr/share/initramfs-tools/scripts/functions file since it changed so much now ...

[Benjamin Drung (bdrung)]

Can you test commenting out the call to _set_available_devices_to_up and add "--nolink" as parameter to the dhcpcd call?

[Stefano (luckylinux777)]

Here you have it

[Stefano (luckylinux777)]

Also the updated /usr/share/initramfs-tools/scripts/functions file since it changed so much now ...

[Benjamin Drung (bdrung)]

That strange. dhcpcd gets the carrier now, but it still retries it.

Can you test the attached functions file? I changed some logging there.

BTW, you can revert the dhcpcd debugging, e.g. `sudo apt install --reinstall dhcpcd-base` and then apply the `return 0` fix.

[Stefano (luckylinux777)]

OK I reverted as you instructed.

I then replaced the functions file with your version: `wget https://launchpadlibrarian.net/728520148/functions -O /usr/share/initramfs-tools/scripts/functions`

Followed by the usual:
`update-initramfs -k all -u; update-grub; update-initramfs -k all -u; update-grub;`

We will have the result in a few Minutes after Rebooting.

[Stefano (luckylinux777)]

Here it is

[Benjamin Drung (bdrung)]

In the first try it only gets a link local address, but no DHCP address. Can you test calling dhcpcd with --noipv4ll?

[Stefano (luckylinux777)]

I'd say we went from 45 seconds until ZFS mounting to 30 seconds until ZFS mounting with --noipv4ll (although I did NOT save all `dmesg` until now, I am comparing the current `dmesg_v9.debug` with --noipv4ll against `dmesg_v4.debug` that I had provided before at https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2065037/comments/2).

So a bit better.

But is the 30 seconds "minimum" dictated by this for loop ?

`for ROUNDTTT in 30 60 90 120; do`

Shouldn't it rather be a lower value at first ? Why wait 30 seconds "for nothing" ?
`for ROUNDTTT in 5 15 30 60 90 120; do`

[Stefano (luckylinux777)]

I did an attempt with `for ROUNDTTT in 5 15 30 60 90 120; do` (including also --noipv4ll).

This brings it down from 30 seconds to approx. 24 seconds.

[Stefano (luckylinux777)]

And now another attempt with `for ROUNDTTT in 5 5 30 60 90 120; do` (including also --noipv4ll).

Still approximatively 24 seconds, that seems to be the minimum thus far.

[Benjamin Drung (bdrung)]

The "-K --noipv4ll" is the solution. Looking at initramfs_v9.debug, dhcpcd is only called once and you do not see any "Sleeping" log messages.

initramfs_v10.debug takes longer because it calls dhcpcd twice. The first call is killed due to "timed out". initramfs_v11.debug calls dhcpcd three times. The first two calls are killed due to the timeout. So you do not want to have a too short timeout to kill a perfectly running dhcpcd client.

[Benjamin Drung (bdrung)]

I opened bug #2065149 because I saw this failure in the logs.

[Stefano (luckylinux777)]

I cannot compare the timing at `initramfs_v9.debug` because I didn't save `dmesg` output then.

I only have `dmesg_v4.debug` and `dmesg_v10.debug` / `dmesg_v11.debug`.

But you can argue that 5-6 seconds difference is not that big of a deal.

I could also re-run with v9 and save dmesg this time.

Looking at `/var/log/dmesg*` I see the last runs were (from most recent to older, i.e. v11-v10-v9-v8-v7-v6, i.e. `dmesg.log`-`dmesg.0`-`dmesg.1.gz`-`dmesg.2.gz`-`dmesg.3.gz`-`dmesg.4.gz`):
```
v11: [ 23.390693] kernel: spl: loading out-of-tree module taints kernel.
v10: [ 24.065033] kernel: spl: loading out-of-tree module taints kernel.
v09: [ 29.016602] kernel: spl: loading out-of-tree module taints kernel.
v08: [ 43.999904] kernel: spl: loading out-of-tree module taints kernel.
v07: [ 44.610778] kernel: spl: loading out-of-tree module taints kernel.
v06: [ 44.220698] kernel: spl: loading out-of-tree module taints kernel.
```

Especially since we went from 300 seconds -> 45 seconds -> 25 ... 30 seconds right now.

That's already a 10x speedup.

What's weird is that on one system I didn't see anything happening at all ... the screen just freezes without any output from dhcpcd or anything else. Maybe it's because on the Laptop I had set `debug` and on the main Workstation I had `nomodeset` ?

(I'm writing you from this "Main" Workstation, the one that we are attempting to fix first is my secondary Laptop ... it's easier to reboot/relogin via SSH rather than having to shutdown my main PC).

Separate Topic ...

Is there a way to configure the logging system so that EVERY boot is a separate /var/log/dmesg and that /var/log/dmesg always stores the FULL content since a given boot ? For "small boots" like the ones I just pasted it works fine, but I think after a while, if the system is actually used, stays in standby/sleep mode for several days and work in-between etc, I think the log gets splitted "after a while". Is there a way to disable this behaviour ? Or else have logs saved by date ? e.g. /var/log/dmesg.20240508.0, /var/log/dmesg.20240508.1, etc ?

[Benjamin Drung (bdrung)]

You can use systemd-analyze to measure the boot speed. This should be more reliable. For some data, it would be useful to boot three times and average over the boot times (plus calculated deviation). The 5-6 seconds difference is not plausible to me since v4 has a 29 seconds sleep. Could you rerun the v4 test (with only the dhcpcd hostname fix) and v9 with the proposed fix (call dhcpcd with "-K --noipv4ll" and remove the _set_available_devices_to_up call)?

Does the system that freezes without any output succeed in booting eventually? If not, that is worth a separate bug report against initramfs-tools.

Regarding your dmesg question: I don't know.

[Stefano (luckylinux777)]

I think you deleted the _set_available_devices_to_up from the functions file yourself when you wanted me to test a custom `functions` File.

I cannot find that function call (or function declaration for that matter) anymore at least ...

I got a bit lost now though ...

So you want me to re-run:

v4: only `need_hostname || return 0` in /usr/lib/dhcpcd/dhcpcd-hooks/30-hostname (https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2064926/comments/21)

v9: `need_hostname || return 0` in /usr/lib/dhcpcd/dhcpcd-hooks/30-hostname (https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2064926/comments/21) PLUS changing `/usr/share/initramfs-tools/scripts/functions` where you want me to change `dhcpcd -1 -t $ROUNDTTT -4 ${DEVICE:+"${DEVICE}"}` to `dhcpcd -1K --noipv4ll -t $ROUNDTTT -4 ${DEVICE:+"${DEVICE}"}` ?

v9: What about the IPv6 Line ? I think you changed it from `dhcpcd -1 -t $ROUNDTTT -6 ${DEVICE6:+"${DEVICE6}"}` to `dhcpcd -1K -t $ROUNDTTT -6 ${DEVICE6:+"${DEVICE6}"}`

[Benjamin Drung (bdrung)]

I suggest to restore the package versions by using `apt install --reinstall` on those package. Then apply the changes that you mentioned plus removing _set_available_devices_to_up in the v9 test. The IPv6 dhcpcd line is not relevant for our case since that code path is not used in your case.

[Stefano (luckylinux777)]

Alright ...

So I issued:
- `apt-get install --reinstall initramfs-tools-core`
- `apt-get install --reinstall dhcpcd-base`

v4_new:
- applied `need_hostname || return 0` in `/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname`
- issued the usual `update-initramfs -k all -u; update-grub; update-initramfs -k all -u; update-grub; reboot`

v9_new:
- same as `v4_new` with respect to `need_hostname || return 0` in /usr/lib/dhcpcd/dhcpcd-hooks/30-hostname
- in `/usr/share/initramfs-tools/scripts/functions` change `dhcpcd -1 -t $ROUNDTTT -4 ${DEVICE:+"${DEVICE}"}` to `dhcpcd -1K --noipv4ll -t $ROUNDTTT -4 ${DEVICE:+"${DEVICE}"}`
- in `/usr/share/initramfs-tools/scripts/functions`remove function call(s) to `_set_available_devices_to_up`

[Benjamin Drung (bdrung)]

Can you run `systemd-analyse` after boot to get the boot time?

[Benjamin Drung (bdrung)]

Looking at dmesg_v4_new.debug:

```
[ 47.841914] systemd[1]: Setting '/proc/sys/kernel/printk_devkmsg' to 'on'
```

This is the first log line from systemd after the initrd handed over the control. So the initrd took roughly 48 seconds.

[Stefano (luckylinux777)]

v9_new output of `systemd-analyze`:
```
Startup finished in 47.314s (kernel) + 27.100s (userspace) = 1min 14.415s
graphical.target reached after 27.063s in userspace.
```

Do I need to repeat `v4_new` ? Looking at `dmesg` I don't see a need since dmesg shows very similar results for v4_new and v9_new.

To be honest v4_new and v9_new behave the same looking at `dmesg`.
We are missing something else.

Both take roughly 45 seconds before ZFS mounting begins.

[Benjamin Drung (bdrung)]

dmesg_v9_new.debug has:

```
[ 47.337075] systemd[1]: Setting '/proc/sys/kernel/printk_devkmsg' to 'on'
```

That matches roughly 47.314s (kernel) from systemd-analyze. So no need to redo v4_new.

v4_new shows 30 seconds of sleep and v9_new does not. Can you sprinkle the code with `cut -f1 -d' ' /proc/uptime` calls to figure out at which point the time is spent? For a baseline, add that call to the beginning and the end of configure_network. I would expect that configure_network takes > 30 seconds for v4_new and it should take ~30 seconds less for v9_new.

[Stefano (luckylinux777)]

Correct me if I'm wrong, but at one point you told me to ADD an `wait_for_udev 10` call before
 (the now disabled) call to `_set_available_devices_to_up`.

Attached the latest `/usr/share/initramfs-tools/scripts/functions` just to make sure we are on the same page with the Modifications.

[Stefano (luckylinux777)]

About `cut -f1 -d' ' /proc/uptime` ... Wouldn't it be better to also indicate where we are when that timestamp is registered ?

If it were BASH I'd probably do a echo "${FUNCNAME[0]} - $(cut -f1 -d' ' /proc/uptime)" but in busybox/dash I really do not know ...

[Benjamin Drung (bdrung)]

Yes, FUNCNAME is only available in bash. You can echo some hard-coded text, e.g.

```
configure_network() {
    echo "$(cut -f1 -d' ' /proc/uptime) configure_network start"
    [...]
    echo "$(cut -f1 -d' ' /proc/uptime) configure_network end"
}

[Benjamin Drung (bdrung)]

The additional `wait_for_udev 10` is not needed (but it should not consume any time at that place).

[Stefano (luckylinux777)]

Probably I had an error in the code, although no error was raised (or at least I didn't catch it):
```
                if [ -z "${DEVICE}" ]; then
                        # _set_available_devices_to_up
                fi
```

An empty if-statement is not valid (at least in BASH it's not acceptable).

Trying to correct to:
```
                if [ -z "${DEVICE}" ]; then
                        # _set_available_devices_to_up
                        local dummyvar=1
                fi

```

[Stefano (luckylinux777)]

Maybe that was the issue indeed ...

Output of `systemd-analyze` after applying the beforementioned fix:
```
Startup finished in 28.780s (kernel) + 24.552s (userspace) = 53.333s
graphical.target reached after 24.517s in userspace.
```

[Benjamin Drung (bdrung)]

You could comment out the complete if-condition instead of adding a dummy variable. BTW, you can check the code with shellcheck after your modification:

```
shellcheck -s sh -e SC3043,SC1090,SC1091 /usr/share/initramfs-tools/scripts/functions
```

Reducing the kernel+initrd time from 47 seconds down to 28 seconds sound correct to me.

[Stefano (luckylinux777)]

Yeah, I should have done that. I'm really getting tired and sleepy, sorry about that.

The 28 seconds is the one we had before as well (the 27-28 s in ... v9, wasn't it ?

But this error caused the script / function to behave similarly to v4 in terms of timings. Could this indicate something else (e.g. that the original script contain some error) ?

But why this minimum of almost 30 seconds ? Is it to satisfy some RFC ?

[Benjamin Drung (bdrung)]

21.67 - 4.42 = 17.25 for the dhcpcd call is quite long. So the remaining initrd takes only 10 seconds.

dhcpcd claims the IP via ARP which takes some time. You can call dhcpcd with `--noarp` to check how much time that takes. Besides of that dhcpcd needs to bring up the interfaces and wait for carriers. I don't know how much time that takes.

[Stefano (luckylinux777)]

Not sure how relevant it is, but **on a booted system**, if I call `dhclient -v` the Interface gets automatically detected, up and offered an IP by the DHCP Server in less than 5 seconds (probably even less than 3 seconds ...).

A bit better with `--no-arp` but not by much.
Output of `systemd-analyze`:
```
Startup finished in 23.722s (kernel) + 27.275s (userspace) = 50.998s
graphical.target reached after 27.194s in userspace.
```

[Stefano (luckylinux777)]

Now I just tried with `dhclient` on my Main Workstation to check the time it takes "from scratch" to bring up and get an IP from DHCP on eno1.

Keep in mind that the "path" to the Router/Gateway (OPNSense Router: 192.168.1.7 master and 192.168.1.8 slave, or 192.168.1.1 Virtual IP) is much longer (there are like 3 extra Switches in between).

EDIT 1: I also tested directly on the Secondary Laptop, there is not a significant time difference. If anything, it is actually slower to bring up Interfaces (possibly due to much weaker CPU).

```
root@HOST:/# ifconfig eno1 0.0.0.0
root@HOST:/# ifconfig
# Only eno1 shown here
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet6 fe80::ec4:7aff:fe79:2d9a prefixlen 64 scopeid 0x20<link>
        ether 0c:c4:7a:79:2d:9a txqueuelen 1000 (Ethernet)
        RX packets 56621 bytes 56090624 (56.0 MB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 20888 bytes 2885632 (2.8 MB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        device memory 0xf7300000-f737ffff
root@HOST:/# ifconfig eno1 down
root@HOST:/# ls -l /var/lib/dhcp/dhclient.*
-rw-r--r-- 1 root root 894 May 9 08:47 /var/lib/dhcp/dhclient.eno1.leases
-rw-r--r-- 1 root root 1552 Feb 20 2022 /var/lib/dhcp/dhclient.eno2.leases
-rw-r--r-- 1 root root 5567 May 6 14:12 /var/lib/dhcp/dhclient.leases
-rw-r--r-- 1 root root 58 Mar 11 18:23 /var/lib/dhcp/dhclient.vmbr0.200.leases
-rw-r--r-- 1 root root 1022 Mar 11 18:23 /var/lib/dhcp/dhclient.vmbr0.leases
-rw-r--r-- 1 root root 641 Mar 9 2022 /var/lib/dhcp/dhclient.wlx00c0ca961be5.leases
root@HOST:/# rm /var/lib/dhcp/dhclient.*
root@HOST:/# date +"%Y%m%d-%H%M%S"; time dhclient -v; date +"%Y%m%d-%H%M%S";
20240509-085910
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

RTNETLINK answers: Network is unreachable
RTNETLINK answers: Network is unreachable
RTNETLINK answers: Network is unreachable
RTNETLINK answers: Network is unreachable
RTNETLINK answers: Network is unreachable
RTNETLINK answers: Network is unreachable
RTNETLINK answers: Network is unreachable
RTNETLINK answers: Network is unreachable
RTNETLINK answers: Network is unreachable
Listening on LPF/virbr0/52:54:00:a2:62:15
Sending on LPF/virbr0/52:54:00:a2:62:15
Listening on LPF/eno2/0c:c4:7a:79:2d:9b
Sending on LPF/eno2/0c:c4:7a:79:2d:9b
Listening on LPF/eno1/0c:c4:7a:79:2d:9a
Sending on LPF/eno1/0c:c4:7a:79:2d:9a
Sending on Socket/fallback
xid: warning: no netdev with useable HWADDR found for seed's uniqueness enforcement
xid: rand init seed (0x6643753e) built using gethostid
DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 3 (xid=0x375da74)
DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 3 (xid=0xc0acb6b)
DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 3 (xid=0xc119e63d)
DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 7 (xid=0xc119e63d)
DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 6 (xid=0x375da74)
DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 4 (xid=0xc0acb6b)
DHCPDISCOVER on eno...

[Stefano (luckylinux777)]

I had to reboot my Main Workstation due to some GTK/Mate/Desktop Environment Issue (maybe related to NVIDIA Drivers ?).

Anyhow I took the opportunity to implement quickly the fixes we discussed:
- `/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname`: `need_hostname || return 0`
- `/usr/share/initramfs-tools/scripts/functions` : `dhcpcd -1K --noipv4ll --noarp -t $ROUNDTTT -4 ${DEVICE:+"${DEVICE}"}`

Output of `systemd-analyze`:
```
Startup finished in 22.505s (kernel) + 50.381s (userspace) = 1min 12.887s
graphical.target reached after 50.366s in userspace.
```

[Stefano (luckylinux777)]

So the good news is that the Fix can be replicated on 2 Machines now :).

ZFS Pool gets mounted at 19.679602 Seconds on the Main Workstation, while it was getting mounted at 20.698236 Seconds on the Secondary Laptop.

That's a bit surprising since the Main Workstation needs to unlock 2 Disks via Clevis (ZFS Pool Mirror VDEV) vs 1 Disk for the Secondary Laptop (ZFS Pool Single Disk VDEV). But of course the Main Workstation has (much) more CPU Power: Intel Xeon E3-1231 v3 (4C / 8T @ 3.50GHz) vs Intel i5-3320M (2C / 4C @ 2.60GHz).

But anyway, that's all within the Margin of Error I'd say. It's consistent behaviour.

Weird though that the Main Workstation screen stays frozen even with `debug` added to the GRUB Command Line and `nomodeset` removed (so it should behave EXACTLY like the Secondary Laptop, except NOTHING gets displayed / refreshed on the screen - maybe output is going to a different console / TTY for some weird reason ?).

[Benjamin Drung (bdrung)]

For the black screen, can you open a separate bug report and document what graphic card you use on that machine and what driver is used on the running system?

[Stefano (luckylinux777)]

Yeah I can do that, that's lower-priority ish. The good thing is that it works. If I cannot see what's happening, that's secondary, I can just look at `dmesg` once the boot is completed, if I really wanted (or `/run/initramfs/initramfs.debug`).

Will you write a Patch for this issue here, like you did with the other DHCPCD bug (the 300s -> 45s Improvement) ?

[Benjamin Drung (bdrung)]

Yes, here is the debdiff for the uploaded SRU fix.

[Timo Aaltonen (tjaalton)]

Hello Stefano, or anyone else affected,

Accepted initramfs-tools into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.142ubuntu25.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Stefano (luckylinux777)]

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"
                        ;;
      ...

[Benjamin Drung (bdrung)]

The ARP check is done to verify that the assigned IP address is not used in the network. So using --noarp will skip this safety-check. IMO the users should do such change explicitly if they want to trade safety by speed (e.g. via a dhcpcd config setting that will be included in the initrd).

[Stefano (luckylinux777)]

Then I think it's OK (if you are satisfied me me being the only one testing the fix) :).

Thanks again for your help.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted initramfs-tools (0.142ubuntu25.1) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

casper/unknown (armhf)
cryptsetup/unknown (arm64)
initramfs-tools/0.142ubuntu25.1 (arm64)
initramfs-tools/unknown (armhf)
mandos/unknown (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#initramfs-tools

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.142ubuntu27

---------------
initramfs-tools (0.142ubuntu27) oracular; urgency=medium

  * Run wrap-and-sort
  * initramfs-tools-core: drop support for upgrading from < 0.138
  * Convert debian/copyright to machine-readable format
  * Switch to debhelper 13
  * Bump Standards-Version to 4.7.0
  * Drop Breaks/Conflicts that predate Debian 10 "buster" and Ubuntu 20.04
  * init: fix setting hostname if busybox is not used

initramfs-tools (0.142ubuntu26) oracular; urgency=medium

  * configure_network: Call dhcpcd with --nolink --noipv4ll to succeed getting
    a DHCP lease on the first try and avoid a 30 seconds delay (LP: #2065037)
  * autopkgtest: Test hostname already set in initrd (LP: #2064926)
  * autopkgtest: Use qemu -cpu max by default

 -- Benjamin Drung <email address hidden> Mon, 20 May 2024 01:17:34 +0200

[Andreas Hasenack (ahasenack)]

I retried the failing armhf dep8 tests and they are now green.

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.142ubuntu25.1

---------------
initramfs-tools (0.142ubuntu25.1) noble; urgency=medium

  * configure_network: Call dhcpcd with --nolink --noipv4ll to succeed getting
    a DHCP lease on the first try and avoid a 30 seconds delay (LP: #2065037)

 -- Benjamin Drung <email address hidden> Fri, 10 May 2024 15:03:48 +0200

[Andreas Hasenack (ahasenack)]

The verification of the Stable Release Update for initramfs-tools has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.