Filter UI: don't show cciss controllers without sets
 

---
iw/filter_gui.py | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/iw/filter_gui.py b/iw/filter_gui.py
index 3b6f573..a0f6704 100644
--- a/iw/filter_gui.py
+++ b/iw/filter_gui.py
@@ -586,6 +586,10 @@ class FilterWindow(InstallWindow):
except (_ped.IOException, _ped.DeviceException):
continue
d["XXX_SIZE"] = int(partedDevice.getSize())
+ # cciss controllers, without any sets defined, show up as a 0 size
+ # blockdev, ignore these
+ if d["XXX_SIZE"] == 0:
+ continue

# This isn't so great, but for iSCSI devices the path contains a lot
# of useful identifiying info that should be displayed.
--
1.6.5.2

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Filter UI: don't show cciss controllers without sets
 

Looks good. Martin
----- "Hans de Goede" <hdegoede@redhat.com> wrote:

> ---
> iw/filter_gui.py | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/iw/filter_gui.py b/iw/filter_gui.py
> index 3b6f573..a0f6704 100644
> --- a/iw/filter_gui.py
> +++ b/iw/filter_gui.py
> @@ -586,6 +586,10 @@ class FilterWindow(InstallWindow):
> except (_ped.IOException, _ped.DeviceException):
> continue
> d["XXX_SIZE"] = int(partedDevice.getSize())
> + # cciss controllers, without any sets defined, show up as
> a 0 size
> + # blockdev, ignore these
> + if d["XXX_SIZE"] == 0:
> + continue
>
> # This isn't so great, but for iSCSI devices the path
> contains a lot
> # of useful identifiying info that should be displayed.
> --
> 1.6.5.2
>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Filter UI: don't show cciss controllers without sets
 

> diff --git a/iw/filter_gui.py b/iw/filter_gui.py
> index 3b6f573..a0f6704 100644
> --- a/iw/filter_gui.py
> +++ b/iw/filter_gui.py
> @@ -586,6 +586,10 @@ class FilterWindow(InstallWindow):
> except (_ped.IOException, _ped.DeviceException):
> continue
> d["XXX_SIZE"] = int(partedDevice.getSize())
> + # cciss controllers, without any sets defined, show up as a 0 size
> + # blockdev, ignore these
> + if d["XXX_SIZE"] == 0:
> + continue
>
> # This isn't so great, but for iSCSI devices the path contains a lot
> # of useful identifiying info that should be displayed.

Should these perhaps be excluded at a lower level, like perhaps in
__is_blacklisted_blockdev or udev_enumerate_block_devices? This feels
like too much of a hack to me.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Filter UI: don't show cciss controllers without sets
 

Hi,

On 01/25/2010 03:36 PM, Chris Lumens wrote:

diff --git a/iw/filter_gui.py b/iw/filter_gui.py
index 3b6f573..a0f6704 100644
--- a/iw/filter_gui.py
+++ b/iw/filter_gui.py
@@ -586,6 +586,10 @@ class FilterWindow(InstallWindow):
except (_ped.IOException, _ped.DeviceException):
continue
d["XXX_SIZE"] = int(partedDevice.getSize())
+ # cciss controllers, without any sets defined, show up as a 0 size
+ # blockdev, ignore these
+ if d["XXX_SIZE"] == 0:
+ continue

# This isn't so great, but for iSCSI devices the path contains a lot
# of useful identifiying info that should be displayed.


Should these perhaps be excluded at a lower level, like perhaps in
__is_blacklisted_blockdev or udev_enumerate_block_devices? This feels
like too much of a hack to me.



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.

The above patch is the tried and proven way of handling this from
mediaPresent in devices.py (and yes I know you object to the naming of mediaPresent
and I agree).

When doing the usb reader fix (which is also being handled through mediaPresent in
devices.py), it occured to me (some time later) that filter ui would also need a
fix for the bizarro 0 bytes large cciss block node case.

IOW I agree, but I think that for now this is the best way of dealing with this,
and then later we can make it prettier.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Filter UI: don't show cciss controllers without sets
 

> 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.

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. 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.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Filter UI: don't show cciss controllers without sets
 

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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list