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!
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, no
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
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
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/
The rule that should be fired i
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 situatio
2012/11/29 Matt Burgess
> 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
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
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/
OK, attached. That is from a fixed copy of the cfg.h fil
2012/11/29 Bruce Dubbs
> 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 r
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}="blki
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 'udevad
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 any
13 matches
Mail list logo
