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 channel on irc.freenode.net
