For anyone else coming across this thread, we had the same problem. The iPXE from the latest version of FOG (1.5.9) did not work, but building the latest iPXE binaries using the instructions on this post worked fine:

https://forums.fogproject.org/post/141618

After that, the Linux kernel we were using also worked fine.

For anyone else coming across this thread, we had the same problem. The iPXE from the latest version of FOG (1.5.9) did not work, but building the latest iPXE binaries using the instructions on this post worked fine:

https://forums.fogproject.org/post/141618

After that, the Linux kernel we were using also worked fine.

We noticed the same thing, looks like in the “specialize” phase Windows setup adds itself as the first entry. I didn’t see any option in the unattend.xml file to disable or alter this, and we didn’t want to use a Dell utility since we have other hardware, so we put this in the custom script we have running at the end of the “specialize” phase:

bcdedit /set {fwbootmgr} displayorder {bootmgr} /addlast

This moves the active Windows boot manager (which was just added and is referenced by {bootmgr}) to the end of the list. The {fwbootmgr} apparently references the system UEFI firmware. If you have more boot options you want in a specific order, you might be better off trying to move the PXE boot option to the top. Also, since you mentioned Bitlocker, I’ve seen posts indicating that you need to have the Windows Boot Manager first if you’re using Bitlocker, so you might not be able to do this anyway.

Since Windows setup will just keep adding more boot managers to the UEFI list every time you image (when it goes through setup), we also added this block to our script to remove old entries:

for /F "tokens=2 delims={}" %%i in ('bcdedit.exe /enum {fwbootmgr}') do (
    if "%%i" NEQ "fwbootmgr" (
        if "%%i" NEQ "bootmgr" (
            echo Checking %%i for old Windows boot manager...
            bcdedit.exe /enum {%%i} | find /C "Windows Boot Manager" >nul
            if errorlevel 1 (
                echo Not old Windows UEFI boot manager.
                bcdedit.exe /enum {%%i} | find "description"
            ) else (
                echo Found Windows UEFI boot manager from previous installation, removing...
                bcdedit.exe /enum {%%i}
                bcdedit.exe /delete {%%i}
            )
        )
    )
)

This will enumerate the UEFI boot list for Windows boot managers excluding the active one, and remove them, so you don’t keep adding an entry every time you image the computer. I would recommend testing this first if you’re going to use it, I have only tested it a couple times

Tom,

Any chance you could elaborate on what the issue is that you found? We’re still on a customized FOG 0.32, and while we will probably upgrade at some point, it’s going to take us a while. I was going to see if I could apply whatever you changed to our older version to see if we can image some of these Yoga tablets.

Like stark325, if we add “iface eth0 inet dhcp” to /etc/networking/interfaces and then run “ifup eth0” it works (in debug mode), but if nothing else I’ll have to try and modify the imaging or boot script to check for Yoga models and do this.

Thanks!

[quote=“andyroo54, post: 24543, member: 267”]Check out the guide I made here:

[url]http://fogproject.org/forum/threads/windows-7-deployment-fog-sad2-driver-tool.380/[/url][/quote]

Thanks Andy, that is a great guide. I guess the question I had was similar to reply #53 on that guide: [url]http://fogproject.org/forum/threads/windows-7-deployment-fog-sad2-driver-tool.380/page-3#post-3147[/url]

You replied (to him):

[QUOTE]You don’t need driver packs, windows 7 will install basically all essential drivers for pretty much an PC living or dead. I use driver packs after install, because occasionally windows 7 may not install a mass storage, or a wifi driver for example. Using driver packs after the OS is installed solves that problem. [/QUOTE]

I was thinking that you needed the critical drivers (at least the mass storage controller) before the SAD tool is run, or it wouldn’t even be able to boot, execute the SAD script, and install the remaining drivers. If Windows doesn’t recognize some new mass storage controller hardware ID, how will it even get to the OOBE stage? I’m still not 100% clear on that, can you just have ALL drivers including the critical ones installed in the OOBE stage?

Also, what I’m looking into doing is something like Doug posted above, having a directory that you can keep all your drivers in, and then having FOG (after deploying image) or Sysprep (during setup) copy the drivers from the network, and then run SAD / DPInst. That way I could add drivers for a new model to the network share and not have to update & re-create the image.

Thanks!

I know this thread is old, but wondering if anyone else has had success with this?

Doug, your method sounds like it would work great, but I’m wondering if that would work with critical drivers such as storage and network? Or do you need to have the storage and network drivers in the image already, and install the rest of the drivers using that method? It seems like since that oobeSystem pass is the last pass, it would need the storage and network drivers by that point.

Thanks,
Nate