exFAT is pretty portable these days and not encumbered by annoying file and disk size limitations. Its the default for SD cards and has had native support in Macos and windows for 15 years, linux has had kernel drivers for 5 years and FUSE/3rd party kernel modules for longer. Unless you need to interface with an ancient system there's no reason to use FAT on portable drives anymore.
Your link discusses how to install fusefs-exfat, which is a separate package, which is what all Linux distributions did before the 2019 licensing - Android had a separate licensed kernel module, etc. I can’t speak to the current state of BSD but a cursory search yields a lot of discussion.
> Companies can integrate exFAT into a specific group of consumer devices, including cameras, camcorders, and digital photo frames for a flat fee. Mobile phones, PCs, and networks have a different volume pricing model.
> exFAT is the official file system of SDXC cards. Because of this, any device not supporting exFAT, such as the Nintendo 3DS, may not legally advertise itself as SDXC compatible, despite supporting SDXC cards as mass storage devices by formatting the card with FAT32 or a proprietary file system tied to the device in question.
> On 28 August 2019, Microsoft published the exFAT specification and released the patent to the Open Invention Network members. The Linux kernel introduced native exFAT support with the 5.4 release in November 2019.
So yes, this has been annoying for years (2006-2019, at a minimum) and left a very bad taste in my mouth as someone who has a few dozen SD cards that regularly move around various embedded devices that are expensive, rarely receive updates, and work just fine (e.g. 3d printers, digital frames, regular printers, local storage on security cameras, adapters for retro hardware, etc.). The Wikipedia article notes that the Nintendo 3DS - 75.94 million units sold during its 2011-2019 lifespan [1] - lacked exFAT support, so it’s not like this only affected low-end/cheap/uncommon devices from small companies.
Windows “helpfully” disabled all ways to format large SD cards as FAT32 so I end up having to rely on a third party tool.
Of course, whenever possible, I use a sane and journaled filesystem but it’s rare that I have a choice. :)
This. and the BSDs or Minix are not in the "Open Invention Network" and as far as i can see, the BSDs still do not have a kernel extfat implementation as i far as i just have checked on their websites
I had trouble booting the Windows 10 installer from an exFAT formatted usb drive. That was thee years ago. So back then I had to recompress a cab file to make it smaller than 4GB using Linux. It worked but I was scratching my head that this was an issue.
I guess this could work but all instructions I could find back then were saying to create a FAT32 file system. I switched to exFAT after finding some installation files being large than 4GB. But then the stupid thing would not boot. So I managed to re-compress the largest cab file and got it below 4GB.
Edit:
But I am not sure an NTFS formatted stick is actually UEFI-bootable.
> But I am not sure an NTFS formatted stick is actually UEFI-bootable.
Practically - no.
But you can make a FAT32 standard bootable thumb drive, without install.wim which is > 4GB, make a second partition on that drive and format it NTFS, place everything (including install.wim) there and launch it from there after WinPE would run from the first partition.
> launch it from there after WinPE would run from the first partition.
How would you launch it from the NTFS partition; is that an option while in WinPE or will Windows automatically look for install.wim on other partitions? (met the 4GB problem in FAT32 and split install.wim in two for a successful USB install drive, but it would be interesting to learn how to do this via NFTS).
Thanks!
After the setup launches it would ask you for the language selection. After that you would be presented with a window which would allows you to install Windows or launch the 'Repair computer' wizard. Now just press Shift+F10, navigate to the other partition and launch setup.exe manually.
If you need, use diskpart to list available volumes:
diskpart
list volume
If the second, NTFS volume somehow don't receive a letter (and hence you can't navigate to it):
diskpart
list vol (note the number of the volume)
sel vol ## (the number of the value)
assign letter=K (or any other to your liking)
I make the setup USB from scratch using built-in Windows tools.
Using recent NT6 admin CMD, enter DISKPART, select your proper (USB) disk, and use the CLEAN command to prepare the USB drive. Safely eject the USB and reboot.
Reinsert the USB and run Diskpart again, select your proper disk, and enter CONVERT MBR to prepare it for traditional widespread bootability. This writes a Master Boot Record up to the first 440 bytes of sector 0, leaving the small remainder of sector 0 blank to allow room for a primary partition table.
Enter CREATE PARTITION PRIMARY to make a single blank partition encompassing the entire drive.
Enter ACTIVE to make the selected primary partition bootable, or it's going to do no such thing for you in BIOS.
Enter FORMAT FS=FAT32 LABEL="yourLabel" QUICK which will quick-format the partition like any other FAT32 volume.[0] Fat32 was originally the minimal default filesystem intended for UEFI firmware to boot from. But NTFS containing a proper EFI folder now usually also works just as well with lots of firmware, so alternatively FORMAT FS=NTFS LABEL="yourLabel" QUICK is mostly OK too if there is a need for storing any single file which would be too big for FAT32. Either way will create a (hidden) original NT6 bootsector for that volume, either a FAT32-NT6 or a NTFS-NT6 bootsector respectively.
(Test-booting in BIOS to USB at this point - without any boot files on the volume yet - should show "An operating system was not found. Try disconnecting any drives that don't contain an operating system. Press any key to restart", which is a sign of potential progress. Otherwise less-generic approaches may be needed before going forward. Test booting by UEFI will not be conclusive yet.)
While in Diskpart your new (hopefully labeled) volume will now have an alphabetical "drive" letter automatically assigned and you should now be able to view its contents using the mouse in File Explorer, there should only be folders for SystemVolumeInformation and RecycleBin, if that. (Sometimes you may need to assign a volume letter yourself, which is easy in Diskpart or the GUI Disk Manager.)
Exit diskpart and you will be back at admin CMD line, which window can then be closed.
In File Explorer, copy the boot files (bootmgrs, BOOT folder, and EFI folder) from the mounted Windows Setup ISO, over to the target formatted USB volume.
(Test-booting in BIOS to USB at this point - with only boot files on the volume so far - will show "Windows Boot Manager / Windows failed to start . . . ENTER=OS Selection", and hitting Enter takes you to the Windows Setup bootmenu entry which is a sign of further progress. Test booting using UEFI shows "Windows Boot Manager / Windows failed to start . . . ENTER=OS Selection / ESC=UEFI Firmware Settings", also progressing to the Windows Setup bootentry. Otherwise, less-generic approaches may be needed before going forward.)
In File Explorer, copy the remaining folders from the mounted Windows Setup ISO, over to the target USB volume. That will end up with the entire contents of the mounted ISO finally present on the USB. But not the least bit dependent on the DVD boot process any more.
Full successful booting should now be possible, BIOS or UEFI on any truly decent mainboard. Analogous to how the physical setup DVD works.
Much simpler & quicker to prepare than it sounds. The most time-consuming thing as usual is waiting for the large install.wim file to be copied from the mounted ISO to the target USB.
For BIOS booting, the mainboard will read the MBR/partitionTable (sector 0) of the designated boot drive which will then direct the boot routine to the active partition's bootsector on that drive, which will then proceed to read the bootsector of that partition, which then reads the bootsector's designated boot files (very commonly) located on the root of that same partition. For BIOS these files are Bootmgr(s), the BOOT folder, and Bootnxt if present. Just like it always was for NT6 before UEFI.
Now also on the Windows Startup media for more versatility there is an EFI folder present so the drive can boot using UEFI without the mainboard needing to utilize CSM/BIOS. UEFI doesn't depend on a coherent MBR, "active" partition, volume bootsector, nor bootmgr (and its associates) in the root of the volume. Just finds a nice accessible correct EFI folder on a firmware-readable filesystem supported by UEFI on that particular mainboard firmware. The ideal mainboard can use UEFI to boot from MBR or GPT layout drives, having a valid EFI folder on either a FAT32 or NTFS volume. A defect sometimes appears when the USB drive needs to be layed out GPT-style to boot just because the mainboard UEFI firmware is garbage.
Oh, well, GIGO.
.
[0] For "yourLabel" I like to use a descriptive abbreviation positively identifying both the drive and the partitionNumber on the drive, as a label for each volume. While keeping the volume label to 11 characters or less as nature intended. Like BLU8GB_P1 for the first (usually only) fat32 partition on a blue 8GB USB drive. Or BLU8GB_N1 if it was NTFS. Another ok labeling option is something like "W11_23H2v2" which gives you an idea of what is on the drive, but instead I still prefer to use the volume label to pinpoint the hardware, then put a more lengthy text file in the root on the volume, named appropriately to document what the software version is.
Unlabeled volumes autoidentify like "Local Drive (X:)" or "Removable Drive (Y:)" so don't let that fool you into thinking they are already labeled. I would take action and label them so they are less of an accident waiting to happen. Labeling can even be accomplished in the File Explorer GUI. Any time in the future that you plug in an unlabeled drive, you want it to contain the only unlabeled volume(s) you see.
