ER: Automatically split install.wim to .swm if bigger than 4GB and FAT32

[o-l-a-v]

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• I clicked the "Log" button in Rufus (last small blue button before START) and copy/pasted the log into the line that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• I also tried one or more of the following:
  • Using a different USB drive.
  • Plugging the USB into a different port.
  • Running Rufus on a different computer.
• If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

Would be awesome if Rufus could utilize Dism.exe to split Windows Install.WIM to span / .SWM, if target is FAT32 and Install.WIM is >=4gb.

Here is Microsoft Docs on the issue
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/split-a-windows-image--wim--file-to-span-across-multiple-dvds

[pbatard]

Rufus already has UEFI:NTFS for that. There really is no need whatsoever to use FAT32 for a Windows installation media, when Rufus provides you with the ability to boot NTFS on ANY UEFI machine.

Did you try UEFI:NTFS (which is what Rufus will apply by default if your target is UEFI and it detects a >4GB install.wim)? Are you experiencing issues with it?

If not I will just close this request, as it's a duplicate for a feature that Rufus already provides.

[o-l-a-v]

Rufus already has UEFI:NTFS for that. There really is no need whatsoever to use FAT32 for a Windows installation media, when Rufus provides you with the ability to boot NTFS on ANY UEFI machine.

Did you try UEFI:NTFS (which is what Rufus will apply by default if your target is UEFI and it detects a >4GB install.wim)? Are you experiencing issues with it?

If not I will just close this request, as it's a duplicate for a feature that Rufus already provides.

You have to disable secure boot in order for that function to work. So yes, there is a real use case for this.

[pbatard]

Not really. If you understand what Secure Boot does, then you'll also understand that, as opposed to what many people irrationally think (simply because disabling something that says "secure" in its title has to be "bad", right?) and as explained in the second part of this FAQ entry, there is no risk associated with temporarily disabling Secure Boot during Windows installation.

Especially, if you want to have certainty that your Windows installer will not install anything malicious while Secure Boot is temporarily disabled, then you can rely on Rufus being digitally signed (therefore trusting that the creation process did not install malcious content) and your ISO having been validated to be official (by comparing its SHA-1 against official values, which you can easily do through adguard.net for instance), then, unless you have strong reasons to believe that the machine you created the media from is infected, there really is no reason to baulk at the idea that Secure Boot must be temporarily disabled.

Still, if you still want to raise the Secure Boot issue, PLEASE complain to Microsoft, because, as explained on the UEFI:NTFS page it's only their plain abuse of power that prevents us from signing UEFI:NTFS for Secure Boot, and therefore requires users like you to temporarily disable it.

Since I still see no real-case for this feature, I will close it.

[o-l-a-v]

Not really. If you understand what Secure Boot does, then you'll also understand that, as opposed to what many people irrationally think (simply because disabling something that says "secure" in its title has to be "bad", right?) and as explained in the second part of this FAQ entry, there is no risk associated with temporarily disabling Secure Boot during Windows installation.

Especially, if you want to have certainty that your Windows installer will not install anything malicious while Secure Boot is temporarily disabled, then you can rely on Rufus being digitally signed (therefore trusting that the creation process did not install malcious content) and your ISO having been validated to be official (by comparing its SHA-1 against official values, which you can easily do through adguard.net for instance), then, unless you have strong reasons to believe that the machine you created the media from is infected, there really is no reason to baulk at the idea that Secure Boot must be temporarily disabled.

Still, if you still want to raise the Secure Boot issue, PLEASE complain to Microsoft, because it's only their plain abuse of power that prevents us from signing UEFI:NTFS for Secure Boot.

Since I still see no real-case for this feature, I will close it.

I'm not here to judge weather secure boot is a good thing.

The fact is that many businesses require secure boot to be enabled. It's also a requirement for modern client management, like Intune MDM. It would make the lifes of many administrators easier if Rufus could do wim to span / swm on the fly. Our options right now is either do the spanning manually (or convert to .ESD) and use fat32, or disable / re-enable Secure Boot with UEFI:NTFS for every PC you reinstall. Which adds up to a considerable amount of time when talking multiple PCs.

I get if you don't see/ agree to the potentially added value, and I won't nag more about it. Just thought it would be a nice feature to add to Rufus.

[pbatard]

Then bring it up to Microsoft.

The ONLY reason you have to disable Secure Boot is because Microsoft have arbitrarily decided, on a very irrational basis (since, strangely, they do allow Linux shims) that anything GPLv3 cannot be signed for Secure Boot.

I hope you can understand that this is a VERY DANGEROUS PRECEDENT. What if, in the near future, Microsoft decide that the only way you'll be able to install applications on Windows is through their App Store, and then apply the same policy of no GPLv3 there (because, after all, if they can justify it for Secure Boot, they can use the exact same arguments to prevent any GPLv3 app being delivered by the App Store). Then, because Rufus is GPLv3, that means all you will have gained by not complaining to them is no more Rufus on Windows.

So, by playing Microsoft's game for short term convenience, you might very well be reducing freedoms, for everyone, in the long run.

I hope you can appreciate that, as a Free Software developer, I do have to balance user convenience with user freedoms, especially as I deliberately chose GPLv3 for my software. Therefore, where some people may bark at seeing their immediate convenience being reduced, they also need to appreciate that there are principles at stake, that need to be fought for, otherwise everybody looses. As such, a developer may have to try to uphold some principles even if it means reducing user convenience.

