rufus

rufus copied to clipboard

First of all- thank you for a great utility!

Does Rufus support command line argument? So that you can specify an ISO when starting Rufus. Something like...

rufus.exe /iso=win7.iso

If not, would you consider adding that feature?

Thank you for your time.

Best regards, Bob

I have had a few requests for this, so I'm likely to implement commandline support eventually. However when I do that, I'd rather add comprehensive support (i.e. not just providing an ISO, but also a target, file system, type and so on), so it will take a while. Adding that feature currently sits around the middle of my backlog so don't expect anything fast...

Thanks for the information.

Thanks for the work on command line request. I also noticed that you added UEFI support a while ago. Thanks for adding UEFI support. I didn't know I needed it- until today!

Can you create readme file with all current and future command line switches that RUFUS uses.

Try rufus -h from an elevated command prompt. :wink:

That works, but I do not see any partition commands. Which what I am anxiously waiting for so I can make partition my drive as UEFI-NTFS format.

Thank you.

That's because, as I said, there is very limited commandline support available, and what you seek has not been implemented.

Realistically, I don't expect to implement the feature you are after for at least a year or two, at best, if at all. Sorry.

This being said, creating an UEFI-NTFS drive from the commandline should be relatively easy if you know what you are doing:

1. Create one large NTFS partition and then a smaller 256KB partition at the end. If using GPT, you should set both partitions to type BASIC_DATA or if MBR, the first one to 0x07 (NTFS) and the second one to 0xef.
2. Format the first partition as NTFS
3. Use dd to copy the uefi-ntfs.img data (256 KB) to the second partition.

That's it.

I see, that sucks. I do not have the ability to do that with disk part and do not have knowledge in grub4dos to do that. Unless you are will to lay it out for me, because it does not sound like a lot of steps.

Attach below is currently what I have to do to make this work.

Thank you.

Const HKCU = &h80000001 Set oshell = WScript.CreateObject("WScript.Shell") Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!.\root\default:StdRegProv") Set oFSO = CreateObject("Scripting.FileSystemObject") Set oWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!.\root\cimv2") Set colItems = oWMIService.ExecQuery ("SELECT * from Win32_LogicalDisk WHERE Description = 'Removable Disk'") oReg.SetDWORDValue HKCU, "SOFTWARE\Akeo Consulting\Rufus", "AdvancedMode", 0 DriveLabel = "IMAGE" RDrives = "" SP = 1 SP2 = 1 Count = 0 FCount = 0 TCount = 1

ANS = Msgbox ("You are about to create USB Imaging Drives, using USBMAKER.exe. Any USB Mass Storage drives that is attach to the system will be converted into a USB-Imaging Drive." & vbNewLine & vbNewLine & "Would you like continue?", vbYesNo + vbCritical, " USBMaker") If ANS = 7 Then WScript.Quit(99) End if Model = InputBox ("Please enter the Model of the devices you are build image sticks for.") For Each objItem in colItems Rdrives = Rdrives & objItem.Name & "," Count = Count + 1 DeviceFound = True Next

If DeviceFound = False Then Msgbox "NO USB devices found" ElseIf DeviceFound = True Then ANS = Msgbox ("This computer has removable USB drives connected with drive letters: " & RDrives & vbNewLine & "Is this corrected?", vbYesNo + vbCritical, "Is this Correct?") If ANS = 7 Then MsgBox ("Please connect all the remaining USB Drives to the system that are missing.") RDrives = "" Count = 0 For Each objItem in colItems Rdrives = Rdrives & objItem.Name & "," Count = Count + 1 Next oshell.Popup "The new list of Removable Drives on this Machine are: " & Rdrives, 15, "Removable Drives" End if End If

'Cleaning all Drives and Pre them for RUFUS If Ofso.FileExists ("C:\Brookdale\USBMaker\DiskpartScript.txt") Then oFSO.DeleteFile "C:\Brookdale\USBMaker\DiskpartScript.txt", True End if oFSO.CreateTextFile "C:\Brookdale\USBMaker\DiskpartScript.txt", True Set dpFile = oFSO.OpenTextFile("C:\Brookdale\USBMaker\DiskpartScript.txt", 2, True) For i = 0 To Len(RDrives) WScript.Sleep 500 DriveLetter = Mid(RDrives, SP, 2) If Not DriveLetter = "" Then dpFile.WriteLine "select volume " & DriveLetter dpFile.WriteLine "clean" dpFile.WriteLine "create partition primary" dpFile.WriteLine "select partition 1" dpFile.WriteLine "format fs=ntfs quick label=" & """" & DriveLabel & """" ElseIf DriveLetter = "" Then dpFile.WriteLine "exit" Exit For End If SP = SP + 3 Next

'Preping Drive for UEFI Formating oShell.Run "Diskpart.exe /s C:\Brookdale\USBMaker\DiskpartScript.txt", 0, True

'Set up for RUFUs UEFICount = Count oshell.Run "taskkill.exe /IM Rufus.exe /T", 0, True

do while UEFICount > 0 'Open Rufus oshell.run "C:\Brookdale\USBMaker\Application-Files\rufus.exe", 1, false WScript.Sleep 500

'Sending keys to App to complete task oshell.AppActivate "Rufus" oshell.SendKeys "{TAB}" oshell.SendKeys "i" 'Rotates between all Drives named like Image oshell.SendKeys "{TAB}" oshell.SendKeys "{TAB}" oshell.SendKeys "{TAB}" oshell.SendKeys "{TAB}" oshell.SendKeys Model ' replace with inputed vaule oshell.SendKeys "{TAB}" oshell.SendKeys " " oshell.SendKeys "{TAB}" oshell.SendKeys "{TAB}" oshell.SendKeys "{TAB}" oshell.SendKeys "{TAB}" oshell.SendKeys "{TAB}" oshell.SendKeys "{DOWN}" oshell.SendKeys "{DOWN}" oshell.SendKeys "{DOWN}" oshell.SendKeys "{DOWN}" oshell.SendKeys "{DOWN}" oshell.SendKeys "{DOWN}" oshell.SendKeys "{DOWN}" oshell.SendKeys "{ENTER}" oshell.SendKeys "{ENTER}" WScript.Sleep 6500

'Close Program and delete Dword oshell.Run "taskkill.exe /IM Rufus.exe /T", 0, True WScript.Sleep 2000 oReg.SetDWORDValue HKCU, "SOFTWARE\Akeo Consulting\Rufus", "AdvancedMode", 0 WScript.Sleep 1000

'Math UEFICount = UEFICount - 1 TCount = TCount + 1 FCount = FCount + 1 Loop

'Add WINPE Files and Image File WINPE = "C:\Brookdale\USBMaker\WINPE" ImageFolder = "C:\Brookdale\USBMaker\ImageFile"

For i = 0 To Len(RDrives) DriveLetter = Mid(RDrives, SP2, 2) If Not DriveLetter = "" Then oshell.Run "C:\Brookdale\USBMaker\Application-Files\FileCopy.hta", 1, False WScript.Sleep 500 oShell.Run "xcopy.exe " & WinPE & " " & DriveLetter & "\ /e /h /y /f" , 0, True WScript.Sleep 500 oShell.Run "xcopy.exe /z " & ImageFolder & " " & DriveLetter & "\ /e /h /y /f", 0, True WScript.Sleep 500 oshell.Run "taskkill.exe /IM mshta.exe /F", 0, True ElseIf DriveLetter = "" Then Exit For End If SP2 = SP2 + 3 Next

MsgBox "USBMake.exe have complete all task and have succefully create these USB Image Drives: " & RDrives

I'm afraid you'll have to seek for help elsewhere then. I provided you the global steps and that's as far as I'll go. If you need to convert them into a VB script, then you're going to have to ask VB help forums or get help from a VB specialist (or train yourself on VB scripts so that you can do it yourself). Sorry.

Well thank you for your support on this, I hope your app soon will have the command line switches. That is something I am willing to donate for. I will try some VBS forms and see if anyone has figured out how to do this using WMI commands in VBS.

Thank you for your time.

We may also want to pick up part of the no-GUI patches from here.

I love your tool, especially the UEFI-NTFS thingy :)

However, I hoped at least the partitioning and applying uefi-ntfs.img part would already be available as command line because there is no (portable) command line tool that allows creation of 256 KB sized partitions.

I already do everything like merging Windows 10 Pro and Enterprise images, applying Language Packs, integrating updates and various software and creating an ISO file. The only thing I can't do is creating a bootable BIOS/UEFI thumbdrive. And yes, I do need NTFS because the Windows 10 install.wim is 6 GB in size.

I hoped at least the partitioning and applying uefi-ntfs.img part would already be available as command line

Commandline is very low priority, because I'm afraid this is not a feature that will help the vast majority of Rufus users, and it is not in very high demand (even if those who demand it might be vocal... which is not still not the same as being in high demand).

there is no (portable) command line tool that allows creation of 256 KB sized partitions.

I hope you can appreciate that this is not really a Rufus problem. As stated in the FAQ: "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".

However, please be aware that, outside of commandline support, Rufus already allows you to create BLANK UEFI:NTFS drives in advanced mode (you get to advanced mode by clicking on the white triangle next to Options). That means it will create the 256KB UEFI:NTFS partition and format the drive to NTFS allowing you to copy content.

Hello, I just read your project FAQ and I saw that you planned to include command line feature, even if it's a sysadmin/expert/confirmed user feature. Great! I'd like to suggest, first, just one command prompt feature: it has the same drawbacks as drag and drop support, but I'd like to be able to Open with Rufus from Windows Explorer.

Even if there isn't a checkbox in Rufus settings to be the default handler for ISO (it could be possible because Rufus is already elevated), I just want it to use the %1 ISO file if I run "rufus.exe" %1 as admin. You'd have to handle .iso files and write in the registry to do this, so maybe it could be only for non-portable (fixed?) Rufus version, but it could be difficult to maintain I tried to manually open with Rufus, and unsurprisingly it did not work, but, something buggy happened: even if I use Rufus Portable regularly in its own folder, so it still has the same rufus.ini file, I remarked that, when I tried to open with Rufus from Explorer, it ran Rufus using the ISO's directory as the working directory, and that's why Rufus created a dirty rufus.ini in my ISO directory and asked me if I want to enable online auto check for updates, instead of using the rufus.ini which is located in the rufus.exe's folder. Do you think that Rufus could search for rufus.ini in the real path of rufus.exe, instead of searching in the process working directory?

Thank you Good luck!

I would like it so you could specify everything, and not even have to open a GUI. This way, people could make installers that call Rufus, but without the UI, so everything is in the shadows. This would be cool

Sorry, as much as I'd like to satisfy all requests ASAP, there's only so much time I can spare for development, so I have to prioritize, and unfortunately, command line usage is a lot lower on my priority list as other features that will benefit a much larger number of people. I am still committed to adding proper command line support to Rufus, but it's not going to happen fast I'm afraid...

📌 Hope to see CLI implemented when it is time for it!

@pbatard Please check out docopts. It could be your most straightforward and easiest way to implement the CLI without having to doxigen and getopts etc with a thousand switches and parsers.

I'm absolutely fine with getopts, which does its job splendidly as far as I'm concerned (and with a low footprint, which is precisely what I want). So the parsing of arguments is a non-issue there.

The real delay comes from spending time to properly implement the commands themselves (not their parsing) and especially the ones that relate to existing UI features. Also, remember that adding commandline support is a very low item on my list, compared to other features, so it is going to be delayed.

Plus, I have a fairly clear idea of what I want to do with regards to commandline implementation, which will require a lot of "behind the scenes" work (similar to what happened for the 3.0 UI redesign, which pretty much required me to drop everything else for about 6 months), so I need to get to a point where I expect to be able to allocate about the same amount of time without more important things getting in the way... which, considering the priority-level of this feature, is unlikely to happen for another few years...

@pbatard Understandable. Can you make a TODO list of the required low-level changes in the repo, though?

I would appreciate to read all the behind-the-scenes plans you have on the CLI implementation :) Also, this might help to give possible contributors a clear idea of how to implement such a thing in the coming years!

Can you make a TODO list of the required low-level changes in the repo, though?

I'm afraid not. Even as this is an Open Source project, there's a good reason I do use codenames, such as DealBreaker or StreetFighter for features that I am planning to implement, and that I don't want other people to know about or put their nose in before I have some tangible ALPHA version to show for.

I've been developing software long enough to have come to an understanding that feedback on super moveable targets does not help anyone, be it the developer or the end users. It's much better to have something to show for, even if it's early stage, before inviting feedback. But I'm a long way to have anything like that as far as commandline is concerned.

And again, I have to stress out, commandline support is at least years away, so there's no way I'm going to go into details on how I'm planning to address something that is that far out, as things can and do change when a lot of time elapses.

I understand. In any case, I appreciate the work you put in Rufus; and I'm sure we all can wait until this feature request comes up on the list. (I have to admit that I'm just now realising your use of codenames here.)

Thanks for being open with us, and as a developer myself, I hope that someday I can reach the level of software wisdom you have.

With no intention to tarnish this project in any way, does UNetBootin even provide a command line interface? Also, for those who can deal with command line interface, you should already have some dd installed in your system.

A lot of us could really use command line options. I'm needing to create an iso from a usb drive from the command line.

Doesn't dd work for most cases already, without relying on rufus?

Yes, however on Windows, I don't think dd is available, meaning that Rufus is one of the best options, considering how portable it is

Could what currently exists for command-line support be placed in the wiki somewhere? I'm sure for some of us it's what we were looking for, just the option to choose what iso to reference (for example in a carefully crafted Windows shortcut) allows us to skip a step when creating regular USB drives (for example for building Windows PE boot drives).

C:\Users\me\Desktop>rufus-3.13.exe -h

C:\Users\me\Desktop>rufus.com

Usage: rufus-3.13 [-x] [-g] [-h] [-f FILESYSTEM] [-i PATH] [-l LOCALE] [-w TIMEOUT]
  -x, --extra-devs
     List extra devices, such as USB HDDs
  -g, --gui
     Start in GUI mode (disable the 'rufus.com' commandline hogger)
  -i PATH, --iso=PATH
     Select the ISO image pointed by PATH to be used on startup
  -l LOCALE, --locale=LOCALE
     Select the locale to be used on startup
  -f FILESYSTEM, --filesystem=FILESYSTEM
     Preselect the file system to be preferred when formatting
  -w TIMEOUT, --wait=TIMEOUT
     Wait TIMEOUT tens of seconds for the global application mutex to be released.
     Used when launching a newer version of Rufus from a running application.
  -h, --help
     This usage guide.

I know there's already command line switches and tweaks, but how long do you think it'll be until you make it where someone can configure all the settings and can deploy ISO images via the command line without needing the open the GUI?

how long do you think it'll be until you make it where someone can configure all the settings and can deploy ISO images via the command line without needing the open the GUI?

To be brutally honest, I don't see that happening for at least 3 more years, and in all likelihood, you might very well double that timeframe.

Doing this properly requires a massive effort of dissociating the UI from the core functions, and, quite frankly, when I do that, I'd rather not use the old .rc/GDI way of displaying UI elements but XAML. And I'm afraid I don't see Microsoft having finalized enough of how they really to do to transition win32 into XAML (yes there exists XAML islands) to make that attractive to pursue just yet, especially as I usually try to support Windows platform for at least one more year after Microsoft sunsets them, on account that Rufus is used by people running these platforms precisely to transition to newer Windows version.

However, XAML Islands require Windows 10 version 1903 or later, and is not compatible at all with Windows 8.1, which means that, even if I were to require that pre 1903 Windows 10 users using Rufus upgrade, I still have to wait for Windows 8.1 EOL + 1 year to be in a position where I am comfortable enough that I am not going to anger the Rufus user base by telling them to upgrade their platforms if they want to use the current version of Rufus, which basically means that I have to wait until the end of 2023 (especially as I want to see if Microsoft are actually that committed to XAML island, or if .NET Core is not going to throw them to introduce a completely different paradigm in order to have a cross platform UI framework).

So, the smart thing for me to do on this is to wait for a few more years, when I will be in a position to actually split Rufus-core and Rufus-UI without thinking "I wish I had waited a couple more years, so that I could have gone with a technology that is much better for the long run" or without angering a significant number of Rufus users who are running versions of Windows that are close to being obsoleted.

Plus, as I said, even if using a framework that should make it easier, this will still be a massive undertaking (I estimate at least 4 months of full time hard work), and I'm way too busy for the foreseeable future to get into something like that.

As such, considering that the requests for commandline Rufus aren't that numerous, the smartest course of action I am continuing to see here is to wait until the vast majority of Windows users have actually upgraded to using Windows versions that should make it a lot easier for me to finally implement this request, even if it's likely to take quite a few more years.