14 replies to this topic

[videoguy]

Hi

I am wondering if there is a creative solution to a problem I am trying to solve. I have a Win10 RE based bootable USB stick that can boot couple of Lenovo laptops fine. I have figured out a way to get wifi networking work on this stick. I managed it by injecting all necessary drivers needed by these laptops pre-injected offline in the boot.wim.

Now I am trying to create this stick for 10 other laptop models. Dell and Hp. I have driver packages for each model.

 

I don't want to pre-inject drivers into the wim. I like to maintain a common boot.wim and a separate folder with model specific drivers. Then when boot.wim becomes a ramdisk during bootup, somehow make the driver folder visible inside the ramdisk (i.e x:\ drive). Then I have a batch file that knows how to load necessary drivers on the fly.

 

My question is if there is a way to make a folder outside of boot.wim but available on the usb stick become available inside the ramdisk.

 

I am aware of enumerating available drives in .bat file and look for drivers. That is not an option that works for the scenario I am trying to solve. For the sake brevity, I am not including all those details in this post.

 

To solve this issue, I started looking at various options. I find that boot.sdi is a mechanism that ramdisk driver uses to create the ramdisk. I also found that boot.sdi is a hollow container that fakes ntfs file system with links to boot.wim. When the boot loader efi application loads the .sdi file, it knows how to get to boot.wim and make it whole. I am wondering if there is a way to create boot.sdi that points to the wim as well as my folder.

 

I appreciate any pointers.

 

Thanks

 

 

 

Edited by videoguy, 11 October 2017 - 05:05 PM.

[Wonko the Sane]

If I get correctly what you are asking, you actually don't need anything "fancy" or particularly "creative".

 

The boot.sdi is actually a "fake" NTFS filesystem that is actually used as a "mountpoint".

 

You need to check a bit of literature on the NTFS filesystem, and on symlinks and mountpoints to get familiar with the matter, but basically once you have a NTFS mounted drive (more properly a volume i.e. *whatever* gets a drive letter) , you can mount another (drive or, better, volume) image "inside" it as a folder (as opposed to a "drive letter").

 

This is what more or less how the boot.sdi is used in the PE booting mechanism 

 

So typically you would integrate in the .wim a driver (like IMDISK as an example) and use it to mount an image of a volume (a superfloppy) to a folder on your main drive.

 

But, even without such a driver, you can have a folder on the "container" (the USB stick where the boot.sdi and boot.wim reside) and plainly make a symlink (or junction) to it. 

 

Here is a good start:

https://docs.microso...nloads/junction

 

Wonko

[videoguy]

I looked for tools to mount .sdi. All I can find is OSFMount. When I mounted sdi, I see a drive show up under explorer. But it says "Please insert .." when I click on it. It is like clicking on CD drive when there is no CD inserted in it.

 

I don't know how this .sdi knows how to mount .wim file and ramdisk see the .wim file contents during bootup.

 

The NTFS junction or symbolic stuff work when you have a real mounted NTFS partition and you are creating those symlinks from the NTFS to another drive or folder. I don't know how to connect your suggestion to .sdi file.

 

Thanks

[steve6375]

Could you explain why you don't want to just use the drivers directly from the USB stick?

 

If the drivers are in a folder on the USB stick, why do you want them as a ramdisk drive?

 

P.S. I found that it is difficult to add similar drivers to WinPE as often they have the same filenames for different versions.

So you cannot just add 'all' drivers. I worked around this issue by only loading the correct driver like this:

https://sites.google...scripts/drvload

[Wonko the Sane]

I looked for tools to mount .sdi. All I can find is OSFMount. When I mounted sdi, I see a drive show up under explorer. But it says "Please insert .." when I click on it. It is like clicking on CD drive when there is no CD inserted in it.

 

I don't know how this .sdi knows how to mount .wim file and ramdisk see the .wim file contents during bootup.

 

The NTFS junction or symbolic stuff work when you have a real mounted NTFS partition and you are creating those symlinks from the NTFS to another drive or folder. I don't know how to connect your suggestion to .sdi file.

 

Thanks

You don't need to "mount" the .sdi.

 

In any case the boot.sdi is nothing but a  "superfloppy" image of an empty NTFS filesystem with a header prepended, the header is 8192 bytes in size, you can use the offset in Imdisk (and I presume also in OFSmount which is derived from Imdisk) to mount it.

 

As a matter of fact you don't even want to know that a .sdi exist at all.

If you want to understand what the .sdi is you can check this (and  also optionally use a "smaller" .sdi), see:

http://www.msfn.org/...ize-of-bootsdi/

 

But this has nothing to do with what I suggested.

 

The "final effect" of a PE booting is to have a NTFS filesystem mounted as drive letter X: (the fact that this is obtained by going through boot.sdi and boot.wim is "irrelevant").

 

Once booted you should be able to:

1) mount a disk image with another ramdisk or filesdisk program and - instead of assigning it another drive letter use a directory in X: as a mountpoint for it

or:

2) use a directory in X: and make a junction to a folder on the USB stick

 

But  as Steve6375 stated the reason why you cannot have "plain" directories on the stick and access them "normally" it is not entirely clear.

 

Wonko

[videoguy]

Thanks guys for those links. I am learning something new.
I didn't quite describe the problem right. To simplify the problem, I used a USB stick as an example. But it is not USB stick that is holding the content.

I have an EFI application that gets launched during boot up. This application goes and downloads boot.wim,boot.sdi, boot manager efi files, drivers and what not into a ram disk that the EFI app created. Then the efi app launches downloaded boot loader. The boot loader goes on as if it is booting from USB stick. But the content is actually coming from the ramdisk created by my efi app. Once WinPE comes alive, all it can see is the content from boot.wim. The ram disk that was created by my EFI is not visible once MS boot loader takes control. I want to get to the drivers folder that is sitting in the first ram disk.

