Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Thu, 2012-11-29 at 23:34 -0800, Bryan Kadzban wrote: Matt Burgess wrote: On Wed, 2012-11-28 at 20:44 -0800, Bryan Kadzban wrote: it's a SATA drive. I'm pretty sure all of those show up as SCSI. That's what I thought as well, hence the sd* name, rather than hd*. What does a udevadm info --attribute-walk on this device's /sys directory show? Attached. Well that looks like it. :-) Thanks for the detailed analysis, Bryan. Obviously, this is all pretty academic for me; if I'd have been using or otherwise needing the by-path symlinks, I would have noticed their disappearance in udev-182. The only reason I noticed they were missing now is because of xinglp's report. Whilst I can understand the use cases for by-uuid and by-label, I can't immediately think of a use for by-path, and as no one else in LFS-land has reported this before then I guess we can just chalk this one up as a curiosity for now :-) Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Matt Burgess wrote: Obviously, this is all pretty academic for me; if I'd have been using or otherwise needing the by-path symlinks, I would have noticed their disappearance in udev-182. The only reason I noticed they were missing now is because of xinglp's report. Whilst I can understand the use cases for by-uuid and by-label, I can't immediately think of a use for by-path, and as no one else in LFS-land has reported this before then I guess we can just chalk this one up as a curiosity for now :-) That's my thought too. It would be a 'nice to have' from a consistency point of view, but I don't see a need that applications depend on. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Bruce Dubbs wrote: Matt Burgess wrote: Obviously, this is all pretty academic for me; if I'd have been using or otherwise needing the by-path symlinks, I would have noticed their disappearance in udev-182. The only reason I noticed they were missing now is because of xinglp's report. Whilst I can understand the use cases for by-uuid and by-label, I can't immediately think of a use for by-path, and as no one else in LFS-land has reported this before then I guess we can just chalk this one up as a curiosity for now :-) That's my thought too. It would be a 'nice to have' from a consistency point of view, but I don't see a need that applications depend on. Agreed; I don't think it's worth a ton of effort to fix again. I might still send something to systemd-devel, seeing what they think about adding a separate layer for the ata* bus number, but ... eh, probably not. They'll probably just go for the perfect solution (as in, the enemy of the good solution, as standard for udev these days :-) ), and do nothing until someone (else!) fixes the ata transport layer in the kernel. signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Bryan Kadzban wrote:
Bruce Dubbs wrote:
Matt Burgess wrote:
On Wed, 2012-11-28 at 14:12 -0600, Bruce Dubbs wrote:
Checking against a slightly older build with udev 182, I only have
two entries in /dev/disk/by-path, /dev/hda (CD-ROM) and /dev/sdc
(which appears to be a leftover usb entry).
Wait, /dev/hda? You might actually be using the ATA transport class,
not the SCSI one. Is your disk hdb, or sda/sdb? The latter should
work; the former won't.
Yes hda. There is no hdb, but there is sd{a,b,c} as well as hda. The
system hw is from 2005.
I don't know why sdc is still present. There is no usb drive plugged in:
hdparm -i /dev/sda
Model=Maxtor 6Y080M0, FwRev=YAR51HW0, SerialNo=Y24N8T1C
hdparm -i /dev/sdb
Model=ST3250310AS, FwRev=3.ADA, SerialNo=6RY5BF78
hdparm -i /dev/sdc
HDIO_GET_IDENTITY failed: Invalid argument
hdparm -i /dev/hda
Model=HL-DT-ST RW/DVD GCC-4481B, FwRev=E106, SerialNo=
It appears that udev did not remove /dev/sdc or the accompanying /sys
info when the drive was removed. I don't recall when I last used a
thumb drive on this system. The uptime is 148 days.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Matt Burgess wrote:
On Wed, 2012-11-28 at 20:44 -0800, Bryan Kadzban wrote:
it's a SATA drive. I'm pretty sure all of those show up as SCSI.
That's what I thought as well, hence the sd* name, rather than hd*.
What does a udevadm info --attribute-walk on this device's /sys
directory show?
Attached.
Well that looks like it. :-)
Note the devpath in there:
/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3
Also, this bit of code in udev-builtin-path_id.c, in handle_scsi():
/*
* We do not support the ATA transport class, it creates duplicated link
* names as the fake SCSI host adapters are all separated, they are all
* re-based as host == 0. ATA should just stop faking two duplicated
* hierarchies for a single topology and leave the SCSI stuff alone;
* until that happens, there are no by-path/ links for ATA devices behind
* an ATA transport class.
*/
if (strstr(name, /ata) != NULL) {
parent = NULL;
goto out;
}
name here is the syspath, which I assume is the devpath printed by
udevadm info. That strstr() is going to return something non-NULL in
your case (it'll point at the ata1 entry), so this code will prevent
path_id from doing anything.
(Which explains why it works for USB. There's no IDE or SATA involved
there.)
The next question is why my machine still has these. And looking at
udev-builtin-path_id.c in my version of udev (-180), indeed, that chunk
is missing -- but I'm still not running the version out of systemd on my
main machine, so that's why.
Looks like it got added back in March:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blobdiff;f=src/udev-builtin-path_id.c;h=5de72194a2185bbbc93b85630d182994fe165c0e;hp=b18b162755880b5d4c35fbc313ec00052d2b0c9e;hb=481dcf7c8fa8fd9fd181b59443b7e30e9b42add4;hpb=8e90942c7af2508f88c7284a0b116caf7ec854a9
in the old separate udev tree. So this has been disabled ever since
-182, if I'm reading the tags correctly in the git tree.
From the comment, it looks like the problem isn't so much the ATA config,
it's the other (according to the comments up in handle_scsi_default())
stupid code in path_id that tries to rebase SCSI host numbers. The fact
that each ata* directory only has one SCSI host* subdirectory, because
(e.g.) ata0 and ata1 are different kobjects, is what's causing the
duplicate symlinks that the comment is talking about.
But if the path_id code just *didn't do the rebasing*, then there
wouldn't be a problem. I suppose at that point it depends on whether the
host number exported from the kernel is stable; if not then it's no worse
this way.
I suppose another way to do it would be to change path_id to use the ata
device as the parent of the scsi device, naming the symlinks
pci-foo-ata-bar-scsi-baz. That could change existing device links,
but they're missing now anyway, so not likely.
The last question is whether there's anything that can be done in the
kernel configuration to stop this (skipping the ata transport stuff). I
don't see anything helpful.
I'm half considering just ripping out both chunks of code in the next
udev I end up building, to see what happens. My one machine isn't a good
enough test for doing that in the book, though, I don't think...
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Tue, 2012-11-27 at 21:42 -0800, Bryan Kadzban wrote:
Hmm, did the Makefile changes for 196 handle the changes where upstream
made both blkid and kmod optional? We now need to add a couple new
defines if we want that to work right, otherwise IMPORT{builtin}=blkid
won't actually do anything, because blkid won't be added to the list of
builtins available in the code:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=f553b3b1074151200187df916427a1468186435e
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e30431623a7d871da123cc37055ac49abf2c20ea
Thanks, Bryan. Adding those 2 defines to udev-lfs' cfg.h was enough to
bring back by-uuid and by-label. I still don't have by-path but will
look into that later.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Bryan Kadzban wrote:
Matt Burgess wrote:
On Tue, 2012-11-27 at 18:42 +, Matt Burgess wrote:
On Tue, 2012-11-27 at 18:13 +0800, xinglp wrote:
The Udev-196 only create /dev/disk/by-path.
Confirmed. I'll take a look.
Well, 2 hours later and I'm stumped. I've run 'udevadm --debug test
/sys/block/sda /root/udevadm-test.lst 21' on both 195 and 196
versions of udev, and can't see anything obviously different between
the 2.
Not having 196 installed, do you have these files somewhere where I
could take a look?
Also I assume the ruleset is calling IMPORT{builtin}=blkid, possibly
with some flags after blkid? That's what sets ID_FS_USAGE and friends
(and what probes for the label and uuid).
Hmm, did the Makefile changes for 196 handle the changes where upstream
made both blkid and kmod optional? We now need to add a couple new
defines if we want that to work right, otherwise IMPORT{builtin}=blkid
won't actually do anything, because blkid won't be added to the list of
builtins available in the code:
Good catch Bryan. Last night I did a recursive diff between -195 and
-195 and look through that. I saw that KMOD and BLKID were made
optional, but didn't connect the dots.
I'll need to add to udev-lfs-196/cfg.h:
#define HAVE_KMOD 1
#define HAVE_BLKID 1
and try again.
Some other things I noticed:
1. Several locations are now hard coded with no ability to override:
/etc/udev/udev.conf
/etc/udev/keymaps/
/etc/udev/rules.d/
/etc/udev/hwdb.d
2. Including a hwdb instead of using lspci/lsusb. Now there are two
locations with possibly different contents for this information. I
didn't see an equivalent to update-pciids or update-usbids.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Matt Burgess wrote:
On Tue, 2012-11-27 at 21:42 -0800, Bryan Kadzban wrote:
Hmm, did the Makefile changes for 196 handle the changes where upstream
made both blkid and kmod optional? We now need to add a couple new
defines if we want that to work right, otherwise IMPORT{builtin}=blkid
won't actually do anything, because blkid won't be added to the list of
builtins available in the code:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=f553b3b1074151200187df916427a1468186435e
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e30431623a7d871da123cc37055ac49abf2c20ea
Thanks, Bryan. Adding those 2 defines to udev-lfs' cfg.h was enough to
bring back by-uuid and by-label. I still don't have by-path but will
look into that later.
With my change and rebooting, I get:
$ ls -l /dev/disk
total 0
drwxr-xr-x 2 root root 400 Nov 28 12:46 by-id
drwxr-xr-x 2 root root 180 Nov 28 12:46 by-partlabel
drwxr-xr-x 2 root root 200 Nov 28 12:46 by-partuuid
drwxr-xr-x 2 root root 180 Nov 28 12:46 by-uuid
I'll also continue to check about by-path.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
2012/11/29 Bruce Dubbs bruce.du...@gmail.com
Matt Burgess wrote:
On Tue, 2012-11-27 at 21:42 -0800, Bryan Kadzban wrote:
Hmm, did the Makefile changes for 196 handle the changes where upstream
made both blkid and kmod optional? We now need to add a couple new
defines if we want that to work right, otherwise IMPORT{builtin}=blkid
won't actually do anything, because blkid won't be added to the list of
builtins available in the code:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=f553b3b1074151200187df916427a1468186435e
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e30431623a7d871da123cc37055ac49abf2c20ea
Thanks, Bryan. Adding those 2 defines to udev-lfs' cfg.h was enough to
bring back by-uuid and by-label. I still don't have by-path but will
look into that later.
With my change and rebooting, I get:
$ ls -l /dev/disk
total 0
drwxr-xr-x 2 root root 400 Nov 28 12:46 by-id
drwxr-xr-x 2 root root 180 Nov 28 12:46 by-partlabel
drwxr-xr-x 2 root root 200 Nov 28 12:46 by-partuuid
drwxr-xr-x 2 root root 180 Nov 28 12:46 by-uuid
I'll also continue to check about by-path.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Thanks for your job.
But will you also check why the ethernet interface not bring up on boot
issue.
I met this in vmware system with a vmxnet3 interface. but I can bring it up
by execute modprobe vmxnet3.
This may also happen in other situation, but not very sure.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Thu, 2012-11-29 at 03:25 +0800, xinglp wrote: But will you also check why the ethernet interface not bring up on boot issue. I met this in vmware system with a vmxnet3 interface. but I can bring it up by execute modprobe vmxnet3. This may also happen in other situation, but not very sure. Have you tried adding the 2 #define lines to your own cfg.h and rebuilding? One of those is for kmod support, which probably would explain why you don't get the automatic modprobe command invoked by udev, thereby meaning your NIC doesn't show up correctly. Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On 11/28/2012 08:25 PM, xinglp wrote: Thanks for your job. But will you also check why the ethernet interface not bring up on boot issue. I met this in vmware system with a vmxnet3 interface. but I can bring it up by execute modprobe vmxnet3. This may also happen in other situation, but not very sure. Just out of curiosity, which VMware product are you using for virtualisation? In VMware Player (and maybe even Workstation) default nic module is vmxnet, not vmxnet3. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Matt Burgess wrote:
On Tue, 2012-11-27 at 21:42 -0800, Bryan Kadzban wrote:
If it is this, then it should be reasonably obvious from the udevadm
test output I'd expect, but a full test would be something like:
udevadm info -q env -p /sys/class/block/whatever partition
The rule that should be fired is
60-persistent-storage.rules:
ENV{DEVTYPE}==partition, ENV{ID_PATH}==?*, \
SYMLINK+=disk/by-path/$env{ID_PATH}-part%n
But when I run
udevadm info -q env -p /sys/class/block/sda5
I get:
DEVTYPE=partition
but no ID_PATH
The best I can tell right now is that ID_PATH should be set in
src/udev/udev-builtin-path_id.c line 536.
That code is included directly in udevd and udevadm -- not a library.
Checking against a slightly older build with udev 182, I only have two
entries in /dev/disk/by-path, /dev/hda (CD-ROM) and /dev/sdc (which
appears to be a leftover usb entry).
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Wed, 2012-11-28 at 14:12 -0600, Bruce Dubbs wrote: Checking against a slightly older build with udev 182, I only have two entries in /dev/disk/by-path, /dev/hda (CD-ROM) and /dev/sdc (which appears to be a leftover usb entry). Ah, now, there's a bit of a clue. Plugging in a USB stick I get the attached, which includes an ID_PATH entry and results in a by-path symlink as expected. So, is this a hotplug vs. coldplug thing, perhaps? Thanks, Matt. DEVLINKS=/dev/disk/by-id/usb-Kingston_DataTraveler_G3_001CC0EC2F39F07185CB12BD-0:0-part1 /dev/disk/by-label/KINGSTON /dev/disk/by-path/pci-:00:1d.0-usb-0:1.5:1.0-scsi-0:0:0:0-part1 /dev/disk/by-uuid/AC67-2575 DEVNAME=/dev/sdb1 DEVPATH=/devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/host6/target6:0:0/6:0:0:0/block/sdb/sdb1 DEVTYPE=partition ID_BUS=usb ID_FS_LABEL=KINGSTON ID_FS_LABEL_ENC=KINGSTON ID_FS_TYPE=vfat ID_FS_USAGE=filesystem ID_FS_UUID=AC67-2575 ID_FS_UUID_ENC=AC67-2575 ID_FS_VERSION=FAT32 ID_INSTANCE=0:0 ID_MODEL=DataTraveler_G3 ID_MODEL_ENC=DataTraveler\x20G3\x20 ID_MODEL_ID=1643 ID_PART_ENTRY_DISK=8:16 ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=1 ID_PART_ENTRY_OFFSET=63 ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_SIZE=31272129 ID_PART_ENTRY_TYPE=0xc ID_PART_TABLE_TYPE=dos ID_PATH=pci-:00:1d.0-usb-0:1.5:1.0-scsi-0:0:0:0 ID_PATH_TAG=pci-_00_1d_0-usb-0_1_5_1_0-scsi-0_0_0_0 ID_REVISION=1.00 ID_SERIAL=Kingston_DataTraveler_G3_001CC0EC2F39F07185CB12BD-0:0 ID_SERIAL_SHORT=001CC0EC2F39F07185CB12BD ID_TYPE=disk ID_USB_DRIVER=usb-storage ID_USB_INTERFACES=:080650: ID_USB_INTERFACE_NUM=00 ID_VENDOR=Kingston ID_VENDOR_ENC=Kingston ID_VENDOR_ID=0951 MAJOR=8 MINOR=17 SUBSYSTEM=block USEC_INITIALIZED=484214 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Matt Burgess wrote: On Wed, 2012-11-28 at 14:12 -0600, Bruce Dubbs wrote: Checking against a slightly older build with udev 182, I only have two entries in /dev/disk/by-path, /dev/hda (CD-ROM) and /dev/sdc (which appears to be a leftover usb entry). Ah, now, there's a bit of a clue. Plugging in a USB stick I get the attached, which includes an ID_PATH entry and results in a by-path symlink as expected. So, is this a hotplug vs. coldplug thing, perhaps? Here's an interesting observation. Take a look at /run/udev/links. ASCII \x2f is a /. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Bruce Dubbs wrote:
Matt Burgess wrote:
On Wed, 2012-11-28 at 14:12 -0600, Bruce Dubbs wrote:
Checking against a slightly older build with udev 182, I only
have two entries in /dev/disk/by-path, /dev/hda (CD-ROM) and
/dev/sdc (which appears to be a leftover usb entry).
Ah, now, there's a bit of a clue. Plugging in a USB stick I get
the attached, which includes an ID_PATH entry and results in a
by-path symlink as expected. So, is this a hotplug vs. coldplug
thing, perhaps?
Here's an interesting observation. Take a look at /run/udev/links.
ASCII \x2f is a /.
I'm pretty sure that's a forward mapping of all the links that udev has
created, so it knows what (in /dev) to delete when the disk device goes
away. :-) The contents of the directories, at least, are the block
major:minor numbers of the symlinks' targets, on my system (though I'm
still on udev-180something, so it's possible this changed).
Might be hotplug versus coldplug. Not sure how best to tell though...
There's a comment in udev-builtin-path_id.c about lacking support for
the ATA transport class, but I can't see that being relevant here;
it should be using the SCSI transport class, no?
It should be, yeah. Especially since, from the file you attached:
ID_ATA_SATA=1
it's a SATA drive. I'm pretty sure all of those show up as SCSI.
What does a udevadm info --attribute-walk on this device's /sys
directory show?
The best I can tell right now is that ID_PATH should be set in
src/udev/udev-builtin-path_id.c line 536.
Yep, but that code doesn't run unless the IMPORT{builtin}=path_id
clause gets run in the rules. (In case that isn't obvious.) The
persistent-storage.rules file has this:
ENV{DEVTYPE}==disk, DEVPATH!=*/virtual/*, IMPORT{builtin}=path_id
which should run it, except on virtual devices, which at least the
examples posted so far, are not. Hmm...
Checking against a slightly older build with udev 182, I only have
two entries in /dev/disk/by-path, /dev/hda (CD-ROM) and /dev/sdc
(which appears to be a leftover usb entry).
Wait, /dev/hda? You might actually be using the ATA transport class,
not the SCSI one. Is your disk hdb, or sda/sdb? The latter should
work; the former won't.
I get:
DEVTYPE=partition
but no ID_PATH
Is the rule that imports parent device attributes not firing or not
working somehow? That's this one:
# for partitions import parent information
ENV{DEVTYPE}==partition, IMPORT{parent}=ID_*
I wonder if the {parent} import type got broken somehow...
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Wed, 2012-11-28 at 20:44 -0800, Bryan Kadzban wrote:
it's a SATA drive. I'm pretty sure all of those show up as SCSI.
That's what I thought as well, hence the sd* name, rather than hd*.
What does a udevadm info --attribute-walk on this device's /sys
directory show?
Attached.
Thanks!
Matt.
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/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3':
KERNEL==sda3
SUBSYSTEM==block
DRIVER==
ATTR{ro}==0
ATTR{size}==41943040
ATTR{stat}==1449 994285828786 41 60 808
28900 747031673
ATTR{partition}==3
ATTR{start}==42098688
ATTR{discard_alignment}==0
ATTR{alignment_offset}==0
ATTR{inflight}== 00
looking at parent device
'/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda':
KERNELS==sda
SUBSYSTEMS==block
DRIVERS==
ATTRS{ro}==0
ATTRS{size}==976773168
ATTRS{stat}==2343 1305024636506 43 60
808 29660 863339470
ATTRS{range}==16
ATTRS{discard_alignment}==0
ATTRS{events}==
ATTRS{ext_range}==256
ATTRS{events_poll_msecs}==-1
ATTRS{alignment_offset}==0
ATTRS{inflight}== 00
ATTRS{removable}==0
ATTRS{capability}==50
ATTRS{events_async}==
looking at parent device
'/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0':
KERNELS==0:0:0:0
SUBSYSTEMS==scsi
DRIVERS==sd
ATTRS{rev}==0001
ATTRS{type}==0
ATTRS{scsi_level}==6
ATTRS{model}==ST9500325AS
ATTRS{state}==running
ATTRS{unload_heads}==0
ATTRS{queue_type}==simple
ATTRS{iodone_cnt}==0x9a2
ATTRS{iorequest_cnt}==0x9a7
ATTRS{queue_ramp_up_period}==12
ATTRS{timeout}==30
ATTRS{evt_media_change}==0
ATTRS{ioerr_cnt}==0x3
ATTRS{queue_depth}==31
ATTRS{vendor}==ATA
ATTRS{device_blocked}==0
ATTRS{iocounterbits}==32
looking at parent device
'/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0':
KERNELS==target0:0:0
SUBSYSTEMS==scsi
DRIVERS==
looking at parent device '/devices/pci:00/:00:1f.2/ata1/host0':
KERNELS==host0
SUBSYSTEMS==scsi
DRIVERS==
looking at parent device '/devices/pci:00/:00:1f.2/ata1':
KERNELS==ata1
SUBSYSTEMS==
DRIVERS==
looking at parent device '/devices/pci:00/:00:1f.2':
KERNELS==:00:1f.2
SUBSYSTEMS==pci
DRIVERS==ahci
ATTRS{irq}==19
ATTRS{subsystem_vendor}==0x10cf
ATTRS{broken_parity_status}==0
ATTRS{class}==0x010601
ATTRS{consistent_dma_mask_bits}==64
ATTRS{dma_mask_bits}==64
ATTRS{local_cpus}==3
ATTRS{device}==0x3b29
ATTRS{enable}==1
ATTRS{msi_bus}==
ATTRS{local_cpulist}==0-1
ATTRS{vendor}==0x8086
ATTRS{subsystem_device}==0x151e
ATTRS{d3cold_allowed}==1
looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On 11/27/2012 11:13 AM, xinglp wrote: The Udev-196 only create /dev/disk/by-path. They are present on my system, but I am still using udev/systemd 195. $ ls -l /dev/disk/ total 0 drwxr-xr-x 2 root root 460 Nov 27 16:04 by-id drwxr-xr-x 2 root root 60 Nov 27 16:04 by-path drwxr-xr-x 2 root root 200 Nov 27 16:04 by-uuid -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Tue, 2012-11-27 at 18:42 +, Matt Burgess wrote: On Tue, 2012-11-27 at 18:13 +0800, xinglp wrote: The Udev-196 only create /dev/disk/by-path. Confirmed. I'll take a look. Well, 2 hours later and I'm stumped. I've run 'udevadm --debug test /sys/block/sda /root/udevadm-test.lst 21' on both 195 and 196 versions of udev, and can't see anything obviously different between the 2. I guess this one is either over to Bryan or off to the systemd lists. I checked their archives and can't see anything related to this issue. Ta, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Tue, 2012-11-27 at 18:42 +, Matt Burgess wrote: On Tue, 2012-11-27 at 18:13 +0800, xinglp wrote: The Udev-196 only create /dev/disk/by-path. Confirmed. I'll take a look. Actually, my symptoms are slightly different. I only get /dev/disk/by-id. I get no other symlinks (by-uuid,by-label,by-path). I wonder whether this is some kind of race condition, whereby the first symlink gets created fine but that prevent any others from being created. I do note though that the persistent-storage rules files seem to require the udev environment to have things like ID_PATH and ID_FS_USAGE set and these are not set. However, they're not set/visible in udev-195 either, so I must be misunderstanding something. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Tue, 2012-11-27 at 21:10 +, Matt Burgess wrote: Actually, my symptoms are slightly different. I only get /dev/disk/by-id. I get no other symlinks (by-uuid,by-label,by-path). I wonder whether this is some kind of race condition, whereby the first symlink gets created fine but that prevent any others from being created. Nope, that theory's shot. I commented out the by-id symlink creation rules in 60-persistent-storage.rules and ended up with no symlinks at all. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On 11/27/2012 10:10 PM, Matt Burgess wrote: On Tue, 2012-11-27 at 18:42 +, Matt Burgess wrote: On Tue, 2012-11-27 at 18:13 +0800, xinglp wrote: The Udev-196 only create /dev/disk/by-path. Confirmed. I'll take a look. Actually, my symptoms are slightly different. I only get /dev/disk/by-id. I get no other symlinks (by-uuid,by-label,by-path). I wonder whether this is some kind of race condition, whereby the first symlink gets created fine but that prevent any others from being created. I do note though that the persistent-storage rules files seem to require the udev environment to have things like ID_PATH and ID_FS_USAGE set and these are not set. However, they're not set/visible in udev-195 either, so I must be misunderstanding something. Matt. I just asked on their irc channel and some people claim that everything is okay even with latest git master, but they are probably using udev and systemd together. -1 for udev without systemd. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Armin K. wrote: On 11/27/2012 10:10 PM, Matt Burgess wrote: On Tue, 2012-11-27 at 18:42 +, Matt Burgess wrote: On Tue, 2012-11-27 at 18:13 +0800, xinglp wrote: The Udev-196 only create /dev/disk/by-path. Confirmed. I'll take a look. Actually, my symptoms are slightly different. I only get /dev/disk/by-id. I get no other symlinks (by-uuid,by-label,by-path). I wonder whether this is some kind of race condition, whereby the first symlink gets created fine but that prevent any others from being created. I do note though that the persistent-storage rules files seem to require the udev environment to have things like ID_PATH and ID_FS_USAGE set and these are not set. However, they're not set/visible in udev-195 either, so I must be misunderstanding something. Matt. I just asked on their irc channel and some people claim that everything is okay even with latest git master, but they are probably using udev and systemd together. So much for we will continue to support standalone udev. It may take me some time, but I'll figure it out. OTOH, a look at mdev may be appropriate. https://wiki.gentoo.org/wiki/Mdev -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On 11/27/2012 11:01 PM, Bruce Dubbs wrote: Armin K. wrote: I just asked on their irc channel and some people claim that everything is okay even with latest git master, but they are probably using udev and systemd together. So much for we will continue to support standalone udev. It may take me some time, but I'll figure it out. OTOH, a look at mdev may be appropriate. https://wiki.gentoo.org/wiki/Mdev -- Bruce They still claim that it is supported. However, you might be interested in gentoo fork. http://thread.gmane.org/gmane.linux.gentoo.project/2262 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On 11/27/2012 11:23 PM, Armin K. wrote: On 11/27/2012 11:01 PM, Bruce Dubbs wrote: So much for we will continue to support standalone udev. It may take me some time, but I'll figure it out. OTOH, a look at mdev may be appropriate. https://wiki.gentoo.org/wiki/Mdev -- Bruce They still claim that it is supported. However, you might be interested in gentoo fork. http://thread.gmane.org/gmane.linux.gentoo.project/2262 Sorry, I forgot ... This is forked udev repo https://github.com/gentoo/eudev -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
Armin K. wrote: On 11/27/2012 11:23 PM, Armin K. wrote: On 11/27/2012 11:01 PM, Bruce Dubbs wrote: So much for we will continue to support standalone udev. It may take me some time, but I'll figure it out. OTOH, a look at mdev may be appropriate. https://wiki.gentoo.org/wiki/Mdev They still claim that it is supported. However, you might be interested in gentoo fork. http://thread.gmane.org/gmane.linux.gentoo.project/2262 Sorry, I forgot ... This is forked udev repo https://github.com/gentoo/eudev Thanks for the links. I'm reading them. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-196 not create /dev/disk/by-{id, label, uuid, ...}, not bring up eth0.
On Tue, Nov 27, 2012 at 04:42:13PM -0600, Bruce Dubbs wrote: Armin K. wrote: Sorry, I forgot ... This is forked udev repo https://github.com/gentoo/eudev Thanks for the links. I'm reading them. -- Bruce I'm still waiting to see how that pans out, and wondering why these devs don't like the udev standalone fork [ sorry, no handy url, but it has been mentioned in the past ]. But I do think that either fork will be a better long-term way to go, if they get going. That's better as in LFS isn't about teaching you how to write Makefiles - no problems with Bruce's versions, I just don't think it's where we should be spending our time :) ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
