i still had issues using 150MB electron based bloated and heavy software instead of rufus, not that it worked for me anyway
Privacy
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
I only tried to use it once, and same. 150MB of a Web app to copy an ISO? I think I was using a Macbook to flash it and decided to use ventoy instead, with my PC.
I understand that it needed a GUI, but 150 megs?? When :
~
❯ ll `which dd`
-rwxr-xr-x 1 root root 63K Sep 29 16:36 /usr/bin/dd*
~
❯
Yeah Mac has dd too, I often forget about the terminal existing there. I wish Ventoy for Mac was a thing tho.
Thats a shame, it was one of the few disk imagers that "just worked"
Here's a wildcard people might not know about: Raspberry Pi Imager
I use it because it's faster than Etcher and it also has a bunch of quick links to download popular images (mainly for RPI and other arm-based SBCs) in one click which is handy if you use those regularly.
Wow, I was not aware of that. I really liked balena. Thankfully, I haven't been using it since installing Mint.
Just use dd
. It's not that hard. You pass it 2 arguments: if=
the file you want to flash, and of=
the destination. If you're feeling fancy, pass in some status=progress
. And don't forget to prepend it with sudo
. That's it.
I just tried this the other day and was unable to boot from the USB. Any chance you could shed some light on what I might have screwed up?
The command was:
dd if=fedora.iso of=/dev/sdc bs=4M status=progress
The USB stick was not mounted and the fedora image was verified. The command completed successfully but I couldn't boot from it. When I used fedora writer to burn the same image to the same USB stick it booted no problem.
Edit: spelling & capitalization
Don't use Fedora myself, but it may not be a hybrid ISO that becomes bootable when written... so I looked and you are missing a flag
dd if=/path/to/image.iso of=/dev/sdX bs=8M status=progress oflag=direct
From https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/
Ah! Thank you! I knew it was something I screwed up!
You didn't screw up, you beautifully proved why the CLI is never a simple solution.
It reminded me when I told a coworker he could force the Windows shutdowns with the command 'shutdown -p -f" from either a Run.exe or a cmd window.
Then he said it wasn't working, and that the cmd window would just open and close quickly but no shutdown.
Imagine my surprise when he was doing shutdown -pf .
This is why people trying to pass this as a primary option baffle me a bit. dd is not that bad in isolation, but all of these little commands add up.
If we want Linux to be mainstream, we need to accept that most users aren't going to be linux enthusiasts. They just want a PC that works normally.
I don't think oflags=direct
has any influence on the result. Apparently that's about disabling the page cache in the kernel, which can avoid a situation in which the system slows down due to buildup yet-to-write pages.
Perhaps not. But the flag allows for direct I/O for data, bypassing buffers which can be overrun with certain size blocks, potentially causing dirty buffer depending on the machine being used. My understanding is that it's "more reliable" for writing (especially on shitty USB Flash drives) and getting the exact ISO properly written.
But it could be useless all the same - I'm just pointing out that OPs command is not the one recommended by Fedora when writing their ISO. Also OP is less likely to pull the drive before buffers have flushed this way.
Oh yeah that's where I was getting at, but I didn't have time to write that out earlier. I agree that OP probably pulled out the usb stick before buffers were flushed. I imagine that direct I/O would mitigate this problem a lot because presumably whatever buffers still exist (there would some hardware buffers and I think Linux kernel I/O buffers) will be minimal compared to the potentially large amount of dirty pages one might accumulate using normal cached writes. So I imagine those buffers would be empty very shortly (less than one second maybe?) after dd finishes, whereas I've seen regular dd finish tens of seconds before my usb stick stopped blinking it's LED. Still if you wait for that long the result will be the same.
Friendship ended with Balena
Now Rufus is my new best friend
Unrelated to balenaEtcher but I haven't been able to flash ISO files from Windows 11, either by using Rufus, Etcher, Fedora Media Writer, or even the WSL. I need to borrow a computer running a FLOSS operating system or to install OpenBSD first, and then from OpenBSD to download and burn an ISO file.
That sounds like an issue with your computer rather than W11. I just used Etcher on my W11 desktop to flash Mint XFCE yesterday with no issues.
Thanks for the tip, I'll try that with different computers.
Rufus is great! I worked with the maintainer to fix a bug in hardware they didn't have and it was a very pleasant experience.
Is no one aware of Fedora Media Writer? It's FOSS and the most trustworthy ISO burning software in existence. It's only issue is that its named as if it is written only for producing Fedora bootable media. It works for everything.
Not using Ventoy in 2025?
I guess I could install Ventoy on the raspberry Pi's SD card, but I prefer it to be bare, since the idea is to keep it simple.
Ventoy uses several blobs without any instructions of compiling them yourself?
Balenaetcher has, for me at least, failed to write to USBs for the last 3 years or so that I've tried to use it - meanwhile random iso writers from flatpak have been more reliable for me. Very obnoxious that so many iso related sites recommend it. Rufus kicks tons of ass, if for whatever reason you're still on windows.
Also on most distros I've tried, the disk utility has some sort of right click or context menu that gets you a 'restore disk image' button that works great as well.
Edit= I used Popsicle USB writer from flatpak on steam deck with no issue today! Made by system76 (makers of popOS) and found on flatpak. It is absolutely no frills, but works well enough to write an SD card image for a raspberry pi! 🙂
If you need a FOSS, cross platform GUI for bootable USB sticks, Raspberry Pi Imager is a really good solution.
It is mainly used to flash SD cards for RPIs, but also you can burn any ISO on any support with it.
Linux mint factory USB creator just right click and make bootable.
I knew that UI had something to hide!
Never trust an overly fancy UI...
That's interesting, apparently it was mentioned on github but nothing seems to have changed in the end
https://github.com/balena-io/etcher/issues/3784
Haven't used that software in a long time but maybe there's an opt-out somewhere during runtime? Although I don't see why a user needs to be required to opt out of nonsense like this when just writing firmware to a USB disk.
Only ever touched balenaEtcher when some project or distro recommended it. Overall prefer Rufus for this sort of thing when working on Windows.