Ubuntu PXE boot fails with UEFI
-
Server
- FOG Version: 1.3.3
- OS: CentOS 7
- dnsmasq Version: 2.76
Description
I’m having some trouble setting up efi booting for my fog pxe server. When using the legacy PXE rom on the clients it works (fog loads, can load Ubuntu, debian, gparted etc from the network). This tells me the NFS, FTP and HTTP servers are setup correctly.
However, when I use the UEFI PXE client roms, it boots to the fog menu but cannot boot into ubuntu as you can see in this image:
Similar errors happen for gparted. Attempting to boot winpe brings up a 2e0008081 ipxe errorConfig and Logs
Ubuntu boot iPXE parameters:
set path /iso/ubuntu set nfs_path /var/www/html/iso/ubuntu kernel http://192.168.0.23${path}/casper/vmlinuz.efi initrd http://192.168.0.23${path}/casper/initrd.lz imgargs vmlinuz.efi root=/dev/nfs boot=casper netboot=nfs nfsroot=192.168.0.23:${nfs_path} ip=dhcp splash quiet boot
Gparted:
kernel http://${fog-ip}/iso/gparted/live/vmlinuz vmlinuz boot=live config components union=overlay username=user noswap noeject ip= vga=788 fetch=http://${fog-ip}/iso/gparted/live/filesystem.squashfs initrd http://${fog-ip}/iso/gparted/live/initrd.img boot
ltsp.conf:
# Don't function as a DNS server: port=0 # Log lots of extra information about DHCP transactions. log-dhcp # Set the root directory for files available via FTP. tftp-root=/tftpboot # The boot filename, Server name, Server Ip Address # dhcp-boot=undionly.kpxe,,192.168.0.23 # 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 dhcp-vendorclass=BIOS,PXEClient:Arch:00000 dhcp-vendorclass=UEFI32,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 dhcp-vendorclass=UEFI64,PXEClient:Arch:00009 dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.0.23 dhcp-boot=net:UEFI,snp.efi,,192.168.0.23 dhcp-boot=net:UEFI64,snp.efi,,192.168.0.23 dhcp-boot=net:BIOS,undionly.kpxe,,192.168.0.23 # 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", 1 # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86, # Intel_Lean_Client, IA32_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=X86PC, "Boot BIOS PXE", undionly.kpxe # PXEClient:Arch:00007 pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi # PXEClient:Arch:00009 pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi dhcp-range=192.168.0.23,proxy
-
There are a couple of things here .
-
dnsmasq 2.72 does not support dynamic detection of uefi systems. I know what the docs say, but functional uefi and dnsmasq wasn’t added until 2.76. Right now to get dnsmasq 2.76 you need to compile it your self . https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support
-
You have this line in your configuration
set nfs_path /var/www/html/iso/ubuntu
The problem is you are defining an nfs path to something that can only be referenced by http. If you want to connect to the fog server via nfs, you need to place the files in the nfs share (or /images) or a subdirectory of the root share.
Your error (kernel panic) basically says the ubuntu kernel can’t find the root fs (because its being referenced by a nfs location)
-
-
Agreed as i was taught by @george1421 inclusive to this i suggest you read my beginning struggles and later success with trying to achieve uefi ubuntu boot here
-
@george1421
My bad, I had already compiled 2.76 from source as you mentioned in one of your posts and I just miss-typed it in my post. Also, i’m pretty sure my lstp.conf is copied directly from one of your posts.$ dnsmasq -v Dnsmasq version 2.76 Copyright (c) 2000-2016 Simon Kelley Compile time options: IPv6 GNU-getopt DBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify
As for the NFS share, it booted correctly in legacy mode, so it should work when using EFI, correct? I have mounted the directory on the server with: mount -t nfs 192.168.0.23:/var/www/html/iso test Here is my /etc/exports:
/var/www/html/iso 192.168.0.0/24(rw,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,crossmnt,fsid=0) /var/www/html/iso/ubuntu 192.168.0.0/24(rw,bind=/var/www/html/iso/ubuntu,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,crossmnt,nohide,fsid=0) /var/www/html/iso/gparted 192.168.0.0/24(rw,bind=/var/www/html/iso/gparted,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,crossmnt,nohide,fsid=0)
I can also fetch all the files via http, for ex, with: http://192.168.0.23/iso/ubuntu/casper/vmlinuz.efi from my browser
-
@saablord I’m not sure how you are mounting with that command unless you are sharing out your root path. This may still be a uefi issue, but what does the output of this command run on the console of your fog server:
showmount -e 127.0.0.1
This will show you the mountable nfs shares on your fog server.
<edit> Sorry I missed your exports in the post before. I was trying to post in the forum via my tablet and its, lets say a bit of a challenge. I would look over @dureal99d thread he posted he did have some success.
-
@george1421 No problem, I edited that in afterwards as I thought you might want to see that. hah.
Thanks for the help and quick responses. I’ll see what else I can dig up.
-
Ahhh thank you for that link. I’ve been looking through so much this weekend that I don’t even know where I have and haven’t been.
-
Well, I figured it out. There was only one difference between my parameters and @dureal99d’s Apparently having initrd=initrd.lz in the imgargs line is vital for UEFI booting, but legacy has no problems with out it.
kernel http://${fog-ip}/iso/ubuntu/casper/vmlinuz.efi initrd http://${fog-ip}/iso/ubuntu/casper/initrd.lz imgargs vmlinuz.efi initrd=initrd.lz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/var/www/html/iso/ubuntu locale=en_US.UTF-8 keyboard-configuration/layoutcode=la mirror/country=US boot
Ill just plop this in here so next time someone searches for not syncing: VFS: unable to mount root fs on unknown-block(0,255) they actually find something
-
@saablord no problem