On Tue, Nov 7, 2017 at 4:03 PM, Thomas Schmitt <scdbac...@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 > 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. > 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 :) > > Thomas > > Thanks! -- Kent West <")))>< Westing Peacefully - http://kentwest.blogspot.com
