Silverblue my arse

My Fedora 36 system was okay - but - not much use to me, or anyone… So I hosed it…

Had to use Fedora’s piece of crap burner app to make a USB - my most recent use of “dd” to write USB or SD-Card boot media have been pretty much “abortions” (which should be legal planetwide - that’s not politics, equal human reproductive rights are not politics) - I don’t do much that’s non-standard with “dd” so I’ve no idea WTF, but so far, Pi Foundation’s numpty “pi image writer” toy fo kids, Balena Etcher, and the flatpak Fedora image writer have all been able to make bootable images… Are they trying to kill / sabotage “dd”?

Man - a world where “dd” is no longer reliable is not one I’m comfortable in maintaining my existence…

So - anyway - Fedora 36 silverlight boots up okay - and - by the time I got here - I’d forgotten why I even bothered - it’s just fucking Gnome 42 which I already had on Fedora 36, and could had with Ubuntu 22.10 if I’d stuck around and persevered…

Bryan Lunduke’s 100% on the money - Linux Sucks… but hey - there’s still stuff that suck even more :smiley:

It may depend on what you are dd’ing
For example, there are ordinary .iso files, and hybrid .iso files
An ordinary .iso file will boot if you dd it to a DVD, but not if you dd it to a usb drive
A hybrid .iso file will boot if you dd it to either a DVD or an usb drive
So, on a block device, the content determines whether it will boot

Your file may not be an .iso, but I think the same principle applies. Someting has to be present to make stuff on a block device bootable

When you use packages like Etcher, they may add something behind your back to make it bootable.
dd will not do that, it guarantees an exact copy.

And, by the way, is all this dd’ing just to get stuff from a file to a block device? Why not use a loop mount instead?

1 Like

Hi @nevj,

Just curious. Is there a why to tell if a .iso file is a regular one or a hybrid?

Run the file command on the ISO image in question. The output from running this command on a non-hybrid ISO will look something like this

image.iso: ISO 9660 CD-ROM filesystem data 'foo' (bootable)

while the output from running this command on a hybrid ISO will look something like this

image.iso: DOS/MBR boot sector ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'foo' (bootable); partition 1 : ID=0x17, active, start-CHS (0x0,0,1), end-CHS (0x288,63,32), startsector 0, 1329152 sectors

Source
3 Likes

Hi @easyt50 ,
Use the file statement

Run the file command on the ISO image in question. The output from running this command on a non-hybrid ISO will look something like this

image.iso: ISO 9660 CD-ROM filesystem data 'foo' (bootable)

while the output from running this command on a hybrid ISO will look something like this

image.iso: DOS/MBR boot sector ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'foo' (bootable); partition 1 : ID=0x17, active, start-CHS (0x0,0,1), end-CHS (0x288,63,32), startsector 0, 1329152 sectors

You can convert from normal to hybrid with isohybrid

Most iso’s these days are hybrid

Cheers
Neville

2 Likes

╰─➤  file Fedora-Silverblue-ostree-x86_64-36-1.5.iso
Fedora-Silverblue-ostree-x86_64-36-1.5.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Fedora-SB-ostree-x86_64-36' (bootable)

╰─➤  file kinetic-desktop-canary-amd64.iso
kinetic-desktop-canary-amd64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Ubuntu 22.10 amd64' (bootable)

Note : *I’ve been using the “file” command since forever (well since the start of my personal epoch where I first used UNIX in the early/mid 1990s) - but I’ve noticed an alarming trend, I’ve actually had to MANUALLY INSTALL this vital piece of kit on recent distros… I think it lives in bsd-utils in Debian derived distros… WTF? Is this binary so VAAAAAAST and cumbersome that it needs to removed to improve housekeeping? Since when did BLOAT ever become a problem for Canonical anyway?

╭─x@titan ~  
╰─➤  which file          
/usr/bin/file
╭─x@titan ~  
╰─➤  ls -al /usr/bin/file
-rwxr-xr-x 1 root root 27200 Mar 25  2022 /usr/bin/file

By JOVE! We can save a MASSIVE 27 kilobytes if we don’t include “file” by default!

Anyway - in both cases, neither of these would boot from USB thumb drive

sudo dd if=ISO-name.iso of=/dev/$device-name bs=4M conv=sync status=progress

And even though I used “conv=sync” I still did a “sudo sync” after, to be sure, to be sure…

Using “lame” (IMHO - I’m arrogant enough to believe that CLI solutions are always superior to clickety-click-click solutions, and will always disparagingly refer to non-CLI things as “lame”) things like balena-etcher - I was able to boot from USB drives written from those ISO files - but - not when I used dd to create them… This sucks…

I want CLI stuff to work… and I don’t care if userland clickety-click-click stuff is broken :smiley: :heart: - long may Linux on the Desktop continue to suck and not become mainstream :smiley: :heart:

I see, they are both bootable hybrid isos according to file statement, but you say a dd copy will not boot.

When I copy hybrid iso files to usb with dd, they boot
so
either

  • your dd is wrong
  • those files are not really bootable
  • you have hardware issues with usb drives or connections

To help resolve it, I would like to try one of those files with my dd.
Are they downloadable from somewhere?

Cheers
Neville

PS…
conv=fsync… but I dont think that is the problem

conv=sync tells dd to pad each block to the left with nulls, so that if, due to error, the full block cannot be read, the full length of the original data is preserved, even though not all of the data itself can be included in the image. that way you at least know how damaged the data is, which might provide you with forensic clues, and if you can't take an image at all due to bad blocks or whatever, you can't analyze any of the data. some is better than none.

conv=sync is really only relevant to reading a serial device like a magnetic tape, which may have variable block sizes.

I think you should try either dropping conv=sync or replacing it with conv=fsync.

2 Likes