[Ltsp-discuss] ltsp uefi client ?

[Truth]

Hi,
I have installed a ltsp-pnp server on Debian jessie and was able to
connect from to different clients.
So far everything is great - and many thanks to the ltsp development team.
However, my problem is that I still can not connect from an UEFI client
to the ltsp-server.

In order to solve the problem ...
(compare
https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)

... I downloded ipxe
apt-get install ipxe

... put two additional lines into /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
dhcp-vendorclass=uefi,PXEClient
dhcp-boot=net:uefi,/ltsp/i386/ipxe.0

... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
ipxe.0 -> /boot/ipxe.efi
ipxe.iso -> /usr/lib/ipxe/ipxe.iso
ipxe.lkrn -> /boot/ipxe.lkrn
ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe

Is there something else to do?
The logfile (see below) does not realy tell me what to do ...

Many thanks in advance.
Truth



After restarting dnsmasq and trying to connect from the UEFI client I
get the following messages (dmesg):
Jan 9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von SIGTERM
Jan 9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung OK.
Jan 9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version 2.72, DNS
abgeschaltet
Jan 9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen: IPv6
GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth
DNSSEC loop-detect
Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im Subnetz
192.168.2.0
Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
192.168.67.20 -- 192.168.67.250, Lease Zeit8h
Jan 9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
ist/var/lib/tftpboot/
Jan 9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1): link
connected
Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS multicast
group on interface eth1.IPv6 with address xxyy::xxy:xxyy:xxyy:xxyy.
Jan 9 16:39:17 ltsp-server avahi-daemon[488]: New relevant interface
eth1.IPv6 for mDNS.
Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Registering new address
record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
Jan 9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1): link
disconnected
Jan 9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1): link
connected
Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
xy:yx:yx:yx:yx:yx
Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
192.168.67.64 xy:yx:yx:yx:yx:yx
Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
192.168.67.64 xy:yx:yx:yx:yx:yx
Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
192.168.67.64 xy:yx:yx:yx:yx:yx
Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User aborted
the transfer von 192.168.67.64 empfangen
Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
/var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
Jan 9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
/var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
Jan 9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1): link
disconnected
Jan 9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1): link
connected
Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
xy:yx:yx:yx:yx:yx
Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
192.168.67.64 xy:yx:yx:yx:yx:yx
Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
192.168.67.64 xy:yx:yx:yx:yx:yx
Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
192.168.67.64 xy:yx:yx:yx:yx:yx
...

On the client side I get:

iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot Firmware
-- http://ipxe.org
Features: VLAN HTTP DNS TFTP EFI Menu

net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:0]
Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
Next server: 192.168.67.1
Filename: /ltsp/i386/ipxe.0
Root path: /opt/ltsp/i386
tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
iPXE initialising devices...ok


iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot Firmware
-- http://ipxe.org
Features: VLAN HTTP DNS TFTP EFI Menu

Press Ctrl-B for the iPXE command line...
...


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additi

[Truth]

On 09.01.2016 17:04, Truth wrote:
> Hi,
> I have installed a ltsp-pnp server on Debian jessie and was able to
> connect from to different clients.
> So far everything is great - and many thanks to the ltsp development team.
> However, my problem is that I still can not connect from an UEFI client
> to the ltsp-server.
>
> In order to solve the problem ...
> (compare
> https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)
>
> ... I downloded ipxe
> apt-get install ipxe
>
> ... put two additional lines into /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
> dhcp-vendorclass=uefi,PXEClient
> dhcp-boot=net:uefi,/ltsp/i386/ipxe.0
>
> ... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
> ipxe.0 -> /boot/ipxe.efi
> ipxe.iso -> /usr/lib/ipxe/ipxe.iso
> ipxe.lkrn -> /boot/ipxe.lkrn
> ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
> undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
> undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe
>
> Is there something else to do?
> The logfile (see below) does not realy tell me what to do ...
>
> Many thanks in advance.
> Truth
>
>
>
> After restarting dnsmasq and trying to connect from the UEFI client I
> get the following messages (dmesg):
> Jan 9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von SIGTERM
> Jan 9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung OK.
> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version 2.72, DNS
> abgeschaltet
> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen: IPv6
> GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth
> DNSSEC loop-detect
> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im Subnetz
> 192.168.2.0
> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
> 192.168.67.20 -- 192.168.67.250, Lease Zeit8h
> Jan 9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
> ist/var/lib/tftpboot/
> Jan 9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1): link
> connected
> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS multicast
> group on interface eth1.IPv6 with address xxyy::xxy:xxyy:xxyy:xxyy.
> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: New relevant interface
> eth1.IPv6 for mDNS.
> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Registering new address
> record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
> Jan 9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1): link
> disconnected
> Jan 9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1): link
> connected
> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
> xy:yx:yx:yx:yx:yx
> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
> 192.168.67.64 xy:yx:yx:yx:yx:yx
> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
> 192.168.67.64 xy:yx:yx:yx:yx:yx
> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
> 192.168.67.64 xy:yx:yx:yx:yx:yx
> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User aborted
> the transfer von 192.168.67.64 empfangen
> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
> /var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
> Jan 9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
> /var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
> Jan 9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1): link
> disconnected
> Jan 9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1): link
> connected
> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
> xy:yx:yx:yx:yx:yx
> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
> 192.168.67.64 xy:yx:yx:yx:yx:yx
> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
> 192.168.67.64 xy:yx:yx:yx:yx:yx
> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
> 192.168.67.64 xy:yx:yx:yx:yx:yx
> ...
>
> On the client side I get:
>
> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot Firmware
> -- http://ipxe.org
> Features: VLAN HTTP DNS TFTP EFI Menu
>
> net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
> [Link:up, TX:0 TXE:0 RX:0 RXE:0]
> Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
> net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
> Next server: 192.168.67.1
> Filename: /ltsp/i386/ipxe.0
> Root path: /opt/ltsp/i386
> tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
> iPXE initialising devices...ok
>
>
> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot Firmware
> -- http://ipxe.org
> Features: VLAN HTTP DNS TFTP EFI Menu
>
> Press Ctrl-B for the iPXE command line...
> ...

The above mentioned link claims "that most dnsmasq is not able to boot
most UEFI devices as it uses DHCP option 43 which they don’t like ..."

For that reason I'vd tried a configuration with isc-dhcp-server instead.
Again, I'm able to connect to several clients but - unfortuantely, I'm
not able to connect to the UEFI-client.

It seems that the problem is related to some tftp-communication problem ...
(compare
https://ask.wireshark.org/questions/22519/tftp-transfer-option-negotiation-failed-error-8-packet-trace).

... but I could not find a solution (link) for this problem.

If someone has been able to connect to an UEFI client, please let me know.










------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additio

[richard kweskin]

On 2016-01-10 21:22, Truth wrote:
> On 09.01.2016 17:04, Truth wrote:
>> Hi,
>> I have installed a ltsp-pnp server on Debian jessie and was able to
>> connect from to different clients.
>> So far everything is great - and many thanks to the ltsp development
>> team.
>> However, my problem is that I still can not connect from an UEFI
>> client
>> to the ltsp-server.
>>
>> In order to solve the problem ...
>> (compare
>>
>> https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)
>>
>> ... I downloded ipxe
>> apt-get install ipxe
>>
>> ... put two additional lines into
>> /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
>> dhcp-vendorclass=uefi,PXEClient
>> dhcp-boot=net:uefi,/ltsp/i386/ipxe.0
>>
>> ... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
>> ipxe.0 -> /boot/ipxe.efi
>> ipxe.iso -> /usr/lib/ipxe/ipxe.iso
>> ipxe.lkrn -> /boot/ipxe.lkrn
>> ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
>> undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
>> undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe
>>
>> Is there something else to do?
>> The logfile (see below) does not realy tell me what to do ...
>>
>> Many thanks in advance.
>> Truth
>>
>>
>>
>> After restarting dnsmasq and trying to connect from the UEFI client
>> I
>> get the following messages (dmesg):
>> Jan 9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von
>> SIGTERM
>> Jan 9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung
>> OK.
>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version 2.72,
>> DNS
>> abgeschaltet
>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen:
>> IPv6
>> GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset
>> auth
>> DNSSEC loop-detect
>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im
>> Subnetz
>> 192.168.2.0
>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
>> 192.168.67.20 -- 192.168.67.250, Lease Zeit8h
>> Jan 9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
>> ist/var/lib/tftpboot/
>> Jan 9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1): link
>> connected
>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS
>> multicast
>> group on interface eth1.IPv6 with address xxyy::xxy:xxyy:xxyy:xxyy.
>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: New relevant
>> interface
>> eth1.IPv6 for mDNS.
>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Registering new
>> address
>> record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
>> Jan 9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1): link
>> disconnected
>> Jan 9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1): link
>> connected
>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>> xy:yx:yx:yx:yx:yx
>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User
>> aborted
>> the transfer von 192.168.67.64 empfangen
>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
>> /var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
>> Jan 9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
>> /var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
>> Jan 9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1): link
>> disconnected
>> Jan 9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1): link
>> connected
>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>> xy:yx:yx:yx:yx:yx
>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>> ...
>>
>> On the client side I get:
>>
>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>> Firmware
>> -- http://ipxe.org
>> Features: VLAN HTTP DNS TFTP EFI Menu
>>
>> net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
>> [Link:up, TX:0 TXE:0 RX:0 RXE:0]
>> Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
>> net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
>> Next server: 192.168.67.1
>> Filename: /ltsp/i386/ipxe.0
>> Root path: /opt/ltsp/i386
>> tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
>> iPXE initialising devices...ok
>>
>>
>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>> Firmware
>> -- http://ipxe.org
>> Features: VLAN HTTP DNS TFTP EFI Menu
>>
>> Press Ctrl-B for the iPXE command line...
>> ...
>
> The above mentioned link claims "that most dnsmasq is not able to
> boot
> most UEFI devices as it uses DHCP option 43 which they don’t like
> ..."
>
> For that reason I'vd tried a configuration with isc-dhcp-server
> instead.
> Again, I'm able to connect to several clients but - unfortuantely,
> I'm
> not able to connect to the UEFI-client.
>
> It seems that the problem is related to some tftp-communication
> problem ...
> (compare
>
> https://ask.wireshark.org/questions/22519/tftp-transfer-option-negotiation-failed-error-8-packet-trace).
>
> ... but I could not find a solution (link) for this problem.
>
> If someone has been able to connect to an UEFI client, please let me
> know.

This was a one off since we were invited once to a pc lab where most
pc's were older but 4 were uefi pc's.

We brought a laptop ltsp server with
http://ts.sch.gr/repo/livecd/12.04/ubuntu-12.04.5-desktop-i386-sch.iso

which is a remastered Ubuntu 12.04 32bit iso. It uses dnsmasq and it
just worked with all the clients once we could get the uefi to boot with
no secure ipxe.

Richard

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.f

[Truth]

On 11.01.2016 21:10, richard kweskin wrote:
> On 2016-01-10 21:22, Truth wrote:
>> On 09.01.2016 17:04, Truth wrote:
>>> Hi,
>>> I have installed a ltsp-pnp server on Debian jessie and was able to
>>> connect from to different clients.
>>> So far everything is great - and many thanks to the ltsp development
>>> team.
>>> However, my problem is that I still can not connect from an UEFI
>>> client
>>> to the ltsp-server.
>>>
>>> In order to solve the problem ...
>>> (compare
>>>
>>> https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)
>>>
>>> ... I downloded ipxe
>>> apt-get install ipxe
>>>
>>> ... put two additional lines into
>>> /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
>>> dhcp-vendorclass=uefi,PXEClient
>>> dhcp-boot=net:uefi,/ltsp/i386/ipxe.0
>>>
>>> ... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
>>> ipxe.0 -> /boot/ipxe.efi
>>> ipxe.iso -> /usr/lib/ipxe/ipxe.iso
>>> ipxe.lkrn -> /boot/ipxe.lkrn
>>> ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
>>> undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
>>> undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe
>>>
>>> Is there something else to do?
>>> The logfile (see below) does not realy tell me what to do ...
>>>
>>> Many thanks in advance.
>>> Truth
>>>
>>>
>>>
>>> After restarting dnsmasq and trying to connect from the UEFI client
>>> I
>>> get the following messages (dmesg):
>>> Jan 9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von
>>> SIGTERM
>>> Jan 9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung
>>> OK.
>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version 2.72,
>>> DNS
>>> abgeschaltet
>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen:
>>> IPv6
>>> GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset
>>> auth
>>> DNSSEC loop-detect
>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im
>>> Subnetz
>>> 192.168.2.0
>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
>>> 192.168.67.20 -- 192.168.67.250, Lease Zeit8h
>>> Jan 9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
>>> ist/var/lib/tftpboot/
>>> Jan 9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> connected
>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS
>>> multicast
>>> group on interface eth1.IPv6 with address xxyy::xxy:xxyy:xxyy:xxyy.
>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: New relevant
>>> interface
>>> eth1.IPv6 for mDNS.
>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Registering new
>>> address
>>> record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
>>> Jan 9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> disconnected
>>> Jan 9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> connected
>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>> xy:yx:yx:yx:yx:yx
>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User
>>> aborted
>>> the transfer von 192.168.67.64 empfangen
>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
>>> Jan 9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
>>> Jan 9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> disconnected
>>> Jan 9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> connected
>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>> xy:yx:yx:yx:yx:yx
>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> ...
>>>
>>> On the client side I get:
>>>
>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>> Firmware
>>> -- http://ipxe.org
>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>
>>> net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
>>> [Link:up, TX:0 TXE:0 RX:0 RXE:0]
>>> Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
>>> net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
>>> Next server: 192.168.67.1
>>> Filename: /ltsp/i386/ipxe.0
>>> Root path: /opt/ltsp/i386
>>> tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
>>> iPXE initialising devices...ok
>>>
>>>
>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>> Firmware
>>> -- http://ipxe.org
>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>
>>> Press Ctrl-B for the iPXE command line...
>>> ...
>> The above mentioned link claims "that most dnsmasq is not able to
>> boot
>> most UEFI devices as it uses DHCP option 43 which they don’t like
>> ..."
>>
>> For that reason I'vd tried a configuration with isc-dhcp-server
>> instead.
>> Again, I'm able to connect to several clients but - unfortuantely,
>> I'm
>> not able to connect to the UEFI-client.
>>
>> It seems that the problem is related to some tftp-communication
>> problem ...
>> (compare
>>
>> https://ask.wireshark.org/questions/22519/tftp-transfer-option-negotiation-failed-error-8-packet-trace).
>>
>> ... but I could not find a solution (link) for this problem.
>>
>> If someone has been able to connect to an UEFI client, please let me
>> know.
> This was a one off since we were invited once to a pc lab where most
> pc's were older but 4 were uefi pc's.
>
> We brought a laptop ltsp server with
> http://ts.sch.gr/repo/livecd/12.04/ubuntu-12.04.5-desktop-i386-sch.iso
>
> which is a remastered Ubuntu 12.04 32bit iso. It uses dnsmasq and it
> just worked with all the clients once we could get the uefi to boot with
> no secure ipxe.
>
> Richard

Thanks for the link.
However, I would like to use my already existing debian server as a ltsp
server.
I do not quite understand what you mean with non secure ipxe.
Does it mean the bios option for secure boot ...or something else?

The reason I would like to get UEFI running is that there are quite nice
low power and low price shuttles with e.g. Pentium J2900 or Celeron
J1900 (22nm, 2,4GHz, 4 Core, 10Watt) available which unfortunately only
available for uefi boot.

Truth







------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp chan

[richard kweskin]

On 2016-01-12 10:53, Truth wrote:
> On 11.01.2016 21:10, richard kweskin wrote:
>> On 2016-01-10 21:22, Truth wrote:
>>> On 09.01.2016 17:04, Truth wrote:
>>>> Hi,
>>>> I have installed a ltsp-pnp server on Debian jessie and was able
>>>> to
>>>> connect from to different clients.
>>>> So far everything is great - and many thanks to the ltsp
>>>> development
>>>> team.
>>>> However, my problem is that I still can not connect from an UEFI
>>>> client
>>>> to the ltsp-server.
>>>>
>>>> In order to solve the problem ...
>>>> (compare
>>>>
>>>>
>>>> https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)
>>>>
>>>> ... I downloded ipxe
>>>> apt-get install ipxe
>>>>
>>>> ... put two additional lines into
>>>> /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
>>>> dhcp-vendorclass=uefi,PXEClient
>>>> dhcp-boot=net:uefi,/ltsp/i386/ipxe.0
>>>>
>>>> ... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
>>>> ipxe.0 -> /boot/ipxe.efi
>>>> ipxe.iso -> /usr/lib/ipxe/ipxe.iso
>>>> ipxe.lkrn -> /boot/ipxe.lkrn
>>>> ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
>>>> undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
>>>> undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe
>>>>
>>>> Is there something else to do?
>>>> The logfile (see below) does not realy tell me what to do ...
>>>>
>>>> Many thanks in advance.
>>>> Truth
>>>>
>>>>
>>>>
>>>> After restarting dnsmasq and trying to connect from the UEFI
>>>> client
>>>> I
>>>> get the following messages (dmesg):
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von
>>>> SIGTERM
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung
>>>> OK.
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version
>>>> 2.72,
>>>> DNS
>>>> abgeschaltet
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen:
>>>> IPv6
>>>> GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset
>>>> auth
>>>> DNSSEC loop-detect
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im
>>>> Subnetz
>>>> 192.168.2.0
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
>>>> 192.168.67.20 -- 192.168.67.250, Lease Zeit8h
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
>>>> ist/var/lib/tftpboot/
>>>> Jan 9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> connected
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS
>>>> multicast
>>>> group on interface eth1.IPv6 with address
>>>> xxyy::xxy:xxyy:xxyy:xxyy.
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: New relevant
>>>> interface
>>>> eth1.IPv6 for mDNS.
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Registering new
>>>> address
>>>> record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
>>>> Jan 9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> disconnected
>>>> Jan 9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> connected
>>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>>> xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User
>>>> aborted
>>>> the transfer von 192.168.67.64 empfangen
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
>>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
>>>> Jan 9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
>>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
>>>> Jan 9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> disconnected
>>>> Jan 9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> connected
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>>> xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> ...
>>>>
>>>> On the client side I get:
>>>>
>>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>>> Firmware
>>>> -- http://ipxe.org
>>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>>
>>>> net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
>>>> [Link:up, TX:0 TXE:0 RX:0 RXE:0]
>>>> Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
>>>> net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
>>>> Next server: 192.168.67.1
>>>> Filename: /ltsp/i386/ipxe.0
>>>> Root path: /opt/ltsp/i386
>>>> tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
>>>> iPXE initialising devices...ok
>>>>
>>>>
>>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>>> Firmware
>>>> -- http://ipxe.org
>>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>>
>>>> Press Ctrl-B for the iPXE command line...
>>>> ...
>>> The above mentioned link claims "that most dnsmasq is not able to
>>> boot
>>> most UEFI devices as it uses DHCP option 43 which they don’t like
>>> ..."
>>>
>>> For that reason I'vd tried a configuration with isc-dhcp-server
>>> instead.
>>> Again, I'm able to connect to several clients but - unfortuantely,
>>> I'm
>>> not able to connect to the UEFI-client.
>>>
>>> It seems that the problem is related to some tftp-communication
>>> problem ...
>>> (compare
>>>
>>>
>>> https://ask.wireshark.org/questions/22519/tftp-transfer-option-negotiation-failed-error-8-packet-trace).
>>>
>>> ... but I could not find a solution (link) for this problem.
>>>
>>> If someone has been able to connect to an UEFI client, please let
>>> me
>>> know.
>> This was a one off since we were invited once to a pc lab where most
>> pc's were older but 4 were uefi pc's.
>>
>> We brought a laptop ltsp server with
>>
>> http://ts.sch.gr/repo/livecd/12.04/ubuntu-12.04.5-desktop-i386-sch.iso
>>
>> which is a remastered Ubuntu 12.04 32bit iso. It uses dnsmasq and it
>> just worked with all the clients once we could get the uefi to boot
>> with
>> no secure ipxe.
>>
>> Richard
>
> Thanks for the link.
> However, I would like to use my already existing debian server as a
> ltsp
> server.
> I do not quite understand what you mean with non secure ipxe.

> Does it mean the bios option for secure boot ...or something else?

Yes, I meant you must disable secure boot and you may need to comb
carefully through the many options in order to enable both the onboard
nic to operate with ipxe and to enable ipxe booting. Unfortunately there
are so many variations of uefi, each manufacturer coming up with its own
version, since there has not yet been an accepted standard to which all
will agree, that makes it difficult to be more specific.

> The reason I would like to get UEFI running is that there are quite
> nice
> low power and low price shuttles with e.g. Pentium J2900 or Celeron
> J1900 (22nm, 2,4GHz, 4 Core, 10Watt) available which unfortunately
> only
> available for uefi boot.
>
> Truth

Essentially, choosing to boot from the lan through ipxe means the unit
will not be in uefi mode but that does not preclude your using the
hardware you describe.

Richard

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP hel

[Truth]

On 13.01.2016 23:52, richard kweskin wrote:
> On 2016-01-12 10:53, Truth wrote:
>> On 11.01.2016 21:10, richard kweskin wrote:
>>> On 2016-01-10 21:22, Truth wrote:
>>>> On 09.01.2016 17:04, Truth wrote:
>>>>> Hi,
>>>>> I have installed a ltsp-pnp server on Debian jessie and was able
>>>>> to
>>>>> connect from to different clients.
>>>>> So far everything is great - and many thanks to the ltsp
>>>>> development
>>>>> team.
>>>>> However, my problem is that I still can not connect from an UEFI
>>>>> client
>>>>> to the ltsp-server.
>>>>>
>>>>> In order to solve the problem ...
>>>>> (compare
>>>>>
>>>>>
>>>>> https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)
>>>>>
>>>>> ... I downloded ipxe
>>>>> apt-get install ipxe
>>>>>
>>>>> ... put two additional lines into
>>>>> /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
>>>>> dhcp-vendorclass=uefi,PXEClient
>>>>> dhcp-boot=net:uefi,/ltsp/i386/ipxe.0
>>>>>
>>>>> ... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
>>>>> ipxe.0 -> /boot/ipxe.efi
>>>>> ipxe.iso -> /usr/lib/ipxe/ipxe.iso
>>>>> ipxe.lkrn -> /boot/ipxe.lkrn
>>>>> ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
>>>>> undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
>>>>> undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe
>>>>>
>>>>> Is there something else to do?
>>>>> The logfile (see below) does not realy tell me what to do ...
>>>>>
>>>>> Many thanks in advance.
>>>>> Truth
>>>>>
>>>>>
>>>>>
>>>>> After restarting dnsmasq and trying to connect from the UEFI
>>>>> client
>>>>> I
>>>>> get the following messages (dmesg):
>>>>> Jan 9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von
>>>>> SIGTERM
>>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung
>>>>> OK.
>>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version
>>>>> 2.72,
>>>>> DNS
>>>>> abgeschaltet
>>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen:
>>>>> IPv6
>>>>> GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset
>>>>> auth
>>>>> DNSSEC loop-detect
>>>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im
>>>>> Subnetz
>>>>> 192.168.2.0
>>>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
>>>>> 192.168.67.20 -- 192.168.67.250, Lease Zeit8h
>>>>> Jan 9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
>>>>> ist/var/lib/tftpboot/
>>>>> Jan 9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1):
>>>>> link
>>>>> connected
>>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS
>>>>> multicast
>>>>> group on interface eth1.IPv6 with address
>>>>> xxyy::xxy:xxyy:xxyy:xxyy.
>>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: New relevant
>>>>> interface
>>>>> eth1.IPv6 for mDNS.
>>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Registering new
>>>>> address
>>>>> record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
>>>>> Jan 9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1):
>>>>> link
>>>>> disconnected
>>>>> Jan 9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1):
>>>>> link
>>>>> connected
>>>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>>>> xy:yx:yx:yx:yx:yx
>>>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User
>>>>> aborted
>>>>> the transfer von 192.168.67.64 empfangen
>>>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
>>>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
>>>>> Jan 9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
>>>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
>>>>> Jan 9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1):
>>>>> link
>>>>> disconnected
>>>>> Jan 9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1):
>>>>> link
>>>>> connected
>>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>>>> xy:yx:yx:yx:yx:yx
>>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>>> ...
>>>>>
>>>>> On the client side I get:
>>>>>
>>>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>>>> Firmware
>>>>> -- http://ipxe.org
>>>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>>>
>>>>> net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
>>>>> [Link:up, TX:0 TXE:0 RX:0 RXE:0]
>>>>> Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
>>>>> net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
>>>>> Next server: 192.168.67.1
>>>>> Filename: /ltsp/i386/ipxe.0
>>>>> Root path: /opt/ltsp/i386
>>>>> tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
>>>>> iPXE initialising devices...ok
>>>>>
>>>>>
>>>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>>>> Firmware
>>>>> -- http://ipxe.org
>>>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>>>
>>>>> Press Ctrl-B for the iPXE command line...
>>>>> ...
>>>> The above mentioned link claims "that most dnsmasq is not able to
>>>> boot
>>>> most UEFI devices as it uses DHCP option 43 which they don’t like
>>>> ..."
>>>>
>>>> For that reason I'vd tried a configuration with isc-dhcp-server
>>>> instead.
>>>> Again, I'm able to connect to several clients but - unfortuantely,
>>>> I'm
>>>> not able to connect to the UEFI-client.
>>>>
>>>> It seems that the problem is related to some tftp-communication
>>>> problem ...
>>>> (compare
>>>>
>>>>
>>>> https://ask.wireshark.org/questions/22519/tftp-transfer-option-negotiation-failed-error-8-packet-trace).
>>>>
>>>> ... but I could not find a solution (link) for this problem.
>>>>
>>>> If someone has been able to connect to an UEFI client, please let
>>>> me
>>>> know.
>>> This was a one off since we were invited once to a pc lab where most
>>> pc's were older but 4 were uefi pc's.
>>>
>>> We brought a laptop ltsp server with
>>>
>>> http://ts.sch.gr/repo/livecd/12.04/ubuntu-12.04.5-desktop-i386-sch.iso
>>>
>>> which is a remastered Ubuntu 12.04 32bit iso. It uses dnsmasq and it
>>> just worked with all the clients once we could get the uefi to boot
>>> with
>>> no secure ipxe.
>>>
>>> Richard
>> Thanks for the link.
>> However, I would like to use my already existing debian server as a
>> ltsp
>> server.
>> I do not quite understand what you mean with non secure ipxe.
>> Does it mean the bios option for secure boot ...or something else?
> Yes, I meant you must disable secure boot and you may need to comb
> carefully through the many options in order to enable both the onboard
> nic to operate with ipxe and to enable ipxe booting. Unfortunately there
> are so many variations of uefi, each manufacturer coming up with its own
> version, since there has not yet been an accepted standard to which all
> will agree, that makes it difficult to be more specific.
>
>> The reason I would like to get UEFI running is that there are quite
>> nice
>> low power and low price shuttles with e.g. Pentium J2900 or Celeron
>> J1900 (22nm, 2,4GHz, 4 Core, 10Watt) available which unfortunately
>> only
>> available for uefi boot.
>>
>> Truth
> Essentially, choosing to boot from the lan through ipxe means the unit
> will not be in uefi mode but that does not preclude your using the
> hardware you describe.
>
> Richard
Ok, secure boot was off.
Nevertheless, I tried several other bios settings ... unfortunately
without success.
I also tried some more things on the server side: e.g. I used tftpd-hpa
and/or isc-dhcp-server together with dnsmasq (of course I first had to
disable tftp and/or dhcp within dnsmasq) ... again, no success :-|

I have to mention that the Error message "Error 8 User aborted the
transfer ..." comes only in the beginning.
After this the client automatically tries again to connect to the server
and it looks like that the ipxe.0 file is sent to the client without
problems.
However, the client refuses to boot and tries to connect again and again.

By the way, if pxe-boot is not depending on uefi or legacy bios ... why
does the uefi client need the ipxe.0 file instead of pxelinux.0?

Truth



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel

[richard kweskin]

On 2016-01-15 00:39, Truth wrote:

snip

> Ok, secure boot was off.
> Nevertheless, I tried several other bios settings ... unfortunately
> without success.

This is tricky because not all options are displayed. Any option that
is a dependency must first be enabled in order for the previously
undisplayed option to appear!!

If you ever tangled with compiling your own custom kernel you will have
come across this phenomenon.

> I also tried some more things on the server side: e.g. I used
> tftpd-hpa
> and/or isc-dhcp-server together with dnsmasq (of course I first had
> to
> disable tftp and/or dhcp within dnsmasq) ... again, no success :-|

Another reason why I first mentioned our success with the other iso is
to say we did not need to alter any of this.

> I have to mention that the Error message "Error 8 User aborted the
> transfer ..." comes only in the beginning.
> After this the client automatically tries again to connect to the
> server
> and it looks like that the ipxe.0 file is sent to the client without
> problems.
> However, the client refuses to boot and tries to connect again and
> again.

Also here, we did not have any ipxe.0 file. It just worked as any other
client. The tricky part was reconfiguring the uefi bios to boot from the
lan using pxe. Once we found how it was needed by those particular
clients they just worked!!

> By the way, if pxe-boot is not depending on uefi or legacy bios ...
> why
> does the uefi client need the ipxe.0 file instead of pxelinux.0?

Careful. I said that booting from the lan using pxe resulted in a
client running in legacy mode, not uefi mode. To explain what I mean
let's take a straight forward case of installing a 64 bit Debian Jessie
or Stretch to an empty hard drive.

If the installer is started from a medium that the uefi bios regards as
non-uefi it will go ahead and install the system which will not run in
uefi mode.

See http://www.rodsbooks.com/linux-uefi/ where he says,

"You should verify an EFI-mode boot by dropping to a Linux shell and
typing ls /sys/firmware/efi. If you see a list of files and directories,
you've booted in EFI mode..."

For us this was a non-issue since we were only interested in getting
these clients to boot with pxe, not to run in uefi mode particularly.

Richard

> Truth


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net

[Truth]

On 15.01.2016 08:08, richard kweskin wrote:
> On 2016-01-15 00:39, Truth wrote:
>
> snip
>
>> Ok, secure boot was off.
>> Nevertheless, I tried several other bios settings ... unfortunately
>> without success.
> This is tricky because not all options are displayed. Any option that
> is a dependency must first be enabled in order for the previously
> undisplayed option to appear!!
>
> If you ever tangled with compiling your own custom kernel you will have
> come across this phenomenon.
>
>> I also tried some more things on the server side: e.g. I used
>> tftpd-hpa
>> and/or isc-dhcp-server together with dnsmasq (of course I first had
>> to
>> disable tftp and/or dhcp within dnsmasq) ... again, no success :-|
> Another reason why I first mentioned our success with the other iso is
> to say we did not need to alter any of this.
>
>> I have to mention that the Error message "Error 8 User aborted the
>> transfer ..." comes only in the beginning.
>> After this the client automatically tries again to connect to the
>> server
>> and it looks like that the ipxe.0 file is sent to the client without
>> problems.
>> However, the client refuses to boot and tries to connect again and
>> again.
> Also here, we did not have any ipxe.0 file. It just worked as any other
> client. The tricky part was reconfiguring the uefi bios to boot from the
> lan using pxe. Once we found how it was needed by those particular
> clients they just worked!!
>
>> By the way, if pxe-boot is not depending on uefi or legacy bios ...
>> why
>> does the uefi client need the ipxe.0 file instead of pxelinux.0?
> Careful. I said that booting from the lan using pxe resulted in a
> client running in legacy mode, not uefi mode. To explain what I mean
> let's take a straight forward case of installing a 64 bit Debian Jessie
> or Stretch to an empty hard drive.
>
> If the installer is started from a medium that the uefi bios regards as
> non-uefi it will go ahead and install the system which will not run in
> uefi mode.
>
> See http://www.rodsbooks.com/linux-uefi/ where he says,
>
> "You should verify an EFI-mode boot by dropping to a Linux shell and
> typing ls /sys/firmware/efi. If you see a list of files and directories,
> you've booted in EFI mode..."
>
> For us this was a non-issue since we were only interested in getting
> these clients to boot with pxe, not to run in uefi mode particularly.
>
> Richard
>
>> Truth
As you can see from the manual
(see http://download.shuttle.eu/Mirror/Slim/XS36V4/Manual/MANUAL.ZIP)
there are not so many possibilities to change the BIOS ...
... and I am quite sure that I tried all of them (in many different
combinations).

The status is that the uefi-client boots, takes an IP-address from the
DHCP-server and receives the ipxe.0 file.
For unknown reason the client does not want go further but restarts and
gets the IP-address again.

A have no idea what else I could do to get more information what's wrong?

Truth



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net

[richard kweskin]

On 2016-01-15 09:46, Truth wrote:
> On 15.01.2016 08:08, richard kweskin wrote:
>> On 2016-01-15 00:39, Truth wrote:
>>
>> snip
>>
>>> Ok, secure boot was off.
>>> Nevertheless, I tried several other bios settings ... unfortunately
>>> without success.
>> This is tricky because not all options are displayed. Any option
>> that
>> is a dependency must first be enabled in order for the previously
>> undisplayed option to appear!!
>>
>> If you ever tangled with compiling your own custom kernel you will
>> have
>> come across this phenomenon.
>>
>>> I also tried some more things on the server side: e.g. I used
>>> tftpd-hpa
>>> and/or isc-dhcp-server together with dnsmasq (of course I first had
>>> to
>>> disable tftp and/or dhcp within dnsmasq) ... again, no success
>>> :-|
>> Another reason why I first mentioned our success with the other iso
>> is
>> to say we did not need to alter any of this.
>>
>>> I have to mention that the Error message "Error 8 User aborted the
>>> transfer ..." comes only in the beginning.
>>> After this the client automatically tries again to connect to the
>>> server
>>> and it looks like that the ipxe.0 file is sent to the client
>>> without
>>> problems.
>>> However, the client refuses to boot and tries to connect again and
>>> again.
>> Also here, we did not have any ipxe.0 file. It just worked as any
>> other
>> client. The tricky part was reconfiguring the uefi bios to boot from
>> the
>> lan using pxe. Once we found how it was needed by those particular
>> clients they just worked!!
>>
>>> By the way, if pxe-boot is not depending on uefi or legacy bios ...
>>> why
>>> does the uefi client need the ipxe.0 file instead of pxelinux.0?
>> Careful. I said that booting from the lan using pxe resulted in a
>> client running in legacy mode, not uefi mode. To explain what I mean
>> let's take a straight forward case of installing a 64 bit Debian
>> Jessie
>> or Stretch to an empty hard drive.
>>
>> If the installer is started from a medium that the uefi bios regards
>> as
>> non-uefi it will go ahead and install the system which will not run
>> in
>> uefi mode.
>>
>> See http://www.rodsbooks.com/linux-uefi/ where he says,
>>
>> "You should verify an EFI-mode boot by dropping to a Linux shell and
>> typing ls /sys/firmware/efi. If you see a list of files and
>> directories,
>> you've booted in EFI mode..."
>>
>> For us this was a non-issue since we were only interested in getting
>> these clients to boot with pxe, not to run in uefi mode
>> particularly.
>>
>> Richard
>>
>>> Truth
> As you can see from the manual
> (see http://download.shuttle.eu/Mirror/Slim/XS36V4/Manual/MANUAL.ZIP)
> there are not so many possibilities to change the BIOS ...
> ... and I am quite sure that I tried all of them (in many different
> combinations).

Ok. Let's work on the assumption that your configuration is correct.

> The status is that the uefi-client boots, takes an IP-address from
> the
> DHCP-server and receives the ipxe.0 file.
> For unknown reason the client does not want go further but restarts
> and
> gets the IP-address again.
>
> A have no idea what else I could do to get more information what's
> wrong?

Well, a quick glance at

http://ipxe.org/howto/chainloading

"Breaking the infinite loop

When the chainloaded iPXE starts up, it will issue a fresh DHCP request
and boot whatever the DHCP server hands out. The DHCP server is
currently set up to hand out the iPXE image, which means that you will
be stuck in an infinite loop: PXE will load iPXE which will load iPXE
which will load iPXE which will load iPXE…
Breaking the loop with the DHCP server

One way that you can break this infinite loop is to configure the DHCP
server to hand out iPXE only for the first DHCP request; the second DHCP
request will return the “real” boot filename."

does seem to describe what you are experiencing. In my opinion using
ipxe.0 is a waste of time as your uefi bios already has booting with pxe
as an option and that you should be loading pxelinux.0 or whatever your
other clients are loading.

Richard

> Truth


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freen

[Truth]

On 16.01.2016 11:36, richard kweskin wrote:
> On 2016-01-15 09:46, Truth wrote:
>> On 15.01.2016 08:08, richard kweskin wrote:
>>> On 2016-01-15 00:39, Truth wrote:
>>>
>>> snip
>>>
>>>> Ok, secure boot was off.
>>>> Nevertheless, I tried several other bios settings ... unfortunately
>>>> without success.
>>> This is tricky because not all options are displayed. Any option
>>> that
>>> is a dependency must first be enabled in order for the previously
>>> undisplayed option to appear!!
>>>
>>> If you ever tangled with compiling your own custom kernel you will
>>> have
>>> come across this phenomenon.
>>>
>>>> I also tried some more things on the server side: e.g. I used
>>>> tftpd-hpa
>>>> and/or isc-dhcp-server together with dnsmasq (of course I first had
>>>> to
>>>> disable tftp and/or dhcp within dnsmasq) ... again, no success
>>>> :-|
>>> Another reason why I first mentioned our success with the other iso
>>> is
>>> to say we did not need to alter any of this.
>>>
>>>> I have to mention that the Error message "Error 8 User aborted the
>>>> transfer ..." comes only in the beginning.
>>>> After this the client automatically tries again to connect to the
>>>> server
>>>> and it looks like that the ipxe.0 file is sent to the client
>>>> without
>>>> problems.
>>>> However, the client refuses to boot and tries to connect again and
>>>> again.
>>> Also here, we did not have any ipxe.0 file. It just worked as any
>>> other
>>> client. The tricky part was reconfiguring the uefi bios to boot from
>>> the
>>> lan using pxe. Once we found how it was needed by those particular
>>> clients they just worked!!
>>>
>>>> By the way, if pxe-boot is not depending on uefi or legacy bios ...
>>>> why
>>>> does the uefi client need the ipxe.0 file instead of pxelinux.0?
>>> Careful. I said that booting from the lan using pxe resulted in a
>>> client running in legacy mode, not uefi mode. To explain what I mean
>>> let's take a straight forward case of installing a 64 bit Debian
>>> Jessie
>>> or Stretch to an empty hard drive.
>>>
>>> If the installer is started from a medium that the uefi bios regards
>>> as
>>> non-uefi it will go ahead and install the system which will not run
>>> in
>>> uefi mode.
>>>
>>> See http://www.rodsbooks.com/linux-uefi/ where he says,
>>>
>>> "You should verify an EFI-mode boot by dropping to a Linux shell and
>>> typing ls /sys/firmware/efi. If you see a list of files and
>>> directories,
>>> you've booted in EFI mode..."
>>>
>>> For us this was a non-issue since we were only interested in getting
>>> these clients to boot with pxe, not to run in uefi mode
>>> particularly.
>>>
>>> Richard
>>>
>>>> Truth
>> As you can see from the manual
>> (see http://download.shuttle.eu/Mirror/Slim/XS36V4/Manual/MANUAL.ZIP)
>> there are not so many possibilities to change the BIOS ...
>> ... and I am quite sure that I tried all of them (in many different
>> combinations).
> Ok. Let's work on the assumption that your configuration is correct.
>
>> The status is that the uefi-client boots, takes an IP-address from
>> the
>> DHCP-server and receives the ipxe.0 file.
>> For unknown reason the client does not want go further but restarts
>> and
>> gets the IP-address again.
>>
>> A have no idea what else I could do to get more information what's
>> wrong?
> Well, a quick glance at
>
> http://ipxe.org/howto/chainloading
>
> "Breaking the infinite loop
>
> When the chainloaded iPXE starts up, it will issue a fresh DHCP request
> and boot whatever the DHCP server hands out. The DHCP server is
> currently set up to hand out the iPXE image, which means that you will
> be stuck in an infinite loop: PXE will load iPXE which will load iPXE
> which will load iPXE which will load iPXE…
> Breaking the loop with the DHCP server
>
> One way that you can break this infinite loop is to configure the DHCP
> server to hand out iPXE only for the first DHCP request; the second DHCP
> request will return the “real” boot filename."
>
> does seem to describe what you are experiencing. In my opinion using
> ipxe.0 is a waste of time as your uefi bios already has booting with pxe
> as an option and that you should be loading pxelinux.0 or whatever your
> other clients are loading.
>
> Richard
>> Truth
Many thanks for all your input.

I've tried to escape from the loop using the 'option client-arch code
93' within isc-dhcp.
Unfortunately, the client still remains within the loop.
I've tried to debug the problem and it turns out that

option client-arch != 0

is always true (the else condition is never reached), which is probably
a bug within the uefi-bios of the client.
This means that I have to find a different way to break the loop.

Is there a way to define user-variables within the isc-dhcp?
I found a lot of parameters and declarations within man dhcpd.conf(5)
but unfortunately it looks like that it is not possible to just define
an integer variable ... however, I failed to do so ...


In addition, I found out that my uefi bios is a little outdated.
Nevertheless, the good news is that after downloading the new bios and
writing it to the client ...
... I am _now_ able to boot via legacy bios (instead of uefi bios) which
solved my initial problem :-)






------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channe

[richard kweskin]

On 2016-01-18 21:09, Truth wrote:
> On 16.01.2016 11:36, richard kweskin wrote:
>> On 2016-01-15 09:46, Truth wrote:
>>> On 15.01.2016 08:08, richard kweskin wrote:
>>>> On 2016-01-15 00:39, Truth wrote:
>>>>
>>>> snip
>>>>
>>>>> Ok, secure boot was off.
>>>>> Nevertheless, I tried several other bios settings ...
>>>>> unfortunately
>>>>> without success.
>>>> This is tricky because not all options are displayed. Any option
>>>> that
>>>> is a dependency must first be enabled in order for the previously
>>>> undisplayed option to appear!!
>>>>
>>>> If you ever tangled with compiling your own custom kernel you will
>>>> have
>>>> come across this phenomenon.
>>>>
>>>>> I also tried some more things on the server side: e.g. I used
>>>>> tftpd-hpa
>>>>> and/or isc-dhcp-server together with dnsmasq (of course I first
>>>>> had
>>>>> to
>>>>> disable tftp and/or dhcp within dnsmasq) ... again, no success
>>>>> :-|
>>>> Another reason why I first mentioned our success with the other
>>>> iso
>>>> is
>>>> to say we did not need to alter any of this.
>>>>
>>>>> I have to mention that the Error message "Error 8 User aborted
>>>>> the
>>>>> transfer ..." comes only in the beginning.
>>>>> After this the client automatically tries again to connect to the
>>>>> server
>>>>> and it looks like that the ipxe.0 file is sent to the client
>>>>> without
>>>>> problems.
>>>>> However, the client refuses to boot and tries to connect again
>>>>> and
>>>>> again.
>>>> Also here, we did not have any ipxe.0 file. It just worked as any
>>>> other
>>>> client. The tricky part was reconfiguring the uefi bios to boot
>>>> from
>>>> the
>>>> lan using pxe. Once we found how it was needed by those particular
>>>> clients they just worked!!
>>>>
>>>>> By the way, if pxe-boot is not depending on uefi or legacy bios
>>>>> ...
>>>>> why
>>>>> does the uefi client need the ipxe.0 file instead of pxelinux.0?
>>>> Careful. I said that booting from the lan using pxe resulted in a
>>>> client running in legacy mode, not uefi mode. To explain what I
>>>> mean
>>>> let's take a straight forward case of installing a 64 bit Debian
>>>> Jessie
>>>> or Stretch to an empty hard drive.
>>>>
>>>> If the installer is started from a medium that the uefi bios
>>>> regards
>>>> as
>>>> non-uefi it will go ahead and install the system which will not
>>>> run
>>>> in
>>>> uefi mode.
>>>>
>>>> See http://www.rodsbooks.com/linux-uefi/ where he says,
>>>>
>>>> "You should verify an EFI-mode boot by dropping to a Linux shell
>>>> and
>>>> typing ls /sys/firmware/efi. If you see a list of files and
>>>> directories,
>>>> you've booted in EFI mode..."
>>>>
>>>> For us this was a non-issue since we were only interested in
>>>> getting
>>>> these clients to boot with pxe, not to run in uefi mode
>>>> particularly.
>>>>
>>>> Richard
>>>>
>>>>> Truth
>>> As you can see from the manual
>>> (see
>>> http://download.shuttle.eu/Mirror/Slim/XS36V4/Manual/MANUAL.ZIP)
>>> there are not so many possibilities to change the BIOS ...
>>> ... and I am quite sure that I tried all of them (in many different
>>> combinations).
>> Ok. Let's work on the assumption that your configuration is correct.
>>
>>> The status is that the uefi-client boots, takes an IP-address from
>>> the
>>> DHCP-server and receives the ipxe.0 file.
>>> For unknown reason the client does not want go further but restarts
>>> and
>>> gets the IP-address again.
>>>
>>> A have no idea what else I could do to get more information what's
>>> wrong?
>> Well, a quick glance at
>>
>> http://ipxe.org/howto/chainloading
>>
>> "Breaking the infinite loop
>>
>> When the chainloaded iPXE starts up, it will issue a fresh DHCP
>> request
>> and boot whatever the DHCP server hands out. The DHCP server is
>> currently set up to hand out the iPXE image, which means that you
>> will
>> be stuck in an infinite loop: PXE will load iPXE which will load
>> iPXE
>> which will load iPXE which will load iPXE…
>> Breaking the loop with the DHCP server
>>
>> One way that you can break this infinite loop is to configure the
>> DHCP
>> server to hand out iPXE only for the first DHCP request; the second
>> DHCP
>> request will return the “real” boot filename."
>>
>> does seem to describe what you are experiencing. In my opinion using
>> ipxe.0 is a waste of time as your uefi bios already has booting with
>> pxe
>> as an option and that you should be loading pxelinux.0 or whatever
>> your
>> other clients are loading.
>>
>> Richard
>>> Truth
> Many thanks for all your input.
>
> I've tried to escape from the loop using the 'option client-arch code
> 93' within isc-dhcp.
> Unfortunately, the client still remains within the loop.
> I've tried to debug the problem and it turns out that
>
> option client-arch != 0
>
> is always true (the else condition is never reached), which is
> probably
> a bug within the uefi-bios of the client.
> This means that I have to find a different way to break the loop.
>
> Is there a way to define user-variables within the isc-dhcp?
> I found a lot of parameters and declarations within man dhcpd.conf(5)
> but unfortunately it looks like that it is not possible to just
> define
> an integer variable ... however, I failed to do so ...
>
>
> In addition, I found out that my uefi bios is a little outdated.
> Nevertheless, the good news is that after downloading the new bios
> and
> writing it to the client ...
> ... I am _now_ able to boot via legacy bios (instead of uefi bios)
> which
> solved my initial problem :-)

Good. All's well that ends well, then.

Richard

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.fr

[richard kweskin]

On 2016-01-12 10:53, Truth wrote:
> On 11.01.2016 21:10, richard kweskin wrote:
>> On 2016-01-10 21:22, Truth wrote:
>>> On 09.01.2016 17:04, Truth wrote:
>>>> Hi,
>>>> I have installed a ltsp-pnp server on Debian jessie and was able
>>>> to
>>>> connect from to different clients.
>>>> So far everything is great - and many thanks to the ltsp
>>>> development
>>>> team.
>>>> However, my problem is that I still can not connect from an UEFI
>>>> client
>>>> to the ltsp-server.
>>>>
>>>> In order to solve the problem ...
>>>> (compare
>>>>
>>>>
>>>> https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)
>>>>
>>>> ... I downloded ipxe
>>>> apt-get install ipxe
>>>>
>>>> ... put two additional lines into
>>>> /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
>>>> dhcp-vendorclass=uefi,PXEClient
>>>> dhcp-boot=net:uefi,/ltsp/i386/ipxe.0
>>>>
>>>> ... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
>>>> ipxe.0 -> /boot/ipxe.efi
>>>> ipxe.iso -> /usr/lib/ipxe/ipxe.iso
>>>> ipxe.lkrn -> /boot/ipxe.lkrn
>>>> ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
>>>> undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
>>>> undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe
>>>>
>>>> Is there something else to do?
>>>> The logfile (see below) does not realy tell me what to do ...
>>>>
>>>> Many thanks in advance.
>>>> Truth
>>>>
>>>>
>>>>
>>>> After restarting dnsmasq and trying to connect from the UEFI
>>>> client
>>>> I
>>>> get the following messages (dmesg):
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von
>>>> SIGTERM
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung
>>>> OK.
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version
>>>> 2.72,
>>>> DNS
>>>> abgeschaltet
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen:
>>>> IPv6
>>>> GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset
>>>> auth
>>>> DNSSEC loop-detect
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im
>>>> Subnetz
>>>> 192.168.2.0
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
>>>> 192.168.67.20 -- 192.168.67.250, Lease Zeit8h
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
>>>> ist/var/lib/tftpboot/
>>>> Jan 9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> connected
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS
>>>> multicast
>>>> group on interface eth1.IPv6 with address
>>>> xxyy::xxy:xxyy:xxyy:xxyy.
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: New relevant
>>>> interface
>>>> eth1.IPv6 for mDNS.
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Registering new
>>>> address
>>>> record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
>>>> Jan 9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> disconnected
>>>> Jan 9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> connected
>>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>>> xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User
>>>> aborted
>>>> the transfer von 192.168.67.64 empfangen
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
>>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
>>>> Jan 9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
>>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
>>>> Jan 9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> disconnected
>>>> Jan 9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1):
>>>> link
>>>> connected
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>>> xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> ...
>>>>
>>>> On the client side I get:
>>>>
>>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>>> Firmware
>>>> -- http://ipxe.org
>>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>>
>>>> net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
>>>> [Link:up, TX:0 TXE:0 RX:0 RXE:0]
>>>> Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
>>>> net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
>>>> Next server: 192.168.67.1
>>>> Filename: /ltsp/i386/ipxe.0
>>>> Root path: /opt/ltsp/i386
>>>> tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
>>>> iPXE initialising devices...ok
>>>>
>>>>
>>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>>> Firmware
>>>> -- http://ipxe.org
>>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>>
>>>> Press Ctrl-B for the iPXE command line...
>>>> ...
>>> The above mentioned link claims "that most dnsmasq is not able to
>>> boot
>>> most UEFI devices as it uses DHCP option 43 which they don’t like
>>> ..."
>>>
>>> For that reason I'vd tried a configuration with isc-dhcp-server
>>> instead.
>>> Again, I'm able to connect to several clients but - unfortuantely,
>>> I'm
>>> not able to connect to the UEFI-client.
>>>
>>> It seems that the problem is related to some tftp-communication
>>> problem ...
>>> (compare
>>>
>>>
>>> https://ask.wireshark.org/questions/22519/tftp-transfer-option-negotiation-failed-error-8-packet-trace).
>>>
>>> ... but I could not find a solution (link) for this problem.
>>>
>>> If someone has been able to connect to an UEFI client, please let
>>> me
>>> know.
>> This was a one off since we were invited once to a pc lab where most
>> pc's were older but 4 were uefi pc's.
>>
>> We brought a laptop ltsp server with
>>
>> http://ts.sch.gr/repo/livecd/12.04/ubuntu-12.04.5-desktop-i386-sch.iso
>>
>> which is a remastered Ubuntu 12.04 32bit iso. It uses dnsmasq and it
>> just worked with all the clients once we could get the uefi to boot
>> with
>> no secure ipxe.
>>
>> Richard
>
> Thanks for the link.
> However, I would like to use my already existing debian server as a
> ltsp
> server.

I only mention the iso above as an example of one which works even for
uefi clients (though not operating in uefi mode) so you may search
further to correct whatever is preventing these clients from booting for
you now.

Richard

snip
>
> Truth


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP h

[Johan Kragsterman]

Hi!


-----Truth <***@gmx.de> skrev: -----
Till: ltsp-***@lists.sourceforge.net
Från: Truth <***@gmx.de>
Datum: 2016-01-12 09:53
Ärende: Re: [Ltsp-discuss] ltsp uefi client ?

On 11.01.2016 21:10, richard kweskin wrote:
> On 2016-01-10 21:22, Truth wrote:
>> On 09.01.2016 17:04, Truth wrote:
>>> Hi,
>>> I have installed a ltsp-pnp server on Debian jessie and was able to
>>> connect from to different clients.
>>> So far everything is great - and many thanks to the ltsp development
>>> team.
>>> However, my problem is that I still can not connect from an UEFI
>>> client
>>> to the ltsp-server.
>>>
>>> In order to solve the problem ...
>>> (compare
>>>
>>> https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)
>>>
>>> ... I downloded ipxe
>>> apt-get install ipxe
>>>
>>> ... put two additional lines into
>>> /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
>>> dhcp-vendorclass=uefi,PXEClient
>>> dhcp-boot=net:uefi,/ltsp/i386/ipxe.0
>>>
>>> ... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
>>> ipxe.0 -> /boot/ipxe.efi
>>> ipxe.iso -> /usr/lib/ipxe/ipxe.iso
>>> ipxe.lkrn -> /boot/ipxe.lkrn
>>> ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
>>> undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
>>> undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe
>>>
>>> Is there something else to do?
>>> The logfile (see below) does not realy tell me what to do ...
>>>
>>> Many thanks in advance.
>>> Truth
>>>
>>>
>>>
>>> After restarting dnsmasq and trying to connect from the UEFI client
>>> I
>>> get the following messages (dmesg):
>>> Jan  9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von
>>> SIGTERM
>>> Jan  9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung
>>> OK.
>>> Jan  9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version 2.72,
>>> DNS
>>> abgeschaltet
>>> Jan  9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen:
>>> IPv6
>>> GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset
>>> auth
>>> DNSSEC loop-detect
>>> Jan  9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im
>>> Subnetz
>>> 192.168.2.0
>>> Jan  9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
>>> 192.168.67.20 -- 192.168.67.250, Lease Zeit8h
>>> Jan  9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
>>> ist/var/lib/tftpboot/
>>> Jan  9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> connected
>>> Jan  9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS
>>> multicast
>>> group on interface eth1.IPv6 with address xxyy::xxy:xxyy:xxyy:xxyy.
>>> Jan  9 16:39:17 ltsp-server avahi-daemon[488]: New relevant
>>> interface
>>> eth1.IPv6 for mDNS.
>>> Jan  9 16:39:17 ltsp-server avahi-daemon[488]: Registering new
>>> address
>>> record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
>>> Jan  9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> disconnected
>>> Jan  9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> connected
>>> Jan  9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>> xy:yx:yx:yx:yx:yx
>>> Jan  9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan  9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan  9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan  9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User
>>> aborted
>>> the transfer von 192.168.67.64 empfangen
>>> Jan  9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
>>> Jan  9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
>>> Jan  9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> disconnected
>>> Jan  9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1): link
>>> connected
>>> Jan  9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>> xy:yx:yx:yx:yx:yx
>>> Jan  9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan  9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> Jan  9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>> ...
>>>
>>> On the client side I get:
>>>
>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>> Firmware
>>> -- http://ipxe.org
>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>
>>> net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
>>>   [Link:up, TX:0 TXE:0 RX:0 RXE:0]
>>> Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
>>> net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
>>> Next server: 192.168.67.1
>>> Filename: /ltsp/i386/ipxe.0
>>> Root path: /opt/ltsp/i386
>>> tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
>>> iPXE initialising devices...ok
>>>
>>>
>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>> Firmware
>>> -- http://ipxe.org
>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>
>>> Press Ctrl-B for the iPXE command line...
>>> ...
>> The above mentioned link claims "that most dnsmasq is not able to
>> boot
>> most UEFI devices as it uses DHCP option 43 which they don&#8217;t like
>> ..."
>>
>> For that reason I'vd tried a configuration with isc-dhcp-server
>> instead.
>> Again, I'm able to connect to several clients but - unfortuantely,
>> I'm
>> not able to connect to the UEFI-client.
>>
>> It seems that the problem is related to some tftp-communication
>> problem ...
>> (compare
>>
>> https://ask.wireshark.org/questions/22519/tftp-transfer-option-negotiation-failed-error-8-packet-trace).
>>
>> ... but I could not find a solution (link) for this problem.
>>
>> If someone has been able to connect to an UEFI client, please let me
>> know.
> This was a one off since we were invited once to a pc lab where most
> pc's were older but 4 were uefi pc's.
>
> We brought a laptop ltsp server with
> http://ts.sch.gr/repo/livecd/12.04/ubuntu-12.04.5-desktop-i386-sch.iso
>
> which is a remastered Ubuntu 12.04 32bit iso. It uses dnsmasq and it
> just worked with all the clients once we could get the uefi to boot with
> no secure ipxe.
>
> Richard

Thanks for the link.
However, I would like to use my already existing debian server as a ltsp
server.
I do not quite understand what you mean with non secure ipxe.
Does it mean the bios option for secure boot ...or something else?

The reason I would like to get UEFI running is that there are quite nice
low power and low price shuttles with e.g. Pentium J2900 or Celeron
J1900 (22nm, 2,4GHz, 4 Core, 10Watt) available which unfortunately only
available for uefi boot.

Truth







I use this mITX Asus board with integrated J1900. I use it for 64 bit fat clients on a ubuntu 14.04 server. There is a lot of options in the firmware to choose if you like UEFI or legacy solutions.

http://www.amazon.com/Intel-Celeron-J1900-Motherboard-J1900I-C/dp/B00KMIJR5Y

This is a very cheap board, and with 8 GB of RAM I get very fast as well, with good graphics performance. I got it in a very small chieftec box.

Rgrds Johan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net

[Truth]

On 12.01.2016 12:49, Johan Kragsterman wrote:
> Hi!
>
>
> -----Truth <***@gmx.de> skrev: -----
> Till: ltsp-***@lists.sourceforge.net
> Från: Truth <***@gmx.de>
> Datum: 2016-01-12 09:53
> Ärende: Re: [Ltsp-discuss] ltsp uefi client ?
>
> On 11.01.2016 21:10, richard kweskin wrote:
>> On 2016-01-10 21:22, Truth wrote:
>>> On 09.01.2016 17:04, Truth wrote:
>>>> Hi,
>>>> I have installed a ltsp-pnp server on Debian jessie and was able to
>>>> connect from to different clients.
>>>> So far everything is great - and many thanks to the ltsp development
>>>> team.
>>>> However, my problem is that I still can not connect from an UEFI
>>>> client
>>>> to the ltsp-server.
>>>>
>>>> In order to solve the problem ...
>>>> (compare
>>>>
>>>> https://forums.fogproject.org/topic/5750/dnsmasq-proxy-booting-with-uefi/22)
>>>>
>>>> ... I downloded ipxe
>>>> apt-get install ipxe
>>>>
>>>> ... put two additional lines into
>>>> /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
>>>> dhcp-vendorclass=uefi,PXEClient
>>>> dhcp-boot=net:uefi,/ltsp/i386/ipxe.0
>>>>
>>>> ... and put some symlinks into /var/lib/tftpboot/ltsp/i386/
>>>> ipxe.0 -> /boot/ipxe.efi
>>>> ipxe.iso -> /usr/lib/ipxe/ipxe.iso
>>>> ipxe.lkrn -> /boot/ipxe.lkrn
>>>> ipxe.pxe -> /usr/lib/ipxe/ipxe.pxe
>>>> undionly.kkpxe -> /usr/lib/ipxe/undionly.kkpxe
>>>> undionly.kpxe -> /usr/lib/ipxe/undionly.kpxe
>>>>
>>>> Is there something else to do?
>>>> The logfile (see below) does not realy tell me what to do ...
>>>>
>>>> Many thanks in advance.
>>>> Truth
>>>>
>>>>
>>>>
>>>> After restarting dnsmasq and trying to connect from the UEFI client
>>>> I
>>>> get the following messages (dmesg):
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[566]: beende nach Empfang von
>>>> SIGTERM
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1447]: dnsmasq: Syntaxprüfung
>>>> OK.
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: gestartet, Version 2.72,
>>>> DNS
>>>> abgeschaltet
>>>> Jan 9 16:39:01 ltsp-server dnsmasq[1456]: Übersetzungsoptionen:
>>>> IPv6
>>>> GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset
>>>> auth
>>>> DNSSEC loop-detect
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, Proxy im
>>>> Subnetz
>>>> 192.168.2.0
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-dhcp[1456]: DHCP, IP-Bereich
>>>> 192.168.67.20 -- 192.168.67.250, Lease Zeit8h
>>>> Jan 9 16:39:01 ltsp-server dnsmasq-tftp[1456]: TFTP Wurzel
>>>> ist/var/lib/tftpboot/
>>>> Jan 9 16:39:16 ltsp-server NetworkManager[467]: <info> (eth1): link
>>>> connected
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Joining mDNS
>>>> multicast
>>>> group on interface eth1.IPv6 with address xxyy::xxy:xxyy:xxyy:xxyy.
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: New relevant
>>>> interface
>>>> eth1.IPv6 for mDNS.
>>>> Jan 9 16:39:17 ltsp-server avahi-daemon[488]: Registering new
>>>> address
>>>> record for xxyy::xxy:xxyy:xxyy:xxyy on eth1.*.
>>>> Jan 9 16:39:17 ltsp-server NetworkManager[467]: <info> (eth1): link
>>>> disconnected
>>>> Jan 9 16:39:20 ltsp-server NetworkManager[467]: <info> (eth1): link
>>>> connected
>>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>>> xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:23 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: Fehler 8 User
>>>> aborted
>>>> the transfer von 192.168.67.64 empfangen
>>>> Jan 9 16:39:26 ltsp-server dnsmasq-tftp[1456]: konnte
>>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 nicht an 192.168.67.64 senden
>>>> Jan 9 16:39:27 ltsp-server dnsmasq-tftp[1456]:
>>>> /var/lib/tftpboot/ltsp/i386/ipxe.0 an 192.168.67.64 verschickt
>>>> Jan 9 16:39:27 ltsp-server NetworkManager[467]: <info> (eth1): link
>>>> disconnected
>>>> Jan 9 16:39:29 ltsp-server NetworkManager[467]: <info> (eth1): link
>>>> connected
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPDISCOVER(eth1)
>>>> xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPOFFER(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPREQUEST(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> Jan 9 16:39:30 ltsp-server dnsmasq-dhcp[1456]: DHCPACK(eth1)
>>>> 192.168.67.64 xy:yx:yx:yx:yx:yx
>>>> ...
>>>>
>>>> On the client side I get:
>>>>
>>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>>> Firmware
>>>> -- http://ipxe.org
>>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>>
>>>> net0: xy:yx:yx:yx:yx:yx using rtl8168 on PCI02:00.2 (open)
>>>> [Link:up, TX:0 TXE:0 RX:0 RXE:0]
>>>> Configuring (net0 xy:yx:yx:yx:yx:yx)... ok
>>>> net0: 192.168.67.64/255.255.255.0 gw 192.168.67.1
>>>> Next server: 192.168.67.1
>>>> Filename: /ltsp/i386/ipxe.0
>>>> Root path: /opt/ltsp/i386
>>>> tftp://192.168.67.1/ltsp/i386/ipxe.0... ok
>>>> iPXE initialising devices...ok
>>>>
>>>>
>>>> iPXE 1.0.0+git-20141004.86285d1-1 -- OPen Source Network Boot
>>>> Firmware
>>>> -- http://ipxe.org
>>>> Features: VLAN HTTP DNS TFTP EFI Menu
>>>>
>>>> Press Ctrl-B for the iPXE command line...
>>>> ...
>>> The above mentioned link claims "that most dnsmasq is not able to
>>> boot
>>> most UEFI devices as it uses DHCP option 43 which they don&#8217;t like
>>> ..."
>>>
>>> For that reason I'vd tried a configuration with isc-dhcp-server
>>> instead.
>>> Again, I'm able to connect to several clients but - unfortuantely,
>>> I'm
>>> not able to connect to the UEFI-client.
>>>
>>> It seems that the problem is related to some tftp-communication
>>> problem ...
>>> (compare
>>>
>>> https://ask.wireshark.org/questions/22519/tftp-transfer-option-negotiation-failed-error-8-packet-trace).
>>>
>>> ... but I could not find a solution (link) for this problem.
>>>
>>> If someone has been able to connect to an UEFI client, please let me
>>> know.
>> This was a one off since we were invited once to a pc lab where most
>> pc's were older but 4 were uefi pc's.
>>
>> We brought a laptop ltsp server with
>> http://ts.sch.gr/repo/livecd/12.04/ubuntu-12.04.5-desktop-i386-sch.iso
>>
>> which is a remastered Ubuntu 12.04 32bit iso. It uses dnsmasq and it
>> just worked with all the clients once we could get the uefi to boot with
>> no secure ipxe.
>>
>> Richard
> Thanks for the link.
> However, I would like to use my already existing debian server as a ltsp
> server.
> I do not quite understand what you mean with non secure ipxe.
> Does it mean the bios option for secure boot ...or something else?
>
> The reason I would like to get UEFI running is that there are quite nice
> low power and low price shuttles with e.g. Pentium J2900 or Celeron
> J1900 (22nm, 2,4GHz, 4 Core, 10Watt) available which unfortunately only
> available for uefi boot.
>
> Truth
>
>
>
>
>
>
>
> I use this mITX Asus board with integrated J1900. I use it for 64 bit fat clients on a ubuntu 14.04 server. There is a lot of options in the firmware to choose if you like UEFI or legacy solutions.
>
> http://www.amazon.com/Intel-Celeron-J1900-Motherboard-J1900I-C/dp/B00KMIJR5Y
>
> This is a very cheap board, and with 8 GB of RAM I get very fast as well, with good graphics performance. I got it in a very small chieftec box.
>
> Rgrds Johan
>
>
Great board - ... and it has the 'Legacy OpROM only' option.
Unfortunately, my XS36V4 shuttle does not offer any legacy option (e.g.
CSM).
However, if there is a way to use my shuttle as an UEFI client I would
like to give a try.

Truth




------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net