Jump to content











Photo
- - - - -

QuickPE

winpe3 winpe winre boot winpe4

  • Please log in to reply
79 replies to this topic

#51 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12688 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 26 November 2015 - 10:21 AM

There is an issue with spaces in the path to ISO / DVD.

 

For the path 'Q:\CDs Standard' I had to change in make_re_from_dvd.cmd:

copy %folder%\sources\boot.wim %dest%\iso\sources

to

copy "%folder%\sources\boot.wim" "%dest%\iso\sources"

Maybe similar is necessary in other batches.

 

Peter :cheers:



#52 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 26 November 2015 - 03:17 PM

There is an issue with spaces in the path to ISO / DVD.

 

For the path 'Q:\CDs Standard' I had to change in make_re_from_dvd.cmd:

copy %folder%\sources\boot.wim %dest%\iso\sources

to

copy "%folder%\sources\boot.wim" "%dest%\iso\sources"

Maybe similar is necessary in other batches.

 

Peter :cheers:

 

 

Good catch !

I'll fix this one and review entire code.



#53 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 November 2015 - 08:56 AM

Wouldn't it have been easier to rename the source path from "Q:\CDs Standard" to "Q:\CDs_Standard"? :whistling:

 

;)

 

:duff:

Wonko



#54 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12688 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 28 November 2015 - 09:02 AM

Yes, that wuold be easier! :cheers:

 

But as always some people use spaces, I intentionally in my development use "tricky" path names.

 

Peter :smart:



#55 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 November 2015 - 11:30 AM

Yes, that wuold be easier! :cheers:
 
But as always some people use spaces, I intentionally in my development use "tricky" path names.
 
Peter :smart:

Sure :), that's "good practice" :thumbsup:, though of course:

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.


JFYI ;):
http://www.911cd.net...showtopic=25612
http://www.msfn.org/...-multiboot-dvd/

Only to prove that even the underscore/minus may become an issue in some cases.... :frusty:

:duff:
Wonko

#56 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 28 November 2015 - 12:51 PM

Reviewed 7 batches and dozens of lines... should work with paths containing spaces.

Did some quick tests and it seems to work about (...) ok :)

 

Did not review wim-update.txt and wim-update_x64.txt yet thus so I cant tell for sure (yet) if the pe_extra folder will be put in boot.wim.



#57 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12688 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 28 November 2015 - 12:55 PM

:thumbsup:

 

Peter



#58 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 16 July 2016 - 07:44 PM

Feedback about QuickPE 0.9.3:

  1. Successfully built a bootable ISO using menu option 6 out of the box (booted OK using VirtualBox)
  2. Why "Browse For Folder" for option 6, rather than browse for individual ISO file?
  3. Browsed to a folder with several Windows 64 bit ISO files, and quickPE used one of them (why did it select the one it did?)
  4. Added some scripts, folders, various files to the "pe_extra" folder according to info here and again rebuilt using option 6
  5. No sign of any of the files I added when booted or using 7z to inspect ISO and boot.wim in the ISO
  6. *.sample files are inadequate to explain what / how to include necessary drivers so networking will function
  7. Nice effort, but needs more documentation

Thanks for your contribution, hope this is helpful.

 

Built on a Windows 7 Ultimate system, the ISO file quickPE used was also a Windows 7 Ultimate ISO (X17-24395).


Edited by thomnet, 16 July 2016 - 07:53 PM.


#59 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 July 2016 - 12:13 PM

#4 and #5:

Have you added those files to "pe_extra" or to "pe_extra_x64"? :dubbio:

 

:duff:

Wonko



#60 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 18 July 2016 - 02:59 AM

#4 and #5:

Have you added those files to "pe_extra" or to "pe_extra_x64"? :dubbio:

 

:duff:

Wonko

 

I followed the directions:

Uncompress to x:\quickpe, stuff your tools (optional) in pe_extra folder, and launch make.cmd.

It works if you put it in pe_extra_x64, but my point was that if you follow the rather sparse directions it fails.

 

How wonderful of M$ to not provide a way to script a dialog for files, or at least insure that the BrowseForFolder method works on platforms other than W98. The 3rd param to BrowseForFolder does provide a "browse for everything" option (0x4000), which does present the ability to select files, however on Windows 7 Ultimate it always returns nothing with err = 80004005 (unknown error). Verified this on 2 machines.

 

I suspect that is why QuickPE doesn't ask for an ISO file as it should, but finds (the first, last, random?) ISO file in the folder the user chooses. Also, I couldn't easily figure out how to launch a script on startup of PE so that when the script finishes your left at a cmd prompt.

 

It seems crazy to me that all 3 of the methods M$ provides to start processes when WinPE starts are synchronous. It's a freak'n powerful multitasking OS for Pete's sake, yet M$ only provides these synchronous execute methods (unless you want to code a far more complex app using the heavy Win32 API or something besides cmd script. I also think you could do it in WHS. Just seems like a poorly thought out architecture, to provide 3 start task methods but all are synchronous.


Edited by thomnet, 18 July 2016 - 03:14 AM.


#61 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 18 July 2016 - 07:22 AM

It works if you put it in pe_extra_x64, but my point was that if you follow the rather sparse directions it fails.

 

Sure :), I got that, and my point was that in my opinion you were whining a bit too much, dedicating to that 2 points of the numbered list, them being, like #6, a subset of point #7.

 

:duff:

Wonko



#62 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 18 July 2016 - 03:40 PM

We're all allowed to have our own opinions Wonko, so be kind enough to allow me mine.

 

I offered my 7 points in hopes it would help. So what if #6 is a subset of #7, it is a specific example. General info is good, specific info is better. Facts carry more weight than opinion, and the fact is the minimal instructions are simply wrong. You can attack me if you like but that won't change the facts. Unless you live and breathe only Microsoft air on a daily basis a few more comments / words of instruction can only help to improve QuickPE and make it easier for more people to understand and use it.

 

Perhaps it would serve the community better if you aimed your criticisms at the faults rather than the messenger. You did a similar thing with the buildpe script that Mark Minasi created, tho in that case you were justified since I republished it. IMO you're whining too much about opinions, which for better or worse provide one person's perspective, a person BTW with tons of experience in the industry. Doesn't mean I'm always right, but I offered the information in good faith as well as thanking the author for his contribution. He didn't have to post QuickPE at all, but he deserves some accolades for his effort even if it isn't perfect. None are.



#63 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 19 July 2016 - 10:12 AM

We're all allowed to have our own opinions Wonko, so be kind enough to allow me mine.

 

I offered my 7 points in hopes it would help. So what if #6 is a subset of #7, it is a specific example. General info is good, specific info is better. Facts carry more weight than opinion, and the fact is the minimal instructions are simply wrong. You can attack me if you like but that won't change the facts. Unless you live and breathe only Microsoft air on a daily basis a few more comments / words of instruction can only help to improve QuickPE and make it easier for more people to understand and use it.

 

Perhaps it would serve the community better if you aimed your criticisms at the faults rather than the messenger. You did a similar thing with the buildpe script that Mark Minasi created, tho in that case you were justified since I republished it. IMO you're whining too much about opinions, which for better or worse provide one person's perspective, a person BTW with tons of experience in the industry. Doesn't mean I'm always right, but I offered the information in good faith as well as thanking the author for his contribution. He didn't have to post QuickPE at all, but he deserves some accolades for his effort even if it isn't perfect. None are.

Sure you are allowed to have your opinions :), and haven't you noticed, we both expressed ours, which is fine.

 

Surely good, exhaustive, detailed and easy to understand instructions are IMHO a very important point of any project, and it is good that people care for that.

 

But specifically here according to your point #4 you added a number of things into the "pe_extra" folder and according to your #5 they didn't come out in the build.

 

There are two possible practical outcomes:

a. you managed to try putting them in the "pe_extra_x64" in a x64 build (though this is not specified in the (scarce) instructions) and had them added to the build

b. you failed at having them in "pe_extra_64" folder and wasn't able to add them to the build.

 

My question was related to that since you didn't specify what happened, while giving a hint to what possibly had been the issue.

 

But anyway you didn't actually "follow the instructions" to the letter, since there is NO "make.cmd" in the project.

 

So the (scarce) info is definitely inaccurate, as what you run is the "_RUN_ME.cmd", but you were also inaccurate when reporting that you followed them.

 

What probably happened is that the early versions of QuickPE were x86 only (and possibly actually had a single "make.cmd"), at the time there was only the "pe_extra" folder and that text in that post wasn't modified to reflect the changes.

 

Now if someone reads this thread and somehow gets in situation b. above he/she will know what to do to add the "extras" in a x64 build (and that he/she needs to run the "_RUN_ME.cmd").

 

:duff:

Wonko



#64 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 19 July 2016 - 03:22 PM

 

There are two possible practical outcomes:

a. you managed to try putting them in the "pe_extra_x64" in a x64 build (though this is not specified in the (scarce) instructions) and had them added to the build

b. you failed at having them in "pe_extra_64" folder and wasn't able to add them to the build.

 

My question was related to that since you didn't specify what happened, while giving a hint to what possibly had been the issue.

 

But anyway you didn't actually "follow the instructions" to the letter, since there is NO "make.cmd" in the project.

 

