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
