AW: AW: AW: PXE boot with UEFI

2019-12-06 Diskussionsfäden Frank Morawietz
>>> You can troubleshoot the issue using a tftp client on one
>>> of your test boxes.
>> Nice idea! I booted the client into Knoppix, installed the  tftp-hpa  client 
>> and tested.
>> I could successfully get every single file from the server in /srv/tftp/fai/ 
>> .
>> Worked without any issue and on server side no refused nor any other error.
>>
>> So it does not seem to be a problem with the tftp server, right?
>>
>Agreed... sigh.  Not sure how much of a difference this would make, but
>did you boot Knoppix in legacy or UEFI?

UEFI, of course.   

>Otherwise this definitely seems to be an issue with the tftp client when
>PXE booting in UEFI mode only.  Interesting that you did not see any
>errors in the logs when you tried with and without the firewall...

Is the tftp client included in the PXE ROM?

>so does that mean you see 2 sets of symptoms:
>Either:
>1. you see the connection refused errors and a few retries in the logs, or
>2. you see no connection refused errors but nothing happens past the
>second request for the syslinux64.efi file

First it was 1. Then it became 2. Logs were always complete, no lines were 
omitted.

>Looking back through the thread I don't see you mentioning anything
>about the client side...

Well, it's hard to see anything on the client if the client does not start.

>Do you see any PXE error messages on the client?

I had the impression that there was an additional message flashing by for a 
millisecond between the trying to boot via PXE and the boot failed messages.
Then I even filmed it with my smartphone and went through the single images.
The messages was "Succeed to download NBP file."

>Have you updated the firmware on the client to the latest available version?

I updated the BIOS to the most recent version. I think the PXE software is part 
of the BIOS.

>Do you have another client box (different brand, or newer model) that
>you can try?

Will do that soon. I just got 16 brand new Dell workstations delivered that I 
plan to install with FAI...

>The one similar set of symptoms I have run across in looking on the web
>also worked in legacy but not uefi... turned out to be a
>hardware/firmware issue on the client box.
>Past this, unfortunately, I got nothing.

Thanks a lot for your ideas!
Frank
--
Frank Morawietz


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, you 
must not copy this message or attachment or disclose the contents to any other 
person. If you have received this transmission in error, please notify the 
sender immediately and delete the message and any attachment from your system. 
Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept 
liability for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any unauthorized 
changes of the content of this message and any attachment thereto. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not guarantee that this 
message is free of viruses and does not accept liability for any damages caused 
by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.


AW: AW: PXE boot with UEFI

2019-12-06 Diskussionsfäden Frank Morawietz
> I had problems with my thinkpad in the past when booting UEFI. First I
> needed the newest syslinux binary, in those days I was still running
> stretch. Then, my thinkpad T480 needs a long time and shows several
> transmision error (currently I  cannot say which exact messages) when
> doing UEFI boot. But after multiple error message it succeeds to boot.

I am not so familiar with Debian versioning...

The pxelinux and syslinux installed on my FAI server seem to be version 6.03:

# dpkg -l pxelinux syslinux-common
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---===
ii  pxelinux3:6.03+dfsg-14.1 all  collection of 
bootloaders (PXE network bootloader)
ii  syslinux-common 3:6.03+dfsg-14.1 all  collection of 
bootloaders (common)

The latest version of syslinux on Kernel.org as well is 6.03 from 2014.

So on first sight they looked like the same to me.

Nevertheless, I downloaded the version from Kernel.org and replaced the EFI 
boot files in  /srv/tftp/fai/  on my FAI server.

To my big surprise, the PXE boot in UEFI mode works with those replaced images!
Good hint, Thomas!

Now, this is a big step forward.
(UEFI installation provides more issues - there is more to come...)

Thanks to all who provided input and ideas!
Frank
--
Frank Morawietz


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, you 
must not copy this message or attachment or disclose the contents to any other 
person. If you have received this transmission in error, please notify the 
sender immediately and delete the message and any attachment from your system. 
Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept 
liability for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any unauthorized 
changes of the content of this message and any attachment thereto. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not guarantee that this 
message is free of viruses and does not accept liability for any damages caused 
by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.


Re: AW: AW: PXE boot with UEFI

2019-12-05 Diskussionsfäden CSCI Technician




On 12/5/19 5:33 AM, Frank Morawietz wrote:



You can troubleshoot the issue using a tftp client on one
of your test boxes.

Nice idea! I booted the client into Knoppix, installed the  tftp-hpa  client 
and tested.
I could successfully get every single file from the server in /srv/tftp/fai/ .
Worked without any issue and on server side no refused nor any other error.

So it does not seem to be a problem with the tftp server, right?

Agreed... sigh.  Not sure how much of a difference this would make, but 
did you boot Knoppix in legacy or UEFI?
Otherwise this definitely seems to be an issue with the tftp client when 
PXE booting in UEFI mode only.  Interesting that you did not see any 
errors in the logs when you tried with and without the firewall... so 
does that mean you see 2 sets of symptoms:

Either:
1. you see the connection refused errors and a few retries in the logs, or
2. you see no connection refused errors but nothing happens past the 
second request for the syslinux64.efi file


Looking back through the thread I don't see you mentioning anything 
about the client side...

Do you see any PXE error messages on the client?
Have you updated the firmware on the client to the latest available version?
Do you have another client box (different brand, or newer model) that 
you can try?


The one similar set of symptoms I have run across in looking on the web 
also worked in legacy but not uefi... turned out to be a 
hardware/firmware issue on the client box.


Past this, unfortunately, I got nothing.

Cheers,
Merlin

--
Merlin Hansen
Department of Computing Science
Vancouver Island University
900 Fifth Street
Nanaimo BC  V9R 5S5
250-753-3245 x 2321
t...@csci.viu.ca



AW: AW: PXE boot with UEFI

2019-12-05 Diskussionsfäden Frank Morawietz
> To clarify, this client can successfully tftp the pxelinux.0 file over
> when configured for legacy BIOS mode?

Yes, exactly. This works.

> This looks suspiciously like a config problem on the server
> (firewall?).

The client is connected via direct cross link TP cable to the server and the 
firewall is configured to accept anything from that interface.
To eliminate mistakes in the firewall configuration or bugs, I also tried with 
the firewall stopped. Same result on the client.

Corresponding complete log on server during this time:

Dec  5 14:21:06 sysadm02 systemd[1]: Stopping nftables...
Dec  5 14:21:06 sysadm02 systemd[1]: Stopped nftables.
Dec  5 14:22:23 sysadm02 dhcpd[12875]: DHCPDISCOVER from 50:9a:4c:43:c1:b7 via 
ens9
Dec  5 14:22:23 sysadm02 dhcpd[12875]: DHCPOFFER on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  5 14:22:27 sysadm02 dhcpd[12875]: DHCPREQUEST for 10.250.217.16 
(10.250.217.102) from 50:9a:4c:43:c1:b7 via ens9
Dec  5 14:22:27 sysadm02 dhcpd[12875]: DHCPACK on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  5 14:22:27 sysadm02 in.tftpd[26988]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  5 14:22:27 sysadm02 in.tftpd[26988]: tftp: client does not accept options
Dec  5 14:22:27 sysadm02 in.tftpd[26989]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  5 14:22:49 sysadm02 systemd[1]: Starting nftables...
Dec  5 14:22:49 sysadm02 systemd[1]: Started nftables.

The connection refused message is missing, but it just ends after second try 
with syslinux64.efi .

With the firewall enabled again, it looks exactly the same:

Dec  5 14:22:49 sysadm02 systemd[1]: Starting nftables...
Dec  5 14:22:49 sysadm02 systemd[1]: Started nftables.
Dec  5 14:26:05 sysadm02 dhcpd[12875]: DHCPDISCOVER from 50:9a:4c:43:c1:b7 via 
ens9
Dec  5 14:26:05 sysadm02 dhcpd[12875]: DHCPOFFER on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  5 14:26:09 sysadm02 dhcpd[12875]: DHCPREQUEST for 10.250.217.16 
(10.250.217.102) from 50:9a:4c:43:c1:b7 via ens9
Dec  5 14:26:09 sysadm02 dhcpd[12875]: DHCPACK on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  5 14:26:09 sysadm02 in.tftpd[27017]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  5 14:26:09 sysadm02 in.tftpd[27017]: tftp: client does not accept options
Dec  5 14:26:09 sysadm02 in.tftpd[27018]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi

Connection refused seems to be gone. But PXE boot still does not work.
Note that the log is complete, no lines were omitted.

> You can troubleshoot the issue using a tftp client on one
> of your test boxes.

Nice idea! I booted the client into Knoppix, installed the  tftp-hpa  client 
and tested.
I could successfully get every single file from the server in /srv/tftp/fai/ .
Worked without any issue and on server side no refused nor any other error.

So it does not seem to be a problem with the tftp server, right?

Regards,
Frank
--
Frank Morawietz


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, you 
must not copy this message or attachment or disclose the contents to any other 
person. If you have received this transmission in error, please notify the 
sender immediately and delete the message and any attachment from your system. 
Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept 
liability for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any unauthorized 
changes of the content of this message and any attachment thereto. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not guarantee that this 
message is free of viruses and does not accept liability for any damages caused 
by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.


Re: AW: PXE boot with UEFI

2019-12-04 Diskussionsfäden CSCI Technician



On 12/4/19 1:40 AM, Frank Morawietz wrote:

Some additional information:

I picked the boot files from the local syslinux installation:
- /usr/lib/syslinux/modules/efi32/syslinux.c32  -->  syslinux32.efi
- /usr/lib/syslinux/modules/efi64/syslinux.c32  -->  syslinux64.efi
- /usr/lib/syslinux/modules/bios/ldlinux.c32  -->  ldlinux.c32
- /usr/lib/syslinux/modules/efi32/ldlinux.e32 -->  ldlinux.e32
- /usr/lib/syslinux/modules/efi64/ldlinux.e64 -->  ldlinux.e64

All boot files are in  /srv/tftp/fai/ , with modified names where necessary.

In comparison, the DHCP + TFTP logs of a working installation in legacy BIOS 
mode look like this:

Dec  3 14:38:44 sysadm02 dhcpd[12875]: DHCPDISCOVER from 50:9a:4c:43:c1:b7 via 
ens9
Dec  3 14:38:44 sysadm02 dhcpd[12875]: DHCPOFFER on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 14:38:48 sysadm02 dhcpd[12875]: DHCPREQUEST for 10.250.217.16 
(10.250.217.102) from 50:9a:4c:43:c1:b7 via ens9
Dec  3 14:38:48 sysadm02 dhcpd[12875]: DHCPACK on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 14:38:48 sysadm02 in.tftpd[14209]: RRQ from 10.250.217.16 filename 
fai/pxelinux.0
Dec  3 14:38:48 sysadm02 in.tftpd[14209]: tftp: client does not accept options
Dec  3 14:38:48 sysadm02 in.tftpd[14210]: RRQ from 10.250.217.16 filename 
fai/pxelinux.0
Dec  3 14:38:48 sysadm02 in.tftpd[14211]: RRQ from 10.250.217.16 filename 
fai/ldlinux.c32
Dec  3 14:38:48 sysadm02 in.tftpd[14212]: RRQ from 10.250.217.16 filename 
fai/pxelinux.cfg/44454c4c-3200-1056-8052-c
3c04f314c32
Dec  3 14:38:48 sysadm02 in.tftpd[14212]: sending NAK (1, File not found) to 
10.250.217.16
Dec  3 14:38:48 sysadm02 in.tftpd[14213]: RRQ from 10.250.217.16 filename 
fai/pxelinux.cfg/01-50-9a-4c-43-c1-b7
Dec  3 14:38:48 sysadm02 in.tftpd[14213]: sending NAK (1, File not found) to 
10.250.217.16
Dec  3 14:38:48 sysadm02 in.tftpd[14214]: RRQ from 10.250.217.16 filename 
fai/pxelinux.cfg/0AFAD910
Dec  3 14:38:48 sysadm02 in.tftpd[14215]: RRQ from 10.250.217.16 filename 
fai/vmlinuz-4.9.0-9-amd64
Dec  3 14:38:49 sysadm02 in.tftpd[14216]: RRQ from 10.250.217.16 filename 
fai/initrd.img-4.9.0-9-amd64

