Web lists-archives.com

RESOLVED: Trouble making bootable USB from ISO image

On Sat, May 04, 2019 at 05:03:42AM +0000, Russell L. Harris wrote:
> On Sat, May 04, 2019 at 11:39:39AM +0900, Mark Fletcher wrote:
> Nonetheless, I do find "Disks" handy to identity the device associated
> with a USB memory stick just plugged in, and to indicate at a glance
> the partitioning and formatting.

Indeed I used that at one point to see what state it thought the disk 
was in after I'd written the ISO image.

> According to "https://www.debian.org/CD/faq/#write-usb";, all Debian
> i386 and amd64 images are created using the isohybrid technology, so
> that they may be copied to USB flash drives which boot directly from
> the BIOS or EFI firmware of most PCs.  In Linux, copy with "cp <file>
> <device>" or with "dd if=<file> of=<device> bs=4M; sync".  And be sure
> you are copying to the device (such as "/dev/sdd") and not to a
> partition of the device (such as "/dev/sdd1").

Indeed, that was how I did it. The Windows download page clearly 
indicated that the ISO was for USB sticks or DVDs. Someone else also 
asked about the size of the image, being too big for a single-layer DVD. 
In answer to their question yes the download page did point that out, if 
one read as far as the troubleshooting section where it said something 
like "If your burner says there isn't enough space on the DVD, it means 
you need a dual-layer DVD" or similar." Since I was using a 16GB pen 
drive I wasn't worried about that element of things.

> In the case of a USB flash drive which refuses to boot, you might try
> using "fdisk" to delete all existing partitions and create a new
> partition, followed by "mkfs.msdos" before you copy the ISO image to
> the drive.

I essentially did that at one point while troubleshooting the pen drive, 
except using Gnome's ability to "format" the device (now there's a blast 
from the past)

> If everything else fails, before you toss the drive into the dumpster,
> plug the drive into a Window$ box and allow Window$ to format the
> drive.  Now and then a Window$ box can do something useful.

Would only be an option if you have a windows machine to do it on. 
Someone did suggest installing kvm and launching the ISO as a VM, and 
then using that to burn the ISO onto a USB stick -- that was a creative 
solution I hadn't thought of. Using a VM for the entire experiment in 
the first place could almost have been a solution, actually -- except 
that I want my son to be able to access the machine when I'm not around.

But in the end it turned out the image was fine -- and the very first 
burn I did was probably also fine. Thank god we are past the days of 
DVDs or I would have had half a dozen shiny new coasters for no good 

The issue was Secure Boot. Specifically, in the case of my test machine, 
it's too old to support secure boot, and in the case of the final target 
machine, secure boot was turned off in the BIOS so that I could boot 
Buster which is what this machine was previously running. When I 
switched the CSM and also turned on Secure Boot (both settings needed to 
be changed) in the BIOS, the machine finally booted from the USB stick, 
and all proceeded smoothly from there.

So the issue in the end, contrary to my instincts, was nothing to do 
with errors or mistakes in writing the image to the pen drive (although 
I'm grateful for the memory refresh around the difference between 
unmounting and ejecting removable drives and the confirmation of the 
common-sense point that a drive needs to not be mounted when you write 
an image to it. In practice I think it actually worked, since the result 
looked healthy when I mounted it, but the advice is good nonetheless)

Thanks all for your help. And now as a result of this exercise I've had 
returned to me another machine which can be my new Buster toy :)

The other thing this has surfaced is all that noise in the logs when 
writing using a motherboard-builtin USB2 socket. When I tried the 
process in a USB3 socket provided by an add-in card, I didn't get all 
that noise in the log with system call quotes and compaints about 
systemd-udevd being blocked for too long. Interesting but I no longer 
think evidence of an actual problem, as I now believe all image writes 
worked correctly.