Hello, everyone! When can we expect to see Centos 4.4? There's a nasty bug in 4.3 where RAID1 and LVM2 don't get along without data corruption that Red Hat just fixed two days ago on RHEL. So, when can expect to see it?
It's hard to install a machine with RAID1 and LVM2 without rolling my own CDs, which I am loathe to do. I did that once. What a PITA.

(Action) stabs Inter-Tel. Again.

TSWoodV: bug tracker entry?
(Action) hugs inter-tel

(Action) stabs donavan.

TSWoodV: watch the announce list or the website

(Action) wishes to read about this nasty bug

Can anyone explain the Centos support for a Xeon 5000? It claims to be a 32/64bit processor. Does the kernel inherently support 64 bit mode? Is there anything I need to do to enable this?

have you installed centos?

Just finished.

what did you download to install?

what 4.4 was just released hours ago and we don't have it rebuilt yet ?

The 4.3server CD.
i386

then you installed a 386 (32 bit) release

doug8429: install the x86_64 architecture version to use the 64-bit capabilities of the xeon

if that processor has em64t and you want a 64bit os, you need the x86_64 release

I thought x86_64 was AMD specific.

it was until amd licensed it
to intel

for use with the xeon, specifically :)

huh?
you can buy other intel crap with em64t

well, that was the first intel chip to use x86_64, no?
anyway, its the most common

OK, great! Thanks a lot. I search the Centos forums for a while and couldn't find this info. Maybe it's just commonly known? Should it be a FAQ?

i'm willing to bet the centos d/l page mentions that the x86_64 arch is for AMD 64 and Xeon em64t
think i remember reading it

devhen: i doubt its most common

i could be wrong. i just remember seeing multiple distros claiming the x86_64 version was for AMD 64 and Xeon em64t

I think it does, I just didn't know if a Xeon 5000 is a em64t processor.

never seen them mention another intel processor

you'll find this: "x86_64 (AMD64 and Intel EM64T)"

im sure your right. thanks for the info.

Yes, I saw that. But I didn't see the word "Xeon", so I wasn't sure.

so, doug8429, i'd recommend the x86_64 arch to sqeeze every bit of performance out of your em64t xeon

dayum intel marketing hype foils another user

OK, thanks a lot everyone.

np. thanks donavan, for straightening me out :)

he might actually only have a 32bit CPU
I was searching

dont know much about the '5000'...
not em64t?

Xeon 5000 is a emt67

not sure, still looking :D

64 even ;)
for Intel Xeon information, http://www.intel.com/design/Xeon/documentation.htm ....if in doubt ;)

Xeon 5000?
Dempsey?

thats what I'm thinking perry753

surely you agree xeon is intel's most popular em64t server chip. its in about 99% of dell servers, and even the xserve now! :)

5100 = woodcrest

they seem to be 64bit

they are

you can never be too sure with intel -- between marketing lies, marketing lies to cover design flaws, the vastly superier marketing lie called itanic, not to mention itanic2

Xeon's have been 64bit for a while

Hey folks, I think there is a variable somewhere which sets the maximum open files on centos. Where is it stored?

sounds like a google question Stormx2

>.< Alright
Does anyone know what this variable would be called, to aid me with my quest?

wow im actually d/l rhel4.4 at 75kB/sec now! sweeeet

Stormx2: at the kernel level or the user level?

devhen: holy sh*t RHEL 4.4?

yep, just released. sloow downloads though

donavan: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164696 for the RAID1 and LVM2 entry.

WTF
I JUST DOWNLOADED 4.0, 4.1, 4.2, 4.3, 4.4
@.@

sucker.

(Action) hugs inter-tel

:(

TSWoodV: where is the information this was fixed?

donavan: I'm not sure. Im getting an IRC server running, and it said
The OS enforces a limit on max open files
Hard Limit: 100 MAXCONNECTIONS: 1024
Fix MAXCONNECTIONS
Ack, sorry for the paste
(Action) slaps mIRC

donavan: Look at the bottom of this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152162
donavan: Seems a relatively small patch that took a lot of digging to find.

TSWoodV: I fail to understand your issue now.... that kernel is ungodly old

donavan: Sorry. This one instead: http://rhn.redhat.com/errata/RHSA-2006-0575.html

a little birdy told me 2.6.9-42 is going to be the 4.4 kernel

donavan: It took a fair amount of link following to get here...

help me understand this: "There's a nasty bug in 4.3 where RAID1 and LVM2 don't get along without data corruption that Red Hat just fixed two days ago on RHEL."

donavan: Some how I'm not coming up with the same link path that I used to find this earlier. Sorry for all the bad starts/stops. I dug this info out of bugzilla that led me to believe that this kernel fixes the RAID1/LVM issue.
donavan: At any rate, neither the original CentOS 4.3 kernel nor the currently-available kernel work properly with this setup.
donavan: I've tried turning off hyperthreading, thinking this was some obscure race condition on MP boxes. That didn't help either.

TSWoodV: what is the output of " uname -a " on the box in question?

donavan: SMART on both drives shows no problems.
donavan: I'll have to try to get it back up enough to tell. A simple rebooting after installation has corrupted at least /var and maybe / as well. Everything except /boot on this box is under LVM.
donavan: I'll have to go down the hall and try to resurrect the box. BRB.

TSWoodV: I doubt anything that redhat fixed 2 days ago is going to be in 4.4 as 4.4 has likely been in final QA from some number of days
if you have corruption after install, I hardly believe the issue can be related to the bugzilla's I've looked at -- particularly if you are installing from 4.3 media

donavan: 2.6.9-34.EL is causing problems. Same thing with the 4.2 media.
donavan: Just rebooted the box and it dropped out for fsck again.
donavan: Previous efforts to run "yum update" have also met with corruption.

I'll stand by my last comment
every box I have with 2 or more drives is doing LVM over raid1 (raid5 or raid6)
not that it matters I also boot off raid1

donavan: It's a relatively simple setup: Two 250GB HDs. Two RAID1 md's: /dev/md0 (512 MB) for /boot, non-LVM and /dev/md1 as a LVM. All other filesystems, including swap, are created within that LVM.

I have 3 boxes that are raid1+lvm

donavan: Nothing too fancy, and nothing that should throw it a loop.
donavan: I agree with you that this shouldn't still be an issue. It was caught last year. But I've seen a fair share of regressions with RHL/RHEL over the years.
donavan: And I'm open to suggestions. I've reinstalled this box 5 times now.

what hardware?

Dell PowerEdge 650. Single 3.06GHz Xeon. 1GB RAM. Two 250GB IDE HDs. One dual gigabit NIC and a single 10/100 3Com NIC.
Nothing fancy.

TSWoodV: wait a week or so. 4.4 will be out relatively soon, and the -42 kernel contains LOADS of fixes.

Evolution: I hope this is one of them. However, considering this was noted and supposedly fixed last year, I'm a bit doubtful.
I think I'm going to throw Ubuntu 6.06-1 on there. Its alternative build is supposed to support LVM and RAID. Just want to see if the kernel they're using avoids the problem.

I have a huge lack of respect for dell hardware, but you may also wish to check out linux.dell.com for drivers, similar issues etc.
(Action) heads back out for another contract meeting.

Evolution: So do I, but that's what this client likes. So that's what I
Evolution: am stuck with.

2 words: client, door

donavan: 2 words: 5 year mega 6 figure deal.
donavan: Ok, so that's more than 2 words. It's also more than $2... ;-)

2 more words: your problem

donavan: LOL!
donavan: At any rate, I don't think it's the hardware. I've got 10 others just like it w/o LVM and they're going strong.

be very bizzare

donavan: They're not HPs or IBMs, but they do seem to run what we need. Oh, how I long for an all-IBM shop again...

The P7 extended the pipeline even further to over 20 stages (or 30 during cache misses), stressing clock speed over execution speed (for marketing reasons) - this led to some questionable design decisions.

Questionable indeed. Cache misses or branch prediction misses are costly. That's why the Netburst architecture was done away with when Conroe hit the streets. Frankly, the Pentium-M kicked a large part of it to the curb.
donavan: Are you the whiteboxlinux dude?

no that's some librarian, isn't it? :)

TSWoodV: I have some history with wbel, my might you ask?
I am not THE wbel dude
s/my/why

donavan: I remember the name from when I first ran WBEL, years ago.
WBEL weaned me from RHEL.

i wonder how that story unravelled

yes, I was the arse who tried to create a community around wbel -- mostly unwelcomed by THE wbel dude

That, and RH ditching RHL...
donavan: Sorry to see that didn't work out - glad to see that CentOS swept you up...

I sold my whiteboxlinux possesions for $.0001/hour invested

donavan: About $.02/year, eh?

I think that's $.20/yeah
assuming 2000 hours/year

Dysk: those are work (paid) hours

Gotta run. Just got Ubuntu alternative down. Gonna see if its kernel is any better.
Thanks for the help.

(Action) still thinks its hardware related

(Action) points out that if it's a 6 figure deal. then TSWoodV's client can surely afford a PNAELV system with proper support

morning guys

(Action) goes to ANOTHER last minute meeting about contracting before heading home

Evolution: no PFY to send ?

Evolution: do you mean to imply that the pony does not provide propper suport

Hello all!