Discuss

discuss@lists.centos.org

34753 discussions

Re: [CentOS] IP6 Anyone?
by sheraznaz＠yahoo.com 07 Mar '11

07 Mar '11

>> Always learning wrote: >> I always thought, mistakenly, IP6 was 6 segments, because it was IP6. IP4 had 4 segments. However IP6 is >actually IP version 6 and it has 8 segments. I don't think I ever heard IP6, but always IPv6. Counting segments might not be as meaningful. IPv6 has twice (8) segments compared to IPv4 however each segment is 2 octets making IPv6 address space 4 times (128 bits) compared to IPv4 (32 bits). Thanks Sheraz Sent from my Verizon Wireless BlackBerry

9 15

Re: [CentOS] CentOS and Marvell SAS/SATA drivers
by Chuck Munro 07 Mar '11

07 Mar '11

On 03/06/2011 09:00 AM, compdoc wrote: > >> >Regarding the Marvell drivers, I had good luck with the 'sata_mv' driver >> >in Scientific Linux 6 just yesterday, running a pair of 4-port PCIe-x4 >> >Tempo 'Sonnet' controller cards. > Are those the Mac/Windows Sonnet cards that go for less than $200? > > What kind of performance you seeing? Are you doing software raid on them? Yes, those are the cards which target Windows and OS-X, but they work fine on Linux as well. They use the Marvell 88SX series chips. They control 6 2TB WD Caviar Black drives, arranged as 5 drives in a RAID-6 array with one hot spare. 3 drives are connected to each of two cards. mdstat shows array re-sync speed is usually over 100 MBytes/sec although that tends to vary quite a bit over time. > ------------------------------ > On 03/06/2011 09:00 AM, John R Pierce wrote: > > On 03/05/11 7:01 AM, Eero Volotinen wrote: >> > >> > areca works.. >> > >> > > for SAS, I prefer LSI Logic. The Supermicro mobo I'm using (X8DAL-3) has an on-board LSI 1068E SAS/SATA controller chip, although I have the RAID functionality disabled so I can use it as a bunch of drives for software RAID-6. Like the Tempo cards, it has 6 2TB WD SATA drives attached which provides a second set of arrays. Performance really sucks, for some unknown reason, and I get lots of I/O error messages logged when the drives get busy. There appears to be no data corruption, just a lot of retries that slow things down significantly. The LSI web site has no info about the errors. The firmware is passing back I/O abort code 0403 and LSI Debug info related to "channel 0 id 9". There are only 8 ports so I don't know which disk drive may or may not be causing problems. The SMART data on all disks shows no issues, although I tend to treat some SMART data with scepticism. I need to track this error down because my understanding is that the LSI controller chip has very good performance. Chuck

3 3

kernel NETDEV WATCHDOG: eth0: transmit timed out
by sync 07 Mar '11

07 Mar '11

Hi , all : Sometimes my server network connection on Linux goes down with short message in syslog saying: "[localhost kernel] NETDEV WATCHDOG: eth0: transmit timed out" (or similar). By the way , I installed the CentOS 5.4 x86_64 bit and the kernel version was 2.6.18-164. Has anyone experienced this problem or is it the bug of the kernel ? I restart the network and that problem have resolved just now.

5 5

Gnu Screen - terminal issues
by Sean Carolan 07 Mar '11

07 Mar '11

I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I type or paste a really long command, and then go back and try to edit it; the text starts to wrap over itself and you have no idea what you are editing. Any fixes for this?

9 33

Updating hardware clock from cron
by Kenneth Porter 06 Mar '11

06 Mar '11

Is there a package to do this? Normally the hardware clock is set during shutdown if one is running ntpd. But if a long-running server shuts down unexpectedly, this isn't done, and the hardware clock might be off by a lot when it comes back up. So setting it periodically from a cron job could be useful. What do others do? Adding a one liner to /etc/cron.daily that invokes /etc/rc.d/init.d/ntpd would do it but it seems heavyweight to restart ntpd. Alas, the script doesn't export just the sync_hwclock function.

5 5

Problem burning dvd's
by Jimmy Bradley 06 Mar '11

06 Mar '11

I have a question on burning dvd iso's, using k3b. I have a sony dvd rw, and I've burned cd's with now problem, including iso's. The problem I'm having is, when I burn a dvd iso, k3b says it's a success, but then when I re-insert the disk, the drive tries to read the disk, but the read/write light just stays on, and the drive can't access the disk. Am I leaving a step out, or something? I burn cd iso's all the time. Thanks Jim

1 0

[Fwd: Re: Centos 6 - What are you looking forward to?]
by James B. Byrne 05 Mar '11

05 Mar '11

On Fri, March 4, 2011 14:12, aurfalien(a)gmail.com wrote: > On Mar 4, 2011, at 11:07 AM, Kenneth Porter wrote: > >> --On Thursday, March 03, 2011 10:11 AM -0500 Digimer >> <linux(a)alteeve.com >> > >> wrote: >> >>> How about the rest of you? What are you looking forward to in >>> CentOS 6 when it is released? >> >> A new Ruby > > +1 I solved this problem on my 5.5 servers in the following manner: login: not_as_root_user . . . $ # Add rpmforge repos to yum per: $ # http://wiki.centos.org/AdditionalResources/Repositories/RPMForge $ sudo yum install checkinstall $ wget ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.7-p334.tar.gz $ # to get latest or most desired source change version as required $ tar -xzf ruby-1.8.7-p334.tar.gz $ # expand source archives in /tmp $ cd ruby-1.8.7-p334 $ # change to source directory $ ./configure $ # configure makefile for this host $ make $ # build the Ruby VM $ checkinstall $ # package ruby VM and suppport files as an RPM package $ sudo yum localinstall \ /usr/src/redhat/RPMS/i386/ruby-1.8.7-p334-1.i386.rpm \ --nogpgcheck $ # install the rpm package from the checkinstall location -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

1 0

Will CentOS become obsolete now because of the changes Red Hat is implementing?
by Rudi Ahlers 05 Mar '11

05 Mar '11

This post appeared on another forum: Will CentOS become obsolete now because of the changes Red Hat is implementing? Red Hat has changed the way it distributes Enterprise Linux kernel code in an effort to prevent Oracle and Novell from stealing its customers, making it more difficult for these competitors to understand which patches have been applied where. Some have speculated that the change is designed to make it harder for Oracle as well as the open source CentOS project to build their own Linux distributions. But Stevens says this is not the case. He says the change is meant to hamper Oracle and Novell's ability to offer support to customers who are already running Red Hat Enterprise Linux (RHEL). "We made the change, quite honestly, because we are absolutely making a set of steps that make it more difficult for competitors that wish to provide support services on top of Red Hat Enterprise Linux," Red Hat chief technology officer Brian Stevens tells The Register, before naming those competitors. "Today, there are two competitors that I'm aware of that go to our customers directly, offering to support RHEL directly for them...Oracle and Novell." In essence, Red Hat is trying to hide information from these competitors that is essential to providing support for RHEL specifically. "What we're trying to impede is competitors that come to customers who are already running RHEL under subscription from Red Hat and saying 'Don't pay Red Hat anymore, pay us, and don't make any changes to your systems'," Stevens says. He insists that the change does not violate either the letter or the spirit of RHEL's GPL open source license. "We were very careful that what we've done does not impede what our customers need to accomplish or what the community needs to accomplish." And he says that the change would not really hamper the development of other Linux distros, including CentOS. "We haven't at all restricted CentOS's ability to grab source code and recompile it and clean-out trademarks and package it. It's just some of the knowledge of the insides that we're hiding," he explains. One longtime CentOS developer agrees. "I'll not lose sleep on the matter," CentOS co-founder Russ Herold tells The Reg. In November, with the release of Red Hat Enterprise Linux 6, the company released its kernel package with all patches pre-applied. "In the past, we distributed the kernel as a base file and then a set of add-on patches that accompany it. Then when you did a build, the build process automatically applied all those patches to the kernel file," Stevens says. "Now, we integrate those patch files directly into that kernel. We do the first part of the build process prior to distribution." This was recently noticed by kernel-community member and LWN editor Jonathan Corbet, who took issue with the change, calling Red Hat's package "obfuscated" kernel source code. "Distribution in this form should satisfy the GPL, but it makes life hard for anybody else wanting to see what has been done with this kernel," Corbet wrote. "Hopefully it is simply a mistake which will be corrected soon." Others speculated that the move would undermine not only Oracle's Unbreakable Linux, but also CentOS. Both are based on RHEL. CentOS is meant to be a RHEL clone. Whereas the compiled bits of Red Hat Enterprise Linux are only available under a Red Hat paid subscription, CentOS is completely free. "The changes will make work harder for distributions such as CentOS, the community-built Linux distribution ... based on Red Hat's sources," H Online said. "CentOS is built from the RHEL source by a limited number of volunteers and Red Hat's change in policy will mean more work for them unless more volunteers or other companies step in and provide them with assistance." We heard similar noises from an experienced Linux kernel developer. He said that Red Hat's change was like shuffling all the cards in an old fashioned Dewey Decimal library file system – the card you want is still there, but finding it is no easy task – and that this would cause problems for CentOS, which is an economic threat to Red Hat. But CentOS founder Russ Herold insists the change is not a big issue. "Private local trial builds of the released RHEL 6 sources by me and others have proceeded with no major problems. I just do not see that the changes as some earth-shattering change. I just think [the patches will be] incrementally more difficult to figure out," he says. "Nothing in Red Hat's new approach prevents a person from running a local version-control system, containing the pristine kernel at point A, and the Red Hat variant which we might call point B. Then one runs a 'diff' in that version-control system between A and B, and starts reading the diffs to see what is happening. Over time, both the pristine kernel, and the patched Red Hat versions will vary, and one will get a sense for which 'diff' parts matter, and which are cosmetic cleanups." Other distros will not be affected, Red Hat's Stevens says, because the company distributes its kernel changes upstream as well. "The work that we've done should not impede companies from building their own versions of Linux and supporting those for their customers," he says. "All the code we deliver through RHEL is out there. In most cases, the changes that go into RHEL. We already distribute into the upstream kernel. We have an upstream-first policy, where we're developing openly and then later integrating into our tree and then delivering it. So it shouldn't at all impede the community or anybody that's in the business of competing on that." Red Hat, he reiterates, is trying to keep RHEL-specific knowledge away from Oracle and Novell. With past RHEL kernel-code distributions, the patches mapped to articles in Red Hat's knowledge base. "It makes competitors do heavy lifting," he says. "If you want to support RHEL, remove the trademarks, and do some heavy lifting. If nothing else, it causes competitors to have to invest." This won't hamper CentOS, he says, because CentOS isn't in the support business. "The code is still available. It's just more difficult to support the distro as a commercial entity. CentOS is not in the support business." Oracle and Novell are in the support business. And whatever collateral damage was caused by Red Hat's change in policy, one thing is for sure. On some level, it will indeed be more difficult for Oracle and Novell to pilfer the company's customers. Full story here : http://www.channelregister.co.uk/201...ode_packaging/ Can any of the CentOS team please comment on this? P.S. I don't want to put extra pressure on you guys seeing as the recent conversations about Centos 5.6 & CentOS 6 have done enough damage already, but it would be interesting to know what the future of CentOS is like with RedHat's change -- Kind Regards Rudi Ahlers SoftDux Website: http://www.SoftDux.com Technical Blog: http://Blog.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532

