Recently, I learned that booting from a dd’d image is actually a major hack. I don’t get it together on my own, but has something to do with no actual boot entry and partition table being created. Because of this, it’s better to use an actual media creation tool such as Rufus or balena etcher.
Same for me. Ventoy is pretty amazing and keeps most of my isos on it. Sadly, sometimes it’s not capable of doing the job, for example when I installed proxmox (based on Debian 12) this week, ventoy couldn’t do it. Apparently this is a known issue in ventoy.
But yeah, for most isos, ventoy is the way of you install OSes somewhat often, as it contains partition layouts and boot records regardless (I think).
Huh thanks for the link. I knew that just dd’ing doesn’t work for windows Isos but I didn’t know that it was the Linux distros doing the weird shenanigans this time around
Thanks for the tip. Not that I plan to read up on the matter and make the next cold installation even more anxiety-inducing that it already is. Sometimes Linux would really benefit if there were One Correct Way to do things, I find. Especially something so critical as this.
As I understand it, there isn’t really a canonical way to burn an ISO. Any tool that copies a file bit for bit to another file should be able to copy a disk image to a disk. Even shell built-ins should do the job. E.g. cat my.iso > /dev/myusbstick reads the file and puts it on the stick (which is also a file). Cat reads a file byte for byte (test by cat’ing any binary) and > redirects the output to another file, which can be a device file like a usb stick.
There’s no practical difference between those tools, besides how fast they are. E.g. dd without the block size set to >=1K is pretty slow [1], but I guess most tools select large enough I/O sizes to be nearly identical (e.g. cp).
Interesting. Is this serious advice and if so, what’s the new canonical command to burn an ISO?
Recently, I learned that booting from a dd’d image is actually a major hack. I don’t get it together on my own, but has something to do with no actual boot entry and partition table being created. Because of this, it’s better to use an actual media creation tool such as Rufus or balena etcher.
Found the superuser thread: https://superuser.com/a/1527373 Someone had linked it on lemmy
Nowadays I just use Ventoy
Same for me. Ventoy is pretty amazing and keeps most of my isos on it. Sadly, sometimes it’s not capable of doing the job, for example when I installed proxmox (based on Debian 12) this week, ventoy couldn’t do it. Apparently this is a known issue in ventoy.
But yeah, for most isos, ventoy is the way of you install OSes somewhat often, as it contains partition layouts and boot records regardless (I think).
Wow. I’ve been using dd for years and I’d consider myself on the more experienced end of the Linux user base. I’ll use cp from now on. Great link.
Huh thanks for the link. I knew that just dd’ing doesn’t work for windows Isos but I didn’t know that it was the Linux distros doing the weird shenanigans this time around
It is really informative! Spread the word.
I was not aware, thanks for the link!
Thanks for the tip. Not that I plan to read up on the matter and make the next cold installation even more anxiety-inducing that it already is. Sometimes Linux would really benefit if there were One Correct Way to do things, I find. Especially something so critical as this.
There is. Just use a media creation tool, like Rufus. dd’ing onto a drive is a hack.
As I understand it, there isn’t really a canonical way to burn an ISO. Any tool that copies a file bit for bit to another file should be able to copy a disk image to a disk. Even shell built-ins should do the job. E.g.
cat my.iso > /dev/myusbstickreads the file and puts it on the stick (which is also a file). Cat reads a file byte for byte (test by cat’ing any binary) and>redirects the output to another file, which can be a device file like a usb stick.There’s no practical difference between those tools, besides how fast they are. E.g. dd without the block size set to >=1K is pretty slow [1], but I guess most tools select large enough I/O sizes to be nearly identical (e.g. cp).
[1] https://superuser.com/questions/234199/good-block-size-for-disk-cloning-with-diskdump-dd#234204