Tried a few things you suggested and seemed to get nowhere so took the option of reinstalling as per the instructions above and although it seems a better install (kernel is now 4.0.2 and booting by default) with no error messages on the dashboard.
However when I go in to the Storage screen and click to wipe any of the discs in the array I get this error
and Rockstor cannot use them until they have been wiped.
I realize that I am joining the party late, but first off, thank you @phillxnet for really helpful and enlightening content.
Even with the current strange behavior with switching default boot kernels(which is resolved and shouldn’t happen in future updates), there is no need for any bootloader config changes. Whenever rockstor boots, it sets 4.1(provided you are running 3.8-2) as the default kernel. So you may need to reboot a couple of times, but it should just boot into 4.1 by doing nothing besides rebooting a couple of times.
I won’t comment on the ip address as you seemed to have fixed it already, sorry for my late responses.
Thanks suman, any idea on the problem above? not being able to wipe the disks in the array
Sorry you ran into this after an enduring effort, but lose no hope over it, we’ll help you. This looks like a real bug to me. Could you please follow the instructions in that error and email the logs? Feel free to attach them here if that is more convenient. If it’s a simple fix, I’ll get it out in the next week’s update.
Unfortunately clicking the link to retrieve the error logs only gets this response
Not really surprised lol
I thought there may be a way to wipe them in recovery mode or something
Wow. I really like your setup. The day we make Rockstor work well on your hardware would be a proud day for us 
If you can ssh/login as root and gzip the /opt/rockstor/var/log directory and send it over, it will definitely help.
Here’s the command you can try to manually wipe a device: wipefs -a /dev/[your_device_path] Be careful not to wipe the root drive, of course.
I’ve never used SSH from a windows 7 machine so not really any idea.
I do have keyboard and screen setup on the server though so if you give me the commands to run and copy the files to a usb stick I could get then that way
As you were I’ve installed putty and logged onto the server as root
if you can give me the commands I should be able to get them
tried “tar -zcf - /opt/rockstor/var/log” > dir.tar.gz
response is no such file or directory
Would the wipe command be wipefs -a /dev/cciss!c0d1
and can I run this in the SSH/putty window?
tar czf logs.tgz /opt/rockstor/var/log
Did you try wipefs -a /path/to/your/drive on your drives?
that command for gzip has not put any file/logs on my host machine.
and I wouldn’t run the wipe command until I know the line is correct and where to run it
btw the O/S is on disk cciss!c0d0
cheers
logs.tgz will be created in the same directory where you executed the command. ls will show it to you. Now, I am not a windows user, but you could perhaps use a program like WinSCP to transfer log.tgz from your rockstor box to your windows machine.
a command like lsblk will show your cciss* devices. Definitely don’t run wipefs on cciss!c0d0, but say you have one other drive called cciss!c0d1(which I think you do given the web-ui error), then you should be able to run wipefs -a /dev/cciss!c0d1
After wipefs, restart rockstor with systemctl restart rockstor. Then on web-ui storage->disks screen, the erase icons should go away.
Ran “wipefs -a /dev/cciss!c0d1” no joy but took a guess and ran wipefs -a /dev/cciss/c0d1 and rescanned the disks in the web-ui and it worked so did the same for the other three.
ran ls and I can see the logs.tgz just got to get it transferred
well supprised myself there transferred it using Filezilla 
Now how do I get it to you?
Or do you now not need the logs?
Logs emailed added [solved} to title
Many thanks for your help suman
You are welcome @Bearbonez. I’ve converted this comment into a wiki topic, which means users with trust level 1 or above can edit this. It would be of major help to others if you can explain what the problem is and detail the solution step by step. Perhaps @phillxnet will consider pitching in.
Just looked at your logs too. Rockstor is definitely confused by these device names. We’ll fix it. I may have to contact you for more quesitons.
no problem but I’m giving in for the night and having a beer
feel like I need one after all that, getting there tho
Someone e-mailed me two links that provide further information on this matter. Just wanted to share them here for future reference.
http://jordanappleson.co.uk/linux/2014/09/18/centos-7-and-hp-raid-drivers/
I’m having a similar issue on the exact same hardware.
First, I added the following to the grub boot line when starting the install:
cciss.cciss_allow_hpsa=1 hpsa.hpsa_allow_any=1 hpsa.hpsa_simple_mode=1
Next, I added the same line to the GRUB_CMDLINE_LINUX variable in /etc/default/grub. This will ensure that on any future reboots (and I hope upgrades), I won’t have to tinker with GRUB just to load the server.
Now that I was in the system, I found that if I click the link for an individual drive on the “Storage” -> “Disks” screen I got the following error:
Unknown client error doing a GET to /api/disks/cciss!c0d0
Also, I noticed that wiping a disk was failing with “ERROR: checking status of /dev/cciss!c0d2: No such file or directory” Hovering over the gear icon to the right of my Rockstor boot volume stated that:
Disk is unusable because it has some other file system on it.
In reading this thread, I noticed that @Bearbonez posted this gem:
Ran “wipefs -a /dev/cciss!c0d1” no joy but took a guess and ran wipefs -a /dev/cciss/c0d1 and rescanned the disks in the web-ui and it worked so did the same for the other three.
Notice that if there is an exclamation mark in the device name (e.g. /dev/cciss!c0d2) the wipefs operation failed. However if the exclamation mark is replaced with a slash (e.g. /dev/cciss/c0d2) the wipefs command worked perfectly. I was able to wipe all my disks using this methodology.
Once I wiped all of my data drives, I decided to create a Pool with them. I received the following error:
Error running a command. cmd = [’/sbin/mkfs.btrfs’, ‘-f’, ‘-d’, u’raid5’, ‘-m’, u’raid5’, ‘-L’, u’data’, u’/dev/cciss!c0d2’, u’/dev/cciss!c0d3’, u’/dev/cciss!c0d4’, u’/dev/cciss!c0d5’]. rc = 1. stdout = [’’]. stderr = [‘ERROR: checking status of /dev/cciss!c0d2: No such file or directory’, ‘’]
However, if I ran the command in the shell making a few changes everything appeared to work:
[root@nas ~]# /sbin/mkfs.btrfs -f -d raid5 -m raid5 -L data /dev/cciss/c0d2 /dev/cciss/c0d3 /dev/cciss/c0d4 /dev/cciss/c0d5
btrfs-progs v4.2.1
See http://btrfs.wiki.kernel.org for more information.
Label: data
UUID: f3d3f35b-8553-476b-8c5e-8ab87598e64e
Node size: 16384
Sector size: 4096
Filesystem size: 1.09TiB
Block group profiles:
Data: RAID5 3.01GiB
Metadata: RAID5 3.01GiB
System: RAID5 16.00MiB
SSD detected: no
Incompat features: extref, raid56, skinny-metadata
Number of devices: 4
Devices:
ID SIZE PATH
1 279.37GiB /dev/cciss/c0d2
2 279.37GiB /dev/cciss/c0d3
3 279.37GiB /dev/cciss/c0d4
4 279.37GiB /dev/cciss/c0d5
Unfortunately, while the command appeared to work - lsblk does not list my pool, nor does it appear in the Rockstor UI. But if I turn around and mount the file system - all appears well:
[root@nas ~]# ls /dev/disk/by-label/
data rockstor_nas00
[root@nas ~]# mkdir /mnt/data
[root@nas ~]# mount /dev/disk/by-label/data /mnt/data
[root@nas ~]# cd /mnt/data/
[root@nas data]# ls
[root@nas data]# ls -la
total 16
drwxr-xr-x. 1 root root 0 Nov 16 01:01 .
drwxr-xr-x. 1 root root 8 Nov 16 01:02 …
[root@nas data]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.9G 0 7.9G 0% /dev
tmpfs 7.9G 0 7.9G 0% /dev/shm
tmpfs 7.9G 8.5M 7.9G 1% /run
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/cciss/c0d0p3 129G 1.5G 126G 2% /
/dev/cciss/c0d0p1 477M 104M 344M 24% /boot
/dev/cciss/c0d0p3 129G 1.5G 126G 2% /home
/dev/cciss/c0d2 1.1T 18M 1.1T 1% /mnt/data
The Rockstor UI still doesn’t show me anything about created pools - though when attempting to add a new pool, I only have one disk listed (cciss!c0d1 - this is accurate as this is the only unallocated drive I have at this point in my testing).
I’m wondering if the general disk operation via the Rockstor front end needs to replace all exclamation points (!) with slashes (/) for both display and commands. It appears to have solved the problems with the command line tools - why not the UI?
As I’m running a development system and attached to the test builds, I’m more than willing to pull down a new version to test it on this system. Also if you want any output from the system (lspci, similar inventory or storage commands) just ask.
Thanks!
To add more information - I reinstalled the server to CentOS 6 with a minimal installation to see the behavior of the CCISS driver when it was part of the main disitribution. Here’s the output I got:
[root@NAS ~]# uname -a
Linux NAS.ellsworth8.net 2.6.32-573.el6.x86_64 #1 SMP Thu Jul 23 15:44:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@NAS ~]# cat /etc/redhat-release
CentOS release 6.7 (Final)
[root@NAS ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
cciss!c0d0 104:0 0 136.7G 0 disk
├─cciss!c0d0p1 104:1 0 500M 0 part
└─cciss!c0d0p2 104:2 0 136.2G 0 part
├─vg_nas-lv_root (dm-0) 253:0 0 50G 0 lvm /
├─vg_nas-lv_swap (dm-1) 253:1 0 7.9G 0 lvm [SWAP]
└─vg_nas-lv_home (dm-2) 253:2 0 78.4G 0 lvm /home
cciss!c0d1 104:16 0 136.7G 0 disk
cciss!c0d2 104:32 0 279.4G 0 disk
cciss!c0d3 104:48 0 279.4G 0 disk
cciss!c0d4 104:64 0 279.4G 0 disk
cciss!c0d5 104:80 0 279.4G 0 disk
sr0 11:0 1 1024M 0 rom
sda 8:0 1 14.9G 0 disk
├─sda1 8:1 1 512K 0 part
└─sda2 8:2 1 14.9G 0 part
[root@NAS ~]# ls -la /dev/cciss
total 0
drwxr-xr-x. 2 root root 200 Nov 16 22:35 .
drwxr-xr-x. 21 root root 3860 Nov 16 22:36 …
brw-rw----. 1 root disk 104, 0 Nov 16 22:36 c0d0
brw-rw----. 1 root disk 104, 1 Nov 16 22:36 c0d0p1
brw-rw----. 1 root disk 104, 2 Nov 16 22:36 c0d0p2
brw-rw----. 1 root disk 104, 16 Nov 16 22:36 c0d1
brw-rw----. 1 root disk 104, 32 Nov 16 22:36 c0d2
brw-rw----. 1 root disk 104, 48 Nov 16 22:36 c0d3
brw-rw----. 1 root disk 104, 64 Nov 16 22:36 c0d4
brw-rw----. 1 root disk 104, 80 Nov 16 22:36 c0d5
So the ! notation in listing commands like lsblk happened in CentOS 6 as well.