But if you have corporate power behind you, then, by all means, please complain to Microsoft and let them know that their "no GPLv3 for Secure Boot" is hurting you and may lead you to reflect as to whether you want to continue to use Microsoft OSes since their installation is becoming a problem as a result. That's the only way they may start to appreciate that their blatant attempt at abusing their power is not something that people are going to let slide under the carpet...

[ThiloL]

Hi Pete,

not all users are allowed (able) to disable "Secure Boot". For this users, the "Split-WIM" feature would be very fine.

We're talking about a (simple) technical feature and not to put Microsoft on the spot.

-Thilo

[pbatard]

All x86 motherboards do allow disabling of Secure Boot.

If you have other information, I'd really like to hear it, because that would be huge news.

Microsoft actually tried to force manufacturers to produce systems where Secure Boot could not be disabled for ARM, because, since it was a new platform where they could introduce new rules, they thought they'd be able to get away with it . But there was such a backlash at the time that the only end result they got is that, since then, motherboard manufacturers are making sure that Secure Boot can always be disabled on x86.

Now, obviously, if the issue is that Secure Boot is enabled, but you don't know the BIOS administrative password to disable it, then clearly you should not be booting something on a machine you aren't entitled to administer, let alone install Windows on it...

[ThiloL]

Hi Pete,

why should users disable and enable secure boot on EVERY installtion, if you could add the Split-Feature?
I'm starting to lose track of your reasoning. You're mixing politics with tech stuff. Microsoft will not change his strategy, even if you change it or not. Or do you believe that?

-Thilo

[pbatard]

why should users disable and enable secure boot on EVERY installtion

For the same reason why users may have to enter their BIOS /UEFI to select their USB installation media when installing Windows. Are you seriously suggesting that users should never be asked to enter their BIOS/UEFI settings ever, even when installing an OS, which is the one occasion where they probably want to double check how they are set-up for OS installation.

You're making this a much bigger deal than it really is. ALL x86 users can disable Secure Boot. So there is no blocking issue there. Sure, it might be inconvenient to do so, but then again, it might also help users know how they can proceed to install an OS that hasn't been Secure Boot signed, which may be important for their freedom, so I fail to see what that issue is. For instance, (Free)DOS is certainly not Secure Boot signed so if you don't disable Secure Boot (and enable CSM if needed), then you can't boot DOS. Yet Rufus does create DOS bootable drives, so if we follow your reasoning, should Secure Boot users also not be required to disable Secure Boot EVERY time they want to boot DOS?

IMO, and this is the part you fail to grasp, by pointing users to Secure Boot matters and making them understand that it is perfectly acceptable to disable Secure Boot when the truth of the matter is that, as long as Microsoft has the ability to arbitrarily exclude whichever software they don't like, then we can educate users with regards to their freedom to bypass Secure Boot if they choose so, and boot software that someone, who is not them, has decided they should not have the freedom to boot, which is a clear benefit for them in the long run.

If you think that I am only starting to mix politics with tech stuff, you must not have looked very closely at what I have been doing all these years. I have been a GPLv3 and FSF proponent for a very long time (heck, my GitHub BIO couldn't make this any more clearer), so of course I will fight for users freedoms wherever I see fit. And not letting an entity with dubious motives control what can and cannot be booted on hardware that you own is a freedom that is worth pointing users to, especially if the only price they have to pay (since again Secure Boot can always be disabled on x86) is a slight inconvenience.

Also, I hope you do realize that Windows 7, Windows 8 and pre 1803 Windows 10 users cannot mount 2 partitions at the same time from removable media, which makes your "(simple) technical feature" not that simple to implement, since you'd have to hide a partition for the other to be mounted, and, if you are a fan of convenience and user-friendliness, users will be very puzzled on why they can only see a 512MB partition on a drive that is supposed to be much larger and contain a bunch of other files from their Windows ISO. So please be mindful of not restricting your view to post 1803 Windows 10 usage only. Rufus still has to support Windows 7 and Windows 8 users.

[ThiloL]

You should not create a second partion. You could split the (>4GB) install.wim in serveral (<4GB) installx.swm. So they can be an a FAT32 partition.
->https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/split-a-windows-image--wim--file-to-span-across-multiple-dvds

[pbatard]

That's even worse. Splitting a wim is not a zero-cost operation. It will increase the time it takes to create the media, whereas copying the content wholesale will always be much faster. I though you were talking about the other approach as suggested here, which is much better in terms of media creation time (but still not something I'm considering implementing when people can always temporarily disable Secure Boot)

One of the established goals of Rufus is to create a bootable media as fast as it can possibly be created. Adding a costly wim splitting operation to the media creation does not meet that goal.

[pbatard]

Also, just to point to the "(simple)" technical aspect of splitting a wim, you'd have to either mount the ISO to be able to access the wim to split (Sorry Windows 7 users, that means you're out!) or first extract the 4GB wim somewhere and then split it (Ouch!). Not all Windows version allow mounting of ISO images, and, in case you don't know, Rufus does not use ISO mounting to copy data (instead it uses a ISO access library that does not provide mounting capabilities).

So we're getting into the "Why is Windows To Go not available for my system in Rufus?" headaches, that aren't so great for users...