Package Details: wimlib 1.11.0-1

Git Clone URL: (read-only)
Package Base: wimlib
Description: A library and program to extract, create, and modify WIM files
Upstream URL:
Licenses: custom
Submitter: Synchronicity
Maintainer: Synchronicity
Last Packager: Synchronicity
Votes: 63
Popularity: 0.710934
First Submitted: 2012-05-02 03:25
Last Updated: 2017-01-18 06:53

Dependencies (9)

Required by (0)

Sources (1)

Latest Comments

Synchronicity commented on 2017-02-11 23:53

If the mount test is failing for you, then please send me your test-suite.log, and let me know whether you are using a non-standard kernel such as grsecurity, and what the permissions on your /dev/fuse are.

wat commented on 2017-02-11 21:20

I am having the same problem as rasoran

rasoran commented on 2017-01-22 00:12

wimlib 1.11.0-1 is failing a test

FAIL: tests/test-imagex-mount

swiftgeek commented on 2016-05-19 09:48

Got new issue - due to GUID not being the same as boot.wim from source Win10 install image, mkwinpeimg creates unbootable image :(
EDIT:Sorry i think i made the same mistake again - it requires mbr partition scheme to boot, no change to bcd needed

tancrackers commented on 2016-03-12 22:45

Weird. It worked now O_o

Synchronicity commented on 2016-03-12 15:22

Please send me your test-suite.log.

tancrackers commented on 2016-03-12 12:19

I get this error:

Makefile:2063: recipe for target 'test-suite.log' failed
make[2]: *** [test-suite.log] Error 1
make[2]: Leaving directory '/tmp/yaourt-tmp-john/aur-wimlib/src/wimlib-1.9.1'
Makefile:2169: recipe for target 'check-TESTS' failed
make[1]: *** [check-TESTS] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-john/aur-wimlib/src/wimlib-1.9.1'
Makefile:2403: recipe for target 'check-am' failed
make: *** [check-am] Error 2

Synchronicity commented on 2016-02-02 01:19

Thanks. I will remove ntfsprogs from the PKGBUILD in the next version.

chungy commented on 2016-02-01 15:59

ntfsprogs can be removed from the optdepends. They've been part of ntfs-3g for a while now.

Synchronicity commented on 2015-11-14 20:36

v1.8.3 of the package, just uploaded, addresses the issue reported earlier in these comments by 'techryda'.

Synchronicity commented on 2015-08-11 14:56

Thanks for the report. The failure was caused by the FUSE device not being available to run the WIM mounting tests. It's not wimlib's responsibility to make sure that the FUSE device is available. However, I might change the test to be skipped in the case where the FUSE device isn't available (the NTFS capture/apply test currently has that behavior and was skipped rather than failed).

Users who do not want WIM mounting support also have the option of configuring wimlib --without-fuse.

tancrackers commented on 2015-08-11 12:29

I was using grsec kernel, and realized that that may have caused the error. The package installed just fine under the default Arch kernel. I'll email you the log anyway, if you want to see.

Synchronicity commented on 2015-08-10 21:34

@tancrackers can you send me the test-suite.log file?

tancrackers commented on 2015-08-10 21:07

I get this:
Testsuite summary for wimlib 1.8.1
# TOTAL: 5
# PASS: 3
# SKIP: 1
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
See ./test-suite.log
Please report to
Makefile:2005: recipe for target 'test-suite.log' failed
make[2]: *** [test-suite.log] Error 1
make[2]: Leaving directory '/tmp/yaourt-tmp-john/aur-wimlib/src/wimlib-1.8.1'
Makefile:2111: recipe for target 'check-TESTS' failed
make[1]: *** [check-TESTS] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-john/aur-wimlib/src/wimlib-1.8.1'
Makefile:2345: recipe for target 'check-am' failed
make: *** [check-am] Error 2
==> ERROR: A failure occurred in check().
==> ERROR: Makepkg was unable to build wimlib
I'm trying to upgrade to 1.8.1-2

Synchronicity commented on 2015-08-06 02:08

Thanks techryda. Yeah, I decided it was time to get off of SourceForge. I replied to your post on the new forums. (There are no email notifications yet, by the way.)

techryda commented on 2015-08-05 17:17

Well, I've been in the hospital for the last week...just getting back to business. I see you have a site and a forum setup now. I'll test the latest version (and 1.8.0, if necessary) and report back there.


Synchronicity commented on 2015-07-30 01:32

There are a few things you could try to narrow the problem down.

Since you reported that earlier versions worked, you could try testing v1.7.4 and v1.8.0 in the exact same situation (exact same filesystem).

You could also try downgrading ntfs-3g from version 2015.3.14-1 to version 2014.2.15-1.

If you want to diff the good and bad filesystems directly you could mount them with ntfs-3g and do a diff, or capture them both with wimlib-imagex and take the diff of the output of 'wimdir --detailed' on each WIM image. But if there is a capture-side problem with NTFS-3g and/or wimlib then it might not be detected.

techryda commented on 2015-07-29 17:00

I realized that I didn't answer one of your questions.

Previous versions of wimlib worked with the exact same 'workflow', but different installs of Windows. These machines are offline, when installed and when imaged. The only other variable that I can think of would be Arch package updates.

techryda commented on 2015-07-29 16:40

Sorry for the vague description, I understand the need for precision...just didn't know what info to provide.

Here are my tools:
- Working with an Arch Linux (32-Bit) install on a USB key
- ntfs-3g
- wimlib (from AUR)
- ms-sys (from AUR)

- Windows 7 DVD (32-Bit)

- Two PC's (Same model)

Here's my workflow:
=== Capture image ===
From Arch USB Key (32-bit) (on PC1)
- Create a 20GiB NTFS Partition
- Make Partition active/bootable

With Windows DVD (on PC1)
- Install Windows 7

From Windows (PC1)
- Enter Audit Mode
- Install Office
- Install Firefox and plugins
- 'Sysprep' - 'Generalize' from 'Audit mode sysprep window'
- Shutdown

Boot from Arch USB key (PC1)
- Capture image of Windows using wimlib
# wimcapture /dev/sda1 Win7-32Bit.wim "Windows 7 32-Bit"
- Capture image of Windows using ntfs-3g
# ntfsclone -s -o - /dev/sda1 | bzip2 -c > Win7-32Bit.bz2

=== End Capture ===

=== Deploy image using wimapply (PC2) ===
Boot from Arch USB key
- Create a 20GiB NTFS Partition on internal HD
- Make Partition active/bootable
- Run
# wimapply Win7-32Bit.wim /dev/sda1
# ms-sys -7 /dev/sda
- Reboot
- (imprecise description) Windows never gets to 'mini-setup', it boots, detects hardware, reboots and begins a boot loop
(Not in front of the PC now so can't give a more detailed description, I'll update later)

=== Deploy image using ntfsclone (PC2) ===
Boot from Arch USB key
- Create a 20GiB NTFS Partition on internal HD
- Make Partition active/bootable
- Run
# bunzip2 -c Win7-32Bit.bz2 | ntfsclone -r -O /dev/sda1 -
# ms-sys -7 /dev/sda
- Reboot
- Windows boots successfully

This is my usual workflow, nothing strange, no extra utilities.

Also, it wasn't accurate of me to say that I narrowed it down to 'this' version.
I have been using wimlib for several years and this is the first time I've had an issue with it.
It was probably March the last time I 'created' a new image with it. So 1.8.0 or, if for some odd reason I didn't update my system, 1.7.4

What kind of comparison could I do between the two deployed images to see what's going on?

Synchronicity commented on 2015-07-29 00:29

Hi techryda,

It can be difficult to debug problems like "Windows doesn't boot", unfortunately.

I assume that you're using the wimlib's NTFS-3g support, i.e. capturing from and applying directly to a block device?

You say you've narrowed it down to "this version of wimlib" (v1.8.1) --- does that mean that previous versions work, even with the exact same filesystem? If previous versions worked, it would be helpful to know which version introduced the problem.

There will some minor changes to NTFS-3g capture and apply in v1.8.2, but this problem is probably not related.

I'll consider adding a wimlib-git package.

techryda commented on 2015-07-28 18:01

Since 1.8.1 I cannot successfully restore a sysprepped Windows 7 image (The only kind I've tried) Windows begins the 'first-boot' process and then goes into a reboot loop with the 'Windows Error Recovery' menu coming up each time. I've tested this on several machines I've reinstalled Windows and recaptured the image at least 6 times. (I just knew it had to be me :-) But I've narrowed it down to this version of wimlib. I even captured the same sysprepped machine with both wimlib and ntfsclone. The version captured and deployed on another PC w/ntfsclone boots and finishes mini-setup just fine. The version captured and deployed with wimcapture/wimapply goes into the boot loop I mentioned. I don't know what info might be helpful to track down the problem but I'm hoping the soon to come out 1.8.2 will fix (has fixed) this issue.

Let me know if I can provide you with any other info, and thank you so much for this utility it's been working great! (until now :-)

Also, is there any possibility of you setting up a wimlib-git in the AUR to built the latest version?

swiftgeek commented on 2014-08-08 15:59

Ok, I have got an idea for feature request for `mkwinpeimg`:
• Overlay, but for root of disk/iso image
• (Creating disk image with mbr/gpt, prerequisite for UEFI boot)
• (UEFI boot, bootloader - 1/Windows/Boot/EFI/bootmgfw.efi from install.wim)
(I have no idea how to do middle one without root)

For now i'm just using ^Z while files are extracting from iso

Synchronicity commented on 2014-02-10 15:01

It already has sha1sums=('11e06e0dbd2145d07dfa99fa047e7e121b79dc71') which seems to be sufficient. Is there any reason for MD5 to be preferred?

helasz commented on 2014-02-10 07:42

Should be added checksum to PKGBUILD:

swiftgeek commented on 2014-01-03 05:16

I have no idea how to access partitions under image file with mbr without losetup && partprobe (so root privileges),
but I guess that copying EFI dir could be still useful with some extra warning in man/output (If that's ok i may lurk into script but … not sure if i have enough skills to do that :P)

Synchronicity commented on 2014-01-02 21:33

I've updated the package to v1.6.0 (just released) and fixed the ntfs-3g dependency and problem with the new syslinux. I didn't add a --uefi switch for this release (a patch would be welcome).

swiftgeek commented on 2014-01-01 07:45

I also managed to get EFI running without hivex - i did dd of generated .img to MBR's first partition and then copy EFI dir to slightly resized partition. It didn't boot from "superfloppy" for me. (Would be awesome to have --uefi switch for that)

ovmf can be used for testing ;)

(And when it comes to syslinux - couple more files than chain.c32 were needed)
---- Prev msg ----
ntfsprogs is now ntfs-3g in repo (i guess since it provides mkfs.ntfs)
And big thanks for this package/software, will save me from going insane ;)

Also /usr/lib/syslinux/chain.c32 is now in bios subdir (mkwinpeimg)

swiftgeek commented on 2013-12-31 05:49

Also /usr/lib/syslinux/chain.c32 is now in bios subdir (mkwinpeimg)

swiftgeek commented on 2013-12-31 05:48

also /usr/lib/syslinux/chain.c32 is now in bios subdir

swiftgeek commented on 2013-12-31 05:10

ntfsprogs is now ntfs-3g in repo (i guess since it provides mkfs.ntfs)
And big thanks for this package/software, will save me from going insane ;)

DaveCode commented on 2013-11-19 06:52

Successful build on i686 and x86_64 both. Thanks so much.

Voted: All packages giving Windows compat belong in main repos, key to Linux uptake.

hcjl commented on 2013-07-23 13:56

During build with makepkg I receive an error:
FAIL: tests/test-imagex-capture_and_apply

Whole test-suite-log:
wimlib 1.4.2: ./test-suite.log

# TOTAL: 5
# PASS: 4
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/test-imagex-capture_and_apply

Testing image capture and application of directory containing nothing
imagex capture in.dir test.wim --compress=None --norpfix
imagex apply test.wim 1 out.dir
imagex split test.wim test.swm 0.01
ERROR: Invalid part size "0.01"
ERROR: The part size must be an integer or floating-point number of megabytes.
Test failure
Failed to split WIM

I think it is due to German localisation, which I use. Building with
LC_ALL=C makepkg
works without any problems.

Thx & Rgds

Synchronicity commented on 2013-05-20 02:33

pkg-config is in the base-devel group, so it does not need to be included as a make dependency.

Anonymous comment on 2013-05-20 02:05

Fixed by install package: pkg-config

It should be included as a dependency.

Anonymous comment on 2013-05-20 02:00

Can't build from aur with error:

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror-implicit-function-declaration -fno-common -Wundef -Wno-pointer-sign -fvisibility=hidden -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -MT src/libwim_la-xml.lo -MD -MP -MF src/.deps/libwim_la-xml.Tpo -c src/xml.c -fPIC -DPIC -o src/.libs/libwim_la-xml.o
src/xml.c:40:29: fatal error: libxml/encoding.h: No such file or directory
#include <libxml/encoding.h>
compilation terminated.
make[1]: *** [src/libwim_la-xml.lo] Error 1

kyrias commented on 2013-02-16 20:54

make check fails because it can't mount without sudo