Ok, I've got a RocketRAID 2300 and when i do the update of the kernel it breaks the raid card since the OS is on the raid card itself, i need to install the driver into the new kernel.. Whats the best way to do this? I am reading the manual from the manufacter, but i dont see anything as to a new kernel upgrade.
Thanks, Ryan Nichols
Ryan Nichols wrote:
Ok, I've got a RocketRAID 2300 and when i do the update of the kernel it breaks the raid card since the OS is on the raid card itself, i need to install the driver into the new kernel.. Whats the best way to do this? I am reading the manual from the manufacter, but i dont see anything as to a new kernel upgrade.
If the kernel module is built from an external driver, you can just copy it to it's place in the new kernel path and then run the command:
depmod -a <version>
also need to rerun mkinitd like this:
mkinitrd /boot/initrd-<version>.img <version>
Johnny Hughes wrote:
Ryan Nichols wrote:
Ok, I've got a RocketRAID 2300 and when i do the update of the kernel it breaks the raid card since the OS is on the raid card itself, i need to install the driver into the new kernel.. Whats the best way to do this? I am reading the manual from the manufacter, but i dont see anything as to a new kernel upgrade.
If the kernel module is built from an external driver, you can just copy it to it's place in the new kernel path and then run the command:
depmod -a <version>
also need to rerun mkinitd like this:
mkinitrd /boot/initrd-<version>.img <version>
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
First command, no error.. 2nd command said image already exists?
Thanks, Ryan Nichols
Johnny Hughes wrote:
Ryan Nichols wrote:
Ok, I've got a RocketRAID 2300 and when i do the update of the kernel it breaks the raid card since the OS is on the raid card itself, i need to install the driver into the new kernel.. Whats the best way to do this? I am reading the manual from the manufacter, but i dont see anything as to a new kernel upgrade.
If the kernel module is built from an external driver, you can just copy it to it's place in the new kernel path and then run the command:
depmod -a <version>
also need to rerun mkinitd like this:
mkinitrd /boot/initrd-<version>.img <version>
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ok, I used -f to get around that.. but now it hates my raid controller and is throwing all kinds of errors...
Thanks, Ryan Nichols
Ryan Nichols wrote:
Johnny Hughes wrote:
Ryan Nichols wrote:
Ok, I've got a RocketRAID 2300 and when i do the update of the kernel it breaks the raid card since the OS is on the raid card itself, i need to install the driver into the new kernel.. Whats the best way to do this? I am reading the manual from the manufacter, but i dont see anything as to a new kernel upgrade.
If the kernel module is built from an external driver, you can just copy it to it's place in the new kernel path and then run the command:
depmod -a <version>
also need to rerun mkinitd like this:
mkinitrd /boot/initrd-<version>.img <version>
Ok, I used -f to get around that.. but now it hates my raid controller and is throwing all kinds of errors...
If it works ok on the old kernel, it should also work OK on the new one.
Johnny Hughes wrote:
Ryan Nichols wrote:
Johnny Hughes wrote:
Ryan Nichols wrote:
Ok, I've got a RocketRAID 2300 and when i do the update of the kernel it breaks the raid card since the OS is on the raid card itself, i need to install the driver into the new kernel.. Whats the best way to do this? I am reading the manual from the manufacter, but i dont see anything as to a new kernel upgrade.
If the kernel module is built from an external driver, you can just copy it to it's place in the new kernel path and then run the command:
depmod -a <version>
also need to rerun mkinitd like this:
mkinitrd /boot/initrd-<version>.img <version>
Ok, I used -f to get around that.. but now it hates my raid controller and is throwing all kinds of errors...
If it works ok on the old kernel, it should also work OK on the new one.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
No idea, it says the OS drive is corrupt,all kinds of errors.. i hate this install that was recommended of putting the stupid OS on the rocketraid card for this very reason..
Thanks, Ryan Nichols
Johnny Hughes wrote:
Ryan Nichols wrote:
Johnny Hughes wrote:
Ryan Nichols wrote:
Ok, I've got a RocketRAID 2300 and when i do the update of the kernel it breaks the raid card since the OS is on the raid card itself, i need to install the driver into the new kernel.. Whats the best way to do this? I am reading the manual from the manufacter, but i dont see anything as to a new kernel upgrade.
If the kernel module is built from an external driver, you can just copy it to it's place in the new kernel path and then run the command:
depmod -a <version>
also need to rerun mkinitd like this:
mkinitrd /boot/initrd-<version>.img <version>
Ok, I used -f to get around that.. but now it hates my raid controller and is throwing all kinds of errors...
If it works ok on the old kernel, it should also work OK on the new one.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/cen
ata1.00: status { DRDY } over and over
No idea what i broke..
Thanks, Ryan Nichols
Am 13.07.2008 um 22:14 schrieb Ryan Nichols:
Johnny Hughes wrote:
If it works ok on the old kernel, it should also work OK on the new one.
Not if it's a binary-driver...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/cen
ata1.00: status { DRDY } over and over
No idea what i broke..
You upgraded the kernel...
Seriously - if this driver is not included in the vanilla- or distribution-kernel, get the heck rid of it (the hardware). With very few exceptions it's usually not worth the trouble. One of these exceptions is Areca (don't know if the driver is in now RHEL/CentOS) - the guy maintaining the driver at Areca actually responds to email enquiries. But then, they distribute source and not BLOBs.
cheers, Rainer
Rainer Duffner wrote:
Am 13.07.2008 um 22:14 schrieb Ryan Nichols:
Johnny Hughes wrote:
If it works ok on the old kernel, it should also work OK on the new one.
Not if it's a binary-driver...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/cen
ata1.00: status { DRDY } over and over
No idea what i broke..
You upgraded the kernel...
Seriously - if this driver is not included in the vanilla- or distribution-kernel, get the heck rid of it (the hardware). With very few exceptions it's usually not worth the trouble. One of these exceptions is Areca (don't know if the driver is in now RHEL/CentOS) - the guy maintaining the driver at Areca actually responds to email enquiries. But then, they distribute source and not BLOBs.
cheers, Rainer
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thats the point Im at, but the man who pays for this hardware wants us to make this work because we already own it and it works until we attempt an upgrade of the kernel .. So i guess its onto tech support with HighPoint RocketRaid...
Thanks, Ryan Nichols
Rainer Duffner wrote:
Am 13.07.2008 um 22:14 schrieb Ryan Nichols:
Johnny Hughes wrote:
If it works ok on the old kernel, it should also work OK on the new one.
Not if it's a binary-driver...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/cen
ata1.00: status { DRDY } over and over
No idea what i broke..
You upgraded the kernel...
Seriously - if this driver is not included in the vanilla- or distribution-kernel, get the heck rid of it (the hardware). With very few exceptions it's usually not worth the trouble. One of these exceptions is Areca (don't know if the driver is in now RHEL/CentOS) - the guy maintaining the driver at Areca actually responds to email enquiries. But then, they distribute source and not BLOBs.
cheers, Rainer
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
ata1.00 cmd c8/00:08:00:00:00:/00:00:00:00/E0 tag 0 dma 4096 in ata1.00 status: {DRDY} ata1.execption Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
and it keeps going and going until it hits Buffer I/O error on device sdc, logical block 0
and if i go back to grub take the old kernel its happy.. werid..
Ryan Nichols
Ryan Nichols wrote:
and if i go back to grub take the old kernel its happy.. werid..
Sounds like you should just stick to the old kernel, what's in the new kernel that you need anyways? Is the system in a secure place?(e.g. separate firewall protecting it, not directly on the internet, don't have untrusted users logging in).
If so, then you really have little to worry about, there is not much interesting things released in the newer minor version releases of the kernel in RHEL/CentOS. It's that way on purpose.
In my experience having all your systems completely up to date is rare. The environment I stepped into a few months ago for example is running RHEL 4 Update 1 for the most part. They still run windows 2000 on several systems, and I don't think they've patched them recently. But the nature of the environment and the users that interact on it don't keep me up at night like a system directly connected to the internet with untrusted users. It'll probably take me the next 6 months to get everything more up to date in this particular environment, it has a lot of interdependencies. And by that point it should be easier to manage going forward, but we'll still probably won't install updates sooner than a month or two after they come out in general because that stuff takes time to test and deploy.
Hopefully your not in a situation where you have untrusted users, if so you should replace the hardware with something that is better supported, or abstract the exposure to the system with something like virtualization, certainly not perfect but it's better then nothing, it will help dramatically against the most common, casual attacks.
nate
nate wrote:
Ryan Nichols wrote:
and if i go back to grub take the old kernel its happy.. werid..
Sounds like you should just stick to the old kernel, what's in the new kernel that you need anyways? Is the system in a secure place?(e.g. separate firewall protecting it, not directly on the internet, don't have untrusted users logging in).
If so, then you really have little to worry about, there is not much interesting things released in the newer minor version releases of the kernel in RHEL/CentOS. It's that way on purpose.
In my experience having all your systems completely up to date is rare. The environment I stepped into a few months ago for example is running RHEL 4 Update 1 for the most part. They still run windows 2000 on several systems, and I don't think they've patched them recently. But the nature of the environment and the users that interact on it don't keep me up at night like a system directly connected to the internet with untrusted users. It'll probably take me the next 6 months to get everything more up to date in this particular environment, it has a lot of interdependencies. And by that point it should be easier to manage going forward, but we'll still probably won't install updates sooner than a month or two after they come out in general because that stuff takes time to test and deploy.
Hopefully your not in a situation where you have untrusted users, if so you should replace the hardware with something that is better supported, or abstract the exposure to the system with something like virtualization, certainly not perfect but it's better then nothing, it will help dramatically against the most common, casual attacks.
nate
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
We're trying to get support from a 3rd party software we use and they are insiting we goto the current versions of everything for there software before they'll move forward on the support.
Thanks, Ryan Nichols
Ryan Nichols wrote:
We're trying to get support from a 3rd party software we use and they are insiting we goto the current versions of everything for there software before they'll move forward on the support.
In that case I would reproduce the problem on another system that doesn't have the strange RAID controller, and on the most up to date software. If you can troubleshoot it there, get the fix and apply it to the system they won't "support".
It seems pretty common with folks and Red Hat /CentOS. They buy red hat for a few high value target systems, and get support on them and use CentOS for the rest, or some other RHEL offshoot. If they have a problem on CentOS they repro it on RHEL and if they can they can get a fix from Red Hat.
Not the most honest thing to do in my opinion but it is an option in many cases.
nate
on 7-13-2008 2:58 PM Ryan Nichols spake the following:
Rainer Duffner wrote:
Am 13.07.2008 um 22:14 schrieb Ryan Nichols:
Johnny Hughes wrote:
If it works ok on the old kernel, it should also work OK on the new one.
Not if it's a binary-driver...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/cen
ata1.00: status { DRDY } over and over
No idea what i broke..
You upgraded the kernel...
Seriously - if this driver is not included in the vanilla- or distribution-kernel, get the heck rid of it (the hardware). With very few exceptions it's usually not worth the trouble. One of these exceptions is Areca (don't know if the driver is in now RHEL/CentOS) - the guy maintaining the driver at Areca actually responds to email enquiries. But then, they distribute source and not BLOBs.
cheers, Rainer
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
ata1.00 cmd c8/00:08:00:00:00:/00:00:00:00/E0 tag 0 dma 4096 in ata1.00 status: {DRDY} ata1.execption Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
and it keeps going and going until it hits Buffer I/O error on device sdc, logical block 0
and if i go back to grub take the old kernel its happy.. werid..
Ryan Nichols
You should be able to compile the driver into the new kernel tree while still running the old kernel. You will just have to add a lot of paths to the compile line and the mkinitrd line. I am surprised that it doesn't give examples somewhere on their website or in the modules docs.
On Sun, 2008-07-13 at 22:23 +0200, Rainer Duffner wrote:
Am 13.07.2008 um 22:14 schrieb Ryan Nichols:
Johnny Hughes wrote:
If it works ok on the old kernel, it should also work OK on the new one.
Not if it's a binary-driver...
I'm familiar with the card & driver ... it's a binary blob with a bit of source to glue it to the kernel. The card is also fakeraid rather than real raid ... more trouble than it's worth.
Paul
Paul wrote:
On Sun, 2008-07-13 at 22:23 +0200, Rainer Duffner wrote:
Am 13.07.2008 um 22:14 schrieb Ryan Nichols:
Johnny Hughes wrote:
If it works ok on the old kernel, it should also work OK on the new one.
Not if it's a binary-driver...
I'm familiar with the card & driver ... it's a binary blob with a bit of source to glue it to the kernel. The card is also fakeraid rather than real raid ... more trouble than it's worth.
Paul
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
So its junk? What would you recommend we move to then? Wont that be messy on the card change to another raid5 set?
Thanks, Ryan Nichols
Ryan Nichols schrieb:
So its junk?
Basically, yes. Just worded more politely in the original mail by Paul.
What would you recommend we move to then?
RAID5+6: Areca, recent 3Ware SATA2 controllers, cciss (HP/CPQ). RAID1: If the system doesn't come with a decent RAID-controller, I'd rather go for software-RAID1. 3Ware doesn't produce any decent RAID1-controllers for SATA2 - the current lineup (8006-LP2) may show problems with SATA2 drives...
Wont that be messy on the card change to another raid5 set?
No. You just need to re-install your server and restore your data ;-)
cheers, Rainer
on 7-13-2008 3:42 PM Ryan Nichols spake the following:
Paul wrote:
Johnny Hughes wrote:
If it works ok on the old kernel, it should also work OK on the new one.
Not if it's a binary-driver...
I'm familiar with the card & driver ... it's a binary blob with a bit of source to glue it to the kernel. The card is also fakeraid rather than real raid ... more trouble than it's worth.
So its junk? What would you recommend we move to then? Won't that be messy on the card change to another raid5 set?
IMHO software raid (even raid5) is better than a fakeraid card. Since fakeraid is software raid with a proprietary driver, you are much better off with a time-tested set of drivers than a manufacturers possible half-baked attempt to port a windows driver to linux.
-
Johnny Hughes -
nate -
Paul -
Rainer Duffner -
Ryan Nichols -
Scott Silva