What I am wondering is if there is any way to put symlinks (or other means) inside boot.sdi so that it drivers folder become visible along with boot.wim content.

I used OSFMount option to mount the .sdi skipping 8192 bytes in the front. Now I see it as a drive in Explorer. It is an empty volume though. I don't see any symlinks to boot.wim.

Edited by videoguy, 12 October 2017 - 05:38 PM.

[Wonko the Sane]

Sure the filesystem is empty with no symlinks, it is the booting mechanism that uses the .sdi as "root" filesystem/mountpoint and makes it on-the-fly.

 

Now that you have shifted the question to the actual situation (which is VERY different from what you initially described), the given suggestion does not apply.

 

You can still - maybe - but that is impossible to know without knowing the verys specific EXACT DETAILS of the WHATEVER EFI tool you use AND the WHOLE booting sequence AND mechanism, map "post-boot" (through another ramdisk such as IMdisk or similar , possibly using awelloc or devio? ) a memory range (provided that the data copied there is still there), and then create the symlink.

 

It would make much more sense to "download" the additional image (or *whatever*) post-boot and then map it "normally".

 

But no way to know or to give you any meaningful hint without the specifics.

 

Wonko

[videoguy]

Trying to do this post boot downloading drivers was looked at. Its a chicken or egg first issue we run into. The driver we want to inject into WinRE is network driver. I am not aware of getting network stack in WinRE work without injecting a network driver. If that is possible, this would be easier to solve.

The efi app we are working on is similar to iPXE (http://ipxe.org/start) . The efi app builds ram drive of 600MB first. It downloads content from a web server and builds a folder structure similar to folder structure in USB stick. Then the app launches the bootx64.efi and let that build the x:\ drive. We had already tried the approach you are suggesting where the app instructs EFI runtime mark the first ram drive reserved and get to it from WinRE after it boots up using a windows ramdisk driver. That was unstable. So I am looking for a way to manipulate the .sdi so that the functionality builtin MS boot manager will make this folder (the driver folder that was downloaded separate from .wim) visible in WinRE after it boots up.

Edited by videoguy, 13 October 2017 - 02:25 PM.

[Wonko the Sane]

Yep, stiil -  as said - what you can do in your app is to load a disk or partition image to a given extent of RAM, then find a ramdisk capable of "hooking" that extent and either map it to a new drive letter or link to it as mountpoint or symlink.

 

Cannot say if Imdisk can do the specific memory extent mapping like that or if any other free ramdisk driver can, though, your "unstable" situation may come from the specific (unknown) ramdisk you used, or by a zillion other reasons.

 

Maybe useful, maybe not, according to Gavotte's (scarce) documentation, it is not possible to have a mountpoint/symlink to a "ramdisk" so the driver needs to expose as a fixed disk or floppy (or superfloppy).

 

Alternatively, but again it depends on how the whatever EFI tool/download/etc. works, it is not like the doctor ordered to do a bootsdi+boot.wim boot, you could use a "flat" boot instead making use of a ramdisk such as Firadisk or Winvblock.

 

Wonko   

[videoguy]

Flat boot is not an option as we are not aware of reliable tools in efi space to expand .wim files. Downloading thousands of flat files from remote web server is not viable either.

[steve6375]

One option we used in our factory was to use cheap USB WiFi dongles which we just plugged into each system (or a USB Ethernet dongle if you have Ethernet available and need faster I/O). That way you just need one driver in your WIM for the WiFi dongle and the rest is easy.

No need to continually try to find and add new WiFi drivers as new models come out, etc.

 

Another thought: Could your software detect the PCI ID of any WiFi adapter and download a different wim file. You could have several different WIMs each with a set of different WiFi drivers.

[Wonko the Sane]

Flat boot is not an option as we are not aware of reliable tools in efi space to expand .wim files. Downloading thousands of flat files from remote web server is not viable either.

Flat boot does not imply in itself the downloading of thousands of flat files, it can be flat boot of an image (such as a raw or a vhd one).

 

Wonko 

[videoguy]

VHD's are not compressed. A 500MB .wim can easily blow to be 3GB. Downloading such a big file is not an option. Lets say we go with this option, how do you setup your BCD so that ramdisk gets initialized with VHD and driver folder.

 

To answer Steve, your suggestion works to download driver for other systems if current booted winre instance has wifi networking capability. Like I mentioned before, it is a chicken or egg first problem.

[steve6375]

I meant that you download the 'correct' wim via iPXE to start with.

 

I am still not 100% clear on what you are doing.

Starting with a PC/notebook that is off, what is the sequence of events (both manual and scripted)...?

[Wonko the Sane]

VHD's are not compressed. A 500MB .wim can easily blow to be 3GB. Downloading such a big file is not an option. Lets say we go with this option, how do you setup your BCD so that ramdisk gets initialized with VHD and driver folder.

I have no idea about what exactly you are trying to do, so what is provided is just semi*random ideas, still you don't have to download a number of small files for flat boot using a VHD.

 

What is inside a VHD can to be a very miinimal system, barely booting, that can later proceed to download one or more other files, that may be .wims alright, create mountpoints and Symlinks for them, etc., such a system should be within the 300-400 Mb size, if I recall correctly.

 

I also believe that the NTFS inside the VHD can use compression.

 

Then whether any of the known approaches will work with EFI and with your EFI tool is another thing.

 

Maybe you have to check Firadisk and/or Winvblock, and modify your EFI tool in such a way that it offers "hooks" in memory for the drivers (just like what grub4dos does).

 

I am still not 100% clear on what you are doing.

And that makes two of us.

 

Wonko