I am a newbie in the computer universe and learn new things with trials and errors. Stuck somewhere….? Does Rufus fail to download the GRUB files.? I know that feeling. If you want, and you have a GitHub account, you can post that log here as I have opened an issue for this in the official Rufus issue tracker.Hey there. I guess if I could take a look at that ISO, I would know for sure.Īlternatively, if you have a larger drive (can be a USB or a VHD, if you don't have a USB), can I ask you to please create a drive using that larger media in Rufus and post the log? This will list precisely what Rufus extracted and should give us an idea of what files might be duplicated as symbolic links. There's really not much else I can see besides symbolic links that can explain the size issue, since our projected size computation is not that complex (we're just parsing all the files and add the number of blocks being used for the ones that aren't empty), so I'm pretty confident that the issue boils down to your ISO making use of symbolic links. Now, you may think that, if that is the case, then Rufus should just ignore the symbolic links for its projected size computation, but the issue is that, because there is no guarantee that the target file system being used by the USB can support symbolic links (for instance, FAT32 does not support these at all), we can't use symbolic links for the target, which means that, if you have an install.wim duplicated twice as a symbolic link, then Rufus will have to physically copy that file 3 times (1 original and then the 2 duplicates), hence, the projected size is indeed the size you need to have on your USB for Rufus to be able to complete its operations. In other words, I have reasons to think that the install.wim and other files from your UDF image are being reported as belonging to different directories, or having different names in the same directory, which of course will make the projected size explode if that file is already larger than 4 GB (which Rufus reports it is). Since you are using UDF, I strongly suspect that the ISO you use contains symbolic links. If not, maybe you can provide some details on how you created that image, so that I can try to replicate that process and see if I get the same issue.Īctually, I think I have an idea of what is actually happening here. Is there any way you could upload it to a file sharing site, and then PM me the link so that I can take a look at it? You have my word that I will not share it with anyone and delete it when I'm done with it, and it would really help ensure that I fix this issue properly. Therefore I would be very interested to have access to your ISO so that I can identify why the projected size computation done by Rufus is that far off, and fix it. iso, it's still very unlikely that a 6.8 GB ISO should require 15.3 GB to be extracted, which means there must be a bug in the way Rufus computes the projected size. Now, I also realize that your LiteTouchMedia.iso isn't that large, so, even as, depending on the content, it is possible to have the total size required by a FAT32 or NTFS file system to be larger than the one used by the ISO9660 or UDF file system of the. So Rufus thinks that the extracted content will be larger than the destination, hence the error. how much size it expects the ISO to occupy on the USB once extracted) is 15.3 GB. But the projected size calculated by Rufus (i.e.
This explains the issue a bit further: As reported by Rufus, your target USB drive has a size of 15472012800 bytes, i.e. Notice: The ISO download feature has been deactivated because 'Check for updates' is disabled in your settings.įound USB 3.0 device 'Kingston DataTraveler 3.0 USB Device' (0951:1666)ĭisk type: Removable, Disk size: 16 GB, Sector size: 512 bytesĬylinders: 1881, Tracks per cylinder: 255, Sectors per track: 63ĭisk GUID: SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E Windows version: Windows 10 64-bit (Build 18363)