IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
Add test/rule-syntax-check.py, a script for checking the syntax of all udev
rules files passed as command line arguments.
Add a wrapper test/rules-test.sh which calls rule-syntax-check.py on all udev
rules that we ship, but does nothing if Python is not available. Integrate this
into make check/distcheck.
... that the GUdevClient object was constructed in. This change makes
GUdev follow the GLib guidelines and, more importantly, makes it
possible to actually use the library in a multi-threaded
application. Prior to this patch, signals were emitted in the thread
that ran the "default" main loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
In v141 -> v142 entry, there's a note about udevd creating
/dev/{null,kmsg,console}. It was added in commit 540f46698d,
but shortly after that removed in a00bdfa16b before v142
release.
Signed-off-by: Michal Soltys <soltys@ziu.info>
Not generating persistent MAC address rules will significantly ease cloning of
VMs. The kernel reliably sorts eth* enumeration by bus number, so as long as
you only have cards from one vendor (or more precisely, drivers), the
enumeration will be stable. Having cards from different vendors is very
unlikely in VMs.
KVM was already covered in the previous commit, this is the equivalent
blacklist for VMWare:
http://www.coffer.com/mac_find/?string=005056http://www.coffer.com/mac_find/?string=000c29https://launchpad.net/bugs/341006
