On 16 Mar 2017, at 12:15, Anatoly Pugachev <matorola@xxxxxxxxx> wrote: > On Wed, Mar 15, 2017 at 1:14 AM, John Paul Adrian Glaubitz > <glaubitz@xxxxxxxxxxxxxxxxxxx> wrote: >> Hi! >> >> Some Debian users who are installing Debian for sparc64 in an LDOM run into >> the problem that the debian-installer is unable to detect the installation >> medium. >> >> Digging through the sources of the responsible debian-installer module, it >> turns out that d-i uses "udevadm info" to query information from all available >> block devices listed in /sys/block. To detect a CD-ROM, it looks for "ID_CDROM=1" >> or "ID_TYPE=cd". >> >> Unfortunately, this fails with sunvdc with a virtual CD-ROM drive as the data >> retrieved by "udevadm info" is very limited as compared to a standard PC with >> a physical CD-ROM drive. >> >> For comparison, on a SPARC T5, I get: >> >> /sys/block # udevadm info -q env -p /sys/block/vdiskd >> DEVLINKS=/dev/disk/by-uuid/2017-03-14-14-05-33-00 /dev/disk/by-label/Debian\x209.0\x20sparc64\x201 >> DEVNAME=/dev/vdiskd >> DEVPATH=/devices/channel-devices/vdc-port-3-0/block/vdiskd >> DEVTYPE=disk >> ID_FS_LABEL=Debian_9.0_sparc64_1 >> ID_FS_LABEL_ENC=Debian\x209.0\x20sparc64\x201 >> ID_FS_TYPE=iso9660 >> ID_FS_USAGE=filesystem >> ID_FS_UUID=2017-03-14-14-05-33-00 >> ID_FS_UUID_ENC=2017-03-14-14-05-33-00 >> ID_PART_TABLE_TYPE=sun >> MAJOR=254 >> MINOR=24 >> SUBSYSTEM=block >> USEC_INITIALIZED=634522 >> /sys/block # >> >> Compare this to the output for a standard USB CD-ROM device on my laptop: >> >> glaubitz@ikarus:/sys/block$ udevadm info -q env -p /sys/block/sr0 >> DEVLINKS=/dev/disk/by-path/pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0 /dev/disk/by-id/usb-TSSTcorp_CDDVDW_SE-S084D_0j468695-0:0 /dev/dvdrw /dev/dvd /dev/cdrom >> /dev/cdrw >> DEVNAME=/dev/sr0 >> DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/host4/target4:0:0/4:0:0:0/block/sr0 >> DEVTYPE=disk >> ID_BUS=usb >> ID_CDROM=1 >> ID_CDROM_CD=1 >> ID_CDROM_CD_R=1 >> ID_CDROM_CD_RW=1 >> ID_CDROM_DVD=1 >> ID_CDROM_DVD_PLUS_R=1 >> ID_CDROM_DVD_PLUS_RW=1 >> ID_CDROM_DVD_PLUS_R_DL=1 >> ID_CDROM_DVD_R=1 >> ID_CDROM_DVD_RAM=1 >> ID_CDROM_DVD_RW=1 >> ID_CDROM_MRW=1 >> ID_CDROM_MRW_W=1 >> ID_FOR_SEAT=block-pci-0000_00_14_0-usb-0_2_1_0-scsi-0_0_0_0 >> ID_INSTANCE=0:0 >> ID_MODEL=CDDVDW_SE-S084D >> ID_MODEL_ENC=CDDVDW\x20SE-S084D\x20 >> ID_MODEL_ID=1836 >> ID_PATH=pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0 >> ID_PATH_TAG=pci-0000_00_14_0-usb-0_2_1_0-scsi-0_0_0_0 >> ID_REVISION=TS00 >> ID_SERIAL=TSSTcorp_CDDVDW_SE-S084D_0j468695-0:0 >> ID_SERIAL_SHORT=0j468695 >> ID_TYPE=cd >> ID_USB_DRIVER=usb-storage >> ID_USB_INTERFACES=:080250: >> ID_USB_INTERFACE_NUM=00 >> ID_VENDOR=TSSTcorp >> ID_VENDOR_ENC=TSSTcorp >> ID_VENDOR_ID=0e8d >> MAJOR=11 >> MINOR=0 >> SUBSYSTEM=block >> SYSTEMD_READY=0 >> TAGS=:systemd:uaccess:seat: >> USEC_INITIALIZED=16198574878 >> glaubitz@ikarus:/sys/block$ >> >> Would it be possible to extend sunvdc to display additional fields? In particular, it would be very useful >> if sunvdc could indicate whether the virtual block device is a regular disk or a CD-ROM drive. > > > Adrian, > > wouldn't it be easier to patch d-i (userspace) to add support for > "ID_FS_TYPE=iso9660" as /dev/cdrom (besides of "ID_CDROM=1"), instead > of patching kernel (sunvdc.c) sources? Patching d-i might make sense, since it will ensure other architectures don't have similar issues, but I believe the problem is in udev itself, specifically 60-cdrom_id.rules[1] which needs to whitelist "vdisk*" as possible CDs. Certainly if you invoke /lib/udev/cdrom_id manually it is able to distinguish between CDs and non-CDs. Regards, James [1] https://github.com/systemd/systemd/blob/master/rules/60-cdrom_id.rules
Attachment:
signature.asc
Description: Message signed with OpenPGP
