Retrieving disk info from sunvdc using udevadm

Retrieving disk info from sunvdc using udevadm

[John Paul Adrian Glaubitz]

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Í".

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Þbian_9.0_sparc64_1
ID_FS_LABEL_ENCÞbian\x209.0\x20sparc64\x201
ID_FS_TYPE=iso9660
ID_FS_USAGE=filesystem
ID_FS_UUID 17-03-14-14-05-33-00
ID_FS_UUID_ENC 17-03-14-14-05-33-00
ID_PART_TABLE_TYPE=sun
MAJOR%4
MINOR$
SUBSYSTEM=block
USEC_INITIALIZEDc4522
/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ÍDVDW_SE-S084D
ID_MODEL_ENCÍDVDW\x20SE-S084D\x20
ID_MODEL_ID\x1836
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Í
ID_USB_DRIVER=usb-storage
ID_USB_INTERFACES=:080250:
ID_USB_INTERFACE_NUM\0
ID_VENDOR=TSSTcorp
ID_VENDOR_ENC=TSSTcorp
ID_VENDOR_ID\x0e8d
MAJOR\x11
MINOR=0
SUBSYSTEM=block
SYSTEMD_READY=0
TAGS=:systemd:uaccess:seat:
USEC_INITIALIZED\x16198574878
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.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Retrieving disk info from sunvdc using udevadm

[Anatoly Pugachev]

On Wed, Mar 15, 2017 at 1:14 AM, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> 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Í".
>
> 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Þbian_9.0_sparc64_1
> ID_FS_LABEL_ENCÞbian\x209.0\x20sparc64\x201
> ID_FS_TYPE=iso9660
> ID_FS_USAGE=filesystem
> ID_FS_UUID 17-03-14-14-05-33-00
> ID_FS_UUID_ENC 17-03-14-14-05-33-00
> ID_PART_TABLE_TYPE=sun
> MAJOR%4
> MINOR$
> SUBSYSTEM=block
> USEC_INITIALIZEDc4522
> /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ÍDVDW_SE-S084D
> ID_MODEL_ENCÍDVDW\x20SE-S084D\x20
> ID_MODEL_ID\x1836
> 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Í
> ID_USB_DRIVER=usb-storage
> ID_USB_INTERFACES=:080250:
> ID_USB_INTERFACE_NUM\0
> ID_VENDOR=TSSTcorp
> ID_VENDOR_ENC=TSSTcorp
> ID_VENDOR_ID\x0e8d
> MAJOR\x11
> MINOR=0
> SUBSYSTEM=block
> SYSTEMD_READY=0
> TAGS=:systemd:uaccess:seat:
> USEC_INITIALIZED\x16198574878
> 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?

PS: running qemu on x86_64 as

$ qemu-system-sparc64  -hda hda.img  -cdrom debian-7.11.0-sparc-netinst.iso

and inside qemu :

# udevadm info -q env -p /sys/block/sr0
DEVLINKS=/dev/cdrom1 /dev/disk/by-id/ata-EQUMD_DVR-MO_MQ0000_3
/dev/disk/by-label/Debian\x207.11.0\x20sparc\x201
/dev/disk/by-path/platform-ffe2b5a8-pci-0000:00:05.0-scsi-1:0:0:0
/dev/dvd1
DEVNAME=/dev/sr0
DEVPATH=/devices/root/ffe2b5a8/pci0000:00/0000:00:05.0/host1/target1:0:0/1:0:0:0/block/sr0
DEVTYPE=disk
GENERATED=1
ID_ATA=1
ID_BUS=ata
ID_CDROM=1
ID_CDROM_DVD=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_CD=1
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_FS_LABELÞbian_7.11.0_sparc_1
ID_FS_LABEL_ENCÞbian\x207.11.0\x20sparc\x201
ID_FS_TYPE=iso9660
ID_FS_USAGE=filesystem
ID_MODEL=EQUMD_DVR-MO
ID_MODEL_ENC=EQUMD\x20DVR-MO\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_PART_TABLE_TYPE=sun
ID_PATH=platform-ffe2b5a8-pci-0000:00:05.0-scsi-1:0:0:0
ID_PATH_TAG=platform-ffe2b5a8-pci-0000_00_05_0-scsi-1_0_0_0
ID_REVISION=.2+5
ID_SERIAL=EQUMD_DVR-MO_MQ0000_3
ID_SERIAL_SHORT=MQ0000_3
ID_TYPEÍ
MAJOR\x11
MINOR=0
SUBSYSTEM=block
TAGS=:udev-acl:
UDEV_LOG=3
USEC_INITIALIZED9425573

