I played a bit with wimlib's ability to apply wimboot without the need of the WOF driver.
There a few problems I noticed:
Applying if source and destination drive are different fails.
Applying image 1 ("Windows 8.1 Pro") from "P:\install.wim" to directory "X:\" [WARNING] Image is not marked as WIMBoot compatible! [WARNING] WOF driver is not available; updating WimOverlay.dat directly. [ERROR] "\?\PhysicalDrive2": Can't get disk info (err=0x0000007a)
ERROR: Exiting with error code 50:
Could not read data from a file.
However applying from drive X:\install.wim to X:\ works, just a warning.
Properly because the log files from system hive are pointer files, so loading the hive fails.
[WARNING] Failed to set \Setup: dword "WimBoot"=1 value in registry hive "\?\X:\Windows\System32\config\SYSTEM" (err=1920): Unknown error
To be able to create boot files with bcdboot, I add these files to WimBootCompress.ini
[ERROR] "\?\PhysicalDrive2": Can't get disk info (err=0x0000007a)
Probably your disk containing P:\ has too many partitions (more than 8). I should be able to fix this.
However applying from drive X:\install.wim to X:\ works, just a warning.
Properly because the log files from system hive are pointer files, so loading the hive fails.
Yes, you should add those files to [PrepopulateList]. Those files shouldn't even be included in the WIM image. (You may notice that they're listed in [ExclusionList].)
This works nice, but add_tree complains about read-only Wim.
wimlib_add_tree() is just a wrapper around wimlib_update_image(). The problem is that the WIM is considered readonly for one of these three reasons:
not a standalone WIM
READONLY flag set in WIM header
operating system file permissions don't allow writing
It is intentional that write access is denied if any of the above is true. Try granting yourself write access to the WIM file in Windows and see if it fixes the problem.
Older version send 250 WIMLIB_PROGRESS_MSG_WIMBOOT_EXCLUDE messages
But now with the current version, there are only 75.
Can you provide an example of a file path for which you received WIMLIB_PROGRESS_MSG_WIMBOOT_EXCLUDE in 1.7.1 but not in 1.7.2? And provide the WimBootCompress.ini file being used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is intentional that write access is denied if any of the above is true. Try granting yourself write access to the WIM file in Windows and see if it fixes the problem.
On second thought, I suppose it would be reasonable to limit the writable checks to wimlib_open_wim() (only if WIMLIB_OPEN_FLAG_WRITE_ACCESS specified) and wimlib_overwrite() --- since wimlib_update_image() only makes in-memory changes. I think you're the first person to actually make use of this capability; wimlib-imagex will never make in-memory changes to a WIM before extracting it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All right, I've just a few updates and posted a v1.7.3-BETA in the "testing" directory. It hopefully should address everything you brought up.
"Can't get disk info" error - the code no longer has a fixed limit of 8 partitions. (Note: this limit could be reached without having 8 actual partitions, because for some reason the Windows API returns more partitions than you actually have.)
"Failed to set dword ... in registry hive" error - the pattern "\Windows\System32\config\SYSTEM*" is now treated as if it's always in PrepopulateList.
"add_tree complains about read-only Wim" - checks for the WIM being read-only are now only made if you actually attempt to overwrite the on-disk file, or if you explicitly open the WIM for write access.
"But 1.7.2 seems to ignore these 2 filters" - the library now attempts to match patterns against every name (hard link) of each file, rather than just the first. I expect that this caused your problem --- although it would have had to be largely random that v1.7.1 "worked" but v1.7.2 did not!
Let me know how v1.7.3-BETA works for you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Eric,
Thanks a lot for your great wimlib library.
I played a bit with wimlib's ability to apply wimboot without the need of the WOF driver.
There a few problems I noticed:
Applying if source and destination drive are different fails.
Applying image 1 ("Windows 8.1 Pro") from "P:\install.wim" to directory "X:\"
[WARNING] Image is not marked as WIMBoot compatible!
[WARNING] WOF driver is not available; updating WimOverlay.dat directly.
[ERROR] "\?\PhysicalDrive2": Can't get disk info (err=0x0000007a)
ERROR: Exiting with error code 50:
Could not read data from a file.
However applying from drive X:\install.wim to X:\ works, just a warning.
Properly because the log files from system hive are pointer files, so loading the hive fails.
[WARNING] Failed to set \Setup: dword "WimBoot"=1 value in registry hive "\?\X:\Windows\System32\config\SYSTEM" (err=1920): Unknown error
To be able to create boot files with bcdboot, I add these files to WimBootCompress.ini
\Users\Default\NTUSER.DAT*
\Windows\Boot
\Windows\System32\bootstr.dll
*bootstr.dll.mui
\Windows\System32\config
\bootmgr
\Boot
Using the following way to apply wimboot image without WOF driver
wimlib_open_wim
extract WimBootCompress.ini with wimlib_extract_paths
add updated WimBootCompress.ini with wimlib_add_tree
wimlib_extract_image
This works nice, but add_tree complains about read-only Wim.
Would this read-only check no be better placed on wimlib_update_image?
Also now with version 1.7.2, there is a problem with the PrepopulateList.
Older version send 250 WIMLIB_PROGRESS_MSG_WIMBOOT_EXCLUDE messages
But now with the current version, there are only 75.
Last edit: JFX 2014-10-13
Probably your disk containing P:\ has too many partitions (more than 8). I should be able to fix this.
Yes, you should add those files to [PrepopulateList]. Those files shouldn't even be included in the WIM image. (You may notice that they're listed in [ExclusionList].)
wimlib_add_tree() is just a wrapper around wimlib_update_image(). The problem is that the WIM is considered readonly for one of these three reasons:
It is intentional that write access is denied if any of the above is true. Try granting yourself write access to the WIM file in Windows and see if it fixes the problem.
Can you provide an example of a file path for which you received WIMLIB_PROGRESS_MSG_WIMBOOT_EXCLUDE in 1.7.1 but not in 1.7.2? And provide the WimBootCompress.ini file being used.
On second thought, I suppose it would be reasonable to limit the writable checks to wimlib_open_wim() (only if WIMLIB_OPEN_FLAG_WRITE_ACCESS specified) and wimlib_overwrite() --- since wimlib_update_image() only makes in-memory changes. I think you're the first person to actually make use of this capability; wimlib-imagex will never make in-memory changes to a WIM before extracting it.
My Disk 2 only have 4 Partitions 2 primary and to extended.
Here's my WimBootCompress.ini: http://pastebin.com/FxuVwBqi
And yes version 1.7.1 works perfecly.
But 1.7.2 seems to ignore these 2 filters:
\Windows\Boot
\Windows\System32\bootstr.dll
Yes, these in-memory changes are a great feature.
And your right I could change the read only attribute temporary.
Thought it might be difficult if the wimboot.wim is protected with NTFS security settings.
All right, I've just a few updates and posted a v1.7.3-BETA in the "testing" directory. It hopefully should address everything you brought up.
"Can't get disk info" error - the code no longer has a fixed limit of 8 partitions. (Note: this limit could be reached without having 8 actual partitions, because for some reason the Windows API returns more partitions than you actually have.)
"Failed to set dword ... in registry hive" error - the pattern "\Windows\System32\config\SYSTEM*" is now treated as if it's always in PrepopulateList.
"add_tree complains about read-only Wim" - checks for the WIM being read-only are now only made if you actually attempt to overwrite the on-disk file, or if you explicitly open the WIM for write access.
"But 1.7.2 seems to ignore these 2 filters" - the library now attempts to match patterns against every name (hard link) of each file, rather than just the first. I expect that this caused your problem --- although it would have had to be largely random that v1.7.1 "worked" but v1.7.2 did not!
Let me know how v1.7.3-BETA works for you.
Wow, that was really fast.
And I can confirm all 4 points are fixed with the 1.7.3-BETA
Thanks a lot!