Jump to content











Photo
- - - - -

Boot VHD or WinPE with grub2

grub2 vhd bootmgr lua

  • Please log in to reply
49 replies to this topic

#26 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 July 2016 - 07:39 AM

Sure, if you can access-protect the volume it will be more than fine, it was just an experiment to try, nothing that really matters.

:duff:
Wonko

#27 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 07 July 2016 - 03:41 AM

Is there any way to set the default path in Win PE 3? I found the info online about the 3 ways to run commands (winpeshl.ini, startnet.cmd and unattend.xml), but nothing about setting the path.

 

I found a way around the problem but it requires an extra cmd.exe and 2 exits to terminate Win PE (of course you can also click the X in the upper right corner to end the PE session).

 

Within the startnet.cmd I can set the path, cd to where I want to end up when the script finishes but upon completion the current directory is always X:\Windows\System32, and running the SET command shows the path is not set as I did in the startnet.cmd file (putting a pause within the startnet shows the path is set and the current folder is not Windows\System32). That behavior is expected for a CMD.exe child process, the question is how to set the environment that child inherits.

 

The workaround I came up with is this startnet.cmd:

@echo off
echo Initializing WinPE, please be patient...
wpeinit

set Path=%Path%%SystemDrive%\SDRState;
cd %SystemDrive%\SDRState
cmd.exe /K initSS.cmd

where initSS.cmd is the script I previously used as startnet.cmd. Like I said it works but the drawback is closing WinPE now requires 2 exits rather than 1. This is yet another minor issue that isn't critical but would be nice to fix.

 

The winpeshl.ini uses an "AppPath" which is not just a path but instead the full pathname to an alternate shell to replace the default CMD.exe shell.



#28 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 July 2016 - 08:38 AM

Do you really *need* to change the PATH environment variable?
Wouldn't it be enough to set the Current Directory of the command prompt?
Technically, it would be more correct to used PUSHD/POPD:
http://ss64.com/nt/pushd.html
if you need to have it run from a given directory and call it with full path and or - if needed - add the Path statement to the initss.cmd itself. :unsure:
 
The double exit is probably because you spawn another instance of CMD.exe with cmd /K, is that actually needed? :dubbio:
 
But it should work from WINPEshl.ini, be aware that WinPEshl.ini is "tricky":
http://reboot.pro/to...yntax/?p=141854
http://www.msfn.org/...ni-not-running/
you need to use the [LaunchApps] and not the [LaunchApp] section.
 
:duff:
Wonko



#29 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 07 July 2016 - 03:18 PM

Do you really *need* to change the PATH environment variable?
Wouldn't it be enough to set the Current Directory of the command prompt?
Technically, it would be more correct to used PUSHD/POPD:
http://ss64.com/nt/pushd.html
if you need to have it run from a given directory and call it with full path and or - if needed - add the Path statement to the initss.cmd itself. :unsure:

The double exit is probably because you spawn another instance of CMD.exe with cmd /K, is that actually needed? :dubbio:

But it should work from WINPEshl.ini, be aware that WinPEshl.ini is "tricky":
http://reboot.pro/to...yntax/?p=141854
http://www.msfn.org/...ni-not-running/
you need to use the [LaunchApps] and not the [LaunchApp] section.

:duff:
Wonko


No, it's not essential, it's for user convenience so they A) don't have to know or figure out where the scripts are to execute them or B) so users can easily find them to see how they accomplish a task or to change them for their own requirements.

You are right, it is indeed the CMD.exe /K that causes the double exit, but I see no other way to leave the user at the "X:\STDState>" command prompt with a path that includes X:\STDState so the user can CD anywhere and still execute these custom scripts.

I found info about the 3 methods available to run custom commands, applications and even a complete replacement for the default CMD.exe shell of Win PE, but nothing about how to set the environmental context of the command prompt that CMD.exe shell leaves the user in. There may be a way to use the unattend.xml mechanism to accomplish that, but I didn't want to go down that rabbit hole with an uncertain outcome as to resolving this context issue.

I suspect the CMD.exe that runs startnet.cmd is launched using a mechanism similar to the winpeshl.exe method like this:

[LaunchApps]
%SYSTEMDRIVE%\System32\CMD.exe, /C startnet.cmd
%SYSTEMDRIVE%\System32\setCWD.exe, /path "%SYSTEMDRIVE%\System32"

As I tried to explain (apparently unsuccessfully), doing anything within the startnet.cmd script DOES NOT AFFECT the context of CMD.exe the user is left in to interact with the system. If the very last things done in startnet.cmd are to set the path and then CD to some other folder, they are not reflected in the CMD.exe window the user is left in. I don't think M$ designed the startnet.cmd or winpeshl.exe methods to provide control over the environmental context of the CMD.exe process the user is dropped into. WITHIN the startnet.cmd script all is possible, but once that terminates what remains is another matter, and is determined by how that interactive CMD.exe shell is launched. That CMD.exe is inheriting it's context and unless M$ provides a way to set it with the unattend.xml mechanism I see no way to set that inherited context.

Without spawning another CMD.exe the user is left at a "X:\Windows\System32>" command prompt with a path that does not include X:\SDRState, so typing the "merge.cmd" command results in "command not found". Not very good for the user.

Clearly the CME.exe process the user is left in to interact with the system is NOT the same as startnet.cmd, otherwise a simple SET or CD within startnet.cmd would set the context of the shell the user interacts with. It must be a separate CMD.exe process. Does that clear things up?

Edited by thomnet, 07 July 2016 - 03:22 PM.


#30 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 July 2016 - 04:39 PM

You are right, it is indeed the CMD.exe /K that causes the double exit, but I see no other way to leave the user at the "X:\STDState>" command prompt with a path that includes X:\STDState so the user can CD anywhere and still execute these custom scripts.

...


As I tried to explain (apparently unsuccessfully), doing anything within the startnet.cmd script DOES NOT AFFECT the context of CMD.exe the user is left in to interact with the system. If the very last things done in startnet.cmd are to set the path and then CD to some other folder, they are not reflected in the CMD.exe window the user is left in. I don't think M$ designed the startnet.cmd or winpeshl.exe methods to provide control over the environmental context of the CMD.exe process the user is dropped into. WITHIN the startnet.cmd script all is possible, but once that terminates what remains is another matter, and is determined by how that interactive CMD.exe shell is launched. That CMD.exe is inheriting it's context and unless M$ provides a way to set it with the unattend.xml mechanism I see no way to set that inherited context.

...

Well, startnet.cmd - AFAICU - is just a normal batch, so it behaves like one.

 

What I am failing to understand is that IF the initSS.cmd needs to be auto-executed at boot, why you do not add:

set Path=%Path%%SystemDrive%\SDRState;
cd %SystemDrive%\SDRState

to the beginning of it, calling it in [LaunchApps] of Winpesh.ini withthe full "%SystemDrive%\initSS.cmd", instead of going through startnet.cmd.

 