I'm very surprised you would take the above position Wonko. Also surprised you even bothered to post a response this thread. Now I see how you came to have nearly 13,000 posts :2nd: 

  1. My point #5 was the outcome / results / what happened by taking the actions in the preceding steps 1 - 4. How was that not clear?
  2. I didn't "fail" at anything. What I wrote is what I did and what I observed.
  3. How can you possibly turn this back on me as my failure in following instructions? If make.cmd doesn't exist how is that my on me? You actually helped make my point that the instructions are faulty.

You seem to be defending what are clearly failures on the part of the author in documenting the use of QuickPE, contrary to what you wrote in your last reply. If you cared to review much of the QuickPE topic you would know that the x64 support was indeed added very late in that thread, so it could only be speculation as to why the author decided to rename make.cmd to _RUN_ME.cmd (assuming make.cmd existed at one time) or not fix the instructions to reflect that change.

 

Had the author invested only a few more minutes to write a sentence or 2 or post a link or 2 it would have saved me an hour of searching to find how to add drivers to support networking. It may be "quick" if you "live and breathe Micro$oft" every day, but everyone doesn't.

 

You can continue to defend such things (by trying to shift the blame onto me), but IMHO you are on very shaky ground. The facts of my post are very simple and plain and don't justify our time spent in discussing them. If you insist on continuing it will be without my participation. You can take that opportunity to paint me in a bad light, but doing so doesn't show your desire to help others or uncover the truth.



#65 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 19 July 2016 - 04:13 PM

I am not at all trying to shift any blame on you for anything, I was only highlighting that if you play the "newbie" role, literally doing what is written you wouldn't have had the outcome in #5 (actually you would have had no outcome at all).

 

The incriminated sentence reads:

 

Uncompress to x:\quickpe, stuff your tools (optional) in pe_extra folder, and launch make.cmd.

 

If you actually followed those (incorrect/outdated) instructions you would not have had a build missing some "extra" files, but no build at all.

 

But you managed to gather that:

1) you don't literally uncompress to x:\quickpe, but rather to <your preferred drive letter>\quickpe

2) you add 32 bit "extras" to "pe_extra" and 64 bit on "pe_extra_x64"

3) you don't actually run make.cmd (that doesn't exist) but rather "_RUN_ME.cmd"

 

So you did not actually "followed the directions", and of three items, three are wrong, but you picked on just one of them:

 

I followed the directions:

 

Uncompress to x:\quickpe, stuff your tools (optional) in pe_extra folder, and launch make.cmd.

It works if you put it in pe_extra_x64, but my point was that if you follow the rather sparse directions it fails.

 

Compare with the known joke about black sheeps:
https://www-users.cs...oke/3.htm#black

 

And yes, I am a picky  (and old, and grumpy) bastard (and cheap, but that is unrelated in this case).

 

:duff:

Wonko



#66 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 20 July 2016 - 05:49 PM

Feedback about QuickPE 0.9.3:

...

 

Thanks for your contribution, hope this is helpful.

 

Built on a Windows 7 Ultimate system, the ISO file quickPE used was also a Windows 7 Ultimate ISO (X17-24395).

 

Hi Thomnet,

 

Thanks for the feedback.

 

See below my answers.

 

Successfully built a bootable ISO using menu option 6 out of the box (booted OK using VirtualBox)
Good ! it works ! :)
 
Why "Browse For Folder" for option 6, rather than browse for individual ISO file?
Because I wanted to stick to easy and batchable tools I could use from command line.
I reused some vbs scripts I found out there.
If you have a better alternative, please share.
 
Browsed to a folder with several Windows 64 bit ISO files, and quickPE used one of them (why did it select the one it did?)
It will pick up the first iso files it will find.
See point above : "cheap" coding...
 
Added some scripts, folders, various files to the "pe_extra" folder according to info here and again rebuilt using option 6
Already discussed with Wonko : 64 bits versus 32 bits.
 
No sign of any of the files I added when booted or using 7z to inspect ISO and boot.wim in the ISO
The files will be in the wim file contained in the iso file.
Look for the "extra" folder which translates into the pe_extra or pe_extra_x64 in the quickpe folder.
 
*.sample files are inadequate to explain what / how to include necessary drivers so networking will function
add-drivers4.sample seems a good start to me : this is an example provided by MS.
The rest is dism syntax : out of scope for quickPE -  Google is your friend.
 
Nice effort, but needs more documentation
Thanks and aggreed ( on both statements  ^_^  ).
I shamelessly rely on this great community to share experience / contribute, eventually make some documentation (like MistyPE did for TinyPXE Server), and secretely count on Wonko to help (but dont tell him).

 

As a whole : I love to code, I love to share and I love to support but writing documentation is my weakness.

