[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Live USB fails; bricks the USB stick

On Tue, Nov 7, 2017 at 4:03 PM, Thomas Schmitt <scdbackup@gmx.net> wrote:

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

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

The first one I tried, yes. But I also tried that machine in Legacy BIOS mode.

The qemu test below I did on a completely different machine. I'm fairly sure it's set to boot in Legacy BIOS 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.)

On the qemu test that I did, based on what you wrote above, that was in an X terminal window on a completely different machine, without the USB stick anywhere near. I was just testing the .ISO file. This machine does not have a /usr/share/ovmf directory, so I did not include that part of the command in my command.

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

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

I just now tried again. I went into the Firmware Setup, and told it to enable the legacy modules, and told it to use the Legacy Boot (turning off the UEFI boot).

I then booted from the (still-working, somewhat) USB stick, and got to a "Main Menu" (no header mentioning grub). I choose the top option (Debian GNU/Linux Live (kernel 4.9.0-4-amd64) and get as a result:

Loading /live/vmlinuz-4.0.9-4-amd64... ok
Loading /live/initrd.img-4.0.9-4-amd64...

and then there's a very brief flash of a line that I can almost imagine I see the word "failed" in, and then it returns to the "Main Menu".


> 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

On the one stick, I get:

dd: failed to open '/dev/sdc': No medium found

I haven't yet tried it on the still-somewhat-working stick.

Whereas I was able to use cfdisk on the now-non-working stick (maybe after using hdparm? maybe after some other thing I tried?), I still get the "cfdisk: cannot open /dev/sdc: Read-only file system" on the still-somewhat-working stick.

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
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.

My somewhat-still-working stick does not generate this "no medium" error. 

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.

I have tried both sticks in at least three machines. The sticks were working fine until I tried to turn them into a Live Debian USB stick, and it's just gone downhill from there. I'm willing to nuke the second somewhat-still-working stick with the "dd if=/dev/zero of=/dev/sdc" command, but I'll wait a few minutes to see if anyone wants to respond to this email.

Have a nice day :)



Kent West                    <")))><
Westing Peacefully - http://kentwest.blogspot.com

Reply to: