539
Tails no longer recommending balenaEtcher (tails.net)
submitted 2 years ago by to c/privacy@lemmy.ml
176 comments fedilink hide all child comments
 

I am shocked by this - the quote in below is very concerning:

"However, in 2024, the situation changed: balenaEtcher started sharing the file name of the image and the model of the USB stick with the Balena company and possibly with third parties."

Can't see myself using this software anymore...

you are viewing a single comment's thread
view the rest of the comments
[–] 20 points 2 years ago (1 child)

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.

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 12 points 2 years ago* (2 children)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 17 points 2 years ago (2 children)

    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/

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 7 points 2 years ago (1 child)

    Ah! Thank you! I knew it was something I screwed up!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 16 points 2 years ago (2 children)

    You didn't screw up, you beautifully proved why the CLI is never a simple solution.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 2 years ago

    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 .

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago* (last edited 2 years ago) (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 2 years ago (1 child)

    Did you make sure that the of is correct? lsblk to make sure.

    If your sure it wrote to the right drive i would make sure that you have a good download. Did you run your checksums?

    I think fedora works with secureboot but you might want to disable it just to see if that is the issue. I believe you can reenable it after install.

    Make sure to go into the bios and boot from external drive/usb.

    Out of 15 years of using dd i have never had a problem.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    I did verify with lsblk, with a listing before and after plugging in the stick to be absolutely sure.

    I also did verify the checksum of the ISO.

    I'll double check SecureBoot, but as I mentioned, the same ISO written to the same stick with Fedora writer did boot in the same machine it wouldn't boot from with the dd version.

    I know it's something I did or didn't do to make it work correctly, so this is not me trying to dunk on dd, just trying to understand what I did wrong.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago

    just trying to understand what I did wrong.

    You might not have done anything wrong.

    There is also the possibility of a bad USB drive or write memory failure. There is lots of things that could go wrong that's not your fault. Might try a different USB or a different USB port on your machine.

    You might want to try zeroing out the USB, if=/dev/zero. Then you might need to make a new partition table. You can use something like gparted. Or https://linuxconfig.org/how-to-manipulate-partition-tables-with-fdisk-cfdisk-and-sfdisk-on-linux

    You can try GPT or DOS. I dont think it matters.

    Not sure if the ISO will have the partition table so you might want make the new partition table just to be sure the stick defiantly has one. If dd overwrites it from the iso no harm no foul.

    Thats all the troubleshooting steps I can think of right now.

  • permalink
  • fedilink
  • source
  • parent