Hi,
On 01/25/2010 04:22 PM, Chris Lumens wrote:
That would be a good idea, yes. But that would require figuring out something in
udev to tell from this is the case (or doing some sysfs grobing in one of
those 2 functions.
Either of which needs access to such a machine to actually see what is there
to trigger this blacklisting on.
Luckily, I do have a machine with CCISS.
At least on my controller, you have to try really hard to get a
configuration with no logical drives. If you go into the firmware and
delete them all, it'll stop you on next boot and ask if you really want
to do that, or if you want to continue with the default of one big
logical drive.
IIRC the original bug report for this was a case of a machine with
2 cciss controllers, and one of them had no physical disks attached
(I think it was an RHTS machine).
Okay, getting past that I do see a cciss/c0d0 in the filtering UI with
size 0. There does not appear to be anything in udev that could help
us. It looks just like a real disk there. There's a device node.
fdisk does not think it exists, however, and parted says it's unable to
determine the geometry. dmesg only shows the bare minimum of
information relating to cciss, too.
In summary, I don't think there's anything we can do now so I'm okay
with pushing this patch.
Ok.
However, I think we should also file a bug
against udev (probably?). I don't think it should be creating these
database entries and devices nodes for devices that don't actually
exist.
Well, it is the driver that is misbehaving here, I guess the driver
is doing this, as it is possible to later on define new sets through
special ioctl's (using a special tool), so it needs atleast one
node so the tool can talk to the driver.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
