Please disregard the “possible lead” at the end of my original description — the idea that the 82 MB initrd and a wrapping block counter are involved is wrong. I wrote that before I had reproduced the failure on purpose; the reproduction happened about half an hour later the same morning and rules file size out.
What does NOT trigger it Fetching files from the server itself, with the daemon otherwise idle: 30x ltsp.ipxe (3.8 KB), 5x snponly.efi (240 KB), 2x initrd.img (82 MB) with curl initrd.img again with atftp at blksize 1468, 1432 and 512, i.e. what iPXE negotiates All of that completed without a single failure. The daemon stayed in state S and kept answering afterwards. So it is neither the file size nor the negotiated block size, and 82 MB over TFTP is served just fine by 2.91. What does trigger it Two consecutive PXE boots of a real client. The first boot completes, the second one hangs the daemon before it answers anything: 09:54:09 PXE(ens18) 192.168.1.60 ltsp/ltsp.ipxe 09:54:09 sent /srv/tftp/ltsp/ltsp.ipxe to 192.168.1.60 09:54:17 sent /srv/tftp/ltsp/x86_64/vmlinuz to 192.168.1.60 09:54:17 sent /srv/tftp/ltsp/ltsp.img to 192.168.1.60 09:54:32 sent /srv/tftp/ltsp/x86_64/initrd.img to 192.168.1.6009:55:49 vendor class: PXEClient:Arch:00000:UNDI:002001 09:55:49 user class: iPXE -- nothing after this line, ever first boot OK From that line on: state R, 1m24s of CPU in 5m51s of uptime, no answer to any TFTP request (not even from localhost), strace -c -p <pid> records zero syscalls, perf record puts 100% of samples in one call path below __libc_start_main, and nothing further is written to the log. That is exactly the state the server was found in on the morning of 2026-09-03. Note what the daemon logs on the second boot: the vendor class and user class lines, i.e. it is processing the client’s DHCP request, and then it never gets to the TFTP part. DNS is off on this machine (port=0), so this is proxy-DHCP plus TFTP only. The client is a VM booting in BIOS mode (Arch:00000, undionly.kpxe), iPXE 1.20.1+, chainloading ltsp.ipxe. Booting the same client the same way twice against 2.90-2ubuntu0.4 does not reproduce it. Current state, 2026-09-08 Still on 2.90-2ubuntu0.4 with both packages held. Five days and roughly a hundred client boots later the daemon is in state S with 0 seconds of CPU time over the last 10.5 hours, having served this morning’s 18 boots. Same workload, same machine — so whatever 2.91 does here, 2.90 does not. Bug #2166430 reports the same package version breaking ProxyDHCP mode for LTSP clients, with the same workaround. Given that proxy DHCP and TFTP are what both setups use, I suspect one defect behind both reports rather than two. Bug #2166679 is a different symptom (2.91 refusing to start on dhcp-host lines), but the same update. The phased rollout has since gone to 100% (apt-cache policy showed 10% on 2026-09-02, 30% on 2026-09-03, 90% today, and the noble-updates publication was refreshed on 2026-09-07). It reached this machine at 10%. On a desktop nobody notices — dnsmasq is only the NetworkManager backend there. It bites where dnsmasq actually serves PXE, i.e. on LTSP and other netboot servers, and those tend to fail in the morning with twenty people in front of dark screens. Please consider holding the update until this is understood. Workaround, unchangedapt-get install --allow-downgrades dnsmasq=2.90-2ubuntu0.4 dnsmasq-base=2.90-2ubuntu0.4 apt-mark hold dnsmasq dnsmasq-base Note that the hold also stops security updates for dnsmasq, which is why this is not a place we can stay. I have the machine, the clients and a scripted TFTP stress test here and I am happy to test a candidate build or run any instrumentation you would like — including a debug build under gdb to get a backtrace out of the spinning process, if that helps more than the perf output -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166312 Title: dnsmasq 2.91 stops serving TFTP after a few transfers and spins at 100% CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2166312/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
