|
Bugzilla – Full Text Bug Listing |
| Summary: | USB drive isn't detected as such since 13.2 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Hans-Peter Jansen <hpj> |
| Component: | Basesystem | Assignee: | systemd maintainers <systemd-maintainers> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | chris, dsterba, hpj, oneukum, sbrabec, systemd-maintainers, whdu |
| Version: | 13.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
udev is using the informations found below /sys with the builtin usb_id and also tools like external toolw blkid and the libblkid You may have a look below /sys/block/ or /sys/class/block/ and /sys/class/scsi_disk/ *what* should be found. Also the tools lsusb (with and without option -v) and also lsscsi (with and without option -v) Dear Werner, thanks for the info. I was able to fix this issue in unetbootin itself with a quick'n'dirty fix: https://build.opensuse.org/package/view_file/home:frispete:tools/unetbootin/unetbootin-locate-usb-devices.diff?expand=1 Will hack in mmc support and send it upstream soon (hopefully). I think, that interpreting the by-id path in unetbootin is a misguided approach anyway and the root of the problem. I'm closing this issue right now and sorry for not doing this earlier.. Cheers, Pete |
Hi, in an attempt to debug a problem with unetbootin, where it is unable to write to certain USB sticks, I found, that udev is using a new scheme for some drives, but not of others. The device tree of the device in question, which is a bog standard Verbatim stick, looks as such: # tree /dev/disk/ | grep sdd │ ├── scsi-1USB_DISK_2.0 -> ../../sdd │ ├── scsi-1USB_DISK_2.0-part1 -> ../../sdd1 │ ├── scsi-28765432ab567abcd -> ../../sdd │ ├── scsi-28765432ab567abcd-part1 -> ../../sdd1 │ ├── scsi-32000acde48234567 -> ../../sdd │ ├── scsi-32000acde48234567-part1 -> ../../sdd1 │ ├── scsi-SVerbatim_MICRO_PLUS_067D09B84020 -> ../../sdd │ ├── scsi-SVerbatim_MICRO_PLUS_067D09B84020-part1 -> ../../sdd1 │ ├── wwn-0x2000acde48234567 -> ../../sdd │ ├── wwn-0x2000acde48234567-part1 -> ../../sdd1 │ ├── pci-0000:00:1d.0-usb-0:1.8.2:1.0-scsi-0:0:0:0 -> ../../sdd │ ├── pci-0000:00:1d.0-usb-0:1.8.2:1.0-scsi-0:0:0:0-part1 -> ../../sdd1 ├── 1A58-6EA9 -> ../../sdd1 For some reason, udev creates masses of names, but not the one's, that unetbootin expects, e.g. those, that start with usb-: # tree /dev/disk/ | grep sdd │ ├── usb-Kingston_DataTraveler_410_0018F3D974BCBB40E00000A2-0:0 -> ../../sdd │ ├── usb-Kingston_DataTraveler_410_0018F3D974BCBB40E00000A2-0:0-part1 -> ../../sdd1 │ ├── usb-Kingston_DataTraveler_410_0018F3D974BCBB40E00000A2-0:0-part2 -> ../../sdd2 │ ├── BOOT -> ../../sdd1 │ └── openSUSE-13.1-DVD-x86_640091 -> ../../sdd2 │ ├── pci-0000:00:1d.0-usb-0:1.8.2:1.0-scsi-0:0:0:0 -> ../../sdd │ ├── pci-0000:00:1d.0-usb-0:1.8.2:1.0-scsi-0:0:0:0-part1 -> ../../sdd1 │ ├── pci-0000:00:1d.0-usb-0:1.8.2:1.0-scsi-0:0:0:0-part2 -> ../../sdd2 ├── 2013-11-06-20-53-57-00 -> ../../sdd2 ├── 2013-11-06-20-55-31-00 -> ../../sdd ├── BED8-013D -> ../../sdd1 I don't want to start another systemd/udev debate here, hence I sorely ask: Is that a bug, or is it fixable with a magic udev term somehow, or do I need to install an older openSUSE release to be able to create USB rescue/install whatever sticks again?!? Thanks in advance.