I have a couple of computers running linux that has HP Smartarray RAID controllers. I performed update on one of them running OpenSUSE 13.1 and having the system on hardware raid in a HP Smartarray P400 controller. After updating everything to the latest i tried to reboot. . . Boot Fail!

Everything is fine up until the when the root filesystem should be mounted. The system root partition did not appear, and eventually i ended up in the emergency shell. Where i could see that none of the disk was detected. Also, both the drivers cciss ans hpsa was loaded. One of them should have presented the disks to the system, but no.

The system has one HP Smartarray P400 RAID controller with 512 MB battery backed cache, and four 2TB WB RE4 disks split up in two RAID5 logical disks - One small for the system "/dev/cciss/c0d0", and one large work disk "/dev/cciss/c0d1".

Before updating, the system was running linux kernel version 3.11.10-34 and everything was working 100%.

HP has decided to introduce the HPSA driver to replace the CCISS driver in the future. The newest Smartarray controllers only work with the HPSA driver, and the oldest controllers will not be supported by the HPSA driver, but will continue to work with the CCISS driver.

The difference between the two drivers can be summarized as follows:

CCISS is a block storage driver, that serve the disks directly, not using SCSI transport. The disks appear with device names like "/dev/cciss/c0d0p1", (First partition on first disk on first controller).

HPSA is a SCSI storage driver. It uses the same naming conventions that most disks use today. Like "/dev/sda1", (First partition on the first scsi disk detected by the BIOS).

Personally i like the CCISS naming convention, since it makes it easier to keep separate the iSCSI disks et cetera from the system disk. The scsi naming convention "/dev/sda1" can cause lots of confusion regarding multipath iSCSI, DMRAID and MDRAID disks. The disks can actually come up in whatever order. Not the CCISS disks, which have a fixed order naming.

More info on the CCISS vs HPSA drivers on the following link: http://cciss.sourceforge.net/

Anyway, back to the booting problem!
Between Linux kernel versions 3.11.10-34 and 3.12.57-44 there is a small cosmetic change in the CCISS driver, and i found this little change to be the culprit. So i decided to make this writeup on the problem and the solution, for others that stumble on the same problem. Or someone that wants to entirely avoid the booting problem when updating their Linux kernel.
So, here it goes!

How to prevent boot problems on systems using CCISS system disk on HP Smartarray P400 raid controllers, which happens when updating OpenSUSE 13.1 to use kernel version 3.12.57-44.

The Linux kernel version 3.12.57-44 update for OpenSUSE 13.1 contains a CCISS driver version 3.6.26 that is slightly changed compared to previous version 3.6.26 used with Linux kernel version 3.11.10-34.

Wait, you say. The same driver version? Different?
Yes. The two different kernel versions for OpenSUSE 13.1 have two different CCISS drivers of the same version.
This leads me to think that someone has been tinkering and clobbering when preparing the kernel update for OpenSUSE?

The "new" driver has the module parameter cciss_allow_hpsa set to 1 as default.
This is incorrect, since it assumes the older raid controllers from Compaq/HP can use the new driver HPSA. But they can't. So with the newer kernel, and the newer driver, the system stalls when trying to mount the root partition, since the HPSA driver takes precedense but will not correctly present the drives to the system.

The previous version of the CCISS driver had the parameter cciss_allow_hpsa set to 0 by default to give the CCISS driver precedence over the HPSA driver.

To continue using the CCISS driver as before, the boot loader must be updated with a new kernel command line parameter.
(Or, better yet, the driver code changed back to the original, correct state).

Simply open up YAST2 / Boot loader, and click on Boot loader options.
Add the following to the "Optional Kernel Command Line Parameter" field:

cciss.cciss_allow_hpsa=0

(Please note that the parameters are separated by space).

After updating the boot loader and rebooting the system, it is safe to update the kernel to version 3.12.57-44.

In case the system got updated with the new kernel before the above mentioned patch of the boot parameters, and did not succed in booting. Then the system can be booted to the previous kernel
version by selecting it in the GRUB2 boot menu. The changes to the boot loader can then be applied as above, and then the system will boot/reboot using the CCISS driver and the newer kernel.

Problem solved!

glad you solved it
BUT
OpenSUSE 13.1 is past it's end of life
https://en.opensuse.org/Lifetime

if you MUST continue to use it , port 13.1 to " Evergreen"
https://en.opensuse.org/openSUSE:Evergreen

Yes. Annoying.

OpenSUSE LEAP does not support 32 bit. I still use many 32-bit systems, so from my point of view LEAP was EOL when it was released. Or rather DOA. It's for the narcissistic nerds.
Not for real nerds that use their computers for real nerdy stuff. Such as revamping an old ReadyNAS by putting OpenSUSE on it instead of the RAIDiator firmware.

OpenSUSE 13.2 is not reliable. Unstable. Unreliable. Shaky! To much of the systemd in it.
The bends.

OpenSUSE 13.1 is the last of the best concerning OpenSUSE. I have to admit it is rather good.

I will look into taking a "leap" into evergreen. Done it before. With OpenSUSE 11.4. More of a proper Linux. But now outdated on drivers and updates on other important stuff. But rock solid compared to what came after it.


Please note that the same issue may well present itself in both OpenSUSE 13.2 and LEAP. But i write about OpenSUSE 13.1 because that is where i found the problem.

MOAN!

I just figured out that the sustained sequential disk write speed plummeted from 212 MB/s to 75 MB/s when going from kernel 3.11.10-34 to kernel 3.12.57-44.

There are no changes in the cciss modified driver that can affect performance.
It can be as simple as the new kernel is misconfigured somehow?

I guess kernel 3.12.57-44 is completely stuffed up with random tinkering and improvements.

So i rolled back to kernel version 3.11.10-34 and stay happy with being able to utilize the full performance of the hardware.

bonnie++

I wonder why people tinker so much with things they don't understand?
At least test the changes before releasing them to the community.

if it ain't broke, don't fix it