Clone this wiki locally
I'm an unaffiliated Software Developer who is also a Free Software enthusiast and a contributor to various Open Source projects.
Akeo is the name of my company, but it's really just a one-man operation that I conduct in my spare time, so please don't expect it to have the same level of resources as Microsoft, Google or Apple when it comes to development and support...
Oh, and incidentally, Akeo is the name of a small lough that's only visible from the top of Muckish, but you don't really care about that, do you?...
A few reasons:
- I have a regular 9 to 5 job, in a company other than Akeo, so all of my public software development activities have to occur in my limited spare time.
- Rufus is only one of the many Open Source projects in which I try to participate.
- Because of its popularity, I do spend quite a lot of time having to answer e-mail queries or looking after the issue tracker. This takes time away from development.
Mostly because I found that I really can't stand proprietary software and grew tired of seeing everybody use the trusted, yet old and limited HPUSBFW formatting utility. Reverse Engineering that tool to create a Free Software clone seemed like an interesting challenge, so I just went for it. For additional background info, see here.
Let me ask you this then: Would you pay $0.99/€0.99 for a utility that simply creates bootable USBs?
Or would you just pick one of the many free alternatives?
Heck, even I would not pay $0.99/€0.99 for this, despite being accurately aware of the cost associated with its development.
So, even if I could try to cash in on the success of Rufus, I see it better to try to benefit millions of users, by providing a free application, instead of just a few thousands with a paid one.
Besides, with the code being Free Software (which is a very deliberate choice as Rufus would not be as good as it is if it was closed source, due to its ability to leverage the great work of others!), anybody could recompile and distribute the same version free of charge.
As of 2015.09.01, Rufus gets downloaded close to 2 million times every month (!). To put that in perspective, that's quite a few more downloads per day than, say, something like Minecraft. ;).
All in all, I estimate that, ever since Rufus was first released in 2012 it has been used by more than 20 million people, and counting...
I try to answer almost all of the mail I receive about Rufus, but there are days when I'm really really busy, where I'll see your mail, make a mental note to reply to it later, because I have something more pressing going on, and then completely forget about it. I'm afraid I'm only human...
If you think I have been forgetting about your mail, you can always wait a little and send a gentle reminder... ;)
That's because you didn't provide a full log and without it, I don't have enough information to help you out.
Rufus was designed to be very verbose about issues, through its prominent Log button. Therefore, I will kindly request that you use the log facility if you encounter any issue, because, short of sitting in front of your computer and being able to interact with the application, that's the only I'll have a chance to figure out what's going on.
To produce a log, just click on the 'Log' button, then perform the problematic operation (e.g. insert your drive if it isn't detected, start a format operation with the ISO that is causing an issue, etc.) and click the 'Save Log' button. Then attach the FULL log with the report of your issue. Please do not be tempted to simply copy/paste the few lines from the log that look relevant to you, as I can guarantee that you will remove very important information, such as which version of the OS you are running, what type of ISO was used, and so on.
So, unless you provide a log that is comprehensive enough for me to help you out, I will just point you to this FAQ entry, without any other form of explanation.
Well, there's no good way to answer that question without sounding like a condescending #"£$%, so I'll be brutally honest:
- As I already pointed out, I don't get paid for developing Rufus. At all.
Even with ads and a few million downloads, I can't hope to come close to what I consider to be a suitable minimal wage that would allow me to start developing Rufus full time (and you better believe I am not a greedy person!).
So any time I invest in developing Rufus is time that costs me and that I have to compensate from another source. Therefore, since I can't spend my days on it, I have to prioritize the features and fixes that are likely to benefit the larger number of people.
As such if the issue is that you can't boot on your specific machine (whereas everybody else's machine seems to be fine) or you are using an obscure ISO image, or are experiencing a specific issue under conditions that very few other people are expected to meet, or want a feature that, when everything is weighted in (rather than your own partial view that "Of course, everybody will want that!"), is not going to see that many users after all, I am likely push your request to the bottom of the list of what I am planning to work on next, if at all.
Also, and this is important, please realize that it's not because you want to perform an operation that is vaguely related to what Rufus does that you should ask for a feature that would allow you to do it from Rufus. The scope of Rufus is to create bootable USB drives, and that's about it. Anything else, such as duplicating what
diskpart, or other utilities do, is out of scope.
- I can't stress that one enough: Developing isn't just about adding code!
To give you an idea, I estimate that, right now, I spend more than 33% of my allocated "development" time on non code related activities, such as answering e-mails about existing code features, regression testing, to make sure that a feature hasn't been broken between revisions, and so on.
I will actually give you Pete's rule on that subject: In the lifetime of an Open Source project, only 10 percent of the time spent adding a feature will be spent coding it. The other 90 percent will be spent in support of that feature. Therefore, if you don't plan spending a lot more time supporting a feature than what what you plan adding the code for it, you shouldn't add the feature in the first place!
What this all means is, whenever you ask me to add a feature or fix an issue that only you seem to be experiencing, I will try to estimate how much time it would cost to support it outside of the immediate code change, and depending on the outcome of that estimation, the odds of the change being "quick and easy" may not actually be as much in your favour as you think they are...
- Developing is hard, and even outside of supporting a feature, adding the code takes much longer than you think!
To illustrate this, let me give you a very detailed example from no later than yesterday: Because I want localization to allow translators to easily modify any aspect of Rufus interface they need, I added a feature that can resize any control using a simple set of instructions. Now, you'd think that, once you have both the control you want to resize, and the desired change in dimensions, an Operating System such as Windows would make it super-easy to just resize any control you want, right?
Wrong. The Windows resizing methods only work as expected as long as your control is something like a button or text box. But if you try to use the same method to resize a full dialog box, you will get unexpected results. Cue in a 2 hours session where various advice was perused and multiple attempts were made to add dialog resizing support, such as directly hooking in Dwmapi.dll to use DwmGetWindowAttribute() (which, of course, is a Vista or later specific call, so requires special handling), before finally settling on using AdjustWindowRectEx to adjust the dialog size according to the dimensions of the borders, since this is the root of the issue.
That was 2 hours required just to achieve something super-elementary such as having a function call that can resize either a control or a dialog. And when developing anything for Windows, IT'S ALWAYS LIKE THAT! But I wouldn't want to have it any other way!
What this means is that even your "How hard can it be to add <insert seemingly elementary feature here> to the app?" might actually require days of hard work, just to code the feature... and a lifetime supporting its users.
Of course, with all this being said, remember that Rufus is 100% Open Source. So if you really want a feature, you can try to find a sympathetic programmer (or even better, develop your own programming skills) to modify the code and then submit a patch for review.
The table below lists the languages that are intended to be natively supported by Rufus.
The current plan is to embed the translation of what I (and others) consider the 35 or so most prevalent languages into a single version of Rufus.
Entries in bold & blue have already been integrated and are available in the current version (or will be available in the next version).
Entries in bold & black are languages that somebody volunteered to translate and that are (hopefully) being worked on.
Entries that are not in bold are languages that either nobody volunteered to translate or that a previous volunteer decided to drop (unfortunately, it does happen). If you think you can translate Rufus in one of these languages, I am very interested in hearing from you! Please see the localization guide if you think you might be interested, to find out what translating Rufus will require from you.
Depending on how much space all of these translations take (each one adds about 5 KB to the executable), as well as translator availability, I may add or remove some languages from this list. But for now, this is the current line up, and I can only express my sincere thanks to all the people who contributed to all of these translations!
While I originally planned to support languages that aren't listed above through downloadable additional 'loc' files, due to the need of keeping translations up to date, as well as the time and effort it requires, I have decided that multiplying language support beyond the ones above wasn't in the best interest of anybody (as it would take precious time away from fixing issues or adding new features).
This doesn't mean that you can not create and provide your own 'rufus.loc', for additional languages. Just that, if you do, you will have to handle the distribution and support of these unofficial files yourself.
The log's prime purpose is to help me, the developer, troubleshoot the application when users encounter an issue. And to be able to do that, I need to be able to understand what appears in it.
Therefore, I very much want all of the log messages to be in English always. Otherwise, I won't be able to help users who don't use Rufus in English!
If you are an advanced user, you can of course use the log to find additional information with regards to what Rufus is doing, but, because this is not targeted at regular users, this data is not meant to be localized and you will be expected to understand English if you want to use the log.
Yes (but not officially)
The truth is, very few people actually need this feature, and figuring out if the target drive has a chance to fit all the content from an ISO is a massive headache. Also having to explain to users, who might not be as tech-savvy as the few people who have requested the feature what NTFS compression means and why it isn't a silver bullet when it comes to trying to cram more content on a flash drive would take away time from the development of other features. Moreover, with Rufus supporting UEFI boot from NTFS partitions (for platforms that support it), and UEFI NTFS drivers unlikely to support compression, I would also have to explain why this can't be used.
With millions of users of Rufus, even if only a small percentage inquires about it, this is something I would rather avoid. This is why, while NTFS compression was added as a cheat mode in version 1.4.4, it is 100% unsupported, which means that if you run into any issue while using it, or have questions, or request any improvement to the feature, I will just ignore you (and point you to this entry).
Since version 1.4.7, Rufus can be used with Microsoft Virtual Hard Drives (VHD or VHDX). What you do with a VHD is really up to you (I am not going to provide any advice on that), but, since I sometime ask people encountering an issue to also test with a VHD, here is how you can create one to use with Rufus, provided that you are using Windows 7 or later:
- Open Computer Management, by going to Control Panel → Administrative Tools. Note that if you don't see Administrative Tools in Control Panel, you may first have to click on the System and Security category.
- In Computer Management, click on Disk Management in the left column (under Storage), and wait for Windows to populate information about the disks.
- Click on a disk (1) and then right click on Disk Management (2). You should now be able to select Create VHD in the menu. Note that until you select a disk on the right hand side, you will not see the Create VHD option.
- Create the VHD by:
- Typing the path for the location where you want Windows to create the VHD file. Or you can use the Browse button. The file does not need to exist - it will be created by Windows.
- Selecting the size of the virtual disk you want Windows to create
- (Optional) Telling Windows to expand the size dynamically. Or you can use a fixed size, but in this case, Windows will need to allocate the size you specified on step 2 right away, meaning that if you chose to create a 8 GB VHD, Windows will allocate 8 GB of disk space for it, even if there isn't any data in the VHD.
- Once you have completed the above, Windows will display the VHD as if it was a real disk, in Disk Manager.
- The VHD will also now be available in Rufus.
Note that a VHD will not be unmounted on reboot. If you want to remount it after a reboot, you can follow the same steps as above, making sure to point to your existing
Also, if you want unmount a VHD without having to reboot, you should right click on the VHD disk in Disk Manager, and select Detach VHD.
If you need the ability to run multiple ISOs or bootable entities from the same flash drive, then what you really want is to perform custom sysadmin operations, and this rapidly becomes a pain to properly automate, because there are tons of incompatible boot methods, and because no two people ever want the same thing from such automation. Thus, if you want to use your flash drive in a sysadmin manner, I would advise you to first acquire the sysadmin skills you need, so that you don't need an automated tool to be able to setup a multiboot drive exactly as you want it.
If, on the other hand, you think you need a utility to setup multiboot for you, then I would have to say that you're probably better off keeping away from trying your hand at sysadmin stuff, and simply stick to a single boot USB drive instead, switching/recreating that drive as needed.
Then again, if you really insist on using Rufus as base for multiboot, you might be interested in this tutorial from our friends at RMPrepUSB... or you might as well use RMPrepUSB altogether (or YUMI), as it's probably what you're really looking for.
Also, and please mark my words, I can guarantee that you will spend a lot more time trying to maintain a multiboot USB, by adding/removing new/obsolete images onto it, as well as tweaking boot settings so that everything works, than you would spend simply recreating that USB for the image you actually need right now. With a decent USB Flash Drive connected to an USB 3.0 port, creating a bootable drive takes about 2-3 minutes, during which you can do something else. Therefore, whether you like it or not, by not trying to provide multiboot, and make you waste HOURS figuring why your ultimate UEFI + Windows + Linux + ISOHybrid collection doesn't boot properly, Rufus actually tries to save you time!.
But hey, since I am really getting a lot of flak about this, feel free to tell me just how arrogant I am for declining to provide you with a feature that, first, seems to be mostly requested by people wanting to install multiple copies of Windows, for which they are very unlikely to have a license (either this or there is an amazingly large number of people who managed to find a loophole to obtain very cheap MSDN subscriptions), and second, in an application that I'm not being paid to develop, and that you got absolutely for free!
Finally, after having spent the best part of 3 years dealing with making USBs bootable, as well as repeatedly coming up with innovative and advanced ways to ease some of the major USB boot process pain points, I hope I can be trusted to have acquired some insight on how things can and will go wrong, if you try to cram everything and anything into a single place, and why I feel entitled to tell you that you are genuinely better off NOT using multiboot...
I briefly toyed with the idea, but I don't think it's worth it, especially as it's a lot more than just creating a bunch of partitions. As with multiboot, you're probably much better off acquiring the knowledge of doing it yourself, than relying on an automated tool to do that for you, and have no clue what's going on when you run into trouble.
What's more, unless your USB Flash Drive is set by the manufacturer to behave as a fixed drive (99% aren't), Windows will not let you see more than a single partition on it. So that makes the idea of using multiple partition a bit moot, when only one of them can be seen at any one time by Windows.
No (unless I get a lot of free time on my hands, which is unlikely to happen).
Once you boot the OS, you should have everything you need to create some space for persistent data, so there's no real need for Rufus to do that.
It's in progress, but don't expect anything fast.
I certainly wish I could, because it sounds like a nice challenge, but I just don't have enough time for that. Also, Rufus was designed to work very closely with the Windows APIs, so porting it to another OS would take a lot of effort. Moreover, most of these platforms already have the tools need to help you achieve what Rufus does (though perhaps not in as convenient a package). As a matter of fact, Rufus relies on tools that were originally designed and run on other platform than Windows such as Syslinux, ms-sys or the bad blocks check feature from e2fsprogs, so at least these capabilities can be obtained on other platforms.
Then again, Rufus is Free Software, so if anybody wants to try to port it to another platform, they have everything they need to do so!
I.e. do you plan to offer 2 versions, one that includes all languages, and another with only English?
First of all, you should understand that even when all the planned native translations are completed, they should not occupy more than 200 KB of the total size of Rufus. That means that, unless you are downloading from a V56 modem, at worst this will only add a couple extra seconds to your download, which isn't that much.
With all the other USB formatting & boot utilities I know off being larger than 1 MB in size, I don't really see adding 200 KB, so that you can simply provide a copy of Rufus to your Korean, Finnish or Brazilian neighbour, should they ever need it, and have them run it in their preferred language, as that big a price to pay.
As you should know, only about 25% of the world population actually speaks English as a first or secondary language. That is why, even if these extra 200K seem to slightly inconvenience some people, I consider it a much more important goal to ensure that a large part of the remaining 75% of the world can use the same copy of Rufus in a language they are familiar with!
I'm hoping that this goal is worth a couple extra seconds of your time...
Rufus is very much designed to work USB drives (as well as VHDs), to avoid the possibility of non tech-savvy people seeing a drive and formatting it, without realizing that it was an internal drive with valuable data, rather than the external drive they just plugged in.
If I were to list non USB/VHD drives, including internal card readers, which are next to impossible to differentiate from other internal drives, I'm pretty sure I would immediately start to get complaints from people who formatted the wrong drive by mistake. And even if I could rightfully shift the blame on user error, I'd still much rather inconvenience a few people, by not letting them erase the data they want, than inconvenience others by allowing them to erase data they don't want to erase.
My priority with Rufus is and remains to avoid any possibility of data loss, even if minimal. As such, if you want to format internal drives, I will respectfully ask that you use another method.
Try to check the List fixed (non flash) or unpartitioned USB disks (v1.3.4 or earlier)/List USB Hard Drives (v1.4.0 or later) option in the advanced options panel. To display the advanced options panel, just click on the white triangle next to Format Options.
Alternatively, you can simply hit Alt-F.
Note however that formatting non flash USB drives, such as USB HDDs, is not officially supported for now. Use at your own risks!
No, it didn't.
While you may not be familiar with USB formatting operations, you should understand the following: even intentionally, it is extremely difficult for software to damage hardware, and it is even more difficult unintentionally. If you ask anyone with knowledge of what really goes on behind the scenes, they'll tell you that an application such as Rufus, that uses low level access to partition, format, or test bad blocks, simply does not have the ability to damage USB hardware. This is because, unlike what Hollywood likes to pretend, there really doesn't exist a set of magic commands that makes hardware self-destruct, and even when governments try to do it (in the form of the Stuxnet virus for instance) they have to invest years and millions of dollars in planning just to target a very specific type of hardware controller (For reference, USB flash drives from different manufacturers tend to use completely different hardware controllers internally, with a completely different proprietary command set).
Now, because Rufus does erase some data, you might still think that a formatting operation is hazardous. But this too is a very inaccurate assumption: As far as the hardware is concerned, formatting or partitioning a drive is no more different than writing to a regular file. Furthermore, if you use quick format, very little data is actually read or written on the device during formatting and partitioning. Finally, as far as standard USB drives are concerned, there is absolutely no difference between the data that gets written during formatting or partitioning and the regular data used for files and directories - It's just completely interchangeable data blocks being read and/or written. So, it has to be stressed out that there doesn't exist any "special" data block on USB drives, that regular applications such as Rufus can access, and that must be present for the drive to be recognized and perform its operations.
What this means is, even if a formatting application were to have a bug, the worst it can do, really, is write some erroneous data to a flash block. But since the USB controller on a flash drive doesn't care about what data is present in which blocks, it still wouldn't matter if all of the flash blocks were to be corrupted, including the ones that contain partition or file system critical information, as these blocks are nothing special and get accessed in exactly the same manner as other blocks.
The only possible way Rufus could actually damage a drive, then, is if you were to repeatedly run the check for bad blocks, as flash memory is not everlasting and will wear out after a lot of read and write cycles. However, for standard USB flash hardware, the number of write cycles before it wears out should be in the tens of thousands and what's more, a proper flash drive also contains circuitry that "moves" blocks around, to minimize the wear and tear (which is another reason why you can be confident that there doesn't exist any special data block on an USB drive). But since Rufus only checks for bad blocks when a user explicitly requests it (bad blocks check is disabled by default because this is a very slow process), the only actual possibility for the application to damage your drive is if you chose to repeatedly run the bad blocks check, for days or weeks on end.
So, unless you have been running bad blocks checks for days, I have to be very categoric that your drive was not damaged by Rufus. Whatever damage you maybe believe has been incurred while you were using Rufus is either a detection issue, or a standard hardware failure due to normal wear and tear, that just happened to coincide with when Rufus was accessing your drive. Obviously, when you use something, there's always a risk it will independently choose that moment to fail. But you can rest assured that your drive would have failed the exact same way, had you been copying a large file using Windows Explorer, instead of using Rufus.
Besides standard hardware failure, Windows detection issues can also be fairly common: if Rufus isn't able to complete a formatting operation, it is possible that the drive may be left improperly partitioned, or dismounted, and therefore it will not show it in Windows explorer (though recent versions of Rufus will try to list the drive even then). This can usually be solved by going to Computer Management → Disk Management in the Windows administrative tools. Also, because Rufus tends to be faster than other tools, it may render issues with sub-par cabling more prominent (due to using poor USB 3.0 extension cables for instance), which may in turn cause Windows to report a hardware failure or disconnected device. Or it may also be that Rufus uses an OS operation, that other applications don't use, to access your device, and which your specific OS configuration has trouble with.
If the above still isn't enough to convince you, then maybe the following will: Currently, Rufus is downloaded more than 1 million times every month, to format a very wide range of USB flash drives. Yet I receive extremely few reports from people believing that Rufus damaged their drive (less than 1 or 2 per month at worst, which means 1 or 2 for more than a million uses), and reports of such issues are very public, so it's not like I could really hide them,even if I wanted to!. This 1 or 2 in a million is pretty much what one expects from coincidental failures, that would have happened regardless of whether someone was using Rufus or not. This should therefore be a good indication that Rufus is safe to use.
I'm afraid your device is most likely dead.
The way an USB drive dies is usually that the flash memory gives out (because it has a limited number of rewrites before it's going to fail), and when that happens, the USB controller from the device, which is usually a generic microchip that is either the same or similar to the microchips that you would find on USB card readers, will detect that it is no longer able to access the memory, and, just like a card reader, report either that it is no longer able to detect a memory media or that it has become read-only.
In the Rufus log, for the first case, this will usually produce the message: Device eliminated because it appears to contain no media.
If you see these issues, it's probably time to purchase a new USB flash drive, because it is very unlikely that you will be able to use this one again. And, no, Rufus did not have anything to do with destroying your drive. Flash memory does have a very limited life, and things with a limited life tend to fail as you use them. See also the previous entry.
Unless a human employee from the company that makes Antivirus X actually confirmed it, I'm just going to ignore yet another false-positive report and point you to this entry without further explanation.
The reason for that is, every single release of Rufus, one of the various Antivirus vendors (it's never the same) seems to find nothing better than to produce a false-positive for the latest Rufus executable, mostly because they don't seem to understand that some size-conscious C programmers would ever want to produce anything but malware on Windows... This is getting exasperating and I have much better things to do than to submit a release for proper analysis every other day, without even getting an apology from security people, when they confirm that the application is perfectly safe, and that the problem was purely with their trigger-happy analysis engine.
This means that, if you want me to pay heed to a report that Rufus contains malware, you'd better first have an e-mail from a human person, working for your security solution, that actually confirms it and can provide technical details about the malware. If not, I will just point you to this and ignore your report.
That's because the way Rufus detects whether it should run in portable or regular mode is by checking the file name of the executable. The way it works is like this: if the file name contains the letter
p, then the code will run in portable mode. And if there is no
p, then regular mode is used. As a matter of fact, on the web server, the download for the portable version is just a symbolic link to the regular version, with a
p added to the name, so of course the binaries will always be identical.
But there's nothing fancy or mysterious about this method - software like Busybox has been doing this for years and you shouldn't freak out, or tell me that there an issue with the downloads, on account that the size and content of the portable and regular version of Rufus are exactly the same. There exists many ways to make the exact same executable behave in a completely different manners, through external factors, such as its file name...
Of course it does!
If you are assuming that Rufus will preserve partitions and only format the first one, then you are not reading the warning message properly. Rufus always deletes ALL partitions when formatting, as it needs to overwrite the bootloader and MBR/GPT table, which is the section of the disk that contains the partitioning information.
The LARGE WARNING that appears before the formatting operation starts does states that all data on the DRIVE will be deleted. A drive encompasses ALL the volumes/partitions.
All versions of Rufus above 1.4.4 will also produce a very clear extra warning that lets you know that all partitions will be destroyed. So if you happen to lose data because you assumed that a drive meant only a single volume or partition, it's because you didn't pay enough attention what Rufus was telling you.
OK, first of all, you can tell Rufus not to create an autorun.inf by unchecking the Create extended label and icon file in the Format Options. So Rufus does not force the creation of an autorun.inf file if you don't want one.
Now, as the option above indicates, the reason Rufus tries to create an autorun.inf file by default is primarily due to file system limitations. Especially, a file system such as FAT can only accommodate volume names that are UPPERCASE, less than 11 characters long and with English characters only. Oh, and it will also prevent you from using characters such as dot (.), comma (,), plus (+) and others...
Say you created a bootable USB from an ISO image labelled Linux Mint 13 Xfce 32-bit. If you don't do anything, then the best label you will be able to set for your USB drive will be LINUX MINT. If you leave that USB alone and then want to figure out what version it was, or whether it's 32 or 64 bit next time you reuse it, good luck!
Even worse, if English is not your mother tongue, as is the case for an estimated 93% of the world you can also forget about labelling your drive in your own language!
All in all, I hope you agree that these limitations with regards to the drive label aren't exactly nice, and that an application like Rufus should try to do something about it if it can...
This is where the autorun.inf file comes into play. Windows actually makes it possible to set a display label that can be as long and contain as many extended characters as you want (Chinese, Russian, Greek and so on), through the use of an autorun.inf file.
When autorun support is enabled, Windows checks any drive for the presence of an autorun.inf file, and, if such a file is found and it contains a label = line, then rather than use the default label, Windows will display whatever comes after the equal sign as the drive label in explorer.
This very useful feature then, lets you list drives with a label that contain lowercase, extended characters and is more than 11 letters long. And this is why Rufus will make use of it by default.
Also, the autorun.inf can also be used to set the icon that should be displayed for the drive in Windows Explorer, and Rufus also uses that feature to make it easy to recognize a flash drive that was created by Rufus.
As to the presence of an autorun.inf being dangerous, there does exist antivirus software (as well as some people) that are paranoid about seeing an autorun.inf created anywhere, due to these files also providing the capability to automatically execute an application (hence the name).
While it is true that, in the past, this capability was used by some viruses to replicate themselves, Rufus does not use the autorun.inf in this fashion, and as such, only a poorly designed security application, that isn't smart enough to actually scan the content of the file and find out whether it attempt to automatically execute a program, should erroneously take objection to the autorun.inf that Rufus creates.
I hope that this explanation is enough to make you understand that, unlike dumb security applications, you need not overreact when you see an autorun.inf on your USB drive and, what's more, understand that this is really done to help the vast majority of the world have the ability to label their drive as they see fit. After all, provided you don't speak Chinese, how would you like it if you could only label all your USB drives in Chinese?
Finally, remember that Rufus does provide some tooltips when you mouse over the options, and in this case, the Create extended label and icon file option indicates that it will create an autorun.inf. And of course, if an ISO already contains an autorun.inf file, Rufus will not overwrite it.
This is because, since it is a formatting utility, Rufus needs to run with administrative credentials, and, by default, Windows considers the Administrator and your regular user as tow completely different entities. Therefore, for security reasons, it will not carry over the network shares you have. You will actually see the exact same behaviour, for instance, if you try to run notepad as Administrator. If you do that, and try to access a text file that resides on one of your usual network shares, you will find that they are missing too.
However, Rufus user Jim Woodring indicates that, if you really need to, you should be able to work around this restriction by following the steps documented by Microsoft here, by creating a
DWORD registry key labelled
EnableLinkedConnections with value
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System and rebooting your system.
Formatting a drive, and even more so altering its boot record, is a privileged operation by nature.
If unprivileged users had the ability to perform it, then the first malicious application ran as a non-elevated user could do all sorts of nasty things. It doesn't matter whether the drive is an USB flash drive or a system disk, the same restrictions apply.
As such, you must have the right to run applications with elevated privileges if you run Rufus, and no, it is not possible to create a version of Rufus that doesn't require elevation.
That is a result of the check for update feature and the name of the executable you use. Depending on the name of the Rufus executable you downloaded, the check for update will or will not be enabled by default. In the second case, you will be prompted to decide whether you want to let Rufus access the internet to check for updates, to which you can say no if you want.
To explain this behaviour, I have to provide some history:
As a software user, I too prefer to use software that is opt-in, i.e. that lets users know that it may try to connect to the internet, and asks users for their permission before it attempts to do so.
As such, initially, I was planning to make Rufus opt-in always. However, I got requests from people redistributing Rufus NOT to prompt the user with regards to connecting to the internet, on account that some people would be confused by the question.
How could I solve this dilemma then? Simple:
If you look at http://rufus.akeo.ie/downloads/ you'll see there are actually 2 versions of the latest Rufus version, one called
rufus-#.#.exe (as well as the corresponding the portable version) and the other called
rufus.exe. They are essentially the same binary file (
rufus.exe is actually just a symbolic link to the first one on the web server). However, when Rufus starts, it checks for the name of its executable, and if it finds that it is called "rufus.exe", it does not display the question on whether a user wants to check for update, and enables that check automatically.
On the other hand, if you launch
rufus-#.#.exe (or any version of Rufus that isn't named
rufus.exe), you will be prompted on whether you want to enable the check for updates, in which case you have the option to disable it altogether, as well as find more information about the information we collect.
If by any chance you downloaded
rufus.exe (or accepted the prompt without realizing it), and want to disable the update check you can one of the following:
- Go to About → Updates and set the Check for updates: dropdown to disabled
Alt-Rin Rufus: You should get a message that states
Application registry keys successfully deleted(since we need to write some information in the registry for the update check as well). Then if you exit Rufus and launch it again (as long as you are not launching
rufus#something.exe), you will see the initial opt-in prompt and have an opportunity to refuse.
1. Whether you enable or disable the check for updates, Rufus needs to store some registry keys under
HKEY_CURRENT_USER\Software\Akeo Consulting\Rufus\ so that it can identify whether the check for update was enabled by the end-user, and how this check should behave (how frequent, when the last check was ran, etc.).
These keys can be deleted by pressing
Alt-R while Rufus is running.
2. Also, while Rufus is running, it temporarily modifies the Local Group Policy so that you don't get a Windows notification about a newly inserted USB device. If we weren't doing that, Windows would prompt you to choose what you want to do with the device, which is annoying when all you probably want to do is use Rufus to format it.
This Local Group Policy is restored to its original value when Rufus exits.
If there are any residuals from this operation, they are not due to Rufus, but rather are the result of how Windows handles Group Policy changes, as it may have to create keys when a Policy is first applied, but that doesn't mean the presence of these extra keys will change the behaviour of your system. On exit, Rufus always requests Windows to restore the policy settings as it found them.
For more on this, please have a look at
SetLGP() calls in
rufus.c, and the implementation of
Oh, and since I'm getting some very vocal complaints about this, if you freak out about an application modifying registry keys and/or using the methodology (Group Policies) that Microsoft advocates system administrators to use when changing Windows settings, then you're probably better off not using Windows at all. Seriously.
Unfortunately, there exist many types of bootable ISOs, and Rufus cannot support them all, especially as some of the bootable ISO format Rufus doesn't support are very custom and not used very much.
However, if the bootable content is DOS based, which would be the case for most unsupported El Torito bootable ISOs, you can usually work around the limitation, by doing the following. For this example, I am going to use the SeaTools for DOS bootable ISO image provided by Seagate. The other tool that you should also have installed for the following is the invaluable 7-zip.
The steps then are as follows:
- Create a bootable USB from Rufus using FAT32 for the file system and FreeDOS as the target
- Open the seatools.iso with 7-zip. In this case, you will see something like this:
- In this case, the content of the root drive doesn't seem to contain the DOS files. However the SeaTools.ima file looks interesting, as it appears to be a virtual disk image. Let's open it with 7-zip (just double click on the file):
- That's more like it! These are DOS files, so you can try extracting them to the root of the bootable USB you created with Rufus (overwriting existing files if needed) and see how it goes...
This error can happen early on in the formatting process if you happen to have disabled automounting (which is a different feature from autorun) and if you are using a Fixed USB drive. If that is the case, you should do the following:
- Open an elevated command prompt (type
cmdin the Windows menu search box, then right click on
cmd.exeand select Run as Administrator).
- Close the command prompt
It may also happen later on during the ISO file extraction process, in which case this isn't the result of the automount settings, but more likely a problem due to a flaky USB connection. For instance it may happen if you try to connect an USB 3.0 flash drive through an extension cable.
The reason is that USB 3.0 is fast and therefore very prone to cross-talk and interferences if the connection to the device is of poor quality, due to a bad cable/connector. When that happens, a temporary disconnection of the flash drive may occur, and because Rufus is usually faster to transfer data than the other tools, it will detect a problem.
Since version 1.4.2, code has been added that attempts to retry the writing of the file if that happens to try to mitigate the problem, but if your USB 3.0 flash drive is not using a solid connection, you should try to take measures to avoid that.
- As of Rufus 2.0, Windows To Go is only available if you are running Rufus on Windows 8 or later. If you are running Rufus on Windows 7 or earlier, the option will not be proposed (though you can create Windows To Go drives from Windows 7 ISOs if you run Rufus on Windows 8 or later).
- To create your Windows To Go drive, you should try to use a version of Windows that it at least the same version as the one of the ISO you are trying to create a To Go drive from. This means that, if you want to create a Windows 8.1 To Go drive, you should run Rufus on Windows 8.1, Windows 10, or a later version of Windows. Trying to create a Windows 8.1 To Go drive on Windows 8.0, for instance, is unsupported and will likely result in errors during creation.
- The Windows To Go option is not available with all Windows images, especially the ones created with the Windows Update Tool. This is because, Microsoft tools can create ISOs containing an
install.wimthat is incompatible with Microsoft's own WIM extraction APIs (which is what Rufus uses). You will however see a line in the log that states:
Note: This WIM version is NOT compatible with Windows To Go
- For more technical details on how Windows To Go is currently implemented in Rufus, see here.
The short answer: If Rufus managed to create a bootable USB, and that USB booted, you really are on your own.
The long answer: As you can expect, there are plenty of ISOs, with plenty of different boot processes out there (If only all ISOs actually booted the same way! There's El Torito with emulation, Syslinux, NTLDR, bootmgr, UEFI, etc, and they are all completely different to set up), and once boot has been achieved, there's nothing guaranteeing that whatever application has been booted (OS installer, live/recovery system, utility...) will actually work with an USB drive. If an application was designed to boot from optical media, it may very well still try to access subsequent files from optical media and completely ignore what is present on USB.
As you can understand, there are way too many bootable ISOs out there for me to become familiar with each one, and tell you how to make the one you are trying to use work... if it can work at all.
Once the application has booted, you should really take it with the developers or the community of users of that application, if you want to get help, as they will be much more suited to provide it.
"Setup was unable to create a new system partition or locate an existing system partition" when installing Windows 7 or later
This seems to happen only with some USB Flash Drives on some platforms, for reasons that only Microsoft knows.
Here is what you should do to work around this issue:
- Remove all partitions on the drive (no need to launch
diskpartas some suggest, you can just use the partition selection screen)
- Unplug the USB drive.
- Click Next. You will get the error:
Windows is unable to install to the selected location. Error: 0x80300001.
- Replug the USB drive.
- Click Refresh.
- Click Next.
The installation should now proceed as expected.
IMPORTANT Ever since Microsoft retired Windows XP in April 2014, all request to help with XP installation will be left unanswered (outside of a link to this entry). Also please note that XP 64 bit is NOT supported by Rufus.
Unfortunately, and unlike what is the case for later versions of Windows, the XP installation process was never designed by Microsoft to be USB compatible. This means that one of the first things an "XP-from-USB" installer application does, including Rufus, is to try to apply some kind of workaround to the XP installation process. For instance, some XP USB installers use a virtual optical drive emulation layer; others try to modify the installation files, etc.
Of course, any time you introduce a workaround, especially if you don't have the testing resources of Microsoft, you introduce a risk that a specific environment you can't test against will break things. This may be due to some form of BIOS incompatibility, hardware configuration, and so on.
In the vast majority of cases, the installation of Windows XP from an USB drive created by Rufus should work fine. But you may be one of the unlucky few who find that it doesn't with the specific hardware you are trying to install XP on.
Hopefully, you will understand that, as a developer with limited development time, I am reluctant to invest resources for the support of a specific hardware configuration, especially if it is the installation of an OS that has been officially retired by Microsoft. Only a handful of people are expected to benefit from identifying and fixing issues that seem to occur on specific hardware, whereas a lot more people could benefit from adding general features to Rufus, such as localization. Therefore, spending time identifying rare XP installation errors doesn't seem a good investment.
This being said:
- If the issue you are encountering is an error such as
Setup cannot find the End User License Agreement, you may be missing some drivers to access your disk. For more info, see here.
- If you have multiple hard drives, you should try to disconnect them all except the one you want to install XP onto. Or you should modify the BIOS ID in the advanced Rufus options.
- As pointed out here, some machines, especially old Dell ones are just incompatible with the Microsoft default installation tool, and need to use a patch for
ntdetect.com. Unfortunately, this patch is rather heavy (it goes much beyond a few bytes being modified), incompatible with the method Rufus uses, and the author of the patch did not document anything, which means that trying to figure out how to make a Rufus compatible version of a patched
ntdetect.comwould take a lot of time, which I don't really have.
Still, with Rufus being 100% Open Source, if you or someone else want to spend time to figure what Rufus should do to make your XP installation work, I'll be happy to accept a patch.
If you try to install XP on a blank or unpartitioned drive, you may find that the USB drive you booted from is listed as C: and therefore prevents you from using C: for the partition you want Windows to be installed on:
To work around this:
- Select Create Partition by typing C and then press the Enter key to create a new partition. You should end up with something similar to the following, where C: is still assigned to the USB drive:
- Type D then L to delete the partition you just created. You will now end up with the following:
- Proceed with the standard XP installation. The installer will now be able to use C: as the target drive.
When starting the installation of openSUSE, you may get the error:
Unable to create repository from URL 'hd:/?device=/dev/disk/by-id/usb-Your_USB_Brand_AABBCCDDEEFF1234567890-0:0-part1'. Details: [|] Valid metadata not found at the specified URL History: - [|] Repository type can't be determined. Try again?
If that is the case, you should answer Yes and on the YaST2 prompt that appears and enter /media.1 in the Directory field (you can leave the Repository Name field empty). Then you should be able to proceed with the installation.
Note: This also affects openSuse Live derivatives such as Mandriva or Gnome.
Because the openSuse Live media detection process is incompatible with a FAT filesystem, it is not possible for Rufus to convert openSuse based live media to bootable USB using its regular method.
If the ISO was created as hybrid, you may however be able to create a bootable USB image by disabling ISO suppport (
Alt-I) and using
First of all, a little reminder as to why this prompt is here in the first place.
By default, the Windows installation process is a two step one. The first step is to boot from USB and copy the installation files to the hard drive, and the second step (after reboot), is to boot from the hard drive and continue the installation.
Obviously, if Rufus creates an USB that always boot, regardless of the step being executed, unattended installations of Windows would be impossible, as someone would need to be in front of the computer to remove the USB or change the BIOS option after the first step is completed to ensure the computer boots from the HDD.
By installing an MBR that prompts the user and will default to boot from the HDD if no action is taken (and it is bootable - if not the USB is always booted), Rufus does let users perform unattended installation of Windows, which is a very desirable feature. As a matter of fact, the "Press any key to boot from USB" prompt mimics the "Press any key to boot from CD" prompt you get when installing Windows from optical media, so in that respect, Rufus tries to be as close as possible to the behaviour one would get when installing from the CD or DVD.
Now, there may be some cases where you still want to disable that prompt, and ensure that your USB will boot always. If so, here's what you should do:
- Click on the arrow to display the advanced options.
- Uncheck the checkbox for "Use Rufus MBR with BIOS ID:", which should have been checked by default.
If you are using a Windows ISO that can be dual booted in UEFI or BIOS mode, you may find that the USB created by Rufus does not preserve the dual UEFI+BIOS boot feature.
Especially, the Windows 8 installation ISOs, that support both UEFI and BIOS boot, will be converted to either one or the other mode, depending on the option you selected under Partition scheme and target type: If you select the first option (MBR partition scheme for BIOS or UEFI computer), the USB will be bootable in BIOS-mode only (even on UEFI systems), and if you select any of the other options, the USB will be bootable in UEFI mode only (and not bootable on a BIOS system at all).
This is done to avoid confusion, as it can be difficult for non expert users to know whether they actually booted in UEFI or BIOS mode, when an USB Flash Drive can be booted in both modes, and installation is meant to be a one-off operation, targeting a very specific machine and boot mode. You probably don't want to go through a full Windows installation, only to realize that it was installed in BIOS mode, when you really wanted it installed in UEFI mode.
By ensuring that only one or the other can be used for Windows installation, there is no room for error with regards to which mode was used.
Note that this does not apply for Windows To Go, and that you can also enable dual UEFI+BIOS boot by using the
Alt-E cheat mode (see below) with Rufus 2.0 or higher.
This can happen if you chose GPT partition scheme for UEFI computer in the Partition scheme dropdown, and part_gpt module was not included in grub when running grub-mkimage (See here).
In this case, you need to select MBR partition scheme for UEFI computer, and the grub.efi boot should work as expected.
You can display advanced options by clicking on the white arrow near Format Options.
Then by, selecting the relevant option in the Create a bootable disk dropdown, this mode also gives you the ability to install:
- a blank Syslinux bootloader
- a blank Grub/Grub4DOS bootloader
- a blank ReactOS bootloader (
- a blank UEFI:NTFS bootloader
Of course, since all of the above does is install the boot records, you will still have to manually provide the relevant configuration files and additional binaries.
B(v1.4.7 or later) - Toggle fake drive detection during bad blocks check:
By default, Rufus will check for fake USB flash drives that pretend there is more capacity than actually is by looping over the flash. This check which is enabled by default is performed by writing the block number sequence and reading it back during the bad block check.
C(v1.4.7 or later) - Force the check for update to be successful:
This is only useful if you are working on a translation and want to check the content of the check for update dialog.
D- Delete the
NoDriveTypeAutorunkey on exit:
This key is used to disable Windows popup messages when an USB drive is plugged in. Rufus does modify it through the use of Local Group Policies. This is only really useful if the app crashed.
E(v2.0 or later) - Enable dual BIOS+EFI mode for Windows installation media. For the reason why dual BIOS+EFI is disabled by default, see here
F- Enable fixed disk detection (v1.3.4 or earlier)/Enable USB HDD detection (v1.4.0 or later):
This is the same as enabling List fixed (non flash) or unpartitioned USB disks (v1.3.4 or earlier) or List USB Hard Drives (v1.4.0 or later) in the advanced options. This UNSUPPORTED mode will let Rufus detect and format USB drives such as USB HDDs, which it doesn't do by default. The reason this is disabled by default is that it can be a potentially risky operation when Rufus is used by non technical-savvy people. For instance, if someone also keeps an USB HDD as a backup drive, and plug an USB Flash Drive, they may inadvertently end up formatting their HDD and lose valuable data. If you use Rufus with this option enabled, you are on your own!
I(v1.4.7 or later) - Toggle ISO image support:
By default, when an ISO image can be used as both a regular bootable ISO (Syslinux, WinPE, ...) or bootable flat disk image (DD), Rufus will choose the former method when copying the data. With this option, you can force DD image writing.
J(v1.4.3 or later) - Toggle Joliet support for ISO9660 images:
Some ISOs (e.g. Ubuntu) have Joliet extensions but expect applications not to use them, due to their reliance on filenames that are greater than 64 chars (the Joliet max length for a file name). This option allows users to ignore Joliet when using such images.
K(v1.4.3 or later) - Toggle Rock Ridge support for ISO9660 images:
Note that when Rock Ridge is enabled, Rufus performs the initial scan of an ISO9660 image with Joliet disabled, so that it can find if Rock Ridge extensions are being used (if there exists a Rock Ridge file with a name greater than 64 chars or if there exist symbolic links). If you would rather prefer Joliet to have precedence over Rock Ridge, you can disable Rock Ridge altogether using this option.
L(v1.3.3 or later) - Force the use of Large FAT32 formatting for all target sizes:
By default, the Large FAT32 formatting functionality, developed by RidgeCrop, is only used for drives that are larger than 32 GB. For any drive smaller than 32 GB, the default Microsoft FAT32 format is used. If you would prefer the Large FAT32 formatting to be used always, you can use this option.
N(v1.4.4 or later) - Enable compression when creating an NTFS drive.
You may have to play with
Alt-Sto disable size checks when using this feature. Also, bear in mind that NTFS file compression is not possible on drives that have a larger cluster size than 4K (which Rufus will NOT check). Finally, if you use this unsupported option, you are 100% on your own!
R(v1.3.0 or later) - Erase registry keys:
Remove all registry keys that were created by Rufus.
S- Disable size limits:
By default, Rufus will not copy ISOs that are larger in size than the target USB drive. If this is enabled, the size checks are disabled.
T(v2.3 or later) - Preserve timestamps when extracting ISO content.
U(v1.4.7 or later) - Use PROPER units when displaying sizes, instead of the whole Kibi/Gibi nonsense.
V(v2.3 or later) - Save selected device to UNCOMPRESSED VHD.
W(v2.0 or later) - Enable VMWare disk detection.
X(v2.0 or later) - Delete the
Z(v2.6 or later) - Zap (zero) the whole target device.
.(v2.3 or later) - Enable verbose USB enumeration debugging.
,(v2.5 or later) - Disable exclusive locking of the USB drive.
If you want some more insight about what Rufus does when it checks for updates, you can create the following registry key: HKEY_CURRENT_USER\Software\Akeo Consulting\Rufus\VerboseUpdateCheck as a DWORD, and assign it a value or 1 (verbose) or 2 (even more verbose). You will then extended information about the update check in the log.
If you're using any of the following, Rufus may not work as expected. In all cases, this is due to the listed software or hardware preventing the level of access required by Rufus to properly set up an USB device, for instance, by preventing operations that are 100% legitimate, such as writing an
autorun.inf file or by latching onto an USB drive and preventing the exclusive access that Rufus requires for partitioning and formatting.
Thus, if you want to use Rufus, I would advise using an alternative from the items listed below: