Rufus: ER: Make USB stick persistent?

[Shohreh]

Hello

Unlike other utilities to burn an ISO onto a USB stick, Rufus doesn't provide an option to make the stick persistant.

I'm testing a Linux distro that isn't persistent, and was wondering if Rufus could somehow make that happen, or persistency is up to the distro.

Thank you.

[pbatard]

I'm not considering this feature at this stage, as if you want to add persistent data to your USB drive, you should be able to do that after booting the Linux distribution. It may be less convenient than having the formatting tool do that for you, but I can't exactly justify duplicating features that should really be handled by the Linux distribution when my time is limited and there are still many other features I want to add to Rufus.

I will reject that request for now.

[Shohreh]

Ok, I understand.

[topiux]

Hi Pete,

Would you consider reopening this request? It seems like one of the best options is to create a partition for the persistent data (i.e. casper-rw). Can Rufus assist with this step?

Thanks,

Topo

[f5j]

Thank you for a marvellous utility.
I tried a number of different utils to get a live Linux distro on a USB stick that would boot in a partitular PC. Eventually I found Rufus and that solved getting around the UEFI (or whatever the problem was). I've since tried and failed to create a persistent partition (persistence) on the USB stick, It would be marvelous if Rufus could do this in one sweep.
Thanks again
Tony

[MagicAndre1981]

Please open the issue again and work with it. Rufus Is the only tool that makes UEFI/GPT compatible drives for me and I would like to test several drivers/kernels and so I need a persistent mode.

[pbatard]

As I said before, my understanding is that people should have the tools they need from Linux to add persistence to their devices, so I don't see it as that much a priority to add something like this in Rufus. Also, please see here.

[MagicAndre1981]

I've tried to create the persistent data on my own, but this always failed and I gave up. I tried others tools which allow it, but they fail to boot under UEFI/GPT

[AresAndy]

Well, I understand what developing means, but that does not allow you to just say "No, you won't see this feature, full stop". Even if opensource, you respond to the "customer", and in this case, the "customer" is always right. Since this utility is the only one stable enough which supports GPT/uEFI, and there are no great alternatives around, you should reconsider implementing that feature. "It's too hard for me" .. That's not a good point enough to just say "NO", you should instead say "It's hard, it'll become a feature as soon as the team and I manage to do it". With this bad attitude you, honestly, won't go veeeeery far. Sincerely, Everybody.

[ghost]

@AresAndy you clearly have no idea how open source works. This is not a paid product. You are not a customer. @pbatard has no obligation to you or anyone regarding this project. If he decides to not write one more line of code, not to accept or even comment on another issue, that is his business. The gall of your comment is offensive and should be removed immediately.

[pbatard]

@svnpenn, I don't mind these kind of comments. I can understand the frustration of people who realize that they will have to do extra work, and would want some software to automate that work for them.

Now, as pointed out in the relevant FAQ entry, the reason I am not planning to add such a feature is not because it's likely to be hard, but because:

• As a single developer (there's not much of a "team" - while people will contribute here and there, which is always greatly appreciated, it's mostly just a single person) who can only work on Rufus in his limited spare time, I am prioritizing the features I am planning to add, and this one is so far down my priority list that I'd rather not give anybody any hope that I'll ever work on it.
• My understanding is that you have all the tools you need from Linux to create a persistent partition if you need one, which is the reason it is so low on my list. So the the reasoning is: Why should I invest time duplicating a feature that the host system should already offer (and might perform better because it's its job)? From a priority perspective it just doesn't make sense. Oh, and if the counter argument to that is _"But then I might have to use some Linux commands or tools I am not familiar with..."_, I'll just answer: _"Then why do you want to use Linux in the first place, if you don't want to become familiar with how it can be used to achieve what you want?"_

Also, as I indicated many times in the past, it's not because I'm not planning to work on a feature any time soon that it's never going to be added. Rufus is Open Source, so all it takes is someone sending a patch, which I will review, and, if the changes look OK, integrate. And even if you consider that I'm holding your favourite feature back, you can also fork and create your own version of Rufus...

Finally, as @svnpenn indicates, please realize that since there is no financial transaction involved, I am under no obligation whatsoever to add the feature you request.

[ichpuchtli]

This project has persistence maybe checkout it out see how hard it is to implement.
https://github.com/SevenBits/Mac-Linux-USB-Loader

[pbatard]

Thanks for the link. Please also see #691.

The main 2 major issues in the way of implementing persistence support in Rufus are that:

• I'll need a means to create an ext2/ext3 file system on Windows
• I'll need to modify the UI, along with logic to only offer the persistence option when required (for instance, it makes no sense to show it when using a Windows image).

Now, the first item is the one that is really problematic. The nice thing about using a Mac is that you're close to be UNIX compatible, so recompiling and using stuff such as mke2fs (which is what Mac-Linux-USB-Loader is really using, as a separate executable it invokes) is no big deal.

For Windows, not so much. If we wanted to try to do what Mac-Linux-USB-Loader (i.e. calling on an external tool...), there does exist an old limited mke2fs for Windows, but I don't believe it supports ext3. And it doesn't seem to have been updated in years... Also, we're very size conscious in Rufus, and even at 100KB, this mke2fs is duplicating some of the stuff we already have (such as a bad blocks check, which we actually picked from ext2fs), so it doesn't seem like a good plan to just embed such an external executable as is. Instead, as we have done for ISO, boot block, compression, and so on, what is much preferable is to create an ext2/ext3 formatting library, compatible with Windows, that we can integrate to the Rufus code. This would ensure that only the stuff we actually need is being used, and ensure that the application size increase is kept the the minimum.

But, and this is what I pointed out before, this will require a lot of work. And then there might be licensing issues (such as the source being GPLv2 only whereas Rufus is GPLv3 or later) on top of that. So, even as I am looking at options to add persistence support in Rufus eventually, it's unlikely to happen soon...

[ghost]

@pbatard maybe this will help, Cygwin is using E2fsprogs; supports
Ext2/3/4. Last updated 5 weeks ago. The Cygwin package has some extra
patches.

Another option might be Ext2fsd; supports ext2/3.

[pbatard]

The problem with cygwin is that it requires the use of a very large cygwin1.dll to provide compatibility between some of the Linux/POSIX APIs and Windows. This is how they manage to produce a development environment where Linux applications can be compiled with minimal changes. However, this is not a solution that is applicable to native Windows applications, as Rufus would have to embed a multimegabyte DLL just to be able to use a cywgin app or library.

As to ext2fsd, this is the project that mke2fs for Windows used to be part of. But right now, ex2fsd stands at ~3MB, so clearly that's not something I can use without a lot of rework. And then, if it's based on ext2fs, and as I mentioned in #691, there will be a major licensing issue for the mke2fs component (GPLv2 only vs GPLv3 or later for Rufus).

I appreciate the help you and others are trying to provide for that feature, but I hope you also understand that I have also looked at these possibilities very closely, and that what might look like an easy solution to implement from an external perspective, might not be so in practice...

[ghost]

I tried building Windows native E2fsprogs, it complains about:

undefined reference to `fchmod'

so looks like it will not build without some hacking.

[CSCameron]

Rufus Persistent Pendrive install

• Create a Live pendrive using Rufus.

• Boot the Rufus pendrive toram to make the drive editable, (press shift when booting, press Esc from language, press F6, press Esc, type Spacetoram after quiet splash ---, and press Enter).

• Create a casper-rw file:

  sudo dd if=/dev/zero of=casper-rw bs=1M count=512

  sudo mkfs.ext3 -L casper-rw -F casper-rw

(where count=512 is persistence size, with max 4GB _[EDIT: Or more if using NTFS]_).

• Move the new casper-rw file from home to the root of the Live Pendrive using nautilus.

• Edit /isolinux/txt.cfg, (for BIOS boot persistence) and /boot/grub/grub.cfg, (for UEFI boot persistence), add a space and the word persistent after quiet splash ---.

• Shut down and reboot the persistent drive.

*Casper-rw partitions do not work for me with Rufus.

[pbatard]

@CSCameron, thanks a lot for posting these instructions here. That's a very good idea!

I'll just point out that I'm still planning to add casper-rw partition support at some stage, but it's still a bit lower on my list of priorities than other features, and it will require a bit of work (due to the need to format a drive in ext# format).

I'm also going to say that, since more and more distros seem to support NTFS formatted drives (last time I checked Debian and Ubuntu were that way), if you are using such a distro, then the main drawback of using a persistent capser-rw file (4GB limit) as opposed to a casper-rw partition goes away provided you choose NTFS instead of FAT32 as the target file system in Rufus.

[lock[bot]]

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.