Need Tutorial for Making this Work with UEFI
Good morning, all.
So, here’s the situation:
I know that UEFI currently does not work. I know there are workarounds. I’ve seen stuff using boot disks, CloneZilla, etc, etc…however—this stuff is old (Pre-1.0.0), so a lot of it doesn’t work when trying it out.
Does anyone have a workaround for UEFI that will work without having to use legacy boot?
We are getting a bunch of Dell E5540’s in this week which will be Windows 8.1 with UEFI. Since these will be going to mobile users, we need to be able to image them quickly. We would like to keep the UEFI if at all possible.
You can keep UEFI, just you’ll need to know a few steps.
Each system, for an imaging task, needs secure boot disabled for the imaging time frame for both upload and download. I don’t have the time right now to test UEFI pxe booting in a pure sense but this IS supported. We just don’t have access to the menu structures or anything yet. This isn’t something I can implement and am just waiting for this functionality in ipxe.
That all said, you CAN uefi PXE boot by forcing the task to point at the bzImage file as well as the init.xz with args as needed. This method should work, but it will ONLY ever boot to this, there’s no by passing, so either way it’s still a bit of work.
However, Legacy mode booting should still work, if you can deal with these steps.
Disable Secureboot (not uefi) and enable legacy pxe booting.
Boot up system and register as we’re all used to.
Create your image definition and upload image to system.
On the next reboot, don’t make PXE boot your primary thing and re-enable secure boot. All should work.
All of those steps should be the same for downloading image to the client as well.
Alright, I prepped the image and stuff, turned off Secure Boot, PXE booted with legacy. However, now i’m having that issue that some others have been happening where it gets an IP address, and then gets an error which flashes too quickly to see before it reboots.
I know these 5540’s have been problematic devices, however I did have the thing booting and loading the fog image at one point. (It was previous to installing 1.1.0) Is there any changes in 1.1.0 that could be causing this issue?
Are you running 1.1.0 or 1.0.1?
[quote=“Tom Elliott, post: 28909, member: 7271”]Are you running 1.1.0 or 1.0.1?[/quote]
I’ve fought and fought with UEFI, and until there is full support for it, I’m just going back to Legacy, and I would suggest you do as well. It is much easier to adapt the OS to use legacy boot than it is to support UEFI on a network boot, let alone if you have a mixed environment.
Need, the problem is that I am currently booting in Legacy, and it is still doing it. I’m going to try to get some video of the problem.
Here we go. Here’s video of what I’m seeing.
So the good news. Your system is booting, and it is booting to to iPXE.
Now the bad news. It looks like it’s the extremely long dhcp time causing your issue. Once it fails, it is set to reboot the system as you’re on 1.1.0. This, as far as I can tell, is your network now returning, or the system to receiving the DHCP address.
So is there a solution you can think of for this? I could make the Fog server a DHCP server, but I don’t want to complicate things with the other DHCP servers on the network.
Are you having DHCP issues on your network?
There you will find a Rogue DHCP Detector. Run this and check the time(ms) it takes to get an ip. I would hope that it is under 300ms. If over 300ms then your looking at an issue with your DHCP server. If under that in windows there may be an issue with your network switches passing the DCHP under pxe situations. Such as STP or portfast settings may need to be changed.
Welp… I do have some DHCP issues, it appears. One of my DC’s is showing as both authorized and “rogue.” I’m going to have to figure out what’s going on there. We had set this up at one point to be a DHCP server for a VLAN that would be for virtual servers, which never came to fruition. I’m wondering if something from that is mucking things up somewhere.
Alright, so here’s the story:
We had that rogue DHCP server. It was our secondary DC, which was VLAN-d to a network that no one else could access anyway, so it really wasn’t causing problems. I disconnected the NIC, anyway.
I was just ignoring the comments about portfast, because myself and the other network engineer were under the impression it was already enabled on our switches. Ignorance will be the death of all IT.
Portfast was NOT enabled. We spent about an hour discussing WHY Cisco would not enable this by default, since the default setting will ignore any port that is in switchport-access trunk mode to begin with.
Whatever. That puppy grabbed a DHCP reservation right away, and brought the Fog Menu up less than 5 seconds later.
It’s now imaging, and hopefully we will have it all done testing, etc…by the time our new laptops get here so we can just image and deploy.
Thanks, all! You’re great!
Alright, Tom—I followed your instructions:
(This is for a test machine—so I’m uploading the image with one drive, removing it, and downloading the image with a clean drive on the same machine.)
-I disabled SecureBoot, leaving UEFI alone.
-Uploaded the image
-Swapped the hard drive.
-Downloaded the image.
I get the “Windows needs to be repaired” screen, with error 0xC0000225.
“A required file is missing or contains errors.”
It points to the \windows\system32\winload.efi file.
Got it to work after researching things you’ve placed in the forums and what not. Here is the run down:
- Disable Secure Boot
- Enable the Legacy Boot Option (You may have an option in Advanced Boot Options to Enable Legacy ROMS. You want to check this, as well to allow the legacy PXE to appear)
- Restart and register the machine in Fog.
- Create the upload task in the Web GUI.
- Restart and upload your image.
- On the machines to be imaged, repeat steps 1-3.
- Create the download task in the Web GUI, if you aren’t using Capone.
- Restart the machines and download the image.
- Re-enable Secure Boot. (You will probably have to disable legacy boot option and legacy ROMS in order to do this.)
- Reboot, BAM! It’s been FOGGED!
Thank you for the detail.
I’ll see if I can get this into a WIKI article for the time being as well so other’s have a starting point.
This is great. Thanks for reporting your results.