109 replies to this topic

[thomnet]

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)?

 

Wonko

 

What works is the original MM buildpe.cmd script that only runs under WAIK. It uses that ultra simple oscdimg command line I posted before. It works just fine in all respects with 32 and 64 bit images.

 

What doesn't work is any version built with QuickPE or QuickRE (selecting an RE not a PE build).

 

I cannot confirm that all ISO's made with oscdimg work (and those made with mkisofs do not). I replaced the mkisofs with oscdimg in the makeISO.cmd script (not shown in code above) with the simple set of options / parameters used by MM's buildpe.cmd script but it too failed to boot with wimboot (it booted just fine from the USB key directly tho).

 

As for the mkisofs switches used in the makeISO.cmd script, they are exactly the same as in QuickPE version 0.9.3. I think the reason for the Rockridge vs Joliet options are due to issues erwan.l had with UEFI support. That is the distinctive difference between the 2 mkisofs lines, one is for EFI the other for BIOS..

 

As for when the error occurs, it is after grub2 loads the PXE wimboot. The error is reported by the wimboot code when it attempts to load the (boot.wim / sdi / bcd) files.

 

I have already posted the oscdimg commands that do work, and the mkisofs options that don't in my last post. HOWEVER, please be aware that the files and folders in the source ISO are quite different, and my gut tells me that's where the issue lies, and I suspect it lies in the boot files or folders ([BOOT] or the folders under BOOT).

 

Not sure what you mean by "extents", but if you explain that and what to compare using ISObuster I can scrutinize the ISO contents more carefully. Particularly with a focus on the boot files in the ISO structure.

[Wonko the Sane]

Explanation of the "extents" note (but won't be needed in this case see below).
When you create a .iso files are inserted in a filesystem in a given order (like alphabetically) so a file (for the example) called aardvark.exe will be written before a file boot.wim.
In some cases if the files put before some other files (needed in the early booting phase) make these latter "shift" their position beyond some limit in the loader this may be able to not "reach" the file. (this happened as an example with SETUPLDR.BIN in the good ol' XP/PE 1.x days)
Additionally and as a side-side note (but this is not the case for bootable media that uses containers such as .wim's) if the order in which files are written (sequentially) is the same as the order in which a file is loaded/accessed during booting, booting speed will be dramatically shorter and the burned CD will be somehow working "better" on all drives.
The right sequence also helps on media such as CF cards or USB sticks or more generally on anything that is slowish.

Extents is the generic term used to identify the position and length of a file (what you would give to - say - dd to extract the file with direct access to the device) , usually LBA is used (also on optical media), a file starting at LBA 1025 and extending for 300 sectors will be in the very early part of a CD/DVD.
JFYI:
http://www.911cd.net...?showtopic=6869
http://www.911cd.net...showtopic=13715
http://www.911cd.net...&st=40&start=40

Back to topic, then the issue is not with the creation of the CD/DVD but rather with the single files:
BOOTMGR
\boot\BCD
boot.sdi
and possibly boot.wim

They are all "interchangeable" (in theory) in the sense that:
BOOTMGR <- should be "fixed" and "same
\boot\boot.sdi <- should be "fixed" and "same" (it is just a generic NTFS filesystem used to mount the boot.wim)
boot\BCD <- it may be different and even invalid, but the error should come from BOOTMGR, not from Wimboot
\sources\boot.wim <- it will be different and even invalid, but the error should come from BOOTMGR or from WINLOAD.EXE, not from Wimboot

What I would try would be to make a copy of the source directory created by the working (WAIK based) script, then experiment with replacing in it those files one by one with those created by the (non WAIK based) script, create the .iso from this modified source and see what happens with Wimboot.

Most probably the first three files are anyway identical, so what would remain is only the boot.wim, and if this is what causes the error than the issue is likely to be some incompatibility of the "wimlib-imagex.exe update".
IF this is the case, if you just REM out the "customize part" of the script (only for the experiment) the result should be a "standard" WinRE but working with Wimboot and with the iso.
It could be also the earlier use of "wimlib-imagex.exe export" but this is IMHO less likely.

Finally it is also possible that the WinRE boot.wim itself is *somehow* incompatible with Wimboot .


Wonko

[thomnet]

Thanks Wonko for the extent explainer.

 

I will look at the uncustomized RE and see if that works, also take a WinPE boot.wim that is known to work (built with MM's buildpe.cmd) and plug it into the makeISO.cmd and see if that can be booted with wimboot.

 

Essentially the 2 variables I'll focus on are the boot.wim file (Re vs. PE) and oscdimg vs. mkisofs. First I'll remove all of the customizations on the RE and see if that works, based on the QuickRE scripts I posted above. If that works the problem is with the customizations. If not it could be something about the RE itself.

 

Second I'll make an ISO using a boot.wim known to work made via WAIK and buildpe.cmd, then use the code in makeISO.cmd to produce an ISO. If that works it points to the problem being in the boot.wim file. If it doesn't work it points to the options used in makeISO.cmd to produce the .ISO file.

[thomnet]

I found the problem. It was a driver file, not sure which one.

The driver pack files I downloaded from DriverPacks.net for WLAN and LAN contained drivers for Vista, Windows 7, Windows 8 and "server". I wrongly assumed only the drivers  needed for the hardware it was running on would be loaded. Sadly, that wasn't the case.

Since the machine boots fine EXCEPT when using PXE's wimboot loader it seems there is an issue with the wimboot loader related to drivers.

I simply moved all but the Windows 7 folder to outside the drivers folder. Boots fine with grub2 --> PXE-wimboot now.

The x86 iso (RE) without extra drivers was 152 MB. With the Win7 LAN and WLAN drivers it is 184 MB.

Edited by thomnet, 11 September 2016 - 12:09 AM.

[Wonko the Sane]

Good, mistery solved.

 

Most probably - even when used "locally" - Wimboot attempts some kind of LAN access and creates the error before actually booting to BOOTMGR, etc.

 

Wonko

[erwan.l]

After looking at WinXShell, I have decided to drop Tinyshell as the winpe shell and adopt WinXshell.

 

The shortcuts on the desktop can be added thru a batch named desktop.cmd in the pe_extra folder.

 

New QuickPE.zip uploaded.

 

As always, drop any file(s) in \pe_extra, or \pe_files\windows or \pe_files\program files and it will be added in the WIM file.

If you want any extra command to be run at the end of the generating script, rename extra.sample to extra.cmd.

About the winpe itself, extra.bat (in \pe_extra) will be called after the winpe shell has been loaded.

 

[mortblanche]

Hello Erwan,

 

I'm having a problem with the new version, which version of AIK or WAIK?

 

In Windows 7? In Windows 8?

 

I do it under a VM, the quickpe boote but a reboot on arrival under the desk.

 

What do you think ?

 

Regards,

 

Mortblanche

[erwan.l]

which option do you choose in the below menu?

version of AIK/WAIK depends on your choice.

 

[mortblanche]

Hello,

 

I tried both and the problem is the same.

 

Regards,

 

Mortblanche

[erwan.l]

 

Hello,

 

I tried both and the problem is the same.

 

Regards,

 

Mortblanche

 

 

Please try option 4 or 5.

 

In the meantime I'll reinstall waik/Adk and will test option 1 & 2.

[mortblanche]

Good evening,

 

I just tested option 4 & 5, I have a window that opens, here it is :

 

 

cordially

 

Mortblanche

[erwan.l]

Good evening,

 

I just tested option 4 & 5, I have a window that opens, here it is :

 

 

cordially

 

Mortblanche

 

what happens next ? pick a folder containing an iso or a folder containing the install files.

[mortblanche]

Good evening, I just selected a folder and another message appears: here it is :

 

Regards, Mortblanche

Good evening, I just selected a folder and another message appears: here it is : Regards, Mortblanche

[erwan.l]

Good evening, I just selected a folder and another message appears: here it is :

 

Regards, Mortblanche

Good evening, I just selected a folder and another message appears: here it is : Regards, Mortblanche

 

select a folder containing an iso (option 4) or installation files (option5 - the selected folder should then a sources sub folder containing boot.wim).

[mortblanche]

Good evening,

with option 5, I have a new message. here it is :

 

After verification, no file is present?

Regards,

Mortblanche

[erwan.l]

de

 

Good evening,

with option 5, I have a new message. here it is :

 

After verification, no file is present?

Regards,

Mortblanche

 

 

describe (via a screenshot for example) what you have in selected folder.

[mortblanche]

Good evening,

in a nutshell, I run the make_re_from_iso.cmd script directly to test, it asks me where the boot.win source is and the previous message appears, I am on a Windows 7 vm.

when i check in the quickpe \ x86 folder - only the tree is created but no file is copied.

I think I have gone around.

Regards,

Mortblanche

[erwan.l]

Good evening,

in a nutshell, I run the make_re_from_iso.cmd script directly to test, it asks me where the boot.win source is and the previous message appears, I am on a Windows 7 vm.

when i check in the quickpe \ x86 folder - only the tree is created but no file is copied.

I think I have gone around.

Regards,

Mortblanche

 

In short, in the folder you select, depending on the option, you either need to have a windows ISO (windows 7 and up) OR the windows (7 and up) installation files (i.e that folder should contain a sources folder which himself will contain a boot.wim).

QuickPE will not recursively scan folder so the folder you select should be the top folder.

 

Make sure you launch QuickPE as local admin.

 

Launch _RUN_ME.CMD rather than the child batches.

[Wonko the Sane]

@erwan.l

I may well be wrong of course but it seems to me like lately the issues are derived (mainly) by the ..vbs you use to look for a folder (as opposed to a given file).

 

Our good friend Rob Van Der Woude has now seemingly lost touch with the base and proposes a .Net based executable

 

There are a couple (IMHO better) solutions on StackOverflow, if we allow the use of Powershell, but all in all the "pure batch" (requires choice.exe so not good for "plain" XP, but in any case I doubt that many people will use QuickPE under XP) seems to me more "in line" with the command line interface of QuickPE, JFYI:

https://stackoverflo...ws-batch-script

https://stackoverflow.com/a/28184159

 

Wonko

[erwan.l]

@erwan.l

I may well be wrong of course but it seems to me like lately the issues are derived (mainly) by the ..vbs you use to look for a folder (as opposed to a given file).

 

Our good friend Rob Van Der Woude has now seemingly lost touch with the base and proposes a .Net based executable

 

There are a couple (IMHO better) solutions on StackOverflow, if we allow the use of Powershell, but all in all the "pure batch" (requires choice.exe so not good for "plain" XP, but in any case I doubt that many people will use QuickPE under XP) seems to me more "in line" with the command line interface of QuickPE, JFYI:

https://stackoverflo...ws-batch-script

https://stackoverflow.com/a/28184159

 

Wonko

 

Agreed : I am not comfortable with using this VBS script.

And actually this is also why I am not comfortable with going with any other script engine relying on some local runtime (that includes Powershell).

 

Hence, I have replaced it by my own "select.exe" which will work on XP and up.

 

Maybe this will adress Mortblanche issue?

[Wonko the Sane]

Maybe this will adress Mortblanche issue?

Yes, as I see it (but more or less the same thing happened to Thomnet) is that the .vbs wants the user to select a folder containing the .iso (or the .wim) but this is most unnatural, you don't select normally a folder containing the file, but rather the specific file, and then if I got it right the script automagically selects first file with the wanted extension it finds , and this is evidently prone to errors (or at least confusing).

 

For the record the proposed "pure batch" solution (with the limitation of the choice.exe presence) has the advantage that user doesn't need the mouse, he selects a choice on the keyboard and then - still through the keyboard only - chooses the path and selects the file.

 

Wonko

[erwan.l]

Yes, as I see it (but more or less the same thing happened to Thomnet) is that the .vbs wants the user to select a folder containing the .iso (or the .wim) but this is most unnatural, you don't select normally a folder containing the file, but rather the specific file, and then if I got it right the script automagically selects first file with the wanted extension it finds , and this is evidently prone to errors (or at least confusing).

 

 

Aggreed : I shall work on that.

I should be able to tweak select.exe so that it either asks for a folder (dvd) or file (iso).

 

Indeed, ideally, it should be all down to a batch but selecting a file thru a batch would mean to type a path which I believe will also lead to user errors.

[Wonko the Sane]

... but selecting a file thru a batch would mean to type a path which I believe will also lead to user errors.

Read (and try) the given batch file example  :

https://stackoverflow.com/a/28184159

 

Wonko

[erwan.l]

Read (and try) the given batch file example  :

https://stackoverflow.com/a/28184159

 

Wonko

 

Will do

Long and painful day at work, lazy brain, reading "in diagonal" mode ...

[erwan.l]

Aggreed : I shall work on that.

I should be able to tweak select.exe so that it either asks for a folder (dvd) or file (iso).

 

Indeed, ideally, it should be all down to a batch but selecting a file thru a batch would mean to type a path which I believe will also lead to user errors.

 

Uploaded a new version.

 

Now the user can select either a folder when selecting the DVD (or install files) option or a file when selecting an ISO.

More user friendly

 

"User friendly" is my middle name...