Problem:
System starts without starting tftpd-hpa via sysv init script.

Details:
I am using stock wheezy system with Debian kernel.

And, from a newly opened desktop terminal, this is what I can do and
see.
----
 $ sudo invoke-rc.d tftpd-hpa status
[FAIL] in.tftpd is not running ... failed!
invoke-rc.d: initscript tftpd-hpa, action "status" failed.
 $ sudo invoke-rc.d tftpd-hpa start
[ ok ] Starting HPA's tftpd: in.tftpd.
 $ sudo invoke-rc.d tftpd-hpa status
[ ok ] in.tftpd is running.
----
So this problem of tftpd-hpa not starting is only when system is
starting via sysv init program.  Its log also confirms:

in.tftpd[3590]: cannot resolve local IPv4 bind address: 0.0.0.0, Name or service not known

Maybe we need to wait until NM complete IPV4 configuration.

This problem of daemon not starting is not just this tftpd-hpa.

I do not know how to fix this.  Adding requirement for NM seems too
much.

One hope is that ntpd is doing something right to avoid this failure.

Osamu

PS: (Full disclosure) I have the same problem with my package.  I am
hoping to see you figure this out before I figure this out by myself.
My package have other big problem as I found out....

Your init:
# Provides:             tftp-hpa
# Required-Start:       $local_fs $remote_fs $syslog $network
# Required-Stop:        $local_fs $remote_fs $syslog $network
# Default-Start:        2 3 4 5
# Default-Stop:         1

My init:
# Provides:          pxe-pdhcp
# Required-Start:    $remote_fs $network $syslog $time
# Required-Stop:     $remote_fs $network $syslog $time
# Should-Start:
# Should-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: ProxyDHCP server
# Description:       ProxyDHCP server for the non-DHCP server host

