Jump to content











Photo
- - - - -

QuickPE

winpe3 winpe winre boot winpe4

  • Please log in to reply
79 replies to this topic

#76 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 10 September 2016 - 12:09 AM

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

 

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.



#77 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 10 September 2016 - 08:09 AM

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 :dubbio:.

:duff:
Wonko

#78 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 10 September 2016 - 05:57 PM

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.



#79 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 11 September 2016 - 12:03 AM

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.


#80 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 September 2016 - 09:33 AM

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. :unsure:

 

:duff:

Wonko







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

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users