So it looks like the UEFI tftp connection refused error happened where ldlinux 
should be transferred.
So here we see a request for pxelinux.0, then option negotiation, then 
request for the pxelinux.0 file; which it looks like happens 
successfully.  All of this happens in the space of a second.


In the UEFI logs we see a request for syslinux64.efi, a connection 
refused error, another request for the file, then negotiations of 
options, then a request for the file again.


It almost looks like the connection refused causes a 4 second backoff 
until it is retried and then successful... at least the connection 
appears successful (being that options are negotiated and the file is 
requested again, which is the same order as the legacy log above).


Do you have a longer trace of the UEFI boot?  What happens after the 
second request after option negotiations? Do you continue to get 
connection refused errors?


I don't know what causes your initial connection refused error but it 
looks like the second attempt is quasi-successful (without seeing more 
of the log).



Did you get a chance to try getting the files manually using a tftp 
client?  The clients have verbose and packet tracing flags that you can 
turn on and maybe get more information.


Cheers,
Merlin.



--

Merlin Hansen
Department of Computing Science
Vancouver Island University
900 Fifth Street
Nanaimo BC  V9R 5S5
250-753-3245 x 2321
t...@csci.viu.ca



Re: AW: PXE boot with UEFI

2019-12-04 Diskussionsfäden Thomas Lange
> On Wed, 4 Dec 2019 09:40:45 +, Frank Morawietz 
>  said:

> So it looks like the UEFI tftp connection refused error happened where 
ldlinux should be transferred.

> Is there anything else I could examine to diagnose further?
I had problems with my thinkpad in the past when booting UEFI. First I
needed the newest syslinux binary, in those days I was still running
stretch. Then, my thinkpad T480 needs a long time and shows several
transmision error (currently I  cannot say which exact messages) when
doing UEFI boot. But after multiple error message it succeeds to boot.

-- 
regards Thomas


AW: PXE boot with UEFI

2019-12-04 Diskussionsfäden Frank Morawietz
> have you considered tcp wrappers ?

Thanks for your input.

In my opinion, installation in legacy mode shouldn't work either if something 
like tcp wrappers or a firewall would hinder the installation in UEFI mode. IP 
addresses and ports would be the same.

Some additional information:

I picked the boot files from the local syslinux installation:
- /usr/lib/syslinux/modules/efi32/syslinux.c32  -->  syslinux32.efi
- /usr/lib/syslinux/modules/efi64/syslinux.c32  -->  syslinux64.efi
- /usr/lib/syslinux/modules/bios/ldlinux.c32  -->  ldlinux.c32
- /usr/lib/syslinux/modules/efi32/ldlinux.e32 -->  ldlinux.e32
- /usr/lib/syslinux/modules/efi64/ldlinux.e64 -->  ldlinux.e64

All boot files are in  /srv/tftp/fai/ , with modified names where necessary.

In comparison, the DHCP + TFTP logs of a working installation in legacy BIOS 
mode look like this:

Dec  3 14:38:44 sysadm02 dhcpd[12875]: DHCPDISCOVER from 50:9a:4c:43:c1:b7 via 
ens9
Dec  3 14:38:44 sysadm02 dhcpd[12875]: DHCPOFFER on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 14:38:48 sysadm02 dhcpd[12875]: DHCPREQUEST for 10.250.217.16 
(10.250.217.102) from 50:9a:4c:43:c1:b7 via ens9
Dec  3 14:38:48 sysadm02 dhcpd[12875]: DHCPACK on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 14:38:48 sysadm02 in.tftpd[14209]: RRQ from 10.250.217.16 filename 
fai/pxelinux.0
Dec  3 14:38:48 sysadm02 in.tftpd[14209]: tftp: client does not accept options
Dec  3 14:38:48 sysadm02 in.tftpd[14210]: RRQ from 10.250.217.16 filename 
fai/pxelinux.0
Dec  3 14:38:48 sysadm02 in.tftpd[14211]: RRQ from 10.250.217.16 filename 
fai/ldlinux.c32
Dec  3 14:38:48 sysadm02 in.tftpd[14212]: RRQ from 10.250.217.16 filename 
fai/pxelinux.cfg/44454c4c-3200-1056-8052-c
3c04f314c32
Dec  3 14:38:48 sysadm02 in.tftpd[14212]: sending NAK (1, File not found) to 
10.250.217.16
Dec  3 14:38:48 sysadm02 in.tftpd[14213]: RRQ from 10.250.217.16 filename 
fai/pxelinux.cfg/01-50-9a-4c-43-c1-b7
Dec  3 14:38:48 sysadm02 in.tftpd[14213]: sending NAK (1, File not found) to 
10.250.217.16
Dec  3 14:38:48 sysadm02 in.tftpd[14214]: RRQ from 10.250.217.16 filename 
fai/pxelinux.cfg/0AFAD910
Dec  3 14:38:48 sysadm02 in.tftpd[14215]: RRQ from 10.250.217.16 filename 
fai/vmlinuz-4.9.0-9-amd64
Dec  3 14:38:49 sysadm02 in.tftpd[14216]: RRQ from 10.250.217.16 filename 
fai/initrd.img-4.9.0-9-amd64

