Rufus silently fails to write an ISO containing large files in file mode w/ FAT32 #1007
Comments
|
I'm very surprised by your report. Rufus does detect > 4 GB files residing on an ISO, and will take measures to work with them. As a result, I expect that Rufus switched to using NTFS instead of FAT32 for the file system, but you didn't notice (of course, having a log would tell this very explicitly, and nothing prevented you from trying the same thing twice to get a log). Now the issue is that while some Linux distros (Debian and IIRC Arch) have no issues with NTFS as the file system used on a bootable USB Flash Drive, there's a minimum level of support that needs to be added to the kernel and the init script for this to work, which your Arch derivative might not follow). Now, if you could give me a link to the ISO you downloaded I could definitely test and see what's up. So can you please provide that information, especially if you don't have a log to provide. Makes it very difficult to treat your request as a relevant one otherwise, as I must confirm an issue before I can address it. Thank you. |
|
OK, interesting. The result was definitely a FAT32 usb stick, as my first attempt to fix the problem was to manually copy the full 6.9 GB .sfs file across, which failed because it was too large for the filesystem. I didn't have time to retry the burn last night but I'll give it a shot now to get a log and see if the problem is reproducible... Yep, it is. The log suggests Rufus has copied the first 4.0 GB of the sfs across, then overwritten it with the last 2.9 GB? xD In case it's something particular to the iso, it's from https://blackarch.org/downloads.html#iso-download (BlackArch Linux 64 bit Live ISO, 2017.06.14). |
|
Thanks for the log. This looks weird, and I'm thinking the issue doesn't come from Rufus, but from the way the ISO was mastered, as the BlackArch people seemed to have split the SFS in 2 parts that use the same name. As such I'm think that ISO9660 file system shenanigans are to blame rather than Rufus. Of course I'm currently downloading the ISO to have a closer look at its content, but, from having worked and tested ISOs that do contain > 4GB file, the behaviour being displayed here seems just too weird not to come from ISO-9660 filesystem abuse. As I was mentioning, Rufus does detect > 4GB files when processing an ISO, and should have displayed an The fact that it didn't, as well as the following two lines from the log tells me that the people who created the ISO used some kind of trickery to split the file in 2 while using the same name for the 2 parts: Anyway, I'll know more after I have a closer look at your ISO. |
|
Gotcha. FWIW opening the ISO in 7zip shows a single file of 7,445,232,000 bytes:
The properties pane of airootfs.sfs suggests that something like you describe may be happening at the ISO9660 level though (I note "Files: 2", although that may be talking about the folder...):
|
|
I got the ISO now, and can confirm that, as far as 7-zip is concerned, Looks like this could be a libcdio bug. I'll get in touch with the libcdio mailing list to find out what they think the issue is, and hopefully get a fix, that I can then integrate in Rufus. It may be a little while before I am able to do so though... |
|
While I'm still waiting for libcdio to fix this issue (though, by the looks of it, I may have to submit a fix myself), I have now added a warning about multi-extent ISO-9660 files in Rufus 2.17. |
* This is related to issue #1007, which libcdio still needs to fix.
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Checklist
Logbutton in Rufus and copy/pasted the log into the line that says<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
#button (at the bottom of the Rufus interface), 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
I used Rufus to write a 7.1 GB .iso to USB (an archlinux derivative). The UI is nice and simple so thank you and props for no installation required :). Anyway, I used mostly default/recommended settings which meant FAT32 and the file-based mode rather than direct-disk mode.
Unfortunately it turns out that the ISO was predominantly comprised of a single 6.9 GB .sfs file, which is of course too large to store on a FAT32 partition. Rufus however happily ignored this problem and just copied ~3.5 GB of the .sfs across. There were no errors or warnings (or at least none prominent) -- it looked like the process had succeeded and it wasn't until attempting to boot from the USB that I noticed something was wrong.
I'm rewriting the USB now in direct-disk mode which I expect will solve my problem so no big deal, it would just save some time to catch this scenario earlier :)
Log
I lied -- I didn't save the log of the run on account of I thought it succeeded!
The text was updated successfully, but these errors were encountered: