UEFI/Secure Boot fixes abound, but is there a Solution?
-
You might try DHCP policies/classes to hand out either a .kkpxe file or a .efi file determined by what the machine reports itself as to DHCP…
There was a thread I made on it, others have made threads too. But I can’t find anything on the forums at the moment… the search doesn’t work well for me.
I recommend what Tom says though, for simplicity.
-
I haven’t played around with RAW much, but I’m assuming that there’s no compression algorithm for this. So do I need to make room for the entirity of the 500GB hard drive installed in this system?
-
The network boot requirements really depend on whether you are running a Linux network environment or a Windows network environment. If you have a Windows network environment, you have to have a 2012R2 DHCP.
-
@Deastrom said:
I haven’t played around with RAW much, but I’m assuming that there’s no compression algorithm for this. So do I need to make room for the entirity of the 500GB hard drive installed in this system?
Compression applies to every image type, even RAW. I hear that free space compresses rather well.
-
I will give RAW a shot after we get through our current attempt (This system is running windows 7 so we’re installing the os with all of that UEFI stuff shut off and trying the upload/download without ever turning uefi/secure on). If RAW works with all of that stuff turned on, then, in theory, we’ll be able to support Windows 8 and Windows 10 (which requires UEFI) using RAW images, correct?
-
Windows 8/8.1/10 do not require UEFI/Secure Boot. They just strongly suggest it. Installed all three on systems incapable of UEFI and they worked fine.
That being said, finding new systems without their OS installed in UEFI mode is near impossible, so it is still a good thing to work out.
-
The question I’ll get in response to this when I go to pitch FOG as our DRS will be; is native UEFI/Secure boot going to be supported (not RAW) in the future? What version when?
I realize this is an opensource software, but this is working great as a DRS so far and is fairly simple to operate, so I’d like to present this solution with the strongest arguments possible.
-
Given some unforeseen circumstance, I really doubt Secure Boot will ever be supported. UEFI support technically exists, it just requires customization for each network.
I was working on UEFI boot for a while before other projects came up. The result I came up against was that you either need to have a Linux DHCP or a Windows Server 2012R2 with DHCP present on the network. You could then configure the DHCP to serve different boot file names depending on detected architecture.
If nobody else does the documentation for the Windows Server configuration before I complete my current projects, I will put it into the Wiki.
-
If you’re doing Disaster recovery, what is wrong with RAW?
FOG is not designed to be a DRS at all. Sure, it can work, but the fact that you’re doing FOG as a DRS and have heads and heels more information in doing it than other sources (I’m guessing?) means that just presenting it as that is a huge push towards it.
We are still trying to come up with a system that natively supports UEFI, but the systems we have do not natively (even EFI booted or not) support Secure Boot remaining enabled. The only way, that I know, of maintaining Secure Boot is to do as I described.
FOG Already can boot UEFI/EFI without much problem. What we’re working on is trying to get a native legacy/uefi detection and booting. Even if this worked, right now, you’d still have to disable secure boot to allow the image to take properly, unless you RAW copy.
-
Thank you all so much for your responses. They were both timely and very helpful. I am very close to implementation of this system (only have a OS/2 Warp on HPFS hurdle to jump) and I’ll be ready to pitch the idea to the server team. I’ll be active in the forums on my findings going down this road (contribute) in an effort to pay you all back for you help.