So it looks like the UEFI tftp connection refused error happened where ldlinux 
should be transferred.

Is there anything else I could examine to diagnose further?

Regards,
Frank
--
Frank Morawietz


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, you 
must not copy this message or attachment or disclose the contents to any other 
person. If you have received this transmission in error, please notify the 
sender immediately and delete the message and any attachment from your system. 
Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept 
liability for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any unauthorized 
changes of the content of this message and any attachment thereto. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not guarantee that this 
message is free of viruses and does not accept liability for any damages caused 
by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.


Re: AW: PXE boot with UEFI

2019-12-03 Diskussionsfäden CSCI Technician




On 12/3/19 2:50 AM, Frank Morawietz wrote:

Many thanks Steffen and Merlin for your configuration details!
I learned a lot already and I believe that we are on the right track.

I included your suggestions into my  dhpcd.conf  .
According to the log output below it seems to select the correct file now.

But I still could not yet get it to work correctly.

In order to debug this I increased the tftpd verbosity level. And this is what 
I now get in daemon.log when I try again:

Dec  3 11:31:34 sysadm02 dhcpd[12875]: DHCPDISCOVER from 50:9a:4c:43:c1:b7 via 
ens9
Dec  3 11:31:34 sysadm02 dhcpd[12875]: DHCPOFFER on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 dhcpd[12875]: DHCPREQUEST for 10.250.217.16 
(10.250.217.102) from 50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 dhcpd[12875]: DHCPACK on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 in.tftpd[13050]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  3 11:31:37 sysadm02 in.tftpd[13050]: tftpd: read: Connection refused
Dec  3 11:31:41 sysadm02 in.tftpd[13052]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  3 11:31:41 sysadm02 in.tftpd[13052]: tftp: client does not accept options
Dec  3 11:31:41 sysadm02 in.tftpd[13053]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi

10.250.217.16 is the installation client.

Any idea which read failed for tftpd ?
The syslinux files all are mode 644, so they are readable. Directories are 755.
What may refuse the connection for tftpd?

The "client does not accept options" does not express a problem. This message 
also appears when the install boot is successful (in legacy BIOS mode).

To clarify, this client can successfully tftp the pxelinux.0 file over 
when configured for legacy BIOS mode?
I agree that the "client does not accept options" message is not an 
issue as I see this also as part of the tftp connection negotiations.
I also confirmed that my files are 644 and owned by root so that is not 
the issue.


This looks suspiciously like a config problem on the server 
(firewall?).  You can troubleshoot the issue using a tftp client on one 
of your test boxes.

- install a tftp client if you do not have one already
- > tftp    (to start the client from the terminal/command prompt)
- > ?   (to list help)
- > connect server.name
- > verbose (to give more detailed output)
- > get fai/syslinux64.efi

this should get the file successfully.  If it does not then you can look 
at the logging on both sides.  Also, if it does not then try "get 
fai/pxelinux.0", which is the BIOS boot file and was working for you.


Not an answer but I hope this helps.

Cheers,
Merlin.

--
Merlin Hansen
Department of Computing Science
Vancouver Island University
900 Fifth Street
Nanaimo BC  V9R 5S5
250-753-3245 x 2321
t...@csci.viu.ca



Re: AW: PXE boot with UEFI

2019-12-03 Diskussionsfäden Sylvain MILOT

