Bug 217807

Created attachment 103704 [details]
YaST2-Logs

I am not a storage specialist, but can that really work: A RAID 1 (disk mirroring) with a 153 GB disk and a 74 GB disk?

From irc.suse.de #suse 2006-11-06:

[16:38:52] <HuHa> any storage / RAID experts here?
[16:38:56] <HuHa> https://bugzilla.novell.com/show_bug.cgi?id=217807
[16:39:01] <buggy> bug #217807: Yast fails to make a valid partition proposal with a Intel On-Board RAID Controller Product: openSUSE 10.2, Component: Installation, Severity: Critical, Assigned to: yast2-maintainers@suse.de, Status: NEW
[16:39:13] <HuHa> can that really work: RAID 1 with one 153 GB disk and one 74 GB disk?
[16:39:29] <HuHa> aren't the disks supposed to have the same size?
[16:40:31] <cgardner> HuHa: software RAID can make that work, but only as 74 GB, with the rest of the 153 GB disk not being RAID'd.
[16:40:48] <cgardner> HuHa: But I don't think hw RAID would like trying to make that work.
[16:40:55] <HuHa> cgardner: OK, thx, that's a beginning
[16:41:07] <HuHa> but enabling that in the BIOS would make it a HW RAID, wouldn't it?
[16:41:21] <darix> HuHa: ask kernel folks if this controller should work at all
[16:41:43] <cgardner> HuHa: *shrug* I don't know about that board.   Yeah, darix is right.
[16:42:01] <HuHa> any kernel people care to have a look?

IRC log continues:

[16:42:44] <lmb> Is that an ICH-7?
[16:42:46] * lmb goes to look
[16:42:59] <HuHa> lmb: ICH8R 
[16:43:16] <lmb> HuHa: Oh, even worse, I think those are not supported yet, but I may be wrong
[16:43:43] <HuHa> lmb: so in any case, this is not a bug of yast2-storage, right?
the other has X-Spam: Not detected... I've already deleted the older ones
[16:44:13] <jbl> HuHa: isnt the bug talking about partition proposal?
[16:44:20] <HuHa> jbl: yes
[16:44:23] <lmb> HuHa: Hm, well, he _does_ see the drives though, so ...
[16:44:48] <HuHa> lmb: yast2-storage sees the disks as individual disks
[16:44:52] <jbl> HuHa: so yast2-storage should do a proposal for 74GB in this case
[16:45:15] <lmb> HuHa: any kernel boot logs available?
[16:45:16] <HuHa> and recognizes incompatible partitioning
[16:45:19] <skh> pasky: I just trust the nuremberg int-it magic, no idea about the .cz mail setup
[16:45:24] <HuHa> lmb: doesn't look like it
[16:45:46] <HuHa> lmb: but since it's internal, it should be easy enough to reproduce and provide kernel logs
[16:46:06] <jbl> HuHa: it always sees them as individual disks but it should recognize all this dmraid stuff
[16:46:11] <lmb> HuHa: Maybe dmraid could help, but I don't know who maintains this
[16:46:36] <jbl> HuHa: since thomas isn't here for the next weeks ... ask hare
[16:46:46] <HuHa> jbl: good hint, thx
[16:46:49] <jbl> HuHa: afair he the the dmraid kernel stuff
[16:47:21] <lmb> dmraid isn't in kernel, the discovery is all user-space
[16:47:46] <lmb> HuHa: mkoenig@suse.de is your victim^Wman ;-)
[16:49:07] <darix> HuHa: ask him to test with fdisk/gpart
[16:49:12] <darix> if they can create partitions


Matthias, Hannes, any clue?

Alexander, could you try fdisk/gpart as mentioned above?

At the moment I have no access to this machine because someone else uses it for testing, but I'll provide the info ASAP.

To comment #5:

Yes, one can create partitions with fdisk in the instsys, but the corresponding proposal will be still wrong. That is, partitions will be showed under /dev/sda and /dev/sdb instead of under /dev/mapper/isw_dafbhcdjdg_TestRAID for instance. The RAID partitions won't be showed until a reboot.

Nevertheless, even if the RAID partitions are available, one can't create valid filesystems and mountpoints for installing.


I'm raising this bug to severity BLOCKER, because it prevents an installation in general.

If additional information is needed, feel free to contact me.

Had a (really short) look into y2log file.
Do not try further with this controller in YaST2 it cannot work.
Since the names for the raid returned by dmraid is once "isw_bgbdheafhf" and 
at another command the name is "isw_bgbdheafhf_TestRAID" libstorage is not able
to match names and cannot handle that dmraid. So far I never had such a 
controller for testing therefore I was not aware of such a possibility. 
Certainly this can be fixed but not easily.

This is hardware support enhancment but not a blocker bug.

Ah, so that's the new innovative culture at Novell?
Workaround known problems?

Problem appears to be that the output of 'dmraid -r -c -c -c' and 'dmraid -s -c -c -c' is different:

dmraid -r -c -c
/dev/sda:isw:isw_bgbdheafhf:GROUP:ok:321672958:0
/dev/sdb:isw:isw_bgbdheafhf:GROUP:ok:156368014:0

dmraid -s -c -c -c isw_bgbdheafhf
isw_bgbdheafhf_TestRAID:156362752:128:mirror:ok:0:2:0
/dev/sda:isw:isw_bgbdheafhf_TestRAID:mirror:ok:156362752:0
/dev/sdb:isw:isw_bgbdheafhf_TestRAID:mirror:ok:156362752:0

libstorage uses to '-r' invocation to detect the raid name, but fails miserably here as the output of '-r' contains only the raid set name. And only the raid name (as printed out by '-s') are represented as device-mapper tables.

Created attachment 105607 [details]
yast2-storage-intel-dmraid-fix

Proposed patch to use the correct raid name instead of the raid set name. Not tested in any way.

Thanks a lot Hannes and Schubi!

It does not work. We will try another solution.

Fixed with Hannes competent support ;-)