On Saturday 10 May 2003 00:09, Michael Daskalov wrote:
It turns out that the stock kernel 2.4.20 from www.kernel.org doesn't have this problem.
LOL. Before 8.2/2.4.20 one would have to fight a bit to get it to see/deal with a raid controller and see the raid hardware correctly. Now (out side of having to get the install setup to see it - i.e. give it the I/Os) you have to fight a bit not to have it set a raid array be default. I have a promise 20276 onboard controller. I use in a generic ATA mode and don't have an array. During install when I went to part and format my drive sure enough - d0p0 was there (or something to that effect). I had to tell the install partitioner to delete the array since it was fictitious/virtual and didn't really exist. In fact it setup virtual arrays for all the partitions on that drive (I have XP partitions on it and SuSE showed these as mirrored as well d0p1. d0p2...). On my first attemp it set this up by default and then made a dir "data1" and set it to mirror it's counterpart partition - /dev/hde1 which was my home dir. Suffice to say this started to lead to some significant kludging with my home fs/data, like program setup/preferences going back to defaults because it was read as new - most likely reading from the virtual data on /data1 dir (a virtual /dev/hde1 setup - I guess?). Anyway, apparently the raid setup is more adept at reading the chipsets/card bios and tries very hard to default to an array. If I ever get another drive in my boxen on that controller I have a feeling that once I let the Promise setup establish the arrays that SuSE raid setup will be much more cogent and workable - at least I'm hoping. Just a note. Cheers, Curtis