3

When I connect my Samsung 390G (a cheap cell phone!) to Ubuntu 13.04, dmesg seems to indicate that the storage device thereon is recognizable:

[Sun Dec 29 01:26:10 2013] scsi16 : usb-storage 2-1.2:1.0
[Sun Dec 29 01:26:11 2013] scsi 16:0:0:0: Direct-Access     SAMSUNG  MMC Storage      2.31 PQ: 0 ANSI: 2
[Sun Dec 29 01:26:11 2013] sd 16:0:0:0: Attached scsi generic sg2 type 0
[Sun Dec 29 01:26:11 2013] sd 16:0:0:0: [sdb] 61497344 512-byte logical blocks: (31.4 GB/29.3 GiB)
[Sun Dec 29 01:26:11 2013] sd 16:0:0:0: [sdb] Write Protect is off
[Sun Dec 29 01:26:11 2013] sd 16:0:0:0: [sdb] Mode Sense: 0f 0e 00 00
[Sun Dec 29 01:26:11 2013] sd 16:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[Sun Dec 29 01:26:11 2013]  sdb: sdb1
[Sun Dec 29 01:26:11 2013] sd 16:0:0:0: [sdb] Attached SCSI removable disk
[Sun Dec 29 01:26:11 2013] sd 16:0:0:0: [sdb] Synchronizing SCSI cache

But the problem is that no device shows up for this (i.e. no /dev/sdb or /dev/sdb1). I'm speculating that I need to do some udev rulemaking here, but don't I need to be able to find the parent node in /sys for that? And I can't find anything -- not completely sure where to look, but so far my reasonable-sounding guesses haven't yielded anything.

Note for reference that this device does mount as a drive in Windows Explorer, so I'm confident that the phone works as expected.

  • not sure if that works, but have you tried to run partprobe? and do you see the device in /proc/partitions? – replay Dec 31 '13 at 15:56
  • @mauro: /proc/partitions shows only my 'sda' and 'sr0' stuff. I did run partprobe, no help. And partprobe -s shows only sda. – Stabledog Dec 31 '13 at 16:01
  • After adding the device can you not run fdisk -l /dev/sdb1? – slm Dec 31 '13 at 21:14
  • @slm That command would be fdisk -l /dev/sdb, but actually that wouldn't do anything useful: phones usually show up as a single filesystem, not a partitioned volume. Stabledog: with a kernel showing sdb, you should see a /sys/block/sdb and a /dev/sdb. The default rules only need to be changed if you want the raw device to be accessible to users. Are there no further kernel messages? Is there an entry under /dev/disk/by-*? Compare the output of find /sys | sort and find /dev | sort with the device in and out. – Gilles Dec 31 '13 at 23:29
  • @Gilles: the absence of /sys/block/sdb is baffling to me. I have recently found a /sys/bus/usb/devices/2-1.2 which matches my phone's vendor and product ID, so now I'm a little further forward, I think. But there's no /sys/block/sdb{*} at all. So I'm hoping I can write a udev rule which turns the /sys... object into something in /dev, but the absence of a block device in /sys/block has me worried. (I've already searched /dev/disk/, btw. No luck) – Stabledog Dec 31 '13 at 23:57
0

You'll likely need to add a UDEV rule to detect this devices presences. Once the device is detected, UDEV can create the corresponding /dev/sdb1 to go along with it.

These docs from OpenSUSE should get you started in the creation of this rule.

Regarding your question:

"... but don't I need to be able to find the parent node in /sys for that? And I can't find anything..."

I would expect that if the kernel has successfully detected /dev/sdb1, which it has since you're getting those messages in your dmesg log, then you'd have corresponding entries under /sys.

I would investigate the /sys more thoroughly, there is likely a device handle hiding in there that corresponds to /dev/sdb1. You can walk around the tree using this command: udevadm info -a -p /sys/class/... you'll need to add on the appropriate device in place of the dots (...).

Example

$ udevadm info -a -p /sys/class/ata_device/dev1.0 

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1f.2/ata1/link1/dev1.0/ata_device/dev1.0':
    KERNEL=="dev1.0"
    SUBSYSTEM=="ata_device"
    DRIVER==""
    ATTR{gscr}==""
    ATTR{class}=="ata"
    ATTR{ering}=="[4294667.658000000]Unknown"
    ATTR{spdn_cnt}=="0"
    ATTR{pio_mode}=="XFER_UDMA_7, XFER_UDMA_6, XFER_UDMA_5, XFER_UDMA_4, XFER_MW_DMA_4, XFER_PIO_6, XFER_PIO_5, XFER_PIO_4, XFER_PIO_3, XFER_PIO_2, XFER_PIO_1, XFER_PIO_0"
    ATTR{dma_mode}=="XFER_UDMA_7, XFER_UDMA_6, XFER_UDMA_5, XFER_UDMA_4, XFER_UDMA_3, XFER_UDMA_2, XFER_UDMA_1, XFER_UDMA_0, XFER_MW_DMA_4, XFER_MW_DMA_3, XFER_MW_DMA_2, XFER_SW_DMA_2, XFER_PIO_6, XFER_PIO_5, XFER_PIO_4, XFER_PIO_3, XFER_PIO_2"
    ATTR{xfer_mode}=="XFER_UDMA_7, XFER_UDMA_6, XFER_UDMA_5, XFER_UDMA_4, XFER_UDMA_3, XFER_UDMA_2, XFER_UDMA_1, XFER_UDMA_0, XFER_MW_DMA_4, XFER_MW_DMA_3, XFER_MW_DMA_2, XFER_SW_DMA_2, XFER_PIO_6, XFER_PIO_5, XFER_PIO_4, XFER_PIO_3, XFER_PIO_2"

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata1/link1/dev1.0':
    KERNELS=="dev1.0"
    SUBSYSTEMS==""
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata1/link1':
    KERNELS=="link1"
    SUBSYSTEMS==""
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata1':
    KERNELS=="ata1"
    SUBSYSTEMS==""
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1f.2':
    KERNELS=="0000:00:1f.2"
    SUBSYSTEMS=="pci"
    DRIVERS=="ahci"
    ATTRS{irq}=="40"
    ATTRS{subsystem_vendor}=="0x17aa"
    ATTRS{broken_parity_status}=="0"
    ATTRS{class}=="0x010601"
    ATTRS{consistent_dma_mask_bits}=="64"
    ATTRS{dma_mask_bits}=="64"
    ATTRS{local_cpus}=="00000000,00000000,00000000,0000000f"
    ATTRS{device}=="0x3b2f"
    ATTRS{msi_bus}==""
    ATTRS{local_cpulist}=="0-3"
    ATTRS{vendor}=="0x8086"
    ATTRS{subsystem_device}=="0x2168"
    ATTRS{numa_node}=="-1"
    ATTRS{d3cold_allowed}=="1"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""
  • The distribution is Ubuntu 13.04 (as stated in the question). I have considered that I need to write a udev rule, but how can I do that if I can't find the device in /sys? That's really the question... I'm aware that there are plenty of resources and guidance for udev rules, but don't they all depend on being able to first find the darn thing in the kernel tree? – Stabledog Dec 31 '13 at 20:12
  • @Stabledog - Yes to a point. I would expect that if the kernel has successfully detected /dev/sdb1 then you'd have corresponding entries under /sys. I would investigate the /sys more thoroughly, there is likely a device handle hiding in there that corresponds to /dev/sdb1. You can walk around the tree using this command: udevadm info -a -p /sys/class/...` you'll need to add on the appropriate device in place of the dots (...). – slm Dec 31 '13 at 21:41
  • Ok, that helped me get oriented. I've found a device under /sys/bus/usb/devices/2-1.2 which corresponds to my phone, and 'udevadm info -a -p ...' applied to that path does dump out a bunch of udev-property style info. So now I hope to be able to follow the standard guides! :) Thanks. – Stabledog Dec 31 '13 at 23:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.