You could use the PATH internal command instead of set path (as a side-side note, it is a good habit to have a routine to check that last character in "current path" is a ";"), and/or use SETX instead (it has to be tested if it's needed specifically in your environment/intended usage), but if you all in all have to add "always" the "X:\SDRState" path it would IMHO be easier (and cleaner) to edit the Registry of the WinPE to add it there, should be

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

Or modify the copyPE.cmd used to build the PE:
http://www.symantec....ntures-winpe-31

 

:duff:

Wonko



#31 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 07 July 2016 - 06:07 PM

 

What I am failing to understand is that IF the initSS.cmd needs to be auto-executed at boot, why you do not add:

set Path=%Path%%SystemDrive%\SDRState;
cd %SystemDrive%\SDRState

to the beginning of it, calling it in [LaunchApps] of Winpesh.ini withthe full "%SystemDrive%\initSS.cmd", instead of going through startnet.cmd.

 

That may work, I didn't try it b/c the info I gathered about winpeshl left me uncertain of the results. I still think you need to have CMD.exe /K %SystemDrive%\initSS.cmd (not /C or the PE session would end when initSS.cmd finished) in the winpeshl.ini file, as I see nothing that leads me to believe that a script can be used in there directly.

 

The purpose of winpeshl.exe / ini appears to be geared more toward .exe programs (i.e. alternate shells) than for scripts. startnet is obviously designed for scripts, not necessarily scripts + interactivity afterwards. I find it very odd that the startnet.cmd CAN'T leave the user in a context dictated by the startnet.cmd script. If I can do this:

[LaunchApps]
%SYSTEMDRIVE%\System32\CMD.exe, /K %SystemDrive%\initSS.cmd

(which includes the path & cd commands within initSS.cmd as you listed) to end up at a "X:\SDRState>" command prompt with a path that includes X:\SDRState; which when exited terminates the PE session that would be cool, problem solved. I'll give that a try, it's easy enough to do.

 

As for editing the PE registry values being a "cleaner & easier" approach I disagree. I will always opt for options that avoid the registry if they're more accessible to change which I am of the perspective editing a script is easier than screwing with the registry, at least for simple settings like this. That's just me I guess.


Edited by thomnet, 07 July 2016 - 06:13 PM.


#32 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 07 July 2016 - 06:52 PM

Using winpeshl.ini It didn't work with the ini file I suggested above:

 

A winpeshl.ini file is present, but no commands were successfully launched. This could be caused by incorrect formatting or an invalid executable name. Please consult the documentation for more information.

 

Here's what was in the ini file:

[LaunchApps]
%SYSTEMDRIVE%\System32\CMD.exe, /K %SystemDrive%\SDRState\initSS.cmd

According to the docs I found:

The Wpeshl.ini file may have either or both of the sections: [LaunchApp] and [LaunchApps]. The apps listed in [LaunchApp] and [LaunchApps] run in order of appearance, and don’t start until the previous app has terminated.

 

I found that in the Windows 8 PE docs, not the Windows 7 PE docs, which were less clear and didn't explicitly state the either / or rule. However it seems odd that rule would change, as the only real difference between the 2 sections is command line parameters (disallowed in the [LaunchApp] section) and multiplicity of apps launched (in the [LaunchApps] section). So who knows why CMD.exe is not a "valid exe".

 

Win 7 docs: https://technet.micr...6(v=ws.10).aspx

Win 8 docs: https://technet.micr...y/hh825046.aspx


Edited by thomnet, 07 July 2016 - 06:59 PM.


#33 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 July 2016 - 07:18 PM

Well, I gave you some links, exactly because the syntax of winpeshl.ini is "tricky", badly documented and "quirky", if you try other things it is not so surprising that it doesn't work.

Mind you, not necessarily it will work but if someone says:

http://www.msfn.org/...ni-not-running/

http://www.msfn.org/...&comment=790371

 

Be careful, the syntax of the commands is a bit tricky in case there are arguments. There MUST be a comma after the command itself and, in case there multiple arguments, all the arguments MUST be enclosed between double quotes (see bginfo line in the previous example).

and you are pointed to it - maybe - it would be advisable to test that first. :dubbio:

If you prefer, you could try either:

[LaunchApps]

%SystemDrive%\SDRState\initSS.cmd

or:

[LaunchApps] 
%SYSTEMDRIVE%\System32\CMD.exe, "/K %SystemDrive%\SDRState\initSS.cmd"

And as said using the PATH or SET PATH (or SETX PATH) should be ok :unsure:.

 

:duff:

Wonko



#34 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 07 July 2016 - 07:45 PM

Given how long our private conversation was and the number of topics we covered in it, I don't recall that "tricky" statement pertaining to winpeshl.ini. It certainly wasn't mentioned in this public thread, I just looked for it.

 

Never-the-less, thanks for the tip. I actually just changed my VM so I'll try the quoted args version when I get back to the VM.

 

Thx Wonko!



#35 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 July 2016 - 07:50 PM

Given how long our private conversation was and the number of topics we covered in it, I don't recall that "tricky" statement pertaining to winpeshl.ini. It certainly wasn't mentioned in this public thread, I just looked for it.

 

Never-the-less, thanks for the tip. I actually just changed my VM so I'll try the quoted args version when I get back to the VM.

 

Thx Wonko!

THIS VERY thread (post #28) only a few post before your quoted reply which is #34):

http://reboot.pro/to...grub2/?p=199423

which ADDITIONALLY you quoted in your reply (#29)

 

Selective blindness? :w00t: :ph34r:

;)

 

:duff:

Wonko



#36 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 07 July 2016 - 07:57 PM

OK, I tried your ini file exactly, but the same issue, same error.

 

Thus I conclude it's just too "tricky" (for me) to use, not worth investigating any more time to figure it out the how to use it. These types of things are what frustrate the ()&^(^ out of me and why I'm down on Micro$oft more often than not.

 

Thanks for the ideas tho Wonko.



#37 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 07 July 2016 - 08:00 PM

Well, I scanned the previous posts, missed it, then searched for a few words from your quote (all the arguments MUST be enclosed between double quotes) using my browser and it failed to find it.



#38 cdob

cdob

    Gold Member

  • Expert
  • 1343 posts

Posted 07 July 2016 - 10:14 PM

Well, without testing, I wonder about
 
@echo off
echo Initializing WinPE, please be patient...
wpeinit

set Path=%Path%%SystemDrive%\SDRState;
cd %SystemDrive%\SDRState
cmd.exe /C initSS.cmd
.
.
Or
@echo off
echo Initializing WinPE, please be patient...
wpeinit.exe

call %SystemDrive%\SDRState\initSS.cmd
initSS.cmd
echo %~n0 %*
cd /d %~dp0
path %~dp0;%~dp0.\bin;%path%
.
.
or
path %~dp0;%~dp0%PROCESSOR_ARCHITECTURE%;%path%
PROCESSOR_ARCHITECTURE is a system default environment varible.
Can be for example:
.\x86\imagex.exe
.\amd64\imagex.exe

And technically, the path setting acan be included to boot.wim. but it's overkill.

#39 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 July 2016 - 08:00 AM

 

And technically, the path setting acan be included to boot.wim. but it's overkill.

 

Maybe overkill, but for a specific build used only to "configure" that particular SteadyState thingy, it seems to me like the simplest, and sure to be working.

 

Being much more dedicated to Occam's Razor usage and effects, personally I would have already put initss.cmd and the other batches in %SYSTEMDRIVE%\System32\ and went outside for a nice walk ;) .

 

:duff:

Wonko



#40 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 08 July 2016 - 04:12 PM

I didn't really get what you were concerned or had questions about cdob's, care to elaborate?

 

Maybe overkill, but for a specific build used only to "configure" that particular SteadyState thingy, it seems to me like the simplest, and sure to be working.

 

Being much more dedicated to Occam's Razor usage and effects, personally I would have already put initss.cmd and the other batches in %SYSTEMDRIVE%\System32\ and went outside for a nice walk ;) .

 

:duff:

Wonko

 

As to Wonko's reference to Occam's Razor, "Simple" is a matter of perspective.

 

For example, if a convention is well established and you break it to go another way, those familiar with the convention wouldn't think it "simpler" to locate the alternate method, the reason it was used, or any number of other considerations (size of code, performance, time for author to implement etc).

 

Just putting things in the System32 "catchall" folder might not be the most obvious place to look for scripts, not to mention the difficulty of finding things there among so many other things, AND that System32 is for WINDOWS, and was not designed for ad hoc user contributions, tho we all know how it has evolved to include such.

 

Don't get me wrong, I am not opposed to breaking with convention if other considerations and priorities outweigh the benefits of the convention. With this present project in particular, it has taken far longer to accomplish that I expected, and I need to bring it to a conclusion, like yesterday. We all also know that software, like writing a book or story, is never "complete", improvements are always possible, documentation can always be made more thorough, even more elegant and concise methods can be applied.

 

I will not be publishing anything more than the bare minimum docs  related to installing Linux and customizing grub2, I will describe what I have done and provide the code, and hopefully that will be enough to convey the value of the approach and usefulness to others.

 

For example, I will provide the grub2 menu and theme, but no scripts to integrate that with the Linux conventions of how grub should be customized, i.e. under /etc/defaults/grub.d/.


Edited by thomnet, 08 July 2016 - 04:18 PM.


#41 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 10 July 2016 - 04:56 PM

Ah yes, the finish line. Glad to be here. I just posted a message on Mark Minasi's forum announcing the completion of my "Steadier State 2" changes, to give him an opportunity to endorse, reject or comment on them. I wote a 7 page Word doc in which the first page is all about the history of my involvement, and which I gave reboot.pro notable mention, as well as credit to "Wonko the Sane" and cdob for their helpful assistance with this project.

 

Thanks again everybody who helped make this what it became.



#42 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 12 July 2016 - 07:02 PM

Mr. Minasi has given me the OK to publish my changes to Steadier State which you can find on my github account.


Edited by thomnet, 12 July 2016 - 07:03 PM.


#43 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 July 2016 - 10:53 AM

Good, now that everything is "official" and public :thumbsup:, I guess we can turn this thread into a bug report/suggestions thread, and possibly provide enhancements or alternative ways.

buildPE.cmd:

echo.
echo I'm sorry, but you must be running from an elevated
echo command prompt to run this command file. Start a new
echo command prompt by right-clicking the Command Prompt icon, and
echo then choose "Run as administrator" and click "yes" if you see
echo a UAC prompt.
goto :done

 

 

Since the idea is[1] to make things as smooth as possible for the less experienced user, an idea could be to automate the elevation, feel free to use or peruse this:
http://www.msfn.org/...se-testelevcmd/

Maybe if not useful for this project, it may be on another one. :)

 

:duff:

Wonko

 

[1] Please read "since I wrongly perceived the idea as being ..."



#44 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 13 July 2016 - 01:46 PM

I dunno, yes and no.

 

Yes to improvements and support stuff, not sure about the "less experienced user" angle. This does require some smarts, and the WAIK is a pretty big deal for the less experienced.

 

Interesting you picked out the UIA thing over other stuff. I barely touched buildpe and cvt2vhd, they're not optimized and 99% MM's code. They get the job done OK. Would be kewl tho if someone decided to do what I did and improve those 2 scripts. I would entertain pull requests on github if someone wanted to submit improvements AND test them out.



#45 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 July 2016 - 02:11 PM

I dunno, yes and no.

 

Yes to improvements and support stuff, not sure about the "less experienced user" angle. This does require some smarts, and the WAIK is a pretty big deal for the less experienced.

 

Interesting you picked out the UIA thing over other stuff. I barely touched buildpe and cvt2vhd, they're not optimized and 99% MM's code. They get the job done OK. Would be kewl tho if someone decided to do what I did and improve those 2 scripts. I would entertain pull requests on github if someone wanted to submit improvements AND test them out.

Yep, you  can call it also surprising, but all I did was to open and quickly glance at the first .cmd I found (in alphabetic order), and posted about the first thing in it that drew my attention.

 

As a different note, there is actually no real *need* for the WAIK (or for the "full" WAIK) to build a PE, as a matter of fact we already have a small set of batches that can build a PE fine both with and without it, again JFYI:
http://reboot.pro/fi...le/340-quickpe/

 

Corrected anyway my previous post rewording it to underline how it was only my impression that the idea was to make things as easy as possible.

 

:duff:

Wonko



#46 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 13 July 2016 - 04:38 PM

Gotcha, I C.  I did look briefly at The Oven (banned website) to add a "Windows Explorer" file browser, but I thought "It's not going to be as easy as downloading and 15 minutes of work to add it", so I put it in my favorites to use another day on another project.

 

The link you sent is also an improvement in the same direction, but yet another opportunity for somebody else to enhance the functionality of the project.

 

Good 2 know tho, thx



#47 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 13 July 2016 - 04:52 PM

I dl'd it and took a quick look at the pkg. What caught my eye was

 

 

ECHO QuickPE 0.9.3 Main Menu
ECHO.                                         
ECHO   Menu Choices                           
ECHO.                                         
ECHO 1 Make WINPE 3.0 - requires MS WAIK (UEFI ok for x64)
ECHO 2 Make WINPE 4.0 - requires MS ADK (UEFI ok)
ECHO 3 Make WINRE from system recovery (UEFI ok for x64)
ECHO -
ECHO 4 Make WINRE from iso x86 (UEFI ok)
ECHO 5 Make WINRE from dvd x86 (UEFI ok)          
ECHO -
ECHO 6 Make WINRE from iso x64 (UEFI ok)          
ECHO 7 Make WINRE from dvd x64 (UEFI ok)         
echo -
ECHO 9 Exit                                  

 

which is slightly different than

 

Alternatively, one can also use the Windows Repair Disk or Windows DVD to build a Winpe (no need for WAIK or ADK then).

 

I read the Menu Choices as only 1 way to build a WinPE 3, which is by using the WAIK. Correct me if I'm wrong, but isn't WinRE & WinPE pretty much the same thing, except RE includes a few other tools like bootsect.exe and bootrec.exe? The brief look I took at the zip contents indicates all of the choices offer explorer++ and the ability to add your own files using wimlib, so that sounds good.

 

Oh, and, this QuickPE DOESook like it could be easy to use in a short period of time, + it has explorer++ already integrated.


Edited by thomnet, 13 July 2016 - 04:54 PM.


#48 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 July 2016 - 06:18 PM

It's a thin line between:

1) a "standard" boot.wim from an install DVD

2) a PE

3) a RE

 

Particularly the PE has been traditionally transformed (since good ol' BartPE days) from the very essential PE Microsoft either provided (WinPE 1.x) or allowed to build via ADK/WAIK (WinPE 2,3,4,5, etc.) to a "fully fledged" temporary OS.

 

The WinRE is actually very similar to a basic WinPE (and to the install DVD boot.wim).

 

The WAIK or ADK install is not really needed even to build a PE, as the few needed tools can be downloaded (and used) without the need for downloading the "whole" thing, let alone "install" it. 

 

Still JFYI:

http://reboot.pro/to...ole-waik-first/
http://www.msfn.org/...-the-huge-isos/

 

In the specific scenario of this "Steadier State" project, unless I am missing something :unsure: what is actually needed is *any* bootable environment actually cpable of running a couple of diskpart commands and a couple of bcdedit ones, besides basic file copying possibilities.

 

For the above a WinRE (or WinPE, wouldn't a rose by any other name .... ;)) created by slightly modifying a "common" boot.wim found on the actual Windows 7 DVD should be enough.

 

Off course it will need to be tested, but the commands used in the set of batches are not much different from the ones normally used in more or less "normal" methods of installing 7.

Getting rid of the WAIK requisite and leveraging on the "standard" boot.wim that the final user must have anyway since it is included on the OS install media would be IMHO a step toward making the whole thing simpler for the end user .

 

:duff:

Wonko



#49 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 13 July 2016 - 06:51 PM

I fully agree. Thx for the info about the PE distinctions. Can you think of a reason for why M$ distinguishes PE from RE? Why bother, and why not just have one animal for both purposes? M$ -- heh, who knows...

 

As to testing, that is the key, as I discovered that subtleties often cause failures. Case in point I noticed all of the files that I added to the PE image that were NOT included within the BOOT.WIM image were all upper case. A quick look at the oscdimg.exe options showed there is a -d option that will not upper case all the files, however when that option is used it renders the ISO unbootable! I wanted to put some files in the root of the PE ISO for access when PE was not running, like from Linux (i.e. grub files) and Windows (i.e. shutdown script). The upper casing was not an issue for Windows but it was for Linux / grub, so I had to add the files inside the BOOT.WIM to preserve case, and move them to the HDD when PrepSSdisk.cmd runs for availability under either OS.

 

You're assumptions about the requirements for this Steadier State project are spot on, I don't think there's a problem with a minimal PE. I did notice tho in looking at the WAIK that there is a distinction between some tools that run under Windows vs. PE, since there are both ..Tools and a ..Tools\PETools exist, each with separate arch folders.

 

The 4 primary tools needed are:

  1. imagex
  2. oscdimg
  3. bcdedit
  4. bootsect

Don't recall if oscdimg has different version for PE, but I doubt it would be an issue that prevents QuickPE from being a replacement to the WAIK (along with the Windows install media of course).



#50 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13748 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 July 2016 - 07:19 PM

Oscdimg (and its "counterpart", which I personally prefer) mkisofs are among (surclassed by genisoimage, JFYI) the most complex tools around, they have such a number of switches that are contrasting with each other that one could write a whole book on each tool.

The origin is - as often happens - a "standard" namely the ISO 9660 one (and it's integration and modifications) that have been often mis-read or mis-implemnted and nowadays you have to deal also with the stupid EFI/UEFI standard.

If you look around you will see a number of threads about the complexities of their command line, the use (and misuse) of iso levels, and what not.

Just as an example (this is particularly complex because of UEFI), very recent post:

http://reboot.pro/to...ideas/?p=199540

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users