Posts made by need2

Yeah sadly this is kind of on the PXE client embedded in each computer. Some are coded well and give up on PXE boot if they can’t get a good reply, others just kind of sit there and stare at the wall.

I have run into this issue as well. By doing heavy amounts of research I came to the following conclusions:
[LIST=1]
[]DnsMasq is hard coded to add a .0 to the end of a file. There is no good reason for this. That’s just how it do.
[]There are some PXE clients (computer firmwares) that have issues with it. They assume the “next-server” to be the DHCP unless given a specific Option 66, unlike most other PXE clients that assume the “next-server” to be the same as where they were told to get the boot file. Once again, no good reason for this, just how they do.
[/LIST]

I will see what I can do as well… light staffing here today so I’m a bit busy.

I see… interesting. This may be the direction that things have to go. DnsMasq seems in sufficient for EFI PXE and some older PXE clients. I’m still going to try a few things with it, but otherwise we might just have to make good documentation on the changes to make to a Windows 2012+ DHCP and a Linux DHCP to achieve coexistence. I will work on the Windows 2012 DHCP configs eventually (assuming DnsMasq fails me), but I will need to spin up a new 2012 server and integrate it to our domain first.

[quote=“Junkhacker, post: 46782, member: 21583”]using the microsoft USB dongle. my legacy machines are working like they always have, uefi machines are loading ipxe.efi[/quote]

Do I need to bribe you?

[quote=“Wayne Workman, post: 46752, member: 28155”]Also, if you used user-based enumeration shares (windows server 12 and up), you can specify encryption of the redirected user data on the server itself, and have the user files NOT EVEN EXIST on the local machines. That’s how my environment is set up. It’s done through GPOs.[/quote]

That too is how we have ours set up. I really, really love not worrying about someone’s files when a drive dies anymore.

I appear to be running into a PortFast issue. It will take me a bit to take control of the switches to blame. Those who can test this, please install dnsmasq, then use the attached file (saving it as /etc/dnsmasq.d/ltsp.conf), replacing <FOG-IP> with your FOG server’s IP. Then, make a copy of undionly.kpxe and snponly.efi, calling the copies undionly.kpxe.0 and snponly.efi.0 respectively.

[url=“/_imported_xf_attachments/1/1962_ltsp.txt?:”]ltsp.txt[/url]

[quote=“Junkhacker, post: 46750, member: 21583”]i spotted your thread earlier, used it and i’ve been working with a Surface Pro 3 network booting all day. network boot works fine.[/quote]

[quote=“Wayne Workman, post: 46747, member: 28155”]Actually, with DHCP classes / policies, you can have windows DHCP server what file you like… I’ve got a thread on it… Just haven’t been able to actually boot an EFI device at all… that’s what’s holding me back from trying it.

However, a dnsmasq solution will be very needed soon. Good work.[/quote]

Are you coexisting BIOS PXE and UEFI PXE?

You’re right. I was thinking more of EFS. The following is dated, but relevant.

[url]https://technet.microsoft.com/en-us/magazine/2007.02.securitywatch.aspx[/url]

I suggest using BitLocker, or at least trying it to see if it it fits your needs better. You should also be able to specify via GPO to have any/all user folders encrypted by machine with BitLocker. That way it wouldn’t matter who you had log in to the laptop, their data would automatically be encrypted within their user folder.

If you could limit the encryption to just User folder space then you will have less issues. OS and Program Files do not need to be encrypted, and doing so would actually degrade performance.

This is a thread for documenting my travels in making a system that lets FOG boot both BIOS and EFI based computers. Input from others is welcomed.

I am aware that if you have a Linux based DHCP there are other methods out there that make this more approachable, but the purpose of my work here will be for those who use a Windows DHCP or other DHCP that they cannot modify.

Currently I am working on using DnsMasq to allow FOG to boot on the network without having to specify a boot file in the DHCP server. This would allow me (in theory) to eventually serve different boot files to different detected architectures. The problem with specifying a boot file in the DHCP is that the file would need to be compatible with all architectures you intend to support, and mixing EFI and BIOS support is (currently) impossible.

I do have BIOS based devices able to talk to the FOG server which is running DnsMasq, without any network boot related settings specified in my Windows DHCP. The device then is handed off to FOG’s boot process, then boots however is relevant.

EFI based devices are not receiving any network boot information at the moment. I have tried a few different devices, so I know it is not just one’s issue. I am continuing to work on this.

Current /etc/dnsmasq.d/ltsp.conf is as follows, mostly taken from the FOG wiki:
[CODE]port=0

log-dhcp

tftp-root=/tftpboot

dhcp-boot=undionly.kpxe,<FOG-IP>,<FOG-IP>

dhcp-option=17,/images

dhcp-option=vendor:PXEClient,6,2b

dhcp-no-override

pxe-prompt=“Press F8 for boot menu”, 3

pxe-service=X86PC, “Boot BIOS”, undionly.kpxe, <FOG-IP>
pxe-service=IA64_EFI, “Boot IA64”, snponly.efi, <FOG-IP>
pxe-service=IA32_EFI, “Boot IA32”, i386-efi/snponly.efi, <FOG-IP>
pxe-service=X86-64_EFI, “Boot x8664EFI”, snponly.efi, <FOG-IP>

dhcp-range=<FOG-IP>,proxy[/CODE]

Notes:
[LIST]
[]Replace <FOG-IP> with the FOG server’s IP address in the form of x.x.x.x
[]I may have more architectures specified than needed, and the delay in boot and quoted messages are just for my debugging. Once in deployment the delay is probably fine as 1 or 0, and no messages should be needed.
[*]Whatever files you specify to boot with the pxe-service parameter, you will need to make a copy of that ends in ‘.0’ . Don’t ask me why DnsMasq requires this.
[/LIST]

Restoring onto the same hardware shouldn’t be a problem, but there may be issues restoring across devices. I do not know from experience though.

It shouldn’t be too hard to have a method to chain to WDS. Its just a matter of triggering the right file. It does matter what version of Windows Server you are running. When I get to that part, I will be making a connection to a Windows Server 2012. The same methods should also work on 2008r2 and 2012r2.

Any/all results and documentation on my UEFI/BIOS coexistence will be going into a new thread. Since that will use DnsMasq it will be off topic for this thread.

Fairly certain I saw config options that would allow for that. I’m pressing forward either way, and if it’s an issue I’ll try to fix it later.

Oh, it is. I’m using dnsmasq.

I may have hit my last straw with WDS. I might be able to make it work by compiling my own rendition of iPXE, but it appears that everyone would have to compile their own if they wanted it to work with this. I am looking at another option now that will in the end still give proper arch detection and handling, and also allow those who want to use WDS to do so. But I can tell you right now that if this works out it will be a lot less hacky.

Ran into technical roadblocks. Probably going to ditch Syslinux. Now looking for a way to get WDS to point straight to a boot file on another server. Hints welcomed.

Well hopefully I will be getting that far today with my system. And yes, if you are not using Windows servers, then you need to use a Linux DHCP and do their version of handling of Option 93. I’ll admit I am not bothering to research that method at all, because we will not be using it.

EDIT: Making progress. Nearly have WDS passing to FOG for BIOS machines, but I’m getting an error that vanishes quite quickly. Hunting that down. Also trying hard to keep all of my references that I’m using straight. I have about 20 tabs open, and files across three monitors right now.

Some progress. I got interrupted. Got UEFI and BIOS systems booting from WDS without specifying a boot file. Tomorrow I’ll be working on another hunch to hijack that to chain load to fog.