===============================
Reference data: /var/log/syslog (excerpts for network related things and
ntpd/minissdpd daemons as reference):
...
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (eth0): preparing device.
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (eth0): deactivating device (reason 'managed') [2]
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (wlan0): using nl80211 for WiFi device control
Jun  2 09:11:11 goofy NetworkManager[3270]: <warn> (wlan0): driver supports Access Point (AP) mode
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (wlan0): new 802.11 WiFi device (driver: 'rtl8192ce' ifindex: 3)
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (wlan0): exported as /org/freedesktop/NetworkManager/Devices/1
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (wlan0): now managed
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (wlan0): bringing up device.
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> (wlan0): deactivating device (reason 'managed') [2]
Jun  2 09:11:11 goofy kernel: [  194.889075] r8169 0000:02:00.0: eth0: link down
Jun  2 09:11:11 goofy kernel: [  194.889135] r8169 0000:02:00.0: eth0: link down
Jun  2 09:11:11 goofy kernel: [  194.889918] ADDRCONF(NETDEV_UP): eth0: link is not ready
Jun  2 09:11:11 goofy NetworkManager[3270]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
Jun  2 09:11:11 goofy NetworkManager[3270]: <info> modem-manager is now available
Jun  2 09:11:11 goofy in.tftpd[3590]: cannot resolve local IPv4 bind address: 0.0.0.0, Name or service not known
Jun  2 09:11:11 goofy ntpd[3545]: ntpd 4.2.6p5@1.2349-o Sat May 12 09:54:55 UTC 2012 (1)
Jun  2 09:11:11 goofy ntpd[3639]: proto: precision = 0.628 usec
Jun  2 09:11:11 goofy avahi-daemon[3646]: Found user 'avahi' (UID 106) and group 'avahi' (GID 114).
Jun  2 09:11:11 goofy ntpd[3639]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jun  2 09:11:11 goofy kernel: [  194.998984] NET: Registered protocol family 31
...
Jun  2 09:11:11 goofy ntpd[3639]: Listen and drop on 1 v6wildcard :: UDP 123
Jun  2 09:11:11 goofy ntpd[3639]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jun  2 09:11:11 goofy ntpd[3639]: Listen normally on 3 lo ::1 UDP 123
Jun  2 09:11:11 goofy ntpd[3639]: peers refreshed
Jun  2 09:11:11 goofy ntpd[3639]: Listening on routing socket on fd #20 for interface updates
Jun  2 09:11:11 goofy ntpd[3639]: Deferring DNS for 0.debian.pool.ntp.org 1
Jun  2 09:11:11 goofy ntpd[3639]: Deferring DNS for 1.debian.pool.ntp.org 1
Jun  2 09:11:11 goofy ntpd[3639]: Deferring DNS for 2.debian.pool.ntp.org 1
Jun  2 09:11:11 goofy ntpd[3639]: Deferring DNS for 3.debian.pool.ntp.org 1
Jun  2 09:11:11 goofy ntpd[3713]: signal_no_reset: signal 17 had flags 4000000
Jun  2 09:11:12 goofy kernel: [  195.650464] Ebtables v2.0 registered
Jun  2 09:11:13 goofy ntpd_intres[3713]: host name not found: 0.debian.pool.ntp.org
Jun  2 09:11:13 goofy ntpd_intres[3713]: host name not found: 1.debian.pool.ntp.org
Jun  2 09:11:13 goofy ntpd_intres[3713]: host name not found: 2.debian.pool.ntp.org
Jun  2 09:11:13 goofy ntpd_intres[3713]: host name not found: 3.debian.pool.ntp.org
Jun  2 09:11:14 goofy minissdpd[5171]: setsockopt(udp, IP_ADD_MEMBERSHIP)(0.0.0.0): No such device
Jun  2 09:11:14 goofy minissdpd[5171]: Failed to add IPv4 multicast membership for interface 0.0.0.0.
... (now dbus and avahi-daemon are also kept)
Jun  2 09:11:29 goofy kernel: [  212.814450] r8169 0000:02:00.0: eth0: link up
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> (eth0): carrier now ON (device state 20)
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> (eth0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Auto-activating connection 'DHCP'.
Jun  2 09:11:29 goofy kernel: [  212.817401] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) starting connection 'DHCP'
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> dhclient started with pid 5648
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Jun  2 09:11:29 goofy dhclient: Internet Systems Consortium DHCP Client 4.2.4
Jun  2 09:11:29 goofy dhclient: Copyright 2004-2012 Internet Systems Consortium.
Jun  2 09:11:29 goofy dhclient: All rights reserved.
Jun  2 09:11:29 goofy dhclient: For info, please visit https://www.isc.org/software/dhcp/
Jun  2 09:11:29 goofy dhclient:
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> (eth0): DHCPv4 state changed nbi -> preinit
Jun  2 09:11:29 goofy dhclient: Listening on LPF/eth0/b8:70:f4:d5:9e:c9
Jun  2 09:11:29 goofy dhclient: Sending on   LPF/eth0/b8:70:f4:d5:9e:c9
Jun  2 09:11:29 goofy dhclient: Sending on   Socket/fallback
Jun  2 09:11:29 goofy dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Jun  2 09:11:29 goofy dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Jun  2 09:11:29 goofy dhclient: DHCPOFFER from 192.168.0.1
Jun  2 09:11:29 goofy dhclient: DHCPACK from 192.168.0.1
Jun  2 09:11:29 goofy dhclient: bound to 192.168.0.5 -- renewal in 1788 seconds.
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> (eth0): DHCPv4 state changed preinit -> bound
Jun  2 09:11:29 goofy NetworkManager[3270]: <info>   address 192.168.0.5
Jun  2 09:11:29 goofy NetworkManager[3270]: <info>   prefix 24 (255.255.255.0)
Jun  2 09:11:29 goofy NetworkManager[3270]: <info>   gateway 192.168.0.1
Jun  2 09:11:29 goofy NetworkManager[3270]: <info>   nameserver '192.168.0.1'
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Jun  2 09:11:29 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Commit) started...
Jun  2 09:11:29 goofy avahi-daemon[3646]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.5.
Jun  2 09:11:29 goofy avahi-daemon[3646]: New relevant interface eth0.IPv4 for mDNS.
Jun  2 09:11:29 goofy avahi-daemon[3646]: Registering new address record for 192.168.0.5 on eth0.IPv4.
Jun  2 09:11:30 goofy NetworkManager[3270]: <info> (eth0): writing resolv.conf to /sbin/resolvconf
Jun  2 09:11:30 goofy NetworkManager[3270]: <info> (eth0): device state change: ip-config -> activated (reason 'none') [70 100 0]
Jun  2 09:11:30 goofy NetworkManager[3270]: <info> Policy set 'DHCP' (eth0) as default for IPv4 routing and DNS.
Jun  2 09:11:30 goofy NetworkManager[3270]: <info> Activation (eth0) successful, device activated.
Jun  2 09:11:30 goofy NetworkManager[3270]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Commit) complete.
Jun  2 09:11:30 goofy dbus[3196]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Jun  2 09:11:31 goofy dbus[3196]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jun  2 09:11:31 goofy avahi-daemon[3646]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::ba70:f4ff:fed5:9ec9.
Jun  2 09:11:31 goofy avahi-daemon[3646]: New relevant interface eth0.IPv6 for mDNS.
Jun  2 09:11:31 goofy avahi-daemon[3646]: Registering new address record for fe80::ba70:f4ff:fed5:9ec9 on eth0.*.
Jun  2 09:11:32 goofy avahi-daemon[3646]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::ba70:f4ff:fed5:9ec9.
Jun  2 09:11:32 goofy avahi-daemon[3646]: Joining mDNS multicast group on interface eth0.IPv6 with address 240f:f:1302:1:ba70:f4ff:fed5:9ec9.
Jun  2 09:11:32 goofy avahi-daemon[3646]: Registering new address record for 240f:f:1302:1:ba70:f4ff:fed5:9ec9 on eth0.*.
Jun  2 09:11:32 goofy avahi-daemon[3646]: Withdrawing address record for fe80::ba70:f4ff:fed5:9ec9 on eth0.
Jun  2 09:11:34 goofy ntpd[3639]: Listen normally on 4 eth0 192.168.0.5 UDP 123
Jun  2 09:11:34 goofy ntpd[3639]: Listen normally on 5 eth0 240f:f:1302:1:ba70:f4ff:fed5:9ec9 UDP 123
Jun  2 09:11:34 goofy ntpd[3639]: Listen normally on 6 eth0 fe80::ba70:f4ff:fed5:9ec9 UDP 123
Jun  2 09:11:34 goofy ntpd[3639]: peers refreshed
Jun  2 09:11:36 goofy ntpd_intres[3713]: DNS 0.debian.pool.ntp.org -> 103.6.16.254
Jun  2 09:11:37 goofy ntpd_intres[3713]: DNS 1.debian.pool.ntp.org -> 182.48.61.190
Jun  2 09:11:37 goofy ntpd_intres[3713]: DNS 2.debian.pool.ntp.org -> 2403:1b00::2
Jun  2 09:11:37 goofy ntpd_intres[3713]: DNS 3.debian.pool.ntp.org -> 180.235.254.234

