Windows 10 Bitlocker Query

[Tom Elliott]

Why do you “have” to boot it into legacy mode to get the option to boot from the network? While I understand the “how” of this occurring (meaning because why – by default – suggest using undionly.kpxe), there is nothing that says you can’t try different options and even pair your DHCP server in the usefulness that is User/Vendor Classes to direct a system (and how it’s booting) to use different boot files (for example dynamically directing UEFI booting devices to use an equivalent ipxe.EFI labelled file and bios booting devices to use an equivalent ipxe.{,k,kk}PXE file.

With that said, if you create the image in UEFI mode, but have to capture it in “legacy” the only change you should need to make is in regards to how the network stack is booting and how to “exit” the system back to the disk after a tasking is completed.

It is fully possibly to image a system in UEFI mode, while using a “legacy” network boot system. These things are 100% different items. Just because you have to network boot in legacy does not mean you have to build your reference image on a system that’s loaded up in legacy mode.

[RobTitian16]

@Tom-Elliott When booting into UEFI, the system says there are no devices to boot from. In order to get the network boot option, I have to disable secure boot, enable Legacy Boot and then either set the network boot as the priority in the boot order, or press F12 at the beginning of the boot cycle to get the option to boot from the network. So I suppose my first question is, how would I get the system to boot from the network in UEFI mode?

And if I created the image in a legacy boot mode, could I push it to a UEFI system without any issues?

Finally, I’m following the wiki article (https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence) on this, (EDIT) and I’m using Windows 2008 R2 for DHCP. I can see it says no-one has got it working yet, so I’m assuming it’s not possible for me at the moment either?

[Tom Elliott]

@RobTitian16 Typically, UEFI network booting is a two - three step process.

First, you need to enable the NIC IPv4 Stack for EFI to even allow network booting. (Secure boot must be off, but only during the imaging up or down, and can be reenabled.)

If you image a system in legacy mode, the receiving system MUST be in Legacy mode, this is because UEFI requires the disk layout to be in GPT. If you have created an image in purely legacy mode it will not work to image a system in legacy mode that will need to be booted in uefi mode.

The same works backwards as well. If your image is UEFI and the device tries to boot in Legacy mode, you will most likely run into issues (unless you’ve corrected the hybrid mbr/gpt partition layout.

[RobTitian16]

@Tom-Elliott
Ah, thanks. That’s what I was looking for to boot it from the network.

As I said before though, I’m running Windows Server 2008 R2 so I’m guessing it’s not possible for me to boot from UEFI? Not unless I upgrade to Server 2012 R2.

[george1421]

@RobTitian16 Tom is right about enabling the network booting stack in uefi mode. On our Dell systems, network booting in uefi mode is disabled by default.

I’m not sure what/why your server OS is important here, you are installing windows 10 on a target computer, this has nothing to do with the server, can you explain?

<edit> unless you are referring to the uefi/bios coexistence. In that case your dhcp server needs to be running windows 2012 or you have dnsmasq running on your fog server to supply the dhcp pxe booting options.

[RobTitian16]

@george1421 Yep, we use Dell too and it’s just something I learnt today (learn something new…).

I was going by the wiki article I mentioned before as it seems like the UEFI network boot won’t load as it’s not given a file to boot from. In fact, it just sort of flashes and then disappears when I try to boot it that way. I’ll see what I can do with dnsmasq. Thanks!

[george1421]

@RobTitian16 If you are going the dnsmasq route, follow this one: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support

And then this one: https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques

Then in your dhcp server remove your dhcp options 66 and 67. As long as the dnsmasq server is on the same subnet as your booting computers it will respond to the dhcp query from the target. If your fog server is on a different subnet than your dhcp clients and you use a dhcp-helper / dhcp-relay agent on your router then add your dnsmasq server as the last dhcp server in the chain.

[RobTitian16]

@george1421 Ah, thanks. I got as far as “Make Install” but then ran into the following problem:

I’m running this on Ubuntu 14.04.

EDIT: I spoke too soon (as usual, doh!)
I just had to install the libidn package.

sudo apt-get install libidn11-dev

[george1421]

@RobTitian16 Did you do this part?

sudo apt-get update

sudo apt-get install build-essential

sudo apt-get install -y wget libdbus-1-dev libnetfilter-conntrack-dev idn libidn11-dev nettle-dev libval-dev dnssec-tools 

The libidn that is mentioned should come in through libidn11-dev

[RobTitian16]

@george1421 Is that an l (as in lower-case L) or a 1? I may have typed it incorrectly, which is why I got that error.

So far so good, although I’m running into an issue when starting PXE over IPv4 in UEFI:

Start PXE over IPv4
Station IP address is 10.1.x.x
Server IP address is 10.1.x.x
NBP filename is ipxe.0
NBP filesize is 0 Bytes
PXE-E23: Client received TFTP error from server. 

I’m guessing it’s because the ipxe.0 file doesn’t actually exist. Where would I get this from?

[george1421]

@RobTitian16 actually, lets do a sanity check first.

You were able to compile the dnsmasq correctly?

If so you still need to configure it. I think maybe I should update my documentation to say you must install your distribution dnsmasq package first then compile this new version.

But once dnsmasq is installed then you need to configure it using the second link. There should be no ipxe.0 file ever used.

If you did not install your distribution’s dnsmasq package first no worries. Install it now, then go back into the dnsmasq 2.76 source and just rerun the make command. Then confirm that 2.76 is installed correctly.

[RobTitian16]

@george1421 Yep, I had dnsmasq installed. Then, I installed the 2.76 version. Then I configured the config file as you did in your post:

port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,192.168.112.24

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

dhcp-range=192.168.112.24,proxy

Am I missing a step somewhere?

[george1421]

@RobTitian16

Well the first thing that jumps out at me is that 192.168.112.X needs to be the IP address of your FOG server. Other than that, it should work out of the box as long as the target computer and dnsmasq server are in the same broadcast domain (subnet). If it doesn’t then we need to get a pcap to see what is going wrong on the wire.

[RobTitian16]

@george1421 Yep, they’re definitely on the same subnet.

This is my full config:

# Sample configuration for dnsmasq  to function as a proxyDHCP server,
# enabling LTSP clients to boot when an external, unmodifiable DHCPserver is present.
# The main dnsmasq configuration is in /etc/dnsmasq.conf;
# the contents of this script are added to the main configuration.
# You may modify the file to suit your needs.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Dnsmasq can also function as a TFTP server. You may uninstall tftpd-hpa if you like and uncomment the next line.
#enable-tftp

#Set the root directory for files available via FTP.
tftp-root=/tftpboot

#The boot filename.
dhcp-boot=undionly.kpxe,,10.1.0.102

# rootpath option, for NFS
dhcp-option=17,/images

# kill multicast

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

# Disable re-use of the DHCP servername and filename fields as extra option space.
# That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override 

# Inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,10.1.0.102
dhcp-boot=net:UEFI,ipxe.efi,,10.1.0.102
dhcp-boot=net:UEFI64,ipxe.efi,,10.1.0.102



# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 3

# A boot service type of 0 is special, and will abort the net boot procedure and continue booting from the local media.
pxe-service=X86PC, "Boot from local hard disk", 0

# If an integer boot service type, rather than a basename is given, then the 
# PXE client will search for a suitable boot service for that type on the 
# network. This search may be done by multicast or broadcast, or direct to a server if its IP address is provided.
# pxe-service=x86PC, "boot from Windows RIS server", 1

#This range(s) is for the public interface, where dnsmasq functions as a proxy DHCP server providing boot information but no IP leases.
# Any IP in the subnet will do, so you may just put your server NIC IP here. Since dnsmasq is not providing true DHCP services, you do not
# want it handing out IP addresses. Just put your servers' IP address for the interface that is connected to the nwtwork on which the FOG 
# client exists. If this setting is incorrect, the dnsmasq may not start, rednering your proxyDHCP ineffective.
dhcp-range=10.1.0.102,proxy

# This range(s) is for the private network on 2-NIC servers, where dnsmasq functions as a normal DHCP server, providing IP leases.
#dhcp-range=192.168.0.20,192.168.0.250,8h

#For static client IPs, and only for the private subnets, you may put entries like this:
# dhcp-host=00:20:e0:3b:13:af,10.160.31.111,client111,infinite 

And I think I’ve just realised what could be wrong… the “#The boot filename” section probably needs to be taken out, right? That’s from the previous installation of dnsmasq.

[george1421]

@RobTitian16 Please move this file to a safe place and use my config file as it is complete and the order the dhcp-boot as they were. What you have should work, but you have the dhcp-boot for undionly first, which may skip the uefi tets since it would be the first match. also you don’t need the dhcp-options settings. What I posted is a complete config file.

[RobTitian16]

@george1421 Okay, I’m now using exactly the same file as your tutorial:

port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,10.1.0.102
dhcp-boot=net:UEFI,ipxe.efi,,10.1.0.102
dhcp-boot=net:UEFI64,ipxe.efi,,10.1.0.102

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,10.1.0.102

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

dhcp-range=10.1.0.102,proxy

However, when booting from a UEFI boot on a Dell Latitude E6430, the system is still saying the same thing.

Start PXE over IPv4
Station IP address is 10.1.x.x
Server IP address is 10.1.x.x
NBP filename is ipxe.0
NBP filesize is 0 Bytes
PXE-E23: Client received TFTP error from server. 

[george1421]

@RobTitian16 Well then, now you get to play “Net Detective”.

“The only truth is what is flying down the wire.”

I need you to do the following:

1. Install tcpdump on the FOG server.
2. Setup tcpdump to capture this dhcp exchange between the target computer, dhcp server, dnsmasq, and the fog server. From the fog server linux console run the following command sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
3. PXE boot the target computer to you reach the error
4. Press Ctrl-C to exit out of the tcpdump program
5. Review the output.pcap file with wireshark to see who is telling the client to request ipxe.0 -OR- post the pcap file here and we will take a look at it. My preference would be for YOU to look at the pcap file so YOU can see what is going on. But with that said we are here to help you learn too. Wireshark is an insanely complex program so using it for the first few times IS a bit daunting.

[RobTitian16]

@george1421 Thanks, George.
From what I can see, the system I’m trying to boot with is requesting the ipxe.0 from the FOG server, but that’s where the log ends.

[george1421]

@RobTitian16 please post the pcap so I can take a look at it.

[RobTitian16]

@george1421 0_1480609373367_output.pcap

It’s right at the end - 10.1.2.32 is the target host.
10.1.0.102 is the FOG Server.