dmesg cut:

[   37.995639] udevd[43]: starting version 175
[   43.839280] SCSI subsystem initialized
[   44.074912] libata version 3.00 loaded.
[   44.168027] scsi0 : pata_cmd64x
[   44.174100] scsi1 : pata_cmd64x
[   44.175483] ata1: PATA max UDMA/33 cmd 0x1fe02008080 ctl
0x1fe02008100 bmdma 0x1fe02008280 irq 7
[   44.176309] ata2: PATA max UDMA/33 cmd 0x1fe02008180 ctl
0x1fe02008200 bmdma 0x1fe02008288 irq 7
[   44.197377] pata_cmd64x: active 10 recovery 10 setup 3.
[   44.197550] pata_cmd64x: active 10 recovery 10 setup 3.
[   44.366417] ata1.01: NODEV after polling detection
[   44.368357] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
[   44.368716] ata1.00: 18874368 sectors, multi 16: LBA48
[   44.369956] pata_cmd64x: active 3 recovery 1 setup 1.
[   44.378555] ata1.00: configured for UDMA/33
[   44.410389] scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK
  2.5+ PQ: 0 ANSI: 5
[   44.430084] pata_cmd64x: active 10 recovery 10 setup 3.
[   44.430132] pata_cmd64x: active 10 recovery 10 setup 3.
[   44.586422] ata2.01: NODEV after polling detection
[   44.586997] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
[   44.587517] pata_cmd64x: active 4 recovery 2 setup 1.
[   44.588013] ata2.00: configured for UDMA/33
[   44.592133] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM
  2.5+ PQ: 0 ANSI: 5
[   45.049560] sd 0:0:0:0: [sda] 18874368 512-byte logical blocks:
(9.66 GB/9.00 GiB)
[   45.057268] sd 0:0:0:0: [sda] Write Protect is off
[   45.057602] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   45.059324] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   45.080040] sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[   45.080716] cdrom: Uniform CD-ROM driver Revision: 3.20
[   45.097015] sr 1:0:0:0: Attached scsi CD-ROM sr0
[   45.104671]  sda: sda1 sda2 sda3
[   45.114193] sd 0:0:0:0: [sda] Attached SCSI disk
[   45.289872] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   45.298169] sr 1:0:0:0: Attached scsi generic sg1 type 5
[   46.943661] device-mapper: uevent: version 1.0.3

Re: Retrieving disk info from sunvdc using udevadm

[John Paul Adrian Glaubitz]

On 03/16/2017 01:15 PM, Anatoly Pugachev wrote:
> 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?

We have discussed this shortly, but we haven't really agreed on whether
this would be a clean solution after all. I mean, if you attach an ISO
file to a virtual CD-ROM drive, the kernel should report the corresponding
block device to be an actual CD-ROM drive, shouldn't it?

> # udevadm info -q env -p /sys/block/sr0
> (...)
> ID_CDROM=1

See, qemu does it correctly, sunvdc does not. And I assume all other type
of virtualization software (VirtualBox, VMWare) reports the right block
device type either. Otherwise we would have already seen lots of bug
reports regarding this. So I don't think it's justified to add a quirk for
sunvdc, is it?

> dmesg cut:
> (...)

I'm not sure how this is relevant here?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Retrieving disk info from sunvdc using udevadm

[James Clarke]

