https://bugzilla.novell.com/show_bug.cgi?id=350573 User drankinatty@suddenlinkmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c1 --- Comment #1 from David Rankin 2007-12-24 12:00:09 MST --- Booting from the install DVD, from maintenance mode, a grub-install /dev/sda restored the menu.lst and I can boot windows again, but the 10.3 install is still thrashed. The install has never completed and the installer cannot handle the raid it seems. Booting from the menu.lst to 10.3 crashes out to /bin/sh. Curiously, rebooting from this mode shows "syncing scsi cache on sd.." as the system shuts down. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 User drankinatty@suddenlinkmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c3 --- Comment #3 from David Rankin 2008-01-01 19:31:06 MST --- No, I did try reinstalling several times, but the same bug persisted each time. With each new install attempt, the installer correctly saw the raid, but since existing raid partitions existed, the installer would suggest deleting: 79M ext3 /dev/mapper/bfefdifda_part1 20G ext3 /dev/mapper/bfefdifda_part2 270G ext3 /dev/mapper/bfefdifda_part3 And then propose the following (same) scheme: 79M ext3 /dev/mapper/bfefdifda_part4 20G ext3 /dev/mapper/bfefdifda_part5 270G ext3 /dev/mapper/bfefdifda_part6 http://en.opensuse.org/How_to_install_SUSE_Linux_on_software_RAID seems to be in error. It states: "If you want to install the kind of RAID that is supported by some motherboards, just enable RAID in your BIOS and install as usual. NOTE: BIOS-RAID is only supported by openSUSE 10.2 or later. Earlier versions of SUSE DO NOT support BIOS-RAID." Yast seems to be trying to do this but failing with this particular controller after partitioning and software install. After spending some 20 hours trying various different installs/repairs/and rescues and finally resorting to the software raid install, reformatting /boot isn't that attractive an option. What else can I send that may help.? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 User dmuhamedagic@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c5 --- Comment #5 from Dejan Muhamedagic 2008-01-04 08:21:16 MST --- Forgot: Set the partition type to Linux RAID only in case you use the software RAID. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 User drankinatty@suddenlinkmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c7 --- Comment #7 from David Rankin 2008-01-04 21:12:23 MST --- Created an attachment (id=189436) --> (https://bugzilla.novell.com/attachment.cgi?id=189436) hwinfo output -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 User teheo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c8 --- Comment #8 from Tejun Heo 2008-01-07 19:04:18 MST --- There are actually three types of RAIDs. 1. h/w RAID - as Dejan described. 2. s/w RAID - mdX, as Dejan described. 3. fake (BIOS) RAID - 99% of [SP]ATA controllers which advertise that they support RAID actually don't have any hardware to support RAID. They are all plain ATA controller which can speak to attached devices as directed by the operating system. The only difference from pure software RAID is that the code stored in the flash chip (BIOS) knows the used RAID format and can boot from RAID. In that sense, BIOS RAID is purely software too where the BIOS and the operating system use the same software RAID format. Before the OS boots, BIOS runs the RAID code. After the OS boots OS code runs its RAID code - which is dm in Linux. Fake RAID is usually worse than software RAID. There are several on-disk formats out there, so when you change system configuration you might need to rebuild the array and not all BIOS RAID implementations are of good quality. Unless there's specific reason to use fake RAID (ie. some other OS requires it or whatever), it's always better to use md && grub can boot from md RAID1. That said, the reported problem doesn't look like a libata or dm problem. I agree with Dejan that most likely cause is misconfigured initrd. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 User mmrazik@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c10 Martin Mrazik changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |drankinatty@suddenlinkmail.com --- Comment #10 from Martin Mrazik 2008-01-08 06:49:43 MST --- Could you please provide yast2 logs? If in doubt follow http://en.opensuse.org/Bugs/YaST -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 User drankinatty@suddenlinkmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c12 --- Comment #12 from David Rankin 2008-01-08 10:07:21 MST --- (In reply to comment #8 from Tejun Heo)

There are actually three types of RAIDs.

1. h/w RAID - as Dejan described.

2. s/w RAID - mdX, as Dejan described.

3. fake (BIOS) RAID - 99% of [SP]ATA controllers which advertise that they support RAID actually don't have any hardware to support RAID. They are all plain ATA controller which can speak to attached devices as directed by the operating system. The only difference from pure software RAID is that the code stored in the flash chip (BIOS) knows the used RAID format and can boot from RAID.

In that sense, BIOS RAID is purely software too where the BIOS and the operating system use the same software RAID format. Before the OS boots, BIOS runs the RAID code. After the OS boots OS code runs its RAID code - which is dm in Linux.

Fake RAID is usually worse than software RAID. There are several on-disk formats out there, so when you change system configuration you might need to rebuild the array and not all BIOS RAID implementations are of good quality. Unless there's specific reason to use fake RAID (ie. some other OS requires it or whatever), it's always better to use md && grub can boot from md RAID1.

That said, the reported problem doesn't look like a libata or dm problem. I agree with Dejan that most likely cause is misconfigured initrd.

Thanks Tejun, But, what would explain the successful BIOS raid install on the Gigabyte/nVidia board/raidChip and the failure to boot on the MSI/Promise board? I used the same 10.3 DVD for both installs. It worked with the gigabyte board, but failed with the MSI board. Is there a bug related to the MSI/Promise install? My point is that "If it worked with the Gigabyte/nVidia board why did it not work with the MSI/Promise board?" Your BIOS raid/md raid discussion is excellent. I guess my understanding was the entirely separate chip on the board that says "Promise SATA RAID Controller" was supposed to handle the data mirroring through that hardware chip and decrease the load on the OS presented by the software raid. If that isn't true, then what is the purpose of the separate chips on the motherboards that say RAID that are separate and apart from the ATA controller chips that are also present? Another interesting point is the disk performance of the dual Seagate 250s on the Gigabyte/nVidia raid board with the hardware/BIOS raid install far exceeds the performance of the dual Seagate 340s on the MSI/Promise system with md software raid configured. Both are P4 2800 systems with 2G of ram. The response time was measured with "rpm -qa | grep php". The difference is nearly 2:1? *** I don't mind dumping the MSI/Promise install and trying again with BIOS raid and exploring the initrd issue if you think that will help *** Also, I will post the yast logs when I get back to work. Thank you all for looking into this. I just want to help fix whatever did not work on the MSI/Promise board for opensuse and for everyone else that has that setup. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 User teheo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c14 --- Comment #14 from Tejun Heo 2008-01-08 18:35:59 MST --- David, the installation failure is probably a bug in the installer. Regarding the performance difference of "rpm -qa", you need more controlled test to compare the performance. rpm -qa result can vary greatly depending on how the various files ended up on the file system and so on. If there actually is performance difference (and it would have nothing to do with the hardware - both md and dm are software RAIDs albeit different code paths), I think Neil would love to hear about it. Dejan, for RAID5, hw acceleration makes sense for checksum computation although not many controllers seem to do it better than md mainly due to their small cache memory (you need to go fetch the rest of stripes to compute XOR on cache miss). For RAID0 and 1, the only added overhead of s/w RAID is extra command issues and extra DMA cycles. You won't notice any difference. Plus, all these don't matter as dm is software too anyway. :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 Cyril Hrubis changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |yast2-maintainers@suse.de Status|ASSIGNED |NEW -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=350573 User drankinatty@suddenlinkmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=350573#c16 David Rankin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #16 from David Rankin 2008-06-27 12:27:10 MDT --- I no longer have this machine and am closing the report -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.