wimboot & winpe - assorted questions

[jpwise]

Morning all, just been playing with wimboot - awesome looking utility guys. Definitely fills a gap in the network booting vs memdisks area.

[links for the new]
http://ipxe.org/wimboot
http://ipxe.org/howto/winpe

Managed to get a selection of 32 & 64bit Windows Recovery Environment Wimboots setup for workshop use (and avoiding the memdisk issue on v.low memory machines).

But.. onto other ideas. Some of the utilities we run in the workshop are PE based and subject to frequent change - input files need changing on an almost weekly/fortnightly basis.

Historically we've run the utilities from USB flashdisks running PE, and just updated the files manually within the USB filesystem, without the need to rebuild the wim file. Utils are command line/batch based, so once you find out which drive letters assigned to the usb drive it's just a matter of changing drive/dir and running the batch.

Firstly - can you think of any methods to achieve a similar use case using an ipxe booted winpe image?

Turning the idea over in my head I'm thinking along several angles.
1) include secondary wim (or other?) file in wimboot process that's mounted as another drive letter - not sure if this is possible?
2) include network drivers in wim file, followed by an included batch file that loads network & downloads updated files - would require injecting network drivers into the wim on an as required basis, but these change less frequently than the input files do.

Other ideas outside the immediate scope of the issue include if there's any way to pass variables to the winpe environment during boot. One thought is to embed a selection of batch files into various indexes within the wim file, but as far as i can tell wimboot doesn't support index selection as yet.
There is some info at: http://forum.sanbarrow.com/viewtopic.php?f=85&t=15 relating to arbitrary index selection which could be used, but it would require more research to implement and potentially custom sdi/bootmgr files.

Ideally it would be nice to have one base pe image that could then go off and load secondary programs depending on what variables it's passed, but realistically I don't know if this can be achieved, so the more immediate project is to determine the best way to load high change files for use with a base PE image - _without_ rebuilding the PE image every time.
Right now from what I've researched, I'm leaning towards #2 as above and loading network drivers + downloading a zip file or similar to uncompress and execute. Then it's just the zip that gets updated as required.

Thanks for any suggestions offered.

Thx.
Jp.

[robinsmidsrod]

I would definitely go with adding appropriate network drivers to your PE image and then bootstrapping the rest of your environment from a SMB network share that contains all the fast-mutating files. Getting that network share mounted to a common drive letter should be fairly trivial with a bundled batch script. I don't really see any reason to package those additional files as a zip. Why don't just use them as-is from the network?

If you regularly boot hardware that doesn't have drivers in the PE image, I'd consider booting these machines from USB network adapters to avoid the driver issue and just update the PE image when you start noticing new network hardware is getting common. Alternatively you can build a PE that automatically scans local storage (including floppies and USB storage devices) for drivers to install and start automatically before the network part of the batch script is executed.

[mcb30]

(2012-10-05 12:44)jpwise Wrote:  Firstly - can you think of any methods to achieve a similar use case using an ipxe booted winpe image?

Modifying a .wim image is fairly painless if you use the Linux version of imagex (available as part of wimlib). On Windows, mounting and unmounting images seems to take a substantial amount of time; on Linux it's almost instantaneous.

Quote:Other ideas outside the immediate scope of the issue include if there's any way to pass variables to the winpe environment during boot. One thought is to embed a selection of batch files into various indexes within the wim file, but as far as i can tell wimboot doesn't support index selection as yet.

Try modifying the byte at offset 0x78 within the .wim file, which I think holds the boot index value.

If this works, then it would be viable to add support for wimboot modifying the boot index in response to a command-line parameter.

Michael

[jpwise]

(2012-10-05 13:06)robinsmidsrod Wrote:  I would definitely go with adding appropriate network drivers to your PE image and then bootstrapping the rest of your environment from a SMB network share that contains all the fast-mutating files. Getting that network share mounted to a common drive letter should be fairly trivial with a bundled batch script. I don't really see any reason to package those additional files as a zip. Why don't just use them as-is from the network?

Yeah, I'm thinking along these lines at the moment currently. It's a somewhat locked down client/dmz area the utils are run in so smb is out, but would be easy enough to download a zip from http (wget etc) and then unzip/run in local. So that's my current leaning at the moment unless a better option eventuates.

(2012-10-05 13:09)mcb30 Wrote:  Modifying a .wim image is fairly painless if you use the Linux version of imagex (available as part of wimlib). On Windows, mounting and unmounting images seems to take a substantial amount of time; on Linux it's almost instantaneous.

Try modifying the byte at offset 0x78 within the .wim file, which I think holds the boot index value.

If this works, then it would be viable to add support for wimboot modifying the boot index in response to a command-line parameter.

Michael

Hi Michael, also thank you for the prompt response (although starting to wonder what timezone you guys are in since it's 1am in the morning here ;p). I haven't worked with wimlib before but will definitely have to take a look at it. Another complicating factor is the setup is run across three sites, which sync nightly from an online master. So modifying the wims may mean more data transfer, but definitely worth considering in the equation. Modifying the boot offset is over my head at the moment, although the information i linked earlier does seem to have a number of the offset addresses listed. When i'm a bit more awake I'll see if I can build a multi index file, and have a play with tweaking it's index selection.

Thanks again both for your responses.
Jp.

[jpwise]

Hi Michael, just a bit of feedback on the 0x78 suggestion. Just gave it a go on a merged Windows Recovery Environment Wim -combining x86 and x64 versions. BootIndex (0x78) after merge is 2. WimBoot it and you end up with the x64 version (Index 2). Just tried modifying 'only' 0x78 from 2 to 1, and reloaded it using WimBoot, ended up with the x64 version still. Having a read through this suggests there may be 3 or 4 values that require changing - 0x60, 0x68, 0x70 and 0x78.

0x78 as you suspected does appear to hold the BootIndex value - also matching with the 4 example headers posted in the above link example.

From my checks with a Windows RE - Win7 32bit, 64bit, and 32+64bit merged wim files I have the following values.

Code:

WinRE - Win7 - 32bit
0x60    - F0 02 09
0x68    - 35 36 8C 08
0x70    - F0 1B 2C
0x78    - 01

WinRE - Win7 - 64bit
0x60    - AC 3F 09
0x68    - 73 06 F3 09
0x70    - B0 64 2D
0x78    - 01

WinRE - Win 7 - merge of above - results:
0x60    - AC 3F 09
0x68    - C6 CA C7 10
0x70    - B0 64 2D
0x78    - 02

The merged values for 0x60 and 0x70 are identical to the 64bit values, and what's what it ends up booting.
Modifying just the boot index - 0x78 to 1 still boots the 64bit.
Modifying 0x60 and 0x70 only, or all 4 values (0x60, 68, 70 & 78) to match the 32bit values, and it starts the initial load, then errors with a winload.exe error.

Was just using 'echo %PROCESSOR_ARCHITECTURE%' from command prompt for the check on which version/index it actually booted.

I haven't found enough information on what those header values actually represent or if they could be calculated/retrieved from the file for rewriting in memory, but booting different indexes isn't a critical feature request. Would be a nice to have one later on though.