[-- Attachment #1: Type: text/plain, Size: 3836 bytes --]

On 16 Mar 2017, at 12:15, Anatoly Pugachev <matorola@gmail.com> wrote:
> On Wed, Mar 15, 2017 at 1:14 AM, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> 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 #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Retrieving disk info from sunvdc using udevadm

[John Paul Adrian Glaubitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/16/2017 01:39 PM, James Clarke wrote:
> 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.

Ah, good point. I will try patching the file and see if that helps.

> Certainly if you invoke /lib/udev/cdrom_id manually it is able to distinguish between CDs and non-CDs.

I have actually been fumbling with that in the past. That was when I fixed
the autoloading mechanism.

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAljKiL8ACgkQdCY7N/W1
+RNcMw//XIBd7T5xnVb7ENWRrld8vMiBP9zl7xkHg7s8zjJ7uQDPlm/P/Styc1fU
IjLOpVSuZyS83uRe33R62SgIEmv1PKKotvmYJXBznIaLZnSrDEwEuISJregJU2Jb
Nb9eYppwyDi/flpxqaKuTHIVrkGyJRU7LAMv1Gd91L5ELqNUAfmF5hsx9A1q4rgJ
ARpw+nQf15zdy0YTgxTXlFz2f8rPYFOv0ueh5ZGqfn8zFQiFZh49OtLghkkpjdFF
SZ4+rQ5NlquAl2WOLXudlC/oIopNhEb6J7nXnI056vuOTHQvhDnPw0wF7tcdf97g
PHxZpr1KRYQrqG3Q/AVAR5uOfxvNKBJUL/sUmBXkY3WLUMeUafzXAIqMWAw81FpB
VIFj6yDkhDFr0bFgAj2GhmoCLnH8izmuUKEK3GSJndsoftP8ilXe4OU0E4/kJxB9
w/LW52YqXb+ih0k2bh2iMdzhzRCo/qyVNJzCHwkv1EDVVHnwV3HlWS29wKlMezcM
4uU6FJPytiAuBs9f8MM0QtHq/u1bqUsghdlgw3SsZYDkXjISW/awMLkjAASf/RSD
c9hKl5kTAg5lMG2Na5NhUloiQ0CLKFRL7UES7PKMbqbQj4lC1MbZDYSgXPRGNjfc
aPuohLXE7+isGBCGRYdwRWXR58kOdyFB9OkPrdwVVLAdFwBy+A8=zoL8
-----END PGP SIGNATURE-----

Re: Retrieving disk info from sunvdc using udevadm

[John Paul Adrian Glaubitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/16/2017 01:44 PM, John Paul Adrian Glaubitz wrote:
> On 03/16/2017 01:39 PM, James Clarke wrote:
>> 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.
> 
> Ah, good point. I will try patching the file and see if that helps.

It does. Sent a pull request to systemd upstream [1].

Adrian

> [1] https://github.com/systemd/systemd/pull/5599

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAljKkNwACgkQdCY7N/W1
+ROC6xAArSbF8zFTTwMu8D1IASAHyNzFa8GpdPfKpaHOKRVZwuTADf4RuVsEct6f
fNy5k1oMXJxTOiguOA4rkuWQjtyVOUVXhxh5W+xBtEDCrz4NSvBw9m4WbpWKbCtk
zgkvq1jXVuiut81VLbZhYDlIjMNcyplHs9tpwqQXbQfWSo0Xu8Yb9exWkSs1/Jg/
O7y0kyUQqkhIHU0stsgsZh+uP97PAFobBfBNhtSbRRNbMQr2nY1v+AHpTvoaHMrI
CLBWXGCJgM/64HKIiBe3TWF9RPwehyLRUgoTKfWDCCst+Yi3OZZ7LGGSdef9tiux
iF1e173ZjWEMnmB78ejogRaZz+TZWAIEBOAH2Bcf83ycm7rnjW6mUShAxt+W7pLN
q1RdFXrNLwVlXmFAlrvLyRTWj6csLgj3Iu8JD3Qn9TE8zWHBXP83EnOeTyyAzERs
716SrkwkopkAcoeBqR2RhvJqi5/DhdPZfZXXCbvF+360BPqGldEkG+FlJdvYtUka
m5lnmGiSFsDZ+wsSvuPoAALWnAuYo7S0v5TFyHO5z3YHs/q9p8n1Ucm36bKHHyYq
qvXB/9k7t+PGd8Kjk3zgB/Nx2EkoCB3VMpxi6QRKzkyOD+aJ/+NLcck2IyNikDMy
eimsN96lWhND7uSYnUi+U8AvxZhHZkTjBwnBRZv3OOM565SkLzM‚ZK
-----END PGP SIGNATURE-----