On Tue, 3 Dec 2019, Frank Morawietz wrote:


Many thanks Steffen and Merlin for your configuration details!
I learned a lot already and I believe that we are on the right track.

I included your suggestions into my  dhpcd.conf  .
According to the log output below it seems to select the correct file now.

But I still could not yet get it to work correctly.

In order to debug this I increased the tftpd verbosity level. And this is what 
I now get in daemon.log when I try again:

Dec  3 11:31:34 sysadm02 dhcpd[12875]: DHCPDISCOVER from 50:9a:4c:43:c1:b7 via 
ens9
Dec  3 11:31:34 sysadm02 dhcpd[12875]: DHCPOFFER on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 dhcpd[12875]: DHCPREQUEST for 10.250.217.16 
(10.250.217.102) from 50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 dhcpd[12875]: DHCPACK on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 in.tftpd[13050]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  3 11:31:37 sysadm02 in.tftpd[13050]: tftpd: read: Connection refused
Dec  3 11:31:41 sysadm02 in.tftpd[13052]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  3 11:31:41 sysadm02 in.tftpd[13052]: tftp: client does not accept options
Dec  3 11:31:41 sysadm02 in.tftpd[13053]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi

10.250.217.16 is the installation client.

Any idea which read failed for tftpd ?
The syslinux files all are mode 644, so they are readable. Directories are 755.
What may refuse the connection for tftpd?


have you considered tcp wrappers ?

ldd $(which in.tftpd) | grep wrap
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x7f9b39f41000)

perhaps this will solve the issue...

echo in.tftpd: ALL >> /etc/hosts.allow

change ALL for something more restrictive perhaps.

HTH,

---
Sylvain Milot (sylvain.mi...@mcgill.ca)
Sr Research Systems Admin
Brain Imaging Centre
Montreal Neurological Institute
3801 University Street, Webster 2B, Room 206
Montreal, Qc., Canada, H3A 2B4
Phone  : (514) 398-4965, Fax: 398-8948
Mobile : (514) 712-1768
Office : Room NW119 (North Wing)


AW: PXE boot with UEFI

2019-12-03 Diskussionsfäden Frank Morawietz
Many thanks Steffen and Merlin for your configuration details!
I learned a lot already and I believe that we are on the right track.

I included your suggestions into my  dhpcd.conf  .
According to the log output below it seems to select the correct file now.

But I still could not yet get it to work correctly.

In order to debug this I increased the tftpd verbosity level. And this is what 
I now get in daemon.log when I try again:

Dec  3 11:31:34 sysadm02 dhcpd[12875]: DHCPDISCOVER from 50:9a:4c:43:c1:b7 via 
ens9
Dec  3 11:31:34 sysadm02 dhcpd[12875]: DHCPOFFER on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 dhcpd[12875]: DHCPREQUEST for 10.250.217.16 
(10.250.217.102) from 50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 dhcpd[12875]: DHCPACK on 10.250.217.16 to 
50:9a:4c:43:c1:b7 via ens9
Dec  3 11:31:37 sysadm02 in.tftpd[13050]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  3 11:31:37 sysadm02 in.tftpd[13050]: tftpd: read: Connection refused
Dec  3 11:31:41 sysadm02 in.tftpd[13052]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi
Dec  3 11:31:41 sysadm02 in.tftpd[13052]: tftp: client does not accept options
Dec  3 11:31:41 sysadm02 in.tftpd[13053]: RRQ from 10.250.217.16 filename 
fai/syslinux64.efi

10.250.217.16 is the installation client.

Any idea which read failed for tftpd ?
The syslinux files all are mode 644, so they are readable. Directories are 755.
What may refuse the connection for tftpd?

The "client does not accept options" does not express a problem. This message 
also appears when the install boot is successful (in legacy BIOS mode).

Best regards,
Frank
--
Frank Morawietz


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, you 
must not copy this message or attachment or disclose the contents to any other 
person. If you have received this transmission in error, please notify the 
sender immediately and delete the message and any attachment from your system. 
Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept 
liability for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any unauthorized 
changes of the content of this message and any attachment thereto. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not guarantee that this 
message is free of viruses and does not accept liability for any damages caused 
by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.