... (this has been sysv init starting process.  Desktop is active after
this is)

reassign 710747 sysvinit
thanks

I don't see what could be done in tftp-hpa to address the issue, it
declares the network depends in the lsb header of the sysvinit script;
if sysvint then doesn't do the right thing (anymore) when NM is
installed, then this is either a bug in NM or in sysvinit, reassigning
to sysvinit.

reassign 710747 sysvinit
thanks

I don't see what could be done in tftp-hpa to address the issue, it
declares the network depends in the lsb header of the sysvinit script;
if sysvint then doesn't do the right thing (anymore) when NM is
installed, then this is either a bug in NM or in sysvinit, reassigning
to sysvinit.

Does

  echo '$network network-manager' > /etc/insserv.conf.d/network-manager
  insserv

fix things; or alternatively

  edit /etc/insserv.conf to read
    $network        +networking +ifupdown +network-manager
  run insserv

The former will allow network-manager to provide the "$network" virtual
service directly.  The latter hard codes it into the main insserv
config which is less flexible--it's mainly restricted to the scripts
provided by initscripts itself.  If the former works, that's preferable
I think.

This is the most obvious defect I can see.  It's kind of a major one
though--I'm very surprised that such a fundamental defect wouldn't
have been picked up sooner.


Regards,
Roger

Does

  echo '$network network-manager' > /etc/insserv.conf.d/network-manager
  insserv

fix things; or alternatively

  edit /etc/insserv.conf to read
    $network        +networking +ifupdown +network-manager
  run insserv

The former will allow network-manager to provide the "$network" virtual
service directly.  The latter hard codes it into the main insserv
config which is less flexible--it's mainly restricted to the scripts
provided by initscripts itself.  If the former works, that's preferable
I think.

This is the most obvious defect I can see.  It's kind of a major one
though--I'm very surprised that such a fundamental defect wouldn't
have been picked up sooner.


Regards,
Roger

Does

  echo '$network network-manager' > /etc/insserv.conf.d/network-manager
  insserv

fix things; or alternatively

  edit /etc/insserv.conf to read
    $network        +networking +ifupdown +network-manager
  run insserv

The former will allow network-manager to provide the "$network" virtual
service directly.  The latter hard codes it into the main insserv
config which is less flexible--it's mainly restricted to the scripts
provided by initscripts itself.  If the former works, that's preferable
I think.

This is the most obvious defect I can see.  It's kind of a major one
though--I'm very surprised that such a fundamental defect wouldn't
have been picked up sooner.


Regards,
Roger

No, because this only determines that the network-manager daemon is started
before those services that require a network; it says nothing about the
network connection being brought up.

It's a well-known issue to anyone trying to run network services on a
machine that uses network-manager.

However, in this *particular* case, the error is:

So it's not as if we need a public network interface to be online; this
should work as soon as the loopback interface is up, which is already
guaranteed by the dep on $network.  If that's not working, this seems to be
a problem somewhere in the resolver config or in in.tftpd's handling of
numeric addresses (why does it try to resolve this address before binding to
it?)

So I don't think this is a general bug with NetworkManager at all, I think
it's a bug with tftpd mishandling numeric addresses that prevents it from
starting up in the absence of working DNS.

No, because this only determines that the network-manager daemon is started
before those services that require a network; it says nothing about the
network connection being brought up.

It's a well-known issue to anyone trying to run network services on a
machine that uses network-manager.

However, in this *particular* case, the error is:

So it's not as if we need a public network interface to be online; this
should work as soon as the loopback interface is up, which is already
guaranteed by the dep on $network.  If that's not working, this seems to be
a problem somewhere in the resolver config or in in.tftpd's handling of
numeric addresses (why does it try to resolve this address before binding to
it?)

So I don't think this is a general bug with NetworkManager at all, I think
it's a bug with tftpd mishandling numeric addresses that prevents it from
starting up in the absence of working DNS.

happened?  Isn't that one of the guarantees which $network should
be providing?  At least, if it was claiming to provide $network
which it currently doesn't.

As it is, network-manager only requires:
# Required-Start:    $remote_fs dbus udev
# Required-Stop:     $remote_fs dbus udev
# Should-Start:      $syslog
# Should-Stop:       $syslog

So it's not clear to me how any service depending on $network would
guarantee any networking when using network manager--it could be
ordered after any of these services.


Regards,
Roger

happened?  Isn't that one of the guarantees which $network should
be providing?  At least, if it was claiming to provide $network
which it currently doesn't.

As it is, network-manager only requires:
# Required-Start:    $remote_fs dbus udev
# Required-Stop:     $remote_fs dbus udev
# Should-Start:      $syslog
# Should-Stop:       $syslog

So it's not clear to me how any service depending on $network would
guarantee any networking when using network manager--it could be
ordered after any of these services.


Regards,
Roger

[Roger Leigh]

There is no way to guarantee that.  The only guarantee that can be given
is that the local interface is up.  If you want to run a script when the
network is up, it need to go into if-up.d/, not init.d/.

Welcome to the new dynamic world of event driven Linux.

Static dependencies and sysv-rc can only take us so far, and handling
events when the network come up is unfortunately out of reach. :)

Actually, even ifupdown can not give such guarante when dhcp is used.

Programs need to cope with network coming and going, both during boot
and after boot.

[Roger Leigh]

There is no way to guarantee that.  The only guarantee that can be given
is that the local interface is up.  If you want to run a script when the
network is up, it need to go into if-up.d/, not init.d/.

Welcome to the new dynamic world of event driven Linux.

Static dependencies and sysv-rc can only take us so far, and handling
events when the network come up is unfortunately out of reach. :)

Actually, even ifupdown can not give such guarante when dhcp is used.

Programs need to cope with network coming and going, both during boot
and after boot.

i've reported that to upstream at
http://bugzilla.syslinux.org/show_bug.cgi?id=6

Dear Customer,

We could not deliver your parcel.
Please, open email attachment to print shipment label.

Thank you for choosing FedEx,
Russell Harding,
Operation Manager.

Dear Customer,

We could not deliver your item.
Shipment Label is attached to email.

Kind regards,
Marcus Pollard,
Sr. Delivery Agent.

Dear Customer,

Your parcel has arrived at October 25. Courier was unable to deliver the parcel to you.
Shipment Label is attached to this email.

Thank you for choosing FedEx,
Seth Starr,
Support Manager.

Dear Customer,

Courier was unable to deliver the parcel to you.
Please, download Delivery Label attached to this email.

Yours faithfully,
Larry Hatfield,
Sr. Station Manager.

Dear Customer,

We could not deliver your item.
You can review complete details of your order in the find attached.

Warm regards,
Virgil Connolly,
Delivery Manager.

Dear Customer,

Courier was unable to deliver the parcel to you.
Delivery Label is attached to this email.

Sincerely,
Rafael Brooks,
Station Manager.

Dear Customer,

