McAfee Drive Encryption not booting into OS after PXE booting to FOG splash screen

[THEMCV]

Debian 8
FOG 1.3.0 RC-23

My process: WebUI > Deploy to FOG client > FOG Client reboots into PXE > PXE Images > FOG deploys drivers > Sysprep applies unattend > Windows Boots to login > FOG Client starts from Unattend file > Client Reboots to rename > Reboots and installs all programs > User Logs In > Encryption starts > Done.

That should be it.

Here’s the problem. After the user (me in the situation) logs in, reboots, and gets past the FOG menu and goes to the McAfee Drive Encryption login, it won’t boot. It does its

Resetting Hardware...
Disabling Mouse...
Disabling Mouse...
Starting Operating System...

Then it hangs, but only if it PXE boots into FOG before hand.

I have no clue where the error lies because clearly FOG has already passed the torch to McAfee, but if I disable PXE booting it works just fine.

Such a weird issue and I’m hoping somebody has had it before.

I can answer any questions that you may have for me.

Thank you

[Wayne Workman]

Try different exit types is the only thing I could suggest.

[Quazz]

What do you use for boot? (undionly.kpxe for eg)

[THEMCV]

@Wayne-Workman I gave that a shot, but no dice on any of them.

I think it might have something to do with McAfee and PXE booting specifically. I switched to AHCI mode and reimaged and now it just BSODs.

1 step forward each day for the month, 100 steps back.

If we didn’t encrypt, this would be a nonissue.

[THEMCV]

@Quazz undionly.kpxe is our default boot. We tried it again with ipxe.efi as well and in UEFI mode with no good results.

[Wayne Workman]

@THEMCV Well, until you can figure this out (if at all), you’ll need to set the boot priority of these systems to HDD first.

Try what @quazz said first though.

[Quazz]

@THEMCV You can’t just randomly switch the BIOS setting for SATA mode, you need to alter registry values (before changing the value) or do a clean install (after changing the value)

Can you try ipxe.pxe ?

[THEMCV]

@Quazz If it’s an agnostic image, shouldn’t it not matter? It’s a VMWare image deployed, so after editing the settings and reimaging it it should still boot correctly, right?

I disabled the encryption and it’s seeming to boot fine.

Yeah, I can try that. Is that UEFI or Legacy?

[Quazz]

@THEMCV Did you sysrep /generalize ? If not, then it will basically use the VMWare drivers which won’t work.

ipxe.pxe is legacy (all UEFI are .efi afaik)

[THEMCV]

@Wayne-Workman I’m only testing right now to convert all the computers to PXE booting, so the only ones set for it first are in my office.

I’ll try changing it over to that. We disabled the encryption and so far it’s good. Sending the encryption command again and giving it a test.

[THEMCV]

@Quazz Yes, it syspreps and pulls drivers down from the FOG server.

I’ll switch that over after this test. The hunt is on.

Thanks!

[THEMCV]

So what I’ve gathered and tested so far:

The issue lies in-between when FOG ends in PXE boot and when McAfee takes over.

I rebooted my computer which has never been imaged by FOG and it got stuck “Starting Operating System” with undionly.kpxe.

Switching to ipxe.pxe allowed me to authenticate into McAfee, but Windows BSODs directly after w/PXE boot enable goes to a black screen and does not bring up McAfee

Disabling PXE boot allowed me to boot up Windows.

Honestly, this has to be a McAfee issue or a passing issue

[george1421]

@THEMCV TBH I only read the initial and past 2 posts, so this may be off point.

Let me also say I don’t have an answer here, only an understanding of how FDE works.

These FDE software will typically rewrite the boot sector on the disk to point to their preboot environment (which typically is linux based). If iPXE doesn’t exit right to load the boot sector properly the FDE preboot environment will not load and access will be blocked to the system.

Since (probably) sanboot, and maybe grub has been tried, you might want to check to see if refind will work to load the proper boot sector to launch the preboot environment. To that end you may have to adjust the refind.conf file to do what you need it to.

In the end you need iPXE to exit correctly to the boot sector of the boot drive, otherwise no joy for you.

And the last comment is, if you don’t need unattended imaging you do not need to have PXE booting setup as the first boot device on the client. You can always press F12 (or F10) when booting and then select the network as a boot device. This is how we do in at my work. We absolutely do not allow unattended imaging. This came about after a tech accidentally selected the wrong system to stage and he wiped out a HR person’s computer and files she should not have been storing on the desktop.

[THEMCV]

@george1421 What I don’t understand is why it’s so hit and miss. Right now the laptops are booting just fine without any issue, but just an hour ago I couldn’t get past it. It seems like it should be straightforward if it’ll work or not.

But I think I have a better understanding now.

And interesting. I can see how that’d pose a threat for sure. That must have been an interesting one to recover from.

Worst case scenario, we ignore PXE boot. I just love the idea of being able to automate the process entirely.

[george1421]

@THEMCV Yeah we had some butt kissing to do to make up for that, mainly my lips since I am accountable for IT. Our system names are very similar since they are based on the Dell asset tag plus a prefix and if you know Dell asset tags the last 4 digits are the lot number so if you buy a number at one time they will typically have the same lot number. One letter off made all the difference between hero and zero.

[THEMCV]

@george1421 Yeah, our names have one letter in front of the SN. Easy to get them mixed up.

Maybe it’s best to call it a day on it and just accept that I’ve got a good imaging solution limited by third party software.

Next job I’ll get it perfect.