This is really quite simple but took me quite awhile to figure out.
Basically from all my reading, most on-board raid controllers are
really not Hardware Raid. A more accurate description or definition
would be a software raid controlled by a BIOS. I sort of knew this
already, but it certainly is frustrating to get one working properly. It is
especially frustrating that some "server" grade hardware uses a software
(fake raid) instead of building in a true hardware raid solution.
So the scoop...There is a function that I had forgotten about. When
you get the first splash screen to install Debian (has several options
ie. expert install, graphical install, expert graphical install etc.),
do not press enter to proceed. Press the "tab" key and you
will get a print out of the actual install/boot parameters. You
simply add to the end of this line,
dmraid=true
Presto. It recognizes the mirror setup that I had done in
the Adaptec configuration. I did not try this on the Intel
controller setting, but expect it would work as well.
Additional note...software raid is a bugger to do under Debian. However, I was well on my way to completing it when I figured this out. The slickthing about it though is that you can take any system that can support 2drives and mirror them at any time. I know that is an obvious statement, but if you come across a system that needs to be mirrored and didn't want to start from scratch, you simply install a drive ofthe same size and an hour later it is mirrored.
Showing posts with label SuperMicro. Show all posts
Showing posts with label SuperMicro. Show all posts
Saturday, October 3, 2009
Thursday, January 22, 2009
SuperMicro 5015B-MTB & CentOS 5.2
A recent project required that I find a linux solution for the 1U SuperMicro Server (5015B-MTB). The 5015B ships with a SATA
Raid controller -
I started with a CentOS 5.2 Network Boot disk and completed a basic install. I did allow it to install iptables (firewall) and knowing that I would be using Samba, made the appropriate selections when prompted. The installation took approximately an hour to complete. I then installed via "yum" a few additional packages...screen, nmap, samba, lynx, sudo etc.
My main goal was achieved with this installation by having a working hardware RAID solution. Once installed, I did test this by removing one of the hard drives while using the system. There was only a momentary pause and then it returned to normal. I then reinserted the drive and after several minutes removed the other in the same fashion. The result was the same. I am very pleased to have had it pass this aggressive test.
Second on the list was to install VMware 2.0. This was my first install of VMware on CentOS. I downloaded the rpm from vmare.com and installed in the typical fashion.
sudo rpm -i vmware-package.rpm
I then proceeded to configure the application. Based on the installation it appeared to be successful. I however quickly found by running
lynx localhost:8222
that it was not listening on the assigned http port. That then led to some additional testing to determine what ports were actually listening on the box.
netstat -anp | grep 8333
This did not return a response and so I began to research the logs to see what information I could glean.
The logs showed the following.
VMware[init]: /usr/lib/vmware/bin/vmware-
shared libraries: /usr/lib/vmware/vmacore/
.so.1.0: cannot restore segment prot after reloc: Permission denied
After some careful googling, I was able to determine that this was a known issue that others had dealt with. I was presented with 2 different solutions but chose to correct it by issuing
chcon -t texrel_shlib_t /usr/lib/vmware/vmacore/
based on http://www.vmware.com/support/server2/doc/releasenotes_vmserver2.html#issues
I then restarted VMware and had a working VM Solution.
While researching this issue, I found several others determined it necessary to make a configuration change to
/etc/SELinux/config
SELinux=permissive
Note: I found this initally set to "enforcing". I later also changed it to "permissive" in order to help troubleshoot a Samba problem.
Update: October 2009
I ordered another one of these servers along with 4 1.5T Seagate drives. I found that under the Adaptec Raid setting, it only saw 512GB of each drive instead of the full 1.5T. It was necessary to configure the bios to use the Intel Raid setup in order for Debian (along with the dmraid=true) to recognize the full size of the drives.
Raid controller -- Intel® ICH9R SATA2 (3 Gbps) controller built-in
- RAID 0, 1, 5, 10 support (Windows Only)
- RAID 0, 1, 10 support (Linux)
I started with a CentOS 5.2 Network Boot disk and completed a basic install. I did allow it to install iptables (firewall) and knowing that I would be using Samba, made the appropriate selections when prompted. The installation took approximately an hour to complete. I then installed via "yum" a few additional packages...screen, nmap, samba, lynx, sudo etc.
My main goal was achieved with this installation by having a working hardware RAID solution. Once installed, I did test this by removing one of the hard drives while using the system. There was only a momentary pause and then it returned to normal. I then reinserted the drive and after several minutes removed the other in the same fashion. The result was the same. I am very pleased to have had it pass this aggressive test.
Second on the list was to install VMware 2.0. This was my first install of VMware on CentOS. I downloaded the rpm from vmare.com and installed in the typical fashion.
sudo rpm -i vmware-package.rpm
I then proceeded to configure the application. Based on the installation it appeared to be successful. I however quickly found by running
lynx localhost:8222
that it was not listening on the assigned http port. That then led to some additional testing to determine what ports were actually listening on the box.
netstat -anp | grep 8333
This did not return a response and so I began to research the logs to see what information I could glean.
The logs showed the following.
VMware[init]: /usr/lib/vmware/bin/vmware-
shared libraries: /usr/lib/vmware/vmacore/
.so.1.0: cannot restore segment prot after reloc: Permission denied
After some careful googling, I was able to determine that this was a known issue that others had dealt with. I was presented with 2 different solutions but chose to correct it by issuing
chcon -t texrel_shlib_t /usr/lib/vmware/vmacore/
based on http://www.vmware.com/support/server2/doc/releasenotes_vmserver2.html#issues
I then restarted VMware and had a working VM Solution.
While researching this issue, I found several others determined it necessary to make a configuration change to
/etc/SELinux/config
SELinux=permissive
Note: I found this initally set to "enforcing". I later also changed it to "permissive" in order to help troubleshoot a Samba problem.
Update: October 2009
I ordered another one of these servers along with 4 1.5T Seagate drives. I found that under the Adaptec Raid setting, it only saw 512GB of each drive instead of the full 1.5T. It was necessary to configure the bios to use the Intel Raid setup in order for Debian (along with the dmraid=true) to recognize the full size of the drives.
Subscribe to:
Posts (Atom)