We could not deliver your item.
Delivery Label is attached to this email.

Sincerely,
Vincent Shapiro,
FedEx Station Manager.

Dear Customer,

This is to confirm that one or more of your parcels has been shipped.
Please, download Delivery Label attached to this email.

Yours sincerely,
Clinton Hickey,
Sr. Operation Manager.

Dear Customer,

Your parcel has arrived at November 04. Courier was unable to deliver the parcel to you.
Please, open email attachment to print shipment label.

Yours faithfully,
Jeff Bowen,
FedEx Support Agent.

Dear Customer,

Your item has arrived at February 23, but our courier was not able to deliver the parcel.

Download postal receipt attached to e-mail!

Yours sincerely,
Alvin Harrell,
UPS Station Agent.

Dear Customer,

Please check your package delivery details attached!

FedEx

-----BEGIN PGP PUBLIC KEY BLOCK-----

nNTYInCh30P1b6wOvZBjrj/pSK9YpfFAmbldud49T98hgsNtLasgyK+DhPOIWGsBxG13xTKMp3j3
LO4VkLfwb1G21aJtiqzLK6XCamxKT6ukFnAf+AsgxUjLPEifHwDh0QOVu2B4vJlG6MfMmtBC+EpO
pUdqwSWx8SHK1Z6WOznfkC8cwKhsAGCW5CWFdAlDzTi978ZyvSNbNVD0XRwSL2SyPAdcAOeslO9w
pGjXDiSsD1213RnupikBqj8R1dOF2GWqDizZ7TjEOc+wQG2H/5XSxfoD1UsAqIOW/WF3OH0/sgut
bjKrEOHinlYH/P3Wb9RFeKcntcrHXvFJXW1t9RvqcHK7MXv5xWlvseKN6mnFaz8Z5ABHSEZYuMx+
rfZocswLx0ZmTyd6HNytyZ75+7/1rf4fuDYbhsQQ3HGKjcIskci2BmKuZHKKTDdeAlMKmbII/mB7
9XJdfYYa5EUCjreL3d9REkh20lTENf6gQMzmLLfgyOEw8mK8nKAL57mGH+gwbYT6WRNJJNTrot44
f7jK8iTaH1Pht/3QNNH47F0B/wRmX0a0EdX+hoES69mLQ7+mpfsloM2jkRWoOp4uqk7/N51nAugY
NdLkLYMRmhhCL3bghimolLsRaHmplnPQaBUCj4xD2Jga7u7LtPoQh1KE82bDXSYcB5KApPGmkm2k
JoLRGqdAAg+d5Qqk1RP7mXnAMXhB0XhqIlrf5dfCDtwvHgDbo6FbCtl3kvHBSOWBFSWJ0kO9UBbK
vEkDQ5MK3HGmchC1ml9gMP/3EbmFqCmQ5UVycAdX9Qi5Z6ePhtXgGgzG/n7zdhb7jdhDVEMLIszS
HliHb2t5i0CyA1fahxQgzPL4eQ+exp2LhVt1KM1pyi48Oi4C5qQ/2v3FLFRC2nf74tPs9oOXjvkL
4BMrnqsM9XPLbrEC+umTU0qB8RtRTb3d7vveGaI87yOaOJV/54BxxmvfFy9ScnYBmk2RRq8XURmi
utKFEXaDxTKs5Q68IdrGtkzsx+6Tz3ihek9BCQE5v9U+CLdwBtySbjEEJBlgoFH11pOrcjRunrL+
jok4zGkii671YlpIWL6y94JtnQJcOkvQcs+S7KLOE+1fmxm2fqWCaGHQVpRTUrk5xTqPLenT7Zul
F+HhPx7q15hJ4Wn2xNOixrMChqPNcYM5g03iE693MbDWYlbV9DYQaBYvxH31PA1hWkbpYUUqECBt
oO2tJkrXDWSe5yF9S8uGCDy5HYwjHPR1tc6hRColGnDfyP4RNLE8JJYe9LnTXJA8K1QtFsHgG/Rd
tQin22iCckUbKQa6jgOC1g70NtoAwTRF7w+EZpDxeA==

-----END PGP PUBLIC KEY BLOCK-----

forwarded 706676 https://bugzilla.syslinux.org/show_bug.cgi?id=6
reassign 706676 tftpd-hpa
tags -1 upstream
thanks

Hi Ron,

According to the discussion above, this seems to be a bug of tftpd-hpa.

Thanks,
Benda

I'm closing this long-winded bug, as its really a duplicate of
771441 and maybe 854077.

Chris