Cart/Horse problem. Injecting drivers as boot critical.


  1. Posts : 5
    Debian
       #1

    Cart/Horse problem. Injecting drivers as boot critical.


    Windows 10 Version 1909. Latest Public ADK a/o this post date.

    In addition to the standard method of using dism to inject drivers to sysprep'd image, how does one 'promote' that driver to early boot or what MS used to call boot critical?

    This for an iscsi project where I am attempting to patch and boot a sysprep'd image on unfamiliar hardware as an iscsi target. When I first boot a machine it loads generic ipxe driver stack to push winpe into ram (pixe/wimboot can inject drivers). Simultaneously the target iscsi image is available for dism edits by the winpe. I can in push network drivers to the iscsi mounted image but I don't understand how to promote them to early boot process.

    Please feel free to correct terminology and dump lots of tech references with hyperlinks to MS training material. I am not asking for someone to do the work, I'm asking where to learn how to fix this.

    --Below is just back story, it gets a bit rambly--

    Before you say it's not possible, it is already possible in a round about ineffiecent way.

    Presently I can boot a machine diskless to ipxe, load winpe, mount smb share, load windows 1909(if the winpe driver network driver patch worked). The problem here is the server is loading data from the server back to the server. So 16GB uniqe vhds per client machine. I get diskless clients but at an unoptimized storage cost.

    If I can get this to work with sysprep'd vhd's as the base for my snapshots, I can save a ton of data. Each diskless client's vhd will only be the computer specific drivers etc existing as a differencing snapshot of the original.

    Gotchas:
    using ipxe with the wimboot module alllows me to dynamically alter the winpe on the fly. Scripts, drivers, it's awesome.
    My dhcp server runs a script that per new client for this network it makes a new vhd, maps new vhd to iscsi iqn based on mac of client machine. The drive images are thin-provisioned so if they don't get used they take little space. However this system will run out of IQNs at 256 clients. Not that this server wouldn't implode from that kind of load, more like a reminder to clean out the fridge of old IQN targets and 1mb disk images never used. But this is assuming network isolation from production etc.
      My Computer

  2. hsehestedt's Avatar
    Posts : 2,431
    Windows 11 Pro, 21H2
       #2

    This is a really interesting question.

    I think that all that is really necessasry is to add the boot-critical drivers to the WinPE image (boot.wim) in addition to the main install.wim. By placing them in the WinPE image, they would be "promoted" or used when WinPE is loaded.

    It would probably also be a good idea to inject the boot-critical driver(s) into the Recovery Environment (WinRE.wim).

    So, I know how to inject Windows updates into the Windows PE image and the Recovory Environment. I do this all the time. In fact, I wrote a program to automate this whole process for myself. Oddly, none of my systems require any boot-critical drivers to be added so I never thought to do that.

    The problem for me is that since I don't have a machine that needs any boot-critical drivers to be added, this may be a little bit difficult to test, but I'm guessing it would be no different than updating the install.wim.

    I'm hoping that someone else can respond with a definitive answer to this, but in the meantime I'm going to see if I can devise some testing.

    Can you tell me how critical this issue is? It may take me a day or two to work through this but if it's an urgent issue I can try to work faster .

    If you update the WinPE image yourself, please let me know if that works for you.
      My Computers


  3. Posts : 5
    Debian
    Thread Starter
       #3

    Hello and thanks for the interest.

    Not production so zero priority. This is a pet project I've worked on for a while. Way back when I was a helpdesk technician, I was often stuck waiting on replacement parts, especially hard drives. I always wondered if a standard desktop could boot off a remotely served iscsi image so the software work could proceede while the system was still diskless. This is a time effenciency hack, as once the physical medium arrives the image process from such a source is already perfectly confgured for the system it's applied to.

    Where can I find good how-to's for debugging bootmgr.efi and winload.exe process?
    Can anyone reccommend a good tool for differenceing two different registries? Preferably one that can ignore all the random generated guid content?

    One clarification, what I have working is booting to a winpe with injected drivers and doing the normal setup with a custom install.wim. That works because the setup process can determine the target is iscsi and configure correctly network drivers and settings. But setup copies the entire install.wim back to the iscsi target. So it's kind of like a network loopback between the installation source and the iscsi target server. Not effiecient at all. But I have this working now.

    I would like the iscsi target to contain a sysprep'd image. The first time a new piece of hardware boots, a pre driver injected winpe will 'patch' the iscsi mounted image with the necessary drivers and settings to allow the sysprep'd image to load by itself on second boot. That way I can snapshot the primary iscsi image and each diskless client will be a difference only snapshot.

    Part of my research for the necessary function

    So far I'm donig this:
    machine has first booted to ipxe and hooked the iscsi target that is a snapshot of a sysprep'd image.
    drvload /x:\windows\custom <--this dir injected to winpe by the ipxe wimboot module.
    winpe can now see network card.
    dism /image:c:\ /add-driver x:\windows\custom /recursive
    drivers now injected to sysprep'd iscsi target.
    Gather network card information
    wmic nic get guid,name,servicename
    This rather undocumented function of dism.
    dism.exe /Image:C:\ /Add-NetAdapter /HostAdapter:{76A614E4-1167-4C66-89B9-2A76C663C547} /BootDriver:ms_tcpip /BootDriver:ms_tcpip6
    Which is part of how setup.exe invokes dism to add the net adapter as a boot device during normal install when iscsi is detected.
    regedit and load hive of iscsi target fo disable pagefile.sys <-- necessary for iscsi function.
    --this part obsolete - or I'm reading it wrong, please comment.
    regedit system hklocalmachine currentcontrolset services, find service name of network service (earlier wmic command) and change start type to zero. (used to be boot critical - again I could be mistaken here.)

    Now for theory and dirty tricks.
    It's a convoluted method but perhaps I could run an empty or nearly empty install.wim through setup.exe to a fresh iscsi target. Then merge the regeistry hives but that sounds like complicated patching. But I need to see what the setup process is doing to make the image iscsi bootable. Setup must be building the early load process framework and just copying the wim file on top of that and merging the regestries, I'm just trying to learn how to do that manually.
      My Computer

  4. hsehestedt's Avatar
    Posts : 2,431
    Windows 11 Pro, 21H2
       #4

    Moriarty, first, I should apologize for failing to welcome you to TenForums in my first response .

    I have to admit that you are doing a few things that are a bit beyond me - at the very least I would need to do some pretty extensive testing to ever get up to the point where you are now. However, there is one user, @Kari, who I suspect might possibly be very interested in what you are doing here. I'm going to ping Kari to see if he might have any insights into this.

    I have to admit that I'm keenly interested in what you are dong here as well, there are just pieces of this where my expertise is distinctly lacking.

    Bear with me, and let's see what we can come up with.
      My Computers


  5. Posts : 5
    Debian
    Thread Starter
       #5

    Thanks for the welcome @hsehestedt,

    After standard setup.exe installs to ipxe target, the winre partition is completly blank for the first post-setup boot, I'm thinking that gets written on next boot, so that means while nice to have, it's not critical to the base issue. Then again, a working winre might give me inspiration to the registry/driver problem. I could use a resource on how winre is built and how to define what drivers go into winre.

    It looks to me like the guid entery points for the nic in hklm are always different. Does this mean they entered by some sort of seed and sign mechanism?

    If so the wmic nic get guid command may be returning guid valid only to the winpe. There is a scratchdir option for dism /add-netadapter that I haven't fully explored. I assumed the scratch dir for windows would be lost after sysprep. perhaps I could save the initial one for the baseline sysprep image and import to iscsi session to provide the guid seed to match the proper instance.

    Also noticed the partition tables for the local vs iscsi install are different sizes. Thats odd. I don't suppose there are extremly verbose setup options undocummented somwhere?
      My Computer


  6. Posts : 1
    Server 2019
       #6

    I've been doing something similar but driven through an SCCM task sequence. Might be missing BCDBOOT?
    -BCDBoot runs to make the Applied OS bootable

    Setup Windows and Configuration Manager
      My Computer



 

  Related Discussions
Our Sites
Site Links
About Us
Windows 10 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 10" and related materials are trademarks of Microsoft Corp.

Designer Media Ltd
All times are GMT -5. The time now is 21:57.
Find Us




Windows 10 Forums