Re: Debian Live USB fails; bricks the USB stick

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i wrote:
> >       Did you also check the MD5 of the copy on USB stick ?

Kent West wrote:
> No, I did not check the MD5 of the USB stick's copy. This is a good thing to
> know for future attempts.

Regarding the current Live ISOs there is a deviation necessary from
  https://www.debian.org/CD/faq/#verify
The image file size is larger than the ISO filesystem size. The checksum
lists tell the checksums for the file size. So you need to use that size
divided by 2048 and not e.g. the result of "/sbin/isosize -x".
I already reported this problem to debian-live.


> The headline says "GNU GRUB Version 2.02~beta3-5". 

So your machine's firmware is running in native EFI mode.


> > qemu-system-x86_64 -enable-kvm -m 512 \
> >                    -bios /usr/share/ovmf/OVMF.fd \
> >                    -hda debian-live-9.2.0-amd64-cinnamon.iso

> Yeah, I get to a partial Cinnamon desktop (it's missing pieces) so that
> tells me that the image [mostly/sort of] works.

So the firmware of your machine has something to do with the problem.
(I assume you made sure to use OVMF by option -bios instead of the default
 firmware which will act as classic BIOS and boot the ISOLINUX menu.)


> But I also tried re-enabling BIOS/Legacy [...] it didn't help.

We need the exact error messages for searching in the code.


> I thought I had rescued one of the sticks by discovering that cfdisk would
> write to it and wipe out the partitions.

There are some stumblestones in the ISOs: Partition start at block 0,
presence of invalid GPT and of its backup GPT at the end of the image.
If the partition editors take offense, there is the nuke option to zero
the whole stick:

  dd if=/dev/zero of=/dev/sdc

Similarly powerful but less devastating is to have a backup image of the
original stick content and to overwrite the whole stick by it.


(next mail:)

> dd: failed to open '/dev/sdc': No medium found
> ...
> [89886.723738] sd 6:0:0:0: [sdc] Attached SCSI removable disk

Now that's a strange one.
Such a behavior can hardly be caused by copying any image data onto the stick.

So where in the kernel can an USB stick cause ENOMEDIUM ... ? 
Probably in line 1344 of
  https://github.com/torvalds/linux/blob/master/drivers/scsi/sd.c
which imposes the question how struct scsi_disk.media_present gets
set to 0.
One possibility is in line 1522, where the error reply of an SCSI device
is interpreted: Key 2, ASC 0x3A means indeed "MEDIUM NOT PRESENT".
This message would stem from the USB stick. But why should it say that ?
(I'd really like to have my theory more plausible.)

I only have experience with optical drives, not with disk-like devices.
Nevertheless i'd say that there are two potential problems:
- a hardware problem with one stick
- a software problem with any stick

In order to investigate the potential software problem you need to get
a stick which does not tell that there is no medium when you try to
write to its device file or to read from it.

The potential hardware problem should be investigated by plugging the
stick into other computers and checking whether one can read from or
write to its device file.


Have a nice day :)

Thomas