PXE UEFI Secure Boot

pxe
tftp
v7

(Mark Dipple) #1

NethServer Version: 7.4.1708
Module: DHCP TFTP?

Hi,

I’ve been using a number of servers over the years (originally Windows servers) but have decided that they are too resource heavy for my little HP MicroServer especially as I’m using VMware to host them (I like using snapshots in case I make a mistake). I came across Nethserver a little while ago and I have to say I’m impressed. I’ve managed to get an AD PDC up and running (thanks to the Docs for pointing out promiscuous mode which was my only problem) and I’ve got the web proxy up and running. All I need now is to get my Windows deployments working so I can move the images I have over from the Windows machine to my Nethserver.

If I use a USB stick I can point the deployment share over to a share created on Nethserver. I use MDT and it doesn’t care where the share is as long as it can read it. A USB deployment works fine and also if I enable PXE on a Windows machine I can also deploy via the Nethserver share however I really want to get rid of the Windows Server (it’s hosted on the same hardware). It’s taking up a lot of resources and I notice everything slowing down went it’s on.

My question is, is it possible for Nethserver to act as a PXE boot server with UEFI and Secure Boot support? I followed the guide (in the Nethserver docs) to get a general none-UEFI boot server running and was successful with that. What else would I need to do to get Windows Secure Boot images working? I’ve looked around and I believe it should be possible but I can’t find any of the config files that are normally mentioned for example here:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/s1-netboot-pxe-config-efi

Yes I know it’s for Red Hat but isn’t CentOS (which I believe Nethserver is based on) based on this?

Currently Nethserver is doing AD, DHCP, DNS and I’m also using SMB shares.

Any help would be greatly appreciated.

Many Thanks,
Mark


(Markus Neuberger) #2

Hi @Mark_Dipple,

what I found out it should be possible but I never tried. NethServer uses dnsmasq 2.76 (this version supports UEFI) for DHCP (and DNS) and many tutorials (like the Redhat one) assume DHCPd so you have to edit /etc/dnsmasq.conf.

Config files are templated and rewritten on updates/reboot so please don’t just edit them, create custom templates instead:

http://docs.nethserver.org/projects/nethserver-devel/en/v7/templates.html#local-site-overrides-templates-custom-and-templates-user-custom

Some links I found:

https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq#Adding_UEFI_support_to_the_basic_script


(fpausp) #3

At the moment I use TFTP/PXE on one of my nethservers to be able to boot a few linux distros. I use Clonezilla to clone my Computers…

Have you ever heard from the - FOG Project - I played a bit with it, tried to install it on nethserver, but did not finish it…

I would like to know if people have experience with FOG and are interested to use this software on nethserver ?


(James Nesbitt) #4

I have previously had some success in setting up FOG under ClearOS5.2 and 6 (which are CentOS 5 and 6 based.

I haven’t yet tried it under NethServer 7 as it is CentOS 7 based, but it should work - I just don’t have enough hours in the day to give FOG (and a long list of other things) a try.

If this had to be an addon module to NethServer, I would view it as a potential killer feature in certain circles (thinking of educational scenarios or internet kiosk scenarios where you have a number of dumb terminals). It may take quite a bit of work to develop that module though…


(fpausp) #5

Maybe we can spread the work on it…

For the beginning, a howto could do the job, to give the community a possibility to try the software…


(Mark Dipple) #6

Thank you all for your assistance but I’m still at a loss. I believe something is happening when I try to do a PXE boot as instead of hanging I get an message stating that the NBP file has been successfully downloaded but it then proceeds to boot from my HDD instead.

I followed the guides the best I can (I have a Windows background so I’m better with a GUI) and have come up with this file which I’ve put into /etc/e-smith/templates-custom/dnsmasq.conf

# If I understand this correctly this will be imported into /etc/dnsmasq.conf after a reboot
# Directory with TFTP boot files is here: /var/lib/tftpboot/

# Log lots of extra information about DHCP transactions.
# log-dhcp - logs are supposedly in /var/log/daemon.log
# actually found that I need to grep /var/log/messages
log-queries

# Set the root directory for files available via FTP.
# tftp-root=/tftpboot
# Nethserver uses /var/lib/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

# Architecture query?

# Intel x86pc (32-bit x86)
dhcp-match=set:bios,60,PXEClient:Arch:00000
dhcp-boot=tag:bios,undionly.kpxe,192.168.2.1,192.168.2.1

# EFI (32-bit Itanium)
dhcp-match=set:efi32,60,PXEClient:Arch:00006
dhcp-boot=tag:efi32,i386-efi/ipxe.efi,192.168.2.1,192.168.2.1

# EFI (32-bit x86)
dhcp-match=set:efibc,60,PXEClient:Arch:00007
dhcp-boot=tag:efibc,ipxe.efi,192.168.2.1,192.168.2.1

# EFI (64-bit x86/AMD64)
dhcp-match=set:efi64,60,PXEClient:Arch:00009
dhcp-boot=tag:efi64,ipxe.efi,192.168.2.1,192.168.2.1

# The boot filename, Server name, Server Ip Address
# dhcp-boot=undionly.kpxe,,192.168.2.1
dhcp-boot=tag:x86PC,pxelinux.0
dhcp-boot=tag:BD_EFI,uefi/bootx64.efi 
# Is another entry needed here for secure boot?

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

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, ARM_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.

# PXEClient:Arch:00000
pxe-service=tag:x86PC,X86PC, "Boot using legacy BIOS", pxelinux

# PXEClient:Arch:00007
# pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
# pxe-service=tag:BC_EFI,BC_EFI, "Boot using x86-64 UEFI", uefi/bootx64.efi

# PXEClient:Arch:00009
# pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi
# secure boot entry here?

Standard PXE works fine, I just can’t get the EFI boot working. I believe the networking part is ‘working’ but the files can’t be found. If this is the case where am I supposed to put them?

Many Thanks,
Mark


(Mark Dipple) #7

Sorry pasted my config file in and it’s formatted strangely. Apologies if it appears as though I’m shouting.


(Marc) #8

To format a post you can make us of markdown, primarly, and some bulletin board and html tags at some extend.


(James Nesbitt) #9

You hit the same problem I stumbled across when I was trying to set it up with NethServer 6 and 7, I just haven’t had the time to wrapped my brain around the EFI and UEFI boot processs yet


(fpausp) #10

I use just this for my FOG-Server (Ubuntu):

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

(fpausp) #11

Please have a look here: HowTo install FOG


(James Nesbitt) #12

Thanks a million! That’s a real help!

Part of the problem I experienced was d\getting all of the software and dependancies installed to generate the undionly.kpxe config. Maybe is was the versions of different software I was using at the time…


(fpausp) #13

Maybe this is also interesting for you: BIOS and UEFI Co-Existence


(Mark Dipple) #14

I’ve just taken a look at that guide and realised that my custom settings weren’t even being applied. I followed the PXE guide initially to get a CentOS kernel running. Every change I’ve made has been ignored but I was never aware until I checked out /etc/dnsmasq.conf and found that none of my settings were present. After looking on your guide I found one crucial part missing from my setup - running expand-templates. My settings are now being applied so now I’m a little more hopeful! Thanks!


(Mark Dipple) #15

Ok, so now I have some partial success. By copying the files from a Windows 10 boot disk into the TFTP root and amending the boot files correctly (I can test this by taking a look at /etc/dnsmasq.conf and can see my changes in there) I have successfully got the Windows 10 EFI boot loader to work!

There’s also a boat load of other files that are required from the Windows disk such as the Boot folder, the EFI folder and the boot.wim from the sources folder which should also be place into a sources folder in the tftp root.

So now when booting up on standard PXE I get a pxelinux menu but when changing over to EFI mode it now boot directly into a Windows 10 setup - well almost. I now get an error message 0x0000000f Boot device inaccessible.

I believe this is caused by further files not being found by the Windows boot loader. My previous experience of Windows network booting is telling me I need a share setting up for the rest of the files to be found but I’m not sure what to share and what the share is to be named… But at least I’m not making progress!


(Mark Dipple) #16

I mean making progress. Not not.


(André Wismer) #17

@fausp

I’m using FOG Server on a Linux Container, running on ProxMox.

Works very well, and, due to Linux Containers, uses very little ressources when idle - most of the time.
I didn’t want to overload my NethServer Backups with the large image files, so I have them on a seperate VM (actually a Container), This let’s me have the images - via NFS - on my NAS, and saves me redundant Backups of huge files.

Let alone the resources saved when imaging, a both servers have different CPU capacities, even when both are running in the same virtual Host, here ProxMox.

It would also be cool to have FOG Project integrated in NethServer, but it needs options like external saving, exceptions from the backups, etc. NethServer’s duplicity based backups doesn’t handle large files very well…

My 2 Cents…
Andy


(Mark Dipple) #18

Ok, so I’ve found out a lot more about why booting up with Windows files is more painful than it should be. Most of it comes down to the file system (on Linux) taking notice of case sensitivity. The problems I was having with the BCD were sorted out by making sure the BCD was put into Boot/BCD. I originally had it in BOOT/BCD. The case really matters, if it doesn’t match what bootx64.efi is expecting, then it will fail.
I then had another problem, again with case sensitivity, in that the BCD was requesting a WIM file from \sources\boot.wim – but I had my WIM file in \Sources\Boot.wim. I had to check the path using this Windows command:

bcdedit /store

I needed to copy the BCD file onto a Windows PC or somewhere else where the command could find it.

It took me a while to figure that one out as it never specifically said that it couldn’t find the WIM file, it just failed with an error code. I originally had code 0x0000000f – boot device inaccessible and then later got 0xc0000022 – BCD unreadable or configuration corrupt (not exact but I’m going by memory here, this message will self-destruct if left on the screen, normally before you’ve had chance to search for it in a search engine). Once all that is in place I could boot an MDT Windows PE image up and proceed with a deployment. In fact, it may even work with Windows 10 setup disks, but I’ve not tried that, and I imagine it would need a lot more in the sources folder which would make the size rather large (install.wim comes to mind).

I used the guide found here http://labalec.fr/erwan/?p=791 for which files I needed, however I found that some of the files were not where they were supposed to be. Generally, if a file cannot be found where it’s supposed to be, look in the EFI folder of your Windows source. I found some of the files in EFI/Microsoft/Boot. I had to check /var/log/messages a few times too to see if the correct files were being served. If something isn’t working right then it’s usually because Microsoft developers seem to be really sloppy with case sensitivity, I had to have ‘boot.sdi’ in a folder called ‘Boot’ and ‘boot’. However, once ‘boot.wim’ has loaded it uses an MS filesystem so no further changes to the filesystem are necessary. On reflection I wish I had created a small FAT partition to host my TFTP files which have solved these problems. Is this even possible?

The file winsipolicy.p7b is required in the EFI/Microsoft/Boot folder for secure boot to work.

I host the actual deployments in a standard Nethserver share created in the web console with read-access for everyone. Once you’ve create the share you can use the MDT Workbench to create a new deployment there using the share name as the path. The resulting WinPE (obtained by ‘updating’ the deployment share) is where I get all my boot files from – bootx64.efi, BCD, boot.sdi etc. This is found in the ‘Boot’ folder of your deployment share. I had to mount the ISO file to get the files.

As for my dnsmasq.conf the config I posted earlier actually works but I’ve stripped it down to:

dhcp-match=set:bios,60,PXEClient:Arch:00000
dhcp-boot=tag:bios,pxelinux.0,192.168.2.1,192.168.2.1

dhcp-match=set:efibc,60,PXEClient:Arch:00007
dhcp-boot=tag:efibc,bootx64.efi,192.168.2.1,192.168.2.1

dhcp-match=set:efi64,60,PXEClient:Arch:00009
dhcp-boot=tag:efi64,bootx64.efi,192.168.2.1,192.168.2.1

I still don’t completely understand it, but it works. If anyone wants to do the same then don’t forget about the Nethserver templates-custom system otherwise your changes aren’t going to be seen. That was my first mistake and the reason for the NBP file messages I originally got.

So finally, I have all the services I could ever need from just one server and have saved on resources by not needing to create a VM for Windows Server which means my Microserver feels a lot more responsive (and for the most part all managed by a web interface). :blush:

One finally thought. I’ve come to realise this isn’t the most efficient way to boot Windows deployment images as it tried to do a majority of it through TFTP. This is slow. Even though the ‘boot.wim’ I use only weighs in at around 350mb it still took around 10 minutes before I was loaded into Windows PE.

Thanks everyone for your help and pointing me in the right direction!

Mark


(James Nesbitt) #19

Thanks for the brilliant work you’ve done there and for the documentation @Mark_Dipple!

I definitely know that I will be using it in the future.

I agree about this not being the most efficient way to boot a Windows deployment - but then its a fairly good method compared to forking out money for a Windows solution.