9 9

Re: [CentOS] CentOS and Marvell SAS/SATA drivers
by Chuck Munro 05 Mar '11

05 Mar '11

On 03/04/2011 09:00 AM, Les Mikesell wrote: > > On 3/3/11 6:52 PM, Chuck Munro wrote: >> > >> > I've been on a real roller coaster ride getting a large virtual host up >> > and running. One troublesome thing I've discovered (the hard way) is >> > that the drivers for Marvell SAS/SATA chips still have a few problems. >> > >> > After Googling around quite a bit, I see a significant number of others >> > have had similar issues, especially evident in the Ubuntu forums but >> > also for a few RHEL/CentOS users. >> > >> > I have found that under heavy load (in my case, simply doing the initial >> > sync of large RAID-6 arrays) the current 0.8 driver can wander off into >> > the weeds after a while, less so for the older 0.5 driver in CentOS-5. >> > It would appear that some sort of bug has been introduced into the newer >> > driver. >> > >> > I've had to replace the Marvell-based controllers with LSI, which seem >> > rock solid. I'm rather disappointed that I've wasted good money on >> > several Marvell-based controller cards (2 SAS/SATA and 2 SATA). > > I replaced separate SII and promise controllers with a single 8-port Marvell > based card and thought it was a big improvement. No problems with centos5.x, > mostly running RAID1 pairs, one of which is frequently hot-swapped and > re-synced. I hope its not going to have problems when I upgrade. > Since I have the luxury of time to evaluate options, I've just downloaded Scientific Linux 6 to see what happens with either the mvsas or sata-mv driver. This is my first experience with SL but I wanted native ext4 rather than the preview version in CentOS-Plus. Even if I stick with SL-6 as the KVM host, I'll continue using CentOS as guest machines. If the Marvell drivers don't pan out, it looks like I'll have to either spend money on a 3Ware|LSI|Promise controller or revert to CentOS-Plus 5.5 for ext4. SL-6 is installing as I write this. Chuck

5 4

Re: [CentOS] CentOS and Marvell SAS/SATA drivers
by Chuck Munro 05 Mar '11

05 Mar '11

On 03/05/2011 09:00 AM, Nico Kadel-Garcia wrote: > > On Fri, Mar 4, 2011 at 4:16 PM, compdoc<compdoc(a)hotrodpc.com> wrote: >>> >>If the Marvell drivers don't pan out, it looks like I'll have >>> >>to either spend money on a 3Ware|LSI|Promise controller >> > >> > The 3ware are excellent... > And Promise, historically, is*not*. > > Yes, I've had problems with Promise cards in the past, but haven't bought any for a long time. They seem to be moving upscale these days. Regarding the Marvell drivers, I had good luck with the 'sata_mv' driver in Scientific Linux 6 just yesterday, running a pair of 4-port PCIe-x4 Tempo 'Sonnet' controller cards. So it appears someone has fixed that particular driver. I've decided to stick with those cards rather than re-install the Supermicro/Marvell SAS/SATA 8-port controllers, which use the 'mvsas' driver that I had problems with on the RHEL-6 evaluation distro. So far, SL-6 has performed very well, all RAID-6 arrays re-synced properly, and running concurrent forced fscks on eight arrays was very fast (because the ext4 filesystems were still empty :-) ). I think I'll stick with SL-6 as the VM host OS, but will use CentOS for the guest VMs. CentOS-5.x will do fine for now, and I'll have the luxury of upgrading guest OSs to CentOS-6 as the opportunity arises. Chuck

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss