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

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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

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





_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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.


--
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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.



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos