I don’t want to be controversial or combative or any such thing,
but:
try
verify for yourself
once the prompt is back
the write is finished.
you can sync
or not
no difference 
I dont think it controversial.
And in many cases, depending on firmware, and the actual speed of the hands moving to remove the device, and so on … it may not be needed.
I include sync for the cases it may be needed.
On that note I might also mention that if you dont have rights do not just run sudo cat some.iso > /dev/sdx
Instead either contain it in a script or drop to root to perform;
sudo sh -c 'cat some.iso > /dev/sdx && sync'
OR
su
cat some.iso > /dev/sdx && sync
exit
While dd gets labeled as potentially hazardous … when cat is used in these ways its just as dangerous (that is it can overwrite data). Users must be sure of the paths in commands!
1 Like
Of course!
It does the very same.
It writes directly to the device.
It’s just as potentially “dangerous” as dd is.
Always an amusing slippery slope … like … at what point do we label pipes ( | ) or vim or anything else potentially hazardous?
Still. Obviously I put up a warning because there still seems some value in reminding people to be aware and accurate with what they do.
I don’t follow …
cat isofile > /dev/sdx
or
dd if=isofile of=/dev/sdx (and usually some more options after that)
will do the exact same thing
dd might return immediately - while the write is still in progress
cat will not
not just some value …
but it won’t help all of them
I’m trying to look up if using cat would bypass any cache and coming up empty.
Maybe that means what you seem to imply is correct - it would somehow never be cached.
I honestly have no idea.
IE; I dont know if using cat means none of the following applies (from the opening of previous shared link):
My understanding has also been that, despite some rumors to the contrary, this is also true for whole blocks or block devices, and not simply for files on or between given filesystems.
right at this moment
as I wanted to correct what I said
I had an internet outage
connected through mobile now
dd
doesn’t return to the prompt as well
before it is actually finished
just like cat
command line tools don’t lie, it seems - just the GUI thingies …
1 Like
I did not know balena is so full of tracking - i only used it once, on windows. I didn’t know about ventoy back then, and since windows doesn’t have dd, or makeiso etc, the choice was between balena, rufus, and unetbootin, and one of the later 2 did not work.
Simple tip about flash drive caching: look at the flashing led. If it blinks, it’s writing out the cache.
I think all USB storage devices “worth their salt” should have an LED but unfortunately many don’t, or for example they put a red LED inside a blue casing 
(I drilled a small hole in one of mine so I could see it).
Also, I’ve had instances where the LED would stop flashing just long enough so you think it’s finished, then does a bit more just as you’re about to unplug it … 
I find it decent practice to add status=progress && sync to dd commands, just to be safe.
2 Likes
There is no wonder the same error appeared.
The command you used is simply wrong;
…you have already been told that:
Use this:
yay -Sua --devel
1 Like
I have uninstalled balena-etcher and archlinux-tweak-tool-git and installed ventoy with yay to check if it installed or gave an error and it installed without any problem. Afterwards I updated the aur packages, but this time I did it with yay -Sua --devel and there were no more problems. Thank you all for your time and help.
ventoy is available from Manjaro extra repository, so an AUR helper is not needed
3 Likes
I’m glad your problem is solved. 
Now, let’s give credit where credit is due.
The solution is now attributed to the post from @Wollie above, in which he corrected your syntax, and that subsequently allowed yay to complete as expected.
2 Likes
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.