On Wednesday 28 January 2009, John Doe wrote:
Yes, that's the plan but, the thing is to be able to run the utilities... I need either to make a live CD with the HP tools installed, or a "temporary OS with the tools... First try will be to create a RAID6 on 3 disks (=1 TB, so no grub problems), install the OS, run HP ACU, extend the RAID to the 12 disks, and create the logical disks... If first try fails, second try would be to use a temporary USB disk to install a temporary OS.
This sounds much better to me. Invest 30 min. and install a centos-5 to a 4G usb-stick. Put hpacucli and hpaducli on it and then you can configure, manage and diagnose any server you want.
I meant RAID6 on 4 disks of course... ^_^ I could install and boot, but the CLI version of the ACU is a bit intimidating... And long and complex command lines, without command history is really painful.
True, that's why you run hpacucli from the linux shell :-)
This way bash (or whatever you use) will save the history.
Anyway, I managed and am currently extending the array to the 12 disks... It seems that it is going to take around 3 days! Maybe because the cache battery is not fully charged and so the writes are not cached... After that, I need to reduce the "boot" logical disk down to a dozen of GBs. And then, I need to create the other(s) logical disk(s).
I think a sane end config is one logical drive for the OS (further chopped up with a ms-dos partition table) and one large logical drive for data (possibly chopped up with a gpt partition table or lvm).
As for the logical disks sizes, we would go with something like 5 disks of 1.9TB. So, just classic msdos partitions. One thing is for sure, HP tries really hard to make it complicated...
Why would you make 5 logical drives? Why use partition tables?
Hum... just wanted to be fdisk friendly (no gpt)...
The is no reason to be ms-dos-partition friendly on the "data device", IMO.
But, since grub problem should be solved, I guess I could make 1 big logical disk with gpt and forget about fdisk...
Don't mix things up here, fdisk is a tool that can only handle ms-dos partition tables. parted is a tool that can handle many types, including gpt. It's the partition table type that is the problem not the tool so to speak.
I saw that the use of LVM was tossed around, don't know if the OP is/plans on using it. If you use ext3 on lvm, you can do a background fsck while the system is up & fs mounted:
I must admit that I have never used lvm... We don't really need resizable/expandable volumes, etc... the server's capacity is already maxed. We try to follow the "KISS" principle as much as we can.
You can look at LVM as just another way to partition a drive. In that sense it's more flexible and harder to mess up than using, say, parted+gpt.
With parted+gpt you'd partition the /dev/cciss/cXdY device into many cXdYpN devices. With lvm you'd get to name them and they would be available as /dev/VOLUMEGROUPNAME/LOGICALVOLUMENAME.
Go with the way you know and understand.
But the live background fsck seems nice.
This feature seems to violate the KISS principle for sure...
/Peter
Do you really think I should learn lvm rightaway?
JD