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
reason.
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.
Mark
Reply to: