Re: Latest netinst iso
> [ 21.343237] ata2.00: ATAPI: HL-DT-ST RW/DVD GCC-H20N, C805, max UDMA/44
Aha. An LG CD burner and DVD reader ("combo" drive). A dozen years old,
> [ 21.367287] ata2.00: configured for MWDMA2
> [ 42.175653] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> [ 42.176013] ata2.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0 dma 96 in
> Inquiry 12 00 00 00 60 00res
> 40/00:02:00:24:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
I recognize an SCSI command INQUIRY (code 0x12) which requests 0x0060 = 96
bytes from the drive. That's quite some bytes more than libburn asks for in
the first contact (0x0024 = 36 bytes).
Nothing happens for 20.8 seconds and then a timeout is reported.
This could be a mis-coordination with the lower drivers. I remember that
about 10 years ago, we burn programmers had to change our SG_IO strategy.
Commands with variable length reply needed to be executed first with
minimum reply length and then again with the reply length that is
announced by the reply to the first command execution.
If we requested too much on the first try, the transaction did not end.
> [ 42.380290] scsi 1:0:0:0: scsi scan: 96 byte inquiry failed. Consider BLIST_INQUIRY_36 for this device
> [ 42.381094] scsi 1:0:0:0: CD-ROM HL-DT-ST RW/DVD GCC-H20N C805 PQ: 0 ANSI: 5
Looks like it tries again with less bytes and gets to sr and cdrom drivers:
> [ 42.509234] sr 1:0:0:0: [sr0] scsi3-mmc drive: 8x/59x cd/rw xa/form2 cdda
> [ 42.509258] cdrom: Uniform CD-ROM driver Revision: 3.20
> [ 42.515251] sr 1:0:0:0: Attached scsi CD-ROM sr0
So far so good. /dev/sr0 should exist now.
> [ 42.661390] ata_id: unable to open '/dev/sr0'
> [ 42.893291] ata_id: unable to open '/dev/sr0'
But why ?
> [ 55.968323] sr 1:0:0:0: Attached scsi generic sg1 type 5
Looks like /dev/sr0 is not totally dead.
So what do you get when trying to read the first MB from it ?
dd if=/dev/sr0 bs=2048 count=512 of=/dev/null
Is it mounted when the installer does not find it ? (As /cdrom ?)
Well, if it is readable, then we could ask at debian-boot list how
CDROM detection is supposed to work and how to debug it.
A first guess for the source would be
I was in an amd64 ISO initrd a few months ago
It contains a script which shall list all CD drives when called with
argument "cd". On my running system it lists /dev/sr0 to /dev/sr4.
It inquires the device type by /bin/udevadm.
What do you get from
If no /dev/sr* is listed, what do you get from
/bin/udevadm info -q env -p /sys/block/sr0
Have a nice day :)