Hi Thomas, On Jun 3, 2018, at 1:26 AM, Thomas Schmitt <scdbac...@gmx.net> wrote:
> Hi, > > Rick Thomas wrote: >> Instead, I used >> firmware-9.4.0-amd64-netinst.iso >> to avoid any possible alpha/testing anomalies. > > Normally i'd say that there is no decisive difference to expect. > In any case copying a "netinst" ISO is much faster than a "DVD-1". > > >> When I tried part (a) — just a simple dd — with >> debian-9.4.0-amd64-netinst.iso, the minnowboard immediately recognized it as >> bootable and presented it as part of the EFI menu labeled “EFI USB Device”. > > Normally this difference should not appear. Very strange. > > But we can now classify the demand for GPT on > https://minnowboard.org/tutorials/best-practice-boot-media-selection > as spin-off of the usual rumor that EFI needs GPT. > > >> it booted without incident and ran the installer. >> When it came to the part where it looks for a CD, it easily found the USB >> stick > > This was expectable. As long as the ISO is marked as partition, the > script in the initrd should find the device. > > >> tried >> part (a) with “firmware-buster-DI-alpha2-amd64-DVD-1.iso”. And guess what! >> That worked too, just the same as the other two. > > Hrmpf. At least above "normally"s are not generally put in doubt. > It would be another riddle if one ISO would fail reproducibly while > the other succedds reproducibly. > > Maybe you changed a setting in the firmware ? In the previous experiments (where I modified the partition tables on the stick after dd-ing) I did try some different setting in the firmware. But for the above described experiments, I reset the firmware to factory defaults before starting the process and made no changes thereafter. >> or there’s something flakey about the USB ports on this device > > But why did the manual start of “fs0:\efi\boot\bootx64.efi” ran the > boot loader, loaded the kernel, and came far enough to run into the > software shortcoming of device detection ? I’m not absolutely sure that the manual start was necessary. I may have gotten used to never seeing the “EFI USB Device” menu entry. So when the stars aligned and the stick *was* seen, I didn’t notice. So, maybe, the fact that I got it to work from the command line was just because it would have worked anyway that time from the EFI menu. >> In any case, I apologize for all the noise. > > I doubt that this was a hallucination. > If not the hardware (stick and port) makes itself a suspect by failing > in normal operation, then i’d bet on the firmware's settings. I’m pretty sure that everything I’ve been seeing can be explained if we assume the minnowboard firmware has trouble recognizing a USB3.0 device as bootable. > ------------------------------------------------------------------------- > >> Thomas, If you would like to follow up on the inability of the installer to >> recognize itself as a suitable installation CD > > I believe to understand that problem. Let's see whether debian-cd will > find a time slot to discuss it and whether trying the devices found by > "list-devices disk" (/dev/sda, /dev/sdb, /dev/sdc on my machine) is > harmless enough. > > It would be interesting to study the history of cdrom-detect.postinst > (package "cdrom-detect", 1600+ commits in > https://salsa.debian.org/installer-team/cdrom-detect/commits/master). > cdrom-detect/blame brings me to some forth and back, which probably > does not tell the reason for the decision not to look for "disk". > > I'd need a comfortable method to look at the revison _before_ a commit > in order to get the next older blaming. > Or a method to see only commits which affect the interesting code parts > devices="$(list-devices cd; list-devices maybe-usb-floppy)" > and > devices="$(list-devices usb-partition)" > ... > if try_mount $device $CDFS; then > > Any GitLab experts here who could help me navigate ? > Or git experts who can augment my knowledge beyond "clone", "add", > "commit", and "push", so that i can inspect a clone locally ? > > > Have a nice day :) > > Thomas >