I know I am wrong as a good software usually comes with good documentation although some dev guys will tell you that a well designed software does not need a documentation :)

 

Regards,

Erwan

 

Edit : updated the first post to reflect on the 32/64 bits remark as well as the make.cmd vs _run_me.cmd.



#67 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 20 July 2016 - 07:51 PM

As a whole : I love to code, I love to share and I love to support but writing documentation is my weakness.

... and don't forget projects and files names and versioning  :whistling:

 

I guess that the basic issue is that QuickPE is understood as being a quick way to build a PE as opposed to a bunch of batches quickly put together that deliver a simple/basic PE with very few bells and whistles (we do have a very quick/fast builder that can create PE's - even extremely complex ones -  in an extremely fast way but that usually delivers something almost, but not quite, completely unlike a working PE ;)).

And still:

 

 

Uncompress the zip file to x:\quickpe, stuff your tools (optional) in pe_extra or pe_extra_x64 folder, and launch _RUN_ME.cmd.
Get winpe.iso in x:\quickpe\%processor_architecture%.

x:\quickpe=<whatever drive letter you use, but usually NOT X: which is generally used by a booted PE>\quickpe

 

:duff:

Wonko



#68 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 06 August 2016 - 06:27 PM

Hi Thomnet,

 

Thanks for the feedback.

 

No problem, looks like it had a positive affect :good:

 

I thought I'd revisit this to help a friend on a different project, and had some trouble with the PENetwork. That may be out of scope for this thread, but thought I'd mention my experience from the same motivation as before (to help improve QuickPE or help others trying to use it like myself).

 

I copied the add-drivers3.sample to add-drivers3-64.cmd and edited it to change %PROCESSOR_ARCHITECTURE%  to "amd64" to match the folder names in the driver archive I downloaded from DriverPacks.net. I then had to edit the make_re_from_iso_x54.cmd to call the add-drivers3-64.cmd script. I added the call to line 54:

if exist add-drivers3-64.cmd call add-drivers3-64.cmd "%dest%\iso\sources\boot.wim"

The resulting ISO is almost 234MB with the LAN and WLAN drivers. After some playing around with PENetwork I figured out the required syntax and managed to get a network drive mapped to a local drive, and use gimagex to save an image to it.

 

So it looks like the only issue was the few minor script changes.

 

Hope this info was helpful.



#69 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 14 August 2016 - 11:12 PM

I noticed another interesting thing about QuickPE. When I use it to build either a 32 bit image OR a 64 bit image, both boot OK on a real system and on a VM. However, neither will boot using PXE's wimboot.com loader, at least not from grub2. I have no trouble booting images made with the WAIK tools using wimboot.com from grub2, either 32 or 64 bit images. I have not tried using QuickPE with the waik.

 

I did notice several differences between the images built with WAIK and those made with QuickPE:

  1. Most but not all filenames were uppercase
  2. There is no boot.catalog folder if made by the WAIK
  3. There is no \BOOT\FONTS folder or \BOOT\BOOTFIX.BIN file
  4. The \EFI\MICROSOFT\BOOT folder is empty if made by QuickPE (WAIK produces a FONTS folder and a BCD file there)
  5. The \EFI folder has an empty boot folder which the WAIK version leaves out

When booting the QuickPE 32 bit image with PXE's wimboot under grub2, wimboot reports:

- Unrecognized block type 0 and FATAL: no bootmgr.exe

 

I don't know if these differences are related to the inability of PXE's wimboot to boot the QuickPE image, but for some reason it can't. Since the QuickPE images boot OK otherwise, I suspect Wimboot may have a bug. I doubt grub2 is related, but I guess it could be.


Edited by thomnet, 14 August 2016 - 11:13 PM.


#70 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 August 2016 - 08:33 AM

Let's go "in reverse":

The \EFI\ folder contains normally parts of the booting files when the system is booted with EFI/YEFI (as opposed to BIOS).

It shouldn't make a difference in PXE booting.

Same goes for boot\fonts  (they are optional fonts) and for \boot\bootfix.bin (bootfix.bin is the file that tells you to press a key to boot from CD/DVD if a partitioned disk is found).

The boot.catalog is part of the .iso standard, it can be visible or not visible, it also shouldn't be involved.

Case of filenames might be involved though, if (as the reference to boot.catalog hints) we are talking of a .iso.

The issue might be in some parameters in the used mkisofs, that has been introduced around here:
http://reboot.pro/to...ickpe/?p=189483

 

The command line:

 

 

mkisofs.exe -iso-level 4 -l -R -J -joliet-long -D -volid "WINRE" -b boot/etfsboot.com -no-emul-boot -boot-load-size 8 -hide boot.catalog -eltorito-alt-boot -eltorito-platform efi -no-emul-
boot -b efi/microsoft/boot/efisys.bin -o x64\winre.iso x64\iso

actually hides boot.catalog (it would be easy to remove that parameter, though I don't believe it is involved), while there are a number of other parameters that might need to be changed, namely the isolevel and the Rockridge ones and it is entirely possible that names need to be uppercased.

The "standard" way to make the same .iso with OSCDIMG is:
https://support.micr...en-us/kb/947024

 

oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,bc:\winpe_x64\etfsboot.com#pEF,e,bc:\winpe_x64\efisys.bin c:\winpe_x64\ISO c:\winpe_x64\winpeuefi.iso

it is entirely possible that wimboot expects *something else* that the OSCDIMG actualy creates and that the mkisofs doesn't, including (no idea if this applies) the filesystem used (CDFS vs. UDF 1.02).

 

The experiment would be to create a winPE with QuickPE then create at the end form the same source directory tywo .iso's, one with mkisofs and one with OSCDIMG and see if the latter works with PXE wimboot and GRUB2.

 

:duff:

Wonko



#71 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 08 September 2016 - 01:45 AM

Let's go "in reverse":

The \EFI\ folder contains normally parts of the booting files when the system is booted with EFI/YEFI (as opposed to BIOS).

It shouldn't make a difference in PXE booting.

Same goes for boot\fonts  (they are optional fonts) and for \boot\bootfix.bin (bootfix.bin is the file that tells you to press a key to boot from CD/DVD if a partitioned disk is found).

The boot.catalog is part of the .iso standard, it can be visible or not visible, it also shouldn't be involved.

Case of filenames might be involved though, if (as the reference to boot.catalog hints) we are talking of a .iso.

The issue might be in some parameters in the used mkisofs, that has been introduced around here:
http://reboot.pro/to...ickpe/?p=189483

 

The command line:

actually hides boot.catalog (it would be easy to remove that parameter, though I don't believe it is involved), while there are a number of other parameters that might need to be changed, namely the isolevel and the Rockridge ones and it is entirely possible that names need to be uppercased.

The "standard" way to make the same .iso with OSCDIMG is:
https://support.micr...en-us/kb/947024

it is entirely possible that wimboot expects *something else* that the OSCDIMG actualy creates and that the mkisofs doesn't, including (no idea if this applies) the filesystem used (CDFS vs. UDF 1.02).

 

The experiment would be to create a winPE with QuickPE then create at the end form the same source directory tywo .iso's, one with mkisofs and one with OSCDIMG and see if the latter works with PXE wimboot and GRUB2.

 

:duff:

Wonko

 

I tried your experiment, well, a similar one at least. I used this command line:

OSCDIMG.EXE -n -m -o -bN:\Misc-Temp\QuickRE\x86\iso\BOOT\ETFSBOOT.COM N:\Misc-Temp\QuickRE\x86\ISO N:\Misc-Temp\QuickRE\x86\oscdIMG.ISObut it results in exactly the same errors (Unrecognized block type 0 and FATAL: no bootmgr.exe). I didn't change a thing with the ISO folder structure or any files under it, so case sensitivity may be the issue.  

I would prefer that QuickPE is built so that it will boot BIOS or EFI, but since the 32 bit Windows ISOs I have don't seem to have EFI boot files, I used the example on technet for a BIOS only machine. I will look at the case of filenames next.



#72 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 08 September 2016 - 04:00 AM

Has the window of time where edits can be made to posts been shortened on reboot.pro?

 

I couldn't find any differences in file case. I'm using 7z and isobuster to look at the ISO. It gets confusing comparing the listings from those tools to Windows Explorer when looking at the source ISO folder.

 

For example, in the source ISO\[BOOT] folder under Windows Explorer there is one file named BOOTABLE_NOEMULATION.IMG, all upper case. When I look at the ISO produced with 7z, it shows 2 files in that folder, one camel case and the other all upper case like the source folder. isobuster only shows one file, all upper case like the source.

 

Aside from the contents of the [BOOT] folder I see no differences in file name case or boot files. I checked how the old buildpe.cmd built the ISO using oscdimg.exe and it only used the -h -n -b options. I can't seem to produce an ISO manually with oscdimg.exe using the QuickPE ISO folder that boots with PXE's wimboot, tho it boots otherwise just fine. The comparison isn't perfect, b/c the ISO folder created by quickPE differs from that built by the old buildpe.cmd script. The buildpe script runs in a VM that has the WAIK installed, whereas quickPE builds the ISO folder from a DVD image. Comparison looks at the boot related files and overall folder structure.

 

Also note that I create the bootable USB using RMPrepUSB and provide the .iso file to RMPrepUSB which copies it to the USB device using 7z.

 

Next I'll try to use the source ISO created by QuickPE with a modified buildpe.cmd script in the WAIK VM. If that fails the issue is in how the ISO source tree is created.



#73 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 September 2016 - 07:22 AM

But have you tried "forcing" an UDF filesystem? (I have no real idea what Wimboot expects)

*like*:

oscdimg  -o -u2 -udfver102 -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe.iso

 

The -m and -n are only useful for CDFS.

 

I am losing you, which "old" buildpe.cmd are you referring to?

 

:duff:

Wonko



#74 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 09 September 2016 - 06:45 PM

But have you tried "forcing" an UDF filesystem? (I have no real idea what Wimboot expects)

*like*:

oscdimg  -o -u2 -udfver102 -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe.iso

I just tried the above udf parameters, same issue. Seems to be pointing to an issue with the WinRE folder contents.

 

I am losing you, which "old" buildpe.cmd are you referring to?

 

:duff:

Wonko

 

The buildpe.cmd created by Mark Minasi that I checked into github for Steadier State-2, not the QuickPE version. MM's version requires the WAIK and uses oscdimg. Very basic and minimal options, but it works:

oscdimg -h -n -betfsboot.com ISO %isofilespec%

Must be something rather subtle, since booting with PXE's wimboot is all that fails. I'm using the same tools / methods to create a bootable USB from the ISO, which boots just fine directly. However, it should be noted that MM's buildpe script was only PE, not RE like I'm now using.

 

I actually refactored the QuickPE version 0.93 and stripped out all the options that required the WAIK and removed redundancies of duplicated code. I did that anticipating it would be checked in as a change to the Steadier State-2 project. Not only does it eliminate the need for WAIK, the new QuickRE code also provides a web browser, a file explorer and full networking - basically a better installation environment than the basic WinPE used by MM. I won't add this new QuickRE to github until I resolve the wimboot issue tho.

 

The refactoring boils down to the following 2 files, which replace _RUN_ME.cmd and all of the make_*.cmd scripts. The remainder of the files and folder structure is the same as for QuickPE v0.9.3.

 

BuildRE.cmd -- replaces _RUN_ME.cmd:

@ECHO OFF
cd /D %~dp0

:START
cls
ECHO ______________________________________________________
ECHO QuickRE 0.1.0 (based on QuickPE 0.9.3)
ECHO.                                         
ECHO   Menu Choices                          
ECHO.                                         
ECHO 1 Make WINRE from host OS (UEFI ok for x64)
ECHO - 
ECHO 2 Make WINRE from iso x86 (UEFI ok) 
ECHO 3 Make WINRE from dvd x86 (UEFI ok)          
ECHO - 
ECHO 4 Make WINRE from iso x64 (UEFI ok)          
ECHO 5 Make WINRE from dvd x64 (UEFI ok)         
echo -
ECHO 6 Exit                                   
ECHO ______________________________________________________
ECHO. 
ECHO Change add-pack.sample or add-driver.sample extension 
ECHO to .cmd and edit to add packages or drivers. 
ECHO. 
SET /P userChoice=ENTER OPTION: 

if %userChoice% == 1 GOTO makere
if %userChoice% == 2 GOTO makereiso
if %userChoice% == 3 GOTO makeredvd
if %userChoice% == 4 GOTO makereiso_x64
if %userChoice% == 5 GOTO makeredvd_x64
if %userChoice% == 6 GOTO QUITMENU

GOTO QUITMENU

:makere
if %PROCESSOR_ARCHITECTURE%==x86 (
   call makeISO.cmd x86 os %SystemDrive%
) else (
   call makeISO.cmd x64 os %SystemDrive%
)
GOTO QUITMENU

:makereiso
call :getIsoFile
call makeISO.cmd x86 iso %iso%
GOTO QUITMENU

:makeredvd
call :getDVDrive
call makeISO.cmd x86 dvd %dvd%:
GOTO QUITMENU

:makereiso_x64
call :getIsoFile
call makeISO.cmd x64 iso %iso%
GOTO QUITMENU

:makeredvd_x64
call :getDVDrive
call makeISO.cmd x64 dvd %dvd%:
GOTO QUITMENU

:getDVDrive
cls
echo =========================================================
echo Enter the drive letter of the DVD from which to extract 
echo the RE (Recovery Environment) wim file.  Enter a single 
echo letter and press enter. Enter  'end'  to exit and abort
echo this script.
echo =========================================================
echo.
set /p dvd=Your response (DVD drive letter, no colon)? 
if a%dvd%==aend ((echo Exiting at your request.)&(echo.)& (goto :end))
echo.
echo Checking your input...
if exist %dvd%:\sources\boot.wim goto :eof
echo That is not an ISO file^!
goto :ERROR_OUT

:getIsoFile
cls
echo =========================================================
echo Enter the fully qualified path to the ISO file from which
echo to extract the RE (Recovery Environment) wim file.  Enter
echo 'end' to exit and abort this script.
echo =========================================================
echo.
set /p iso=Your response (folder name for ISO file)? 
if a%iso%==aend ((echo Exiting at your request.)&(echo.)& (goto :end))
echo.

echo Checking your input...
if /I %iso:~-3%==iso goto :eof
echo That is not an ISO file^!

:ERROR_OUT

:QUITMENU

makeISO.cmd -- replaces the various make_* scripts:

@echo off
:: makeISO.cmd - ISO creation -------------------------------------------
::               Parameters:
::               -- %~1: Architecture (x86 or x64)
::               -- %~2: Wim source type (os or iso or dvd)
::               -- %~3: Wim path (a drive letter or fully qualified path)
::               Returns:
::               -- nothing
::               
::               This batch file is called from the BuildRE.cmd menu to 
::               setup the folder structure, environment and copy the Wim
::               file into if from either a DVD drive letter or a Wim path.
::               It then produces the ISO file for the proper architecture.
:: SETLOCAL
cls
:: *** STEP 1 ********* Create the required folder structure 
set WINPE_ARCH=%1
set DEST=%~dp0%WINPE_ARCH%
rmdir "%DEST%" /s /q
mkdir "%DEST%"
mkdir "%DEST%\iso"
mkdir "%DEST%\iso\boot"
mkdir "%DEST%\iso\efi\boot"
mkdir "%DEST%\iso\efi\microsoft"
mkdir "%DEST%\iso\efi\microsoft\boot"
mkdir "%DEST%\iso\sources"

:: *** STEP 2 ********* Obtain the Wim file
cd /D %~dp0
if exist boot.wim del boot.wim /Q >nul
echo Getting boot.wim from "%3"
if /I "%2"=="os" (
   for /f %%a in ('dir /b /a:h /S c:\recovery\*.wim') do set WINRE=%%a
   IF "%WINRE%" == "" GOTO error
   attrib -H -S -R %WINRE%
   copy "%WINRE%" "%DEST%\iso\sources\boot.wim"
   attrib +H +S +R %WINRE%
) else (
   if /I "%2"=="iso" (
      pe_tools\7-zip\7z.exe e "%3" sources\boot.wim
      move boot.wim "%DEST%\iso\sources"
   ) else (
      copy "%3\sources\boot.wim" "%DEST%\iso\sources"
   )
)
::
:: *** STEP 3 ********* Actually produce the ISO based on architecture
::
rem ******** Get the index 2 image from boot.wim (Recovery Environment)
pe_tools\wimlib\wimlib-imagex.exe export "%DEST%\iso\sources\boot.wim" 2 "%DEST%\iso\sources\boot2.wim" --boot
if exist "%DEST%\iso\sources\boot.wim" del "%DEST%\iso\sources\boot.wim" /q
ren "%DEST%\iso\sources\boot2.wim" boot.wim
if NOT exist "%DEST%\iso\sources\boot.wim" goto :error
echo ""!!!!!! BOOT.WIM OK "!!!!!!"
echo.
rem ******** Get the BootMgr files for BIOS and EFI
pe_tools\wimlib\wimlib-imagex.exe extract "%DEST%\iso\sources\boot.wim" 1 /Windows/Boot/PCAT/bootmgr --dest-dir="%DEST%\iso"
pe_tools\wimlib\wimlib-imagex.exe extract "%DEST%\iso\sources\boot.wim" 1 /Windows/Boot/EFI/bootmgr.efi --dest-dir="%DEST%\iso" --nullglob
pe_tools\wimlib\wimlib-imagex.exe extract "%DEST%\iso\sources\boot.wim" 1 /Windows/Boot/EFI/bootmgfw.efi --dest-dir="%DEST%\iso\efi\boot" --nullglob
ren "%DEST%\iso\bootmgr.efi" BOOTMGR.EFI
ren "%DEST%\iso\bootmgr" BOOTMGR
if /I "%1"=="x86" (
   copy "%DEST%\iso\BOOTMGR" pe_extra\Other /Y >NUL
   ren "%DEST%\iso\efi\boot\bootmgfw.efi" BOOTIA32.EFI
   set WIM_UPDATE=wim-update.txt
   set EXTRAS=extra.cmd
) else (
   copy "%DEST%\iso\BOOTMGR" pe_extra_x64\Other /Y >NUL
   ren "%DEST%\iso\efi\boot\bootmgfw.efi" BOOTX64.EFI
   set WIM_UPDATE=wim-update_x64.txt
   set EXTRAS=extra_x64.cmd
)
pe_tools\wimlib\wimlib-imagex.exe extract "%DEST%\iso\sources\boot.wim" 1 /Windows/Boot/DVD/PCAT/bcd --dest-dir="%DEST%\iso\boot"
pe_tools\wimlib\wimlib-imagex.exe extract "%DEST%\iso\sources\boot.wim" 1 /Windows/Boot/DVD/EFI/bcd --dest-dir="%DEST%\iso\efi\microsoft\boot" --nullglob
pe_tools\wimlib\wimlib-imagex.exe extract "%DEST%\iso\sources\boot.wim" 1 /Windows/Boot/DVD/EFI/en-US/efisys.bin --dest-dir="%DEST%\iso\efi\microsoft\boot" --nullglob
pe_tools\wimlib\wimlib-imagex.exe extract "%DEST%\iso\sources\boot.wim" 1 /Windows/Boot/DVD/PCAT/boot.sdi --dest-dir="%DEST%\iso\boot"
pe_tools\wimlib\wimlib-imagex.exe extract "%DEST%\iso\sources\boot.wim" 1 /Windows/Boot/DVD/PCAT/etfsboot.com --dest-dir="%DEST%\iso\boot"
echo ""!!!!!! WINRE BUILT OK "!!!!!!"
echo.
rem ******** Update the basic WinRE with our customizations using the awesome WimLib
cd %~dp0
if exist wim-update.new del wim-update.new /q
sed -e "s/#path#//g" %WIM_UPDATE% > wim-update.new
pe_tools\wimlib\wimlib-imagex.exe update "%DEST%\ISO\sources\boot.wim" < %~dp0wim-update.new
IF NOT %ERRORLEVEL%.==0. goto error
echo ""!!!!!! CUSTOMIZED WIM OK "!!!!!!"

rem ******** Add any drivers we find
if exist add-drivers3.cmd call add-drivers3.cmd "%DEST%\iso\sources\boot.wim" %1
if exist %EXTRAS% call %EXTRAS% "%DEST%\iso\sources\boot.wim" %1
echo ""!!!!!! WIM CHANGES  DONE "!!!!!!"
echo.
rem ******** Finally, produce the ISO file from file structure
if exist "%DEST%\iso\efi\microsoft\boot\efisys.bin" (
   call mkisofs.exe -iso-level 4 -l -R -UDF -D -volid "WINRE" -b boot/etfsboot.com -no-emul-boot -boot-load-size 8 -hide boot.catalog -eltorito-alt-boot -eltorito-platform efi -no-emul-boot -b efi/microsoft/boot/efisys.bin -o "%DEST%\winre.iso" "%DEST%\iso"
) else (
   echo "!!!!!! efisys.bin MISSING !!!!!!"
   call mkisofs.exe -iso-level 4 -l -R -J -joliet-long -D -volid "WINRE" -b boot/etfsboot.com -no-emul-boot -boot-load-size 8 -hide boot.catalog -o "%DEST%\winre.iso" "%DEST%\iso"
)

echo.
echo "!!!!!! ISO BUILT OK "!!!!!!"
echo.
goto end

:error
echo.
echo "!!!!!! ERROR OCCURED !!!!!!"
echo.

:end
goto :EOF


#75 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 September 2016 - 07:12 PM

It is strange, though I am not even sure what works and what not.

 

Can you confirm that OSCDIMG made .iso's work and MKISOFS made ones do not?

 

Maybe it is an issue with file position (if this is the case then the Wimboot has a bug, minor as you want but still a bug).

Mkisofs has however an option to write files with a given "priority", in case.

 

You need a tool like isobuster (or similar) to find the actual file extents and compare them, but before that, have you tried some varations of the mkisofs command?

 

I mean, right now you have the -R switch (that will create a RockRidge directory structure) in one of the two commands and -J -joliet-long on the other (which will create a Joliet directory structure) whilst the:
oscdimg -h -n -betfsboot.com ISO %isofilespec%

seems like "as plain as possible" (maybe it has just a lower isolevel directory structure).

 

Another question.

 

Does the issue appear with just BOOTMGR and \boot\BCD (or their EFI counterparts) or is the boot.wim involved?

(of course if there is a "fake" boot.wim the bootmgr will give an error, but it would be useful to understand if the Wimboot rror hapens before the bootmgr runs or 

 

Can you post a set of commands that work (making use of oscdimg) and a set of commands that do not work (making use of OSCDIMG or MKISOFS)?

 

:duff:

Wonko







Also tagged with one or more of these keywords: winpe3, winpe, winre, boot, winpe4

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users