wimlib

You need to convert it to a non-solid wim first (eg, "wimoptimize --compress lzx install.wim")

For what it's worth, the DVD version of Windows 11 already contains a WIM file in the suitable format.

As an aside, you might consider formatting your USB drive as exFAT. It maintains the simple permission-less kind of file system like FAT32 is, but there's no file size limit.

exFAT isn't usable on very old versions of Windows, or very old Linux, very old Mac, but everything from the past good few ...

You might want to use so that wimcapture can actually capture the partition itself rather than the whole disk (which includes the partition label)

A path like "/run/media/m/BEE6-6CB5/" suggests to me that the USB drive is formatted with FAT, which cannot support hard links in the first place.

Edit: in principle filenames with a well-defined encoding other than UTF-8, say ISO-8859-1, could be mapped to UTF-16 as well. Almost everyone uses UTF-8 now though, so there hasn't been a need to support this.


It should be possible, even, to have a flag that interprets all file names as ISO ...

I tried copying it to a non-FAT32 FS


Did you save it to FAT32 first? There's a file size limit that's smaller than the file you are supposed to be working with in the first place...

Just about any other file system doesn't have this same limit. exFAT, NTFS, HFS+ would all work for saving this ...

Sorry for the delay & thanks for the quick & prompt response! I realize that the process is very heavy. Is it possible to break the whole procedure in small parts ?

wimlib does this by default by splitting off into as many compression threads as you have CPU cores. If you aren't using "--threads ...

You can use wimupdate like so:

I assume you mean this: https://en.wikipedia.org/wiki/Microsoft ... nt_Toolkit

I doubt it will be possible to provision Linux operating systems with it. wimlib could certainly be used as part of Linux deployment, but you're going to want to base it from a Linux system in the first place.

The wim format and wimlib seem to support some kind of extra integrity information (hashing the compressed contents of the wim file?), but I don't really know when this might be desirable. wimverify is still able to assure that a wim file is not corrupted even if a file doesn't have this information ...