We need to preserve the database of network interfaces while we
rename them. Use the kernel's numbers wherever possible, instead
of the device names.
Fix wrong database filenames which contain a '/', translated
from '!' in the kernel name.
Fix segfault for kobject pathes where the subsystem can not be
determined from sysfs.
The output will always be quoted:
$ udevadm info --export --export-prefix=MY_ --query=property --name=sda
MY_UDEV_LOG='3'
MY_DEVPATH='/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda'
MY_MAJOR='259'
MY_MINOR='0'
MY_DEVNAME='sda'
MY_DEVTYPE='disk'
MY_SUBSYSTEM='block'
The bsg devices node are created after the LUN, so we fail in the
hotplug case, but succeed at coldplug, and create inconsistent data
that way.
The bsg device event order will need to be sorted out, by changing the
kernel.
Originally we added an ACL for some particular mobile phone product IDs to
enable users to run e. g. the Android SDK as non-root. This was removed in
232f180 as we don't want to maintain product/vendor ID lists in udev.
However, we already know from media-player-info that devices like this are
media players. There is little reason to deny user access to those, so add back
a generic rule which adds an ACL to media player raw USB devices.
https://launchpad.net/bugs/316215
We'll need to standardise on the Touchpad related keys in udev, kernel, and
X.org. I selected F21 for XF86TouchpadToggle, F22 for XF86TouchpadOn and F23
for XF86TouchpadOff.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=31333
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
The major benefit here, is that we get the ATAPI device serial
number. With SCSI ID we didn't get this since it's not part of the
SCSI INQUIRY command. Specifically this means that we get symlinks to
empty optical drives, e.g.
/dev/disk/by-id/ata-VBOX_CD-ROM_VB2-01700376
which we didn't get earlier. So this is a major win.
Also make ata_id work on CD-ROM devices when using /dev/bsg nodes so
this works on both the scsi_device as well as the block device. We do
this, basically, by issuing the ATA IDENTIFY PACKET DEVICE command
instead of the ATA IDENTIFY command. We also use 16-byte pass-through
ATA passthrough instead of 12-byte passthrough to avoid clashing with
the MMC BLANK command.
This means that we get this output
# udevadm info -q all -p /sys/devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
P: /devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
E: DEVTYPE=scsi_device
E: DRIVER=sr
E: MODALIAS=scsi:t-0x05
E: SUBSYSTEM=scsi
E: ID_ATA=1
E: ID_TYPE=cd
E: ID_BUS=ata
E: ID_MODEL=VBOX_CD-ROM
E: ID_MODEL_ENC=VBOX\x20CD-ROM\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x 20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=1.0
E: ID_SERIAL=VBOX_CD-ROM_VB2-01700376
E: ID_SERIAL_SHORT=VB2-01700376
instead of just
# udevadm info -q all -p /sys/devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
P: /devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
E: DEVTYPE=scsi_device
E: DRIVER=sr
E: MODALIAS=scsi:t-0x05
E: SUBSYSTEM=scsi
E: ID_SCSI=1
E: ID_VENDOR=VBOX
E: ID_VENDOR_ENC=VBOX\x20\x20\x20\x20
E: ID_MODEL=CD-ROM
E: ID_MODEL_ENC=CD-ROM\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=1.0
E: ID_TYPE=cd
Signed-off-by: David Zeuthen <davidz@redhat.com>
In a multi-initiator setup, the HBA may very well export a SCSI device
for a device that another initiator has already logged into. But since
another initiator has already logged in, the kernel will not create a
block device.
Note that this is also the case for some RAID HBAs - for example, the
LSI 1068 series cards will export a SCSI device for a disk that is in
use by the HBAs RAID engine (no block device will be created here).
Running scsi_id and ata_id on the actual SCSI device means that we can
inquire the capabilities of the device. For example, we can check
whether ID_ATA_FEATURE_SET_SMART and ID_ATA_FEATURE_SET_SMART_ENABLED
is set and, if so, periodically poll the SMART status of the
disk. Even when other initiators has claimed the disk and if the disk
is in use by the RAID engine of the HBA.
Note that we run scsi_id and ata_id on /dev/bsg/* nodes - this is safe
to do because the scsi core guarantees that the bsg device has been
created before the actual add uevent for the scsi_device is emitted.
Since the block device is a direct child of the scsi_device we can
avoid running scsi_id and ata_id again by simply importing the
resulting ID_* properties from the parent.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This makes it possible to use /dev/bsg/* nodes for ata_id:
# /lib/udev/ata_id --export /dev/bsg/0\:0\:0\:0
ID_ATA=1
ID_TYPE=disk
ID_BUS=ata
ID_MODEL=INTEL_SSDSA2MH080G1GC
ID_MODEL_ENC=INTEL\x20SSDSA2MH080G1GC\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_REVISION=045C8802
[...]
This means that our cd-rom detection as per commit
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=160b069c25690bfb0c785994c7c3710289179107
needs to be reworked since we can't just use the CDROM_GET_CAPABILITY
ioctl on a /dev/bsg node (which is a character device). We do this by
just sending the SCSI INQUIRY command and checking the type (CD-ROM's
are all type 0x05 and disks are type 0x00) before we issue the ATA
IDENTIFY command through the SCSI command ATA PASS_THROUGH (12).
(Yes, it's a bit perverse how we have to tunnel our ATA commands
through a SCSI command but that's how Linux currently work.)
We still support for SG_IO version 3 (we fail back if version 4 fails
with EINVAL) because testing reveals that some drivers (such as
mpt2sas) still only support version 3 on the block nodes.
Signed-off-by: David Zeuthen <davidz@redhat.com>
If the disc is unreadable and reading of the first 32 blocks fails set the
cd_media status to 0 (not present). This will prevent udev from executing blkid
next that tries to determine fs on the disc and which in this case may seem to
hang forever locking the drive.
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
<Md> kay: can you look at rename_netif()? it returns -errno in a place,
but I think that it may by changed by err() (at least)
<kay> Md: yeah, that doesn't look correct
The force-release list for Samsung is already an ultralong monster, and
reportedly still incomplete (see https://launchpad.net/bugs/574250).
Give up and instead apply the force-release quirk to all Samsung models. The
worst that can happen is that autorepeat behaves a bit weird, but that's much
better than a complete freeze after each keypress.
Renaming network devices might delay events for the other device, which has
the same devpath in the meantime as the original event. Causing a delay until
the timout of the event is reached.
Look at the ifindex/devnum of the devices to check if they are really
the same devices.
This is to match where libudev.so is installed and it works because
all dependent libraries are already installed in / instead of /usr on
most distros:
$ ldd /usr/lib64/libgudev-1.0.so
linux-vdso.so.1 => (0x00007fff44dff000)
libudev.so.0 => /lib64/libudev.so.0 (0x0000003bf2600000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003fb5200000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x0000003fb4e00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d5b000000)
librt.so.1 => /lib64/librt.so.1 (0x0000003d5b800000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003fb4a00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003d5ac00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003d5a800000)
With this change it is possible to write libgudev applications that
can be installed in /bin or /sbin and can run without /usr being
mounted. This is needed for e.g. udisks, NetworkManager and other
subsystem-specific daemons.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Some drives don't like huge feature buffers, so we query twice. First
run for the current profile and to get the length.
Second time we query the whole profile feature set.
Read the first and last track from the TOC header, and do not go beyond that
stated number of tracks when reading the TOC. Otherwise we interpret random
data which leads to bogus tracks. (Reported on an IronKey, which reported 1
data track, and 4 audio tracks which weren't actually present.)
Reportedly, some "when I'm grown up I want to be a CD drive" fake USB CD sticks
like the IronKey neither support the SCSI "GET CONFIGURATION" nor the older
(pre-MMC2) "READ DISC INFORMATION" command. In that case, check if
cd_media_compat() detected that there is a disc present, and assume that we
have a CD-ROM medium.
Turns out we can do this much simpler by assuming that cd_media_compat() works,
which seems to be the case for the IronKey.
This reverts commit ea88774a92.
Reportedly, some "when I'm grown up I want to be a CD drive" fake USB CD sticks
like the IronKey neither support the SCSI "GET CONFIGURATION" nor the older
(pre-MMC2) "READ DISC INFORMATION" command. In that case, check if we can read
data from the drive, and assume that we have a CD-ROM medium if it succeeds.
