Re: Is there a kernel update for SL 6.2 coming up soon?
On 24/01/13 08:08, jdow wrote: On 2013/01/23 23:55, Phil Perry wrote: Here is the announcement I made back in November that the 310.xx series nvidia drivers were dropping support for older 6xxx and 7xxx based hardware: http://lists.elrepo.org/pipermail/elrepo/2012-November/001525.html And how was I to know that and how was I to prevent 310 being placed on a no longer supported brand new system? It's rather a bummer you know. Did you read the release notes for the new driver? That's how I found out. Did you read my discussion thread on the issue? That's how other elrepo users found out and suggested the solution. I really don't know what you expect me to say. We have set up an email list to communicate with our users and we use it. We use our IRC channel too. Many thousands of people use the software we package. Only a very small percentage subscribe to the lists. There will be many people in exactly the same position as you. I guess when things break for them they will come looking for answers as you did, and we do our best to provide them. In this case we knew of the issue, we had documented the issue and we had a solution prepared and waiting for you. I'm really not sure what more you expect me to do for you, for free in my own volunteered time? I'm really sorry if you feel it's a bummer. As I said before, if you subscribe to the elrepo mailing list (or even hang out in #elrepo on IRC) we *will* highlight important issues that affect the software that we release as we did above in a discussion thread that ran for 2 months. No, this is the nvidia driver telling you that your hardware is no longer supported. It even tells you that you need the NVIDIA 304.xx Legacy drivers. That's not obvious. And I feel I have a rather perfect right to presume the board should be supported. It is a brand new machine as of May last year. That's correct - you need to stay at the 304.xx driver as this is the *last* driver that will support your older hardware (7xxx based chipset). We released the legacy kmod-nvidia-304xx and nvidia-x11-drv-304xx packages to aid in this (see the thread linked above) and pushed them out to the main repo *before* we released the updated 310.xx series drivers. Please uninstall the kmod-nvidia driver and install the kmod-nvidia-304xx and then you can continue to receive updates from elrepo. I've just tried to downgrade and see what happens. Nothing screwed up, nvidia simply decided it was time to move on from supporting aging hardware (~8 years old?) in the current driver release. Nvidia screwed up. The hardware was brand new about 8 months ago. So I feel I have a perfect right to be annoyed. You'd need to take that up with nvidia, or maybe even your hardware vendor why they are using old chipsets. Now, how do I stop new stuff from coming in? If there is a change in what is supported then it behooves somebody to provide an automated test to make sure the systems keep running by not downloading updates that do not fit the particular system. After all lspci exists, reports this line 00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 7025 / nForce 630a] (rev a2), and the install could be aborted when that is found and the administrator notified. Yes, we had that discussion and if we knew of a way to technically implement that we would have seriously considered it. Please, if you can suggest a mechanism for an RPM package to know what hardware is present *before* it installs itself, and then prevent itself from installing if the correct hardware isn't present, and do all this from within a yum transaction, them I'm all ears. You can run such tests in %pre or %post scripts but by then the yum transaction is already underway and the package is set to be installed or is already installed. At which point the best you can do is log the issue to warn the user, which is *exactly* what the nvidia driver does - even then you didn't understand what the log entry was telling you. We didn't see any need to replicate that. If you are using an installer script then it's doable, but then you also lose all the advancements and convenience of a package manager with automatic updates, not to mention kABI-tracking RPM packaged drivers that survive kernel updates. Nvidia uses an installer script - feel free to use that if it better suits your requirements. Anyway, this isn't an SL issue so lets please not clutter the SL list any further. I'm happy to continue the discussion on the elrepo lists or on IRC. Regards, Phil
Re: Is there a kernel update for SL 6.2 coming up soon?
On 24/01/13 09:37, jdow wrote: Agreed. I figure I'll drop it. Please drop me a brief note directly how to prevent simply automatically downloading 310 again. yum erase kmod-nvidia nvidia-x11-drv yum install kmod-nvidia-304xx nvidia-x11-drv-304xx and reboot your system. Then you will stay on the legacy 304.xx release and only get updates to the legacy driver.
Re: Is there a kernel update for SL 6.2 coming up soon?
On 24/01/13 06:04, jdow wrote: On 2013/01/23 20:33, Akemi Yagi wrote: On Wed, Jan 23, 2013 at 8:04 PM, jdow j...@earthlink.net wrote: On 2013/01/23 19:27, Alan Bartlett wrote: I fail to see the significance -- or relevance -- of your last sentence. Please remember this is the main support channel for Scientific Linux. Alan. It's not this channel's support issue. I understand that. This is why I wondered if 6.2 was going to have a kernel update. ElRepo pushed the newer 310 NVidia modules before any appropriate kernel appeared on SL2. So I have to back off. I simply wondered if waiting for a new kernel was practical or not. And that's been answered. ElRepo messed up pushing updates. (Or else there should be a more recent kernel for 6.2 than what I am running, 2.6.32-279.19.1.el6.x86_64.) Not true. Let me post once again the link I provided for you earlier in this thread. I'm afraid you missed it. http://elrepo.org/tiki/kmod-nvidia-304xx That page has a list of supported GPUs. This is all about the hardware you have and the version of Nvidia's driver that supports it. Which kernel version is _not_ relevant. You may also want to check out this post on the ELRepo's mailing list: http://lists.elrepo.org/pipermail/elrepo/2013-January/001587.html I quoted an essential part of it in my earlier post as well. I strongly suggest you subscribe to the ELRepo general mailing list. If you still have questions about the Nvidia-related packages offered by ELRepo, please ask on the ELRepo's list. With all due respect, Akemi, I'd like you to note two details. With all due respect you are not listening to what people are telling you. Akemi is right and you are wrong. First the message you point to is for version 304. ElRepo pushed 310. Before that program load I was up to date with nVidia as well as kernel. I'm not sure if I had 304 or earlier. Given the date, that is the version I had loaded as of yesterday when 310 replaced it. Here is the announcement I made back in November that the 310.xx series nvidia drivers were dropping support for older 6xxx and 7xxx based hardware: http://lists.elrepo.org/pipermail/elrepo/2012-November/001525.html We've been planning this migration for 2 months. May I suggest that if you are going to use elrepo packages then you subscribe to the elrepo mailing list where you will find out such important information first hand. It really is very low volume. Second I get this message in the dmesg log from a reboot this morning. ===8--- nvidia: module license 'NVIDIA' taints kernel. Disabling lock debugging due to kernel taint NVRM: The NVIDIA GeForce 7025 / nForce 630a GPU installed in this system is NVRM: supported through the NVIDIA 304.xx Legacy drivers. Please NVRM: visit http://www.nvidia.com/object/unix.html for more NVRM: information. The 310.32 NVIDIA driver will ignore NVRM: this GPU. Continuing probe... NVRM: No NVIDIA graphics adapter found! ===8--- Apparently the kernel or something does NOT supported with 310. So pushing the 310 was apparently an error of overoptimism for this system. I'd have expected the RPM to take this into account. But this is an ElRepo issue not one from here. So I've tried to be brief. I see I had to give up that effort. No, this is the nvidia driver telling you that your hardware is no longer supported. It even tells you that you need the NVIDIA 304.xx Legacy drivers. The elrepo-packaged nvidia driver currently supports all kernels from SL6.1 through SL6.3. That said it appears I have to go back to 304 and turn off elrepo updates, which is moderately inconvenient. The Nvidia 7025 is embedded on the motherboard that is less than a year old. So I figure SOMETHING screwed up if it's no longer supported. That's correct - you need to stay at the 304.xx driver as this is the *last* driver that will support your older hardware (7xxx based chipset). We released the legacy kmod-nvidia-304xx and nvidia-x11-drv-304xx packages to aid in this (see the thread linked above) and pushed them out to the main repo *before* we released the updated 310.xx series drivers. Please uninstall the kmod-nvidia driver and install the kmod-nvidia-304xx and then you can continue to receive updates from elrepo. Nothing screwed up, nvidia simply decided it was time to move on from supporting aging hardware (~8 years old?) in the current driver release. Regards, Phil
Re: Figured out my flash-plugin problem
On 02/01/13 19:06, Todd And Margo Chester wrote: On 12/29/2012 11:15 PM, Dr Andrew C Aitchison wrote: On Thu, 27 Dec 2012, Todd And Margo Chester wrote: Hi All, Figured out my flash-plugin problem: If you are using flash-plugin higher than 11.1.102.63 and you are getting reversed colors and artifacts in Firefox, open a flash video right click in the video while it is playing, go to settings, Display (tab), unclick Enable hardware acceleration Which graphics card (and driver) do you have ? EVGA 01G-P3-1370-TR GeForce GTX 460 Graphics Card - PCI Express 2.0 x16 - 1 GB GDDR5 SDRAM $ rpm -qa \*nvidia\* nvidia-x11-drv-295.20-1.el6.elrepo.x86_64 nvidia-x11-drv-32bit-295.20-1.el6.elrepo.x86_64 kmod-nvidia-295.20-1.el6.elrepo.x86_64 Your drivers are quite outdated (the current release is 310.19). At least two security issues have been fixed in subsequent releases: Fixed in 295.71 http://permalink.gmane.org/gmane.comp.security.full-disclosure/86747 Fixed in 295.40 CVE-2012-0946 http://nvidia.custhelp.com/app/answers/detail/a_id/3109/~/security-vulnerability-cve-2012-0946-in-the-nvidia-unix-driver Not to mention numerous bug fixes including a few affecting issues with flash. Any reason yum isn't automatically updating these for you?
Re: Crash in tg3 driver on SL6.3 when interface goes down
On 29/12/12 21:21, Vladimir Mosgalin wrote: Hi Phil Perry! On 2012.12.27 at 13:59:49 +, Phil Perry wrote next: Elrepo has an updated kmod package for the tg3 driver you could try. With elrepo installed; yum install kmod-tg3 and reboot. If it doesn't fix the issue, try giving the elrepo folks a ping to see if there is a more recent version you could try that might fix the issue. Thanks for advice! I completely missed the fact that version is newer because I saw same 3.122 number; actually in-kernel is version 3.122 and elrepo has 3.122n, and this n makes a lot of difference. I tried it, according to changelog it includes fix --- tg3: Fix tg3_get_stats64 for 5700 / 5701 devs tg3_get_stats64() takes tp-lock when dealing with non-serdes bcm5700 and bcm5701 devices. However, functions that call tg3_halt() have already acquired tp-lock. When tg3_get_stats64() is called in tg3_halt(), deadlock will occur. --- which exactly resolves my problem. This fix is dated Feb 28, sad that Red Hat maintainers have missed it in their version :( But at least I have the solution now. Glad it fixed your issue. That's exactly why elrepo exists - to roll out updates quicker than Red Hat is able to do, for understandable reasons. Hopefully Red Hat will get the driver updated in the next update release. In the meantime, perhaps you could file a bug report upstream with Red Hat and mention the issue is fixed in the latest driver version.
Re: Crash in tg3 driver on SL6.3 when interface goes down
On 26/12/12 19:21, Vladimir Mosgalin wrote: Hello everybody. For a few months I've been experiencing this problem - it was a bit hard to track because it usually happens only during shutdown, when network interfaces go down, so I just didn't notice it. A kernel panic happens when one of the interfaces, provided by tg3 driver goes down. ifdown eth2 is enough to cause it. It doesn't matter if this interface was actively used or even if the link was up - I can unplug the cable, boot up (interface is configured to use dhcp, it will attempt to go up and fail), then execute ifdown eth2 and system will crash. It's a bit hard to get the full message of the crash as this happens on the machine which I use for remote logging itself.. The best thing I can get right away are screenshots, however, some of information might be missing on them. It goes like this on shutdown (or ifdown eth2, or service network restart etc): 1) interfaces are being brought down, at some point eth2 is being brought down 2) nothing happens for about 10 seconds, system appears to be hang 3) lots of lines with call traces appear and scroll through the screen. These are last lines which I captured in screenshot: http://img202.imageshack.us/img202/5459/20121225205828.png 4) about 10 second pause again 5) kernel panic happens, more lines scroll. Again, here are some of the last ones: http://img5.imageshack.us/img5/397/20121225205838.png 6) system hangs completely This happens on latest kernel-2.6.32-279.19.1.el6.x86_64. It also happened on 2.6.32-279.11.1.el6.x86_64 and 2.6.32-279.14.1.el6.x86_64. It didn't happen in SL6.2 with (official, not from elrepo) kmod-tg3-3.122 package installed which was present in 6.2-fastbugs repository. I found some information about tg3 crashes like this http://elrepo.org/bugs/view.php?id=315 or this http://bugs.centos.org/view.php?id=5428 but in either case 3.122 version of tg3 driver solved the problem. However, I'm already using 3.122 and still experience crash. The controller in question is Broadcom NetXtreme BCM5701, PCI-X version which is inserted into PCI-X slot of Supermicro X7SBE. There haven't been any hardware changes lately and it is working stable. I'm pretty sure that this bug has appeared somewhere along the 6.2-6.3 upgrade or in one of the 6.3 kernels. It's a bit hard to track because it appears simply as hang during reboot or shutdown, which rarely happens for this system, but I'm sure that few months ago it rebooted and powered off just fine. This is interface used for internet connection. VLANs are not used. There exists sixxs-based IPv6 interface in system, configured to work over this interface. This problem doesn't happen with other (intel e1000e) network interfaces. $ cat /etc/sysconfig/network-scripts/ifcfg-eth2 DEVICE=eth2 BOOTPROTO=dhcp ONBOOT=yes TYPE=Ethernet HWADDR=00:02:A5:E7:0A:10 PEERDNS=no NOZEROCONF=yes $ ifconfig eth2 eth2 Link encap:Ethernet HWaddr 00:02:A5:E7:0A:10 inet addr:skipped... inet6 addr: fe80::202:a5ff:fee7:a10/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:130906804 errors:0 dropped:0 overruns:0 frame:0 TX packets:178575110 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:83971053482 (78.2 GiB) TX bytes:205754543966 (191.6 GiB) Interrupt:52 $ dmesg|grep '\(eth2\|tg3\)' tg3.c:v3.122 (December 7, 2011) tg3 :03:02.0: PCI INT A - GSI 52 (level, low) - IRQ 52 tg3 :03:02.0: eth2: Tigon3 [partno(253212-001) rev 0105] (PCIX:133MHz:64-bit) MAC address 00:02:a5:e7:0a:10 tg3 :03:02.0: eth2: attached PHY is 5701 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) tg3 :03:02.0: eth2: RXcsums[0] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[0] tg3 :03:02.0: eth2: dma_rwctrl[76db000f] dma_mask[64-bit] ADDRCONF(NETDEV_UP): eth2: link is not ready tg3 :03:02.0: eth2: Link is up at 100 Mbps, full duplex tg3 :03:02.0: eth2: Flow control is on for TX and on for RX ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Does anyone know some solution or workaround? I'm fine with installing other version of this driver from kmod (if I knew where to get better version), but not very comfortable with using kernel-3.5/3.6/3.7 etc from elrepo. Elrepo has an updated kmod package for the tg3 driver you could try. With elrepo installed; yum install kmod-tg3 and reboot. If it doesn't fix the issue, try giving the elrepo folks a ping to see if there is a more recent version you could try that might fix the issue. Hope that helps.
Re: WiFi driver broken w/update
On 22/08/12 07:24, Akemi Yagi wrote: Sorry I meant this link: http://lists.elrepo.org/pipermail/elrepo/2012-August/001359.html But expect the updated version of kmod-compat-wireless to be out real soon now. :) Akemi Just released: http://lists.elrepo.org/pipermail/elrepo/2012-August/001390.html For those not familiar with the compat-wireless project, they backport the wireless branch from the latest stable kernel. They actually backport a few other bits and pieces too like a few ethernet drivers and some bluetooth bits, and they are in the process of renaming their project to compat-drivers to better reflect that it's not just wireless but I'm going off topic now :-) Anyway, elrepo packages the compat-wireless project as a kmod for el6.3. The latest version is based on the stable 3.5.1 kernel so backports the complete wireless stack from that kernel. If your wireless device isn't natively supported on SL out of the box then this might be a quick and easy method to see if it's supported by the latest upstream kernel drivers. If anyone has wireless issues on 6.3 and would like to test this then we'd really appreciate the feedback (preferably on the elrepo list). Thanks.
Re: Error with 'irq_set_affinity_hint' while compiling compat-wireless
On 10/07/12 14:17, Mark Stodola wrote:
On 07/10/2012 07:59 AM, Freak Trick wrote:
I have Atheros Ethernet (On Board) which is not detected by the SL 6.2
(Updated).
Ethernet Details:
[root@localhost compat-wireless-2012-03-12-p]# lspci | grep Ethernet
02:00.0 Ethernet controller: Atheros Communications Inc. AR8151 v2.0
Gigabit Ethernet (rev c0)
After looking up various internet resources, I came across:
http://www.linuxfoundation.org/collaborate/workgroups/networking/alx
The site has the required drivers. I am going as per the instructions
mentioned to compile and install the drivers, however I get the
following error:
[root@localhost compat-wireless-2012-03-12-p]# make
make -C /lib/modules/2.6.32-220.23.1.el6.i686/build
M=/home/sunhost/Downloads/compat-wireless-2012-03-12-p modules
make[1]: Entering directory `/usr/src/kernels/2.6.32-220.23.1.el6.i686'
CC [M] /home/sunhost/Downloads/compat-wireless-2012-03-12-p/compat/main.o
In file included from
/home/sunhost/Downloads/compat-wireless-2012-03-12-p/include/linux/compat-2.6.h:55,
from command-line:0:
/home/sunhost/Downloads/compat-wireless-2012-03-12-p/include/linux/compat-2.6.35.h:27:
error: static declaration of ‘irq_set_affinity_hint’ follows non-static
declaration
include/linux/interrupt.h:218: note: previous declaration of
‘irq_set_affinity_hint’ was here
make[3]: ***
[/home/sunhost/Downloads/compat-wireless-2012-03-12-p/compat/main.o]
Error 1
make[2]: ***
[/home/sunhost/Downloads/compat-wireless-2012-03-12-p/compat] Error 2
make[1]: ***
[_module_/home/sunhost/Downloads/compat-wireless-2012-03-12-p] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.32-220.23.1.el6.i686'
make: *** [modules] Error 2
I would be thankful for any help provided in resolving the issue.
Thanks!
You might want to try the various atl drivers from ELrepo (elrepo.org).
They maintain current drivers for a lot of devices not generally
supported by TUV. I think you'll want kmod-atl2. If you find that none
of the ELrepo drivers work, it might be worth contacting them to get the
correct one built and added to the repository.
-Mark
I think the atl1c driver in kmod-compat-wireless might also support that
device, but first we really need to see the vendor:device ID pairing to
be able to advise further.
Please post the output from the following command (note this is on one
line):
for BUSID in $(/sbin/lspci | awk '{ IGNORECASE=1 } /net/ { print $1 }');
do /sbin/lspci -s $BUSID -m; /sbin/lspci -s $BUSID -n; done
Re: Error with 'irq_set_affinity_hint' while compiling compat-wireless
On 10/07/12 15:40, Freak Trick wrote: Hi Phil, As I noted in my earlier mail, the problem was resolved by installing atl1e driver from elrepo. Also, before that I had already tried with atl1c but it did not work. Great, if that driver works then that is definitely the preferred driver for you and you can disregard my earlier suggestion :-) Just in case if you do require (for curiosity or better solution) here is the output from the command offered by yourself: 02:00.0 Ethernet controller Atheros Communications Inc. AR8151 v2.0 Gigabit Ethernet -rc0 Giga-byte Technology Device e000 03:01.0 Network controller Ralink corp. RT2500 Wireless 802.11bg -r01 Linksys WMP54G 2.0 PCI Adapter Thanks for your reply!
Re: For the RPMForge guys
On 28/06/12 05:52, jdow wrote:
On 2012/06/27 13:58, S.Tindall wrote:
On Wed, 2012-06-27 at 13:12 -0700, jdow wrote:
On 2012/06/27 12:43, S.Tindall wrote:
On Wed, 2012-06-27 at 12:31 -0700, jdow wrote:
Latest clamav update main.cvd is an empty file. It apparently
should not be
empty. For two days now I've gotten this message:
ERROR: Corrupted database file /var/clamav/main.cld: Broken or not
a CVD file
{^_^}
Run freshclam and then restart clamd.
Steve
rerunning freshclam gives:
ClamAV update process started at Wed Jun 27 13:11:13 2012
main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60,
builder: sven)
daily.cld is up to date (version: 15092, sigs: 222617, f-level: 63,
builder:
ccordes)
bytecode.cld is up to date (version: 185, sigs: 39, f-level: 63,
builder: neo)
WARNING: [LibClamAV] cli_cvdverify: Can't read CVD header
ERROR: Corrupted database file /var/clamav/main.cld: Broken or not a
CVD file
Corrupted database file renamed to /var/clamav/main.cld.broken
Trying again in 5 secs...
ClamAV update process started at Wed Jun 27 13:11:19 2012
main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60,
builder: sven)
daily.cld is up to date (version: 15092, sigs: 222617, f-level: 63,
builder:
ccordes)
bytecode.cld is up to date (version: 185, sigs: 39, f-level: 63,
builder: neo)
It's broken, Jim! (Sorry Star Trek)
{^_^}
You fixed it with freshclam. As per the final section, main.cvd,
daily.cld and bytecode.cld are now up to date.
If /var/clamav/*broken bothers you, then delete it/them.
# rm /var/clamav/*broken
# ls /var/clamav/
bytecode.cld daily.cld main.cvd mirrors.dat
At least on my EL6 systems, those satisfy clamd.
# service clamd restart
Stopping Clam AntiVirus Daemon: [ OK ]
Starting Clam AntiVirus Daemon: [ OK ]
Steve
Then main.cld is a surplus file now? I didn't know that!
{^_^}
There seems to be two formats for the database files, .cld and .cvd.
It doesn't seem to matter which you have, so just delete one or the
other. IIRC having both causes some log file noise.
On my system I have:
$ ls /var/clamav/
bytecode.cld daily.cld main.cld mirrors.dat
and after each update to clamav from rpmforge I manually remove the
*.cvd files in stalled from clamav-db:
rm /var/clamav/*.cvd
and restart the clamd service.
I guess the real questions here are why there are two formats, which is
preferable and why, and can we get the packaged version to deliver only
the preferred format.
To date it's not bothered me enough to go looking for the answers to
those questions so long as my workaround above seems to work :-)
Anyway, this discussion would all be better placed on the rpmforge
mailing lists rather than here as it's not an SL issue.
Re: Lenovo L2440p resolution detected incorrect on SL6 with Intel graphics
On 16/03/12 18:43, James M Pulver wrote: We've got some basic E30 model 782449U connected to the Lenovo L2440p model 4420-HB2 monitor where the maximum selectable resolution in SL6 seems to be 1920x1080. These monitors are native 1920x1200 - so everything looks stretched. There isn't an X.conf from what I can tell, so is this a bug or is there a workaround I don't know to get this set to the full resolution? Hi James, Correct, there is no xorg.conf by default in SL6 any more as things are now auto-detected (which is fine when it works). However, if you make one then it should be honoured, so I'd suggest making a very basic xorg.conf and manually setting the resolution to see if that works. No idea if there's a more correct way to fix this but that solution has worked for me. Regards, Phil
Re: serious bug in boot sequence when fsck is required
On 30/01/12 22:39, Yasha Karant wrote: We had a massive power failure, beyond what the UPS could handle. Despite attempts to find a way for the system to shut down gracefully, it simply powered down without unmounting the disk partitions. Nominally, the backup local UPS I am using (APC Back-UPS 650) has an interface Port DB-9 RS-232 but I have not found any Linux application that reliably would communicate with this model of UPS (that is, emulate the same behavior as the application available from APC for MS Win that senses the RS-232 information from APC, waits the appropriate time, and then shutdown -- anyone found one?). apcupsd, available from rpmforge? Works fine on my ancient APC Back-UPS Pro device using the supplied 940-0024C cable. You do need the right cable though, and must configure it accordingly. Check your cable type and UPS compatibility here: http://www.apcupsd.org/manual/manual.html#supported-upses-and-cables
Re: SL 5.5 machines crash when using ATI proprietary driver
On 13/10/11 16:51, Steven Leikeim wrote: On Tue, Oct 11, 2011 at 09:38:31AM -0600, Alex Finch wrote: We have a number of SL 5.5 machines with ATI graphics cards. We have discovered that they freeze when using the ati proprietary driver (fglrx). I am guessing this is since the recent xorg-x11-server update on 7th October. They had worked fine previously, and they work ok if I revert to a default xorg.conf. Does anyone else see this problem, or even better, have a solution? Alex Finch We had the same problem here (with SL 5.6) on some lab machines where we have to use the ATI proprietary driver. As I was away on Friday when this showed up, the machines were rebuilt resulting in working machines (but with mediocre performance). Re-installing our local custom RPM for the fglrx driver was successful with no changes required. I suspect that the problem arises from the fglrx driver replacing some of the system files with it's own and when these files were changed by the RPM they belong to, the fglrx driver got confused and stopped operating properly. It looks like the solution may be as simple as just re-installing the fglrx driver. Steven Leikeim That would make sense. The ATI installer overwrites some OpenGL libs with it's own libs and if the package providing those libs within the distro subsequently receives an update then it will subsequently overwrite the ATI libs thus breaking the driver. This is one of the advantages of using a properly packaged version of the driver - the ATI libs can then be safely installed to a location where they will not conflict with the distro libs and this type of situation can be avoided.
Re: need help installing nvidia driver on new laptop
On 11/09/11 18:39, Chris Pemberton wrote: Some good info over at the archlinux forums: https://bbs.archlinux.org/viewtopic.php?pid=881549 http://linux-hybrid-graphics.blogspot.com/ To test the nvidia driver: blacklist the nouveau and intel graphic modules, disable kernel mode-setting, and boot to runlevel 3 (all via the kernel command line args below). Then run nvidia's xorg creation tool (nvidia-xconfig). Give X a try and see if it works. nouveau.disable=1 intel.disable=1 nomodeset 3 --append this to grub kernel line The elrepo.org kmod-nvidia package already disables nouveau mode-setting (nouveau.modeset=0), blacklists the nouveau driver and runs nvidia-xconfig to create a suitable xorg.conf file. Perhaps in the case of these hybrid systems we also need to blacklist the Intel driver too as suggested above. Do we know which Intel driver is being loaded? Once you have worked out what works for you through testing, you should file a bug at http://elrepo.org/bugs/ and we can get these fixes incorporated into the package. If that wont work, black list nouveau and nvidia, and try the intel module (delete the xorg.conf made by nvidia-xconfig) nouveau.disable=1 nomodeset 3 -- append this to grub kernel line Hope that helps. Chris
Re: need help installing nvidia driver on new laptop
On 12/09/11 04:18, Akemi Yagi wrote: On Sun, Sep 11, 2011 at 8:00 PM, Kevin Thomasaxel2...@gmail.com wrote: You are correct that when you install the kmod-nvidia package, it automatically disables nouveau and blacklists it for you, but I didn't know there was a new nvidia xorg.conf file created. After I installed the kmod-nvidia package again, I restarted and modified the kernel arguements to include the intel.disable=1 arguement, but the result was the sameeventually the screen flickered a few times and it stopped booting, although I could still open a terminal via alt+F2. I'm not sure what to try next. Someone requested some command output from me in a different email, which I provided, but I'm lost now. I didn't think it would be this difficult. Kevin Can you somehow disable the Intel graphics (in the BIOS perhaps) and see if that helps? Just in case the intel.disable=1 argument is not working as intended... Akemi If not, perhaps try the kernel argument i915.disable=1 assuming it's the i915 driver it's trying to load?
Re: need help installing nvidia driver on new laptop
On 12/09/11 03:54, Kevin Thomas wrote: Of course. I installed kmod-nvidia, booted to run level 3, and I've pasted the output of the commands you referenced below. Thanks - everything looks in order there.
Re: need help installing nvidia driver on new laptop
On 10/09/11 06:36, Kevin Thomas wrote: Ok, I jujst got a brand new Dell XPS laptop a few days ago. I managed to install Windows 7 and SL 6.1 side by side in a dual boot setup. This laptop has the core i7 processor, which means it has integrated Intel HD 3000 graphics, but it also has a 2GB Nvidia GT540M (with optimus) discrete card as well. I know that optimus is not natively supported yet, but according to the SL forums, the generic nvidia driver can be installed instead (kmod-nvidia). The instructions said to just do yum install kmod-nvidia. This installed the drivers for me and when I rebooted, I saw the plymouth-rings splash screen for the first time ever, but the system hung. I restarted again and pushed ESC to see the messages and the screen flickered a few times and it stopped on registering binary handler for windows applications Some googling informed me that this was due to the wine service being enabled, so I disabled it and restarted. This time, it got hung on starting atd: and the screen flickered a few times. I have a feeling that if I disabled atd, it would just hang on the next service. I had to uninstall the kmod-nvidia package just to boot my system again. There has to be a way to get the nvidia driver working. Any help would be appreciated. Kevin In order to help troubleshoot, could you please provide some more information. Please install kmod-nvidia and see if you can boot to runlevel 3 and provide the following information (output from the following commands): uname -a find /lib/modules -name nvidia.ko cat /boot/grub/grub.conf Thanks.
Re: Scientific mirrors in Japan
On 26/08/11 17:55, Akemi Yagi wrote: On Fri, Aug 26, 2011 at 9:36 AM, Troy Dawsondaw...@fnal.gov wrote: On 08/26/2011 11:22 AM, Akemi Yagi wrote: [Starting a new thread] 2011/8/26 Ichihara Takashiichih...@rarfaxp.riken.go.jp: Hi, Dag, http://dag.wieers.com/blog/centos-devel-ml-feels-like-devnull We are all expecting your efforts on the Scientific Linux ! Could you please add our mirror of your repository to your mirror list? http://ftp.riken.jp/Linux/dag/ Best Regards, Takashi Ichihara Scientific Linux used to be unknown in Japan but has been gaining much attention. I find many blogs/web articles about SL written in Japanese. One of the subjects I see often is how to edit the repo file to add SL mirror sites in Japan. Connie, could you consider adding at least one site from Japan? The riken site, as requested by Mr. Ichihara is fast and being used by many users in Japan, as I understand. In relation to this, I also wish yum-plugin-mirrorlist is installed (and enabled) by default. Akemi Hi Akemi, I haven't read the article, so I cannot comment to everything, but we do have 4 mirror sites in Japan. http://www.scientificlinux.org/download/mirrors And they are in the mirrorlist http://ftp.scientificlinux.org/linux/scientific/mirrorlist/ Troy What I meant (and probably Mr. Ichihara too) was to have the mirror(s) added to the baseurl= line in the repo file (sl-release). That's what SL users in Japan are editing so that they can get to the sites within Japan. They (users in .jp) also need to manually install the fastest mirror plugin to take advantage of this. So, my wish to see this plugin installed by default. :) Akemi I have to agree, if you have a mirrorlist then it kind of makes sense to install yum-fastestmirror by default to make use of it. CentOS do this by adding yum-fastestmirror (or yum-plugin-fastestmirror on el6) as a dependency to yum. Regards, Phil PS: I should probably declare that I have a vested interest though as elrepo users without yum-fastestmirror installed hit our main server rather than using the mirror system and that's crippling access to other services hosted on that server (like the main website/wiki and bugs). If all SL users had yum-fastestmirror installed, that could significantly reduce the load we experience on our main server. As a large proportion of elrepo users are SL users, I would very much like to see yum-fastestmirror installed by default.
Re: Tesla c1060 driver installation
On 21/08/11 04:48, Jon Peatfield wrote: btw there are plenty of rpms of the nvidia drivers using dkms for the auto-kernel-module rebuilding (and probably others using kabi tracking). We use locally maintained rpms based on the DAG srpms but with some local tweaks (which might make them not ideal for others) and updated to a version of the nvidia binary blobs that we just download from nvidia whenever we feel the need for an update... Until recently we were using nvidia version 190.42, but are in the middle of updating to 280.13 at the moment - so far it seems to be fine and we plan to roll it out to the rest of our sl5 boxes next Wednesday... That said we do this mainly for X support - that these drivers also support CUDA is mostly (for us) a bonus though we do have one box with a C1060 card using it... Dag's dkms drivers have been unmaintained for some time and are deprecated in favour of the nvidia kmod packages available in elrepo. These are currently well maintained and version 280.13 has been available since it's upstream release. http://elrepo.org/ http://elrepo.org/tiki/kmod-nvidia
Re: SL site unreachable
On 14/08/11 14:25, jdow wrote:
On 11:59, Akemi Yagi wrote:
On Sat, Aug 13, 2011 at 1:51 AM, Vincent
Verhagenvinc...@zijnemail.nl wrote:
Hi all,
As I don't have access to the web site admins email addresses, a
heads up
for them via this list :)
I'm having trouble accessing the SL site
(http://www.scientificlinux.org).
I get a 500 Internal server error.
Best regards,
Vincent Verhagen
The site is still down. I'm sure the admins are receiving mail from
this list but just in case, I cc'd this to Troy and Connie.
Akemi
For the record, Akemi, this (obviously) made it to the list.
It made it into the spam folder due to hitting this rule:
URIBL_BLACKB Contains an URL listed in the URIBL blacklist
[URIs: scientificlinux.org]
Somehow I think that was somewhat erroneous of URIBL.
{^_^}
Thanks for the heads up on the URIBL listing. I have submitter status
with URIBL so have requested a delisting. I can confirm it's currently
still listed. My delisting request is pending review.
Re: SL site unreachable
On 14/08/11 15:28, Phil Perry wrote:
On 14/08/11 14:25, jdow wrote:
On 11:59, Akemi Yagi wrote:
On Sat, Aug 13, 2011 at 1:51 AM, Vincent
Verhagenvinc...@zijnemail.nl wrote:
Hi all,
As I don't have access to the web site admins email addresses, a
heads up
for them via this list :)
I'm having trouble accessing the SL site
(http://www.scientificlinux.org).
I get a 500 Internal server error.
Best regards,
Vincent Verhagen
The site is still down. I'm sure the admins are receiving mail from
this list but just in case, I cc'd this to Troy and Connie.
Akemi
For the record, Akemi, this (obviously) made it to the list.
It made it into the spam folder due to hitting this rule:
URIBL_BLACKB Contains an URL listed in the URIBL blacklist
[URIs: scientificlinux.org]
Somehow I think that was somewhat erroneous of URIBL.
{^_^}
Thanks for the heads up on the URIBL listing. I have submitter status
with URIBL so have requested a delisting. I can confirm it's currently
still listed. My delisting request is pending review.
Looks like it's fixed now, and listed on the whitelist so it won't get
blacklisted by mistake again.
BTW, the website is now back up (at least for me). I wonder if the
blacklisting at URIBL was a result of the website being down - maybe an
automated listing of a domain appearing in mail flow with no
corresponding website.
Re: Kernel update broke microphone
On 22/07/11 23:24, Phil Lembo wrote: I had the very same problem and backed out to kernel-2.6.32-71.29.1 while looking around for a solution. I found an ALSA kernel module on atrpms.net and decided to give it a try. First I updated to kernel-2.6.32-131.6.1.el6.x86_64 (I'm running 64-bit). which once again killed my mic. Then I went up to atrpms.net and grabbed alsa-kmdl-2.6.32-131.6.1.el6.x86_64-1.0.23-86.el6.x86_64 (look in http://packages.atrpms.net/dist/el6/alsa-driver-1.0.23/). After another reboot I found my mic worked again. Phil Lembo http://eldapo.lembobrothers.com Just a note that elrepo.org also has kmod packages for alsa (kmod-alsa) for both el5 and el6. These are kABI tracking packages so will work seamlessly across kernel updates meaning you won't need to update them every time you update your kernel. Hope that helps. Phil
Re: Kernel update broke microphone
You're welcome. On 23/07/11 15:14, Phil Lembo wrote: Excellent! I missed those. Actually a much better solution going forward. On Sat, Jul 23, 2011 at 5:38 AM, Phil Perryp...@pendre.co.uk wrote: On 22/07/11 23:24, Phil Lembo wrote: I had the very same problem and backed out to kernel-2.6.32-71.29.1 while looking around for a solution. I found an ALSA kernel module on atrpms.net and decided to give it a try. First I updated to kernel-2.6.32-131.6.1.el6.x86_64 (I'm running 64-bit). which once again killed my mic. Then I went up to atrpms.net and grabbed alsa-kmdl-2.6.32-131.6.1.el6.x86_64-1.0.23-86.el6.x86_64 (look in http://packages.atrpms.net/dist/el6/alsa-driver-1.0.23/). After another reboot I found my mic worked again. Phil Lembo http://eldapo.lembobrothers.com Just a note that elrepo.org also has kmod packages for alsa (kmod-alsa) for both el5 and el6. These are kABI tracking packages so will work seamlessly across kernel updates meaning you won't need to update them every time you update your kernel. Hope that helps. Phil
Re: Kernel update broke microphone
On 23/07/11 16:13, Phil Lembo wrote: Thanks Phil! I just tested both alsa kernel mods in epel-testing and found the newer one (1.0.24-1) didn't fix the problem for me (my hardware uses the even older N10/ICH7 chipset), kmod-alsa-1.0.23-1.el6.elrepo did. Given the advantages of kAPI-tracking kmods, I'll be sticking with that for now. Great. Yes, newer is not always better for some packages, especially when they provide multiple kernel modules (e.g, kmod-alsa and kmod-video4linux), hence why we like to keep a few versions available.
Re: RPM: file versions
On 15/07/11 19:54, Andrew Z wrote:
On Fri, Jul 15, 2011 at 2:42 PM, Phil Perryp...@pendre.co.uk wrote:
On 15/07/11 19:28, Andrew Z wrote:
Skip
You need to have your SPEC file create the symlinks in the buildroot so that
they are a part of the package, i.e, the symlinks are owned by the rpm
package. Then when you uninstall or update the package rpm will
remove/update the symlinks for you rather than leave them dangling as per
your example above.
Take a look in any relevant package SPEC file from the distro for examples
of how this should be handled.
Phil,
thank you. That's what i thought and i took a look @
glibc-2.3.4-2.54.src.rpm. I didn't notice any of the functionality you
mentioned, which prompted me to write the email.
another question is :
do i explicitly add the file.version to the %files section or just
mention the link ?
Thank you
Andrew
To summarize, lib_andrew-123.rpm installs the file lib_andrew.so.123
and creates a symlink to it called lib_andrew.so
Here is how I would handle it:
# make the libdir directory in the buildroot
%{__mkdir_p} %{buildroot}/path/to/libdir/
# then install the lib
%{__install} -p -m 0755 lib_andrew.so.123 %{buildroot}/path/to/libdir/
# then create the symlink(s) as necessary
%{__ln_s} lib_andrew.so.123 %{buildroot}/path/to/libdir/lib_andrew.so
You must also make sure /path/to/libdir is on the ldconfig path if you
have installed to a non-standard path - if not, add it like so:
%{__mkdir_p} %{buildroot}%{_sysconfdir}/ld.so.conf.d/
echo /path/to/libdir
%{buildroot}%{_sysconfdir}/ld.so.conf.d/lib_andrew.conf
but if you can, it's far easier to just install to /usr/lib(64)
Finally, in %post run /sbin/ldconfig
Your %files section then needs to include all of the above.
Hope that helps
Re: RPM: file versions
On 15/07/11 21:59, Mark Stodola wrote:
If I'm not mistaken, you should not need to manually link libraries.
ldconfig should be taking care of this for you, so all you would need is
the %post entry to run ldconfig with the proper flags after
install/upgrade/removal. Assuming it ends up in a standard path,
otherwise the ld.so.conf entries are needed as well.
-Mark
Correct. Running ldconfig in %post will create the symlinks from the
SONAME, assuming they are present in the lib. But you must still ensure
the symlinks are owned by the package otherwise they get left behind
when the package is removed. A wildcard entry in %files might be all
that's needed (e.g, %{_libdir}/lib_andrew.so*)
You can query the SONAME with objdump:
objdump -p /usr/lib/lib_andrew.so.1.2.3 | grep SONAME
Re: USB 3 not working with SL 6 rolling kernel but with Fedora 15 kernel
On 07/07/11 21:09, Yasha Karant wrote: I have done several tests with various kernels in an attempt to get full USB 3 external hard drives to work. Hello Yasha, Firstly, apologies as I've not been following your thread closely and I've not read back through it in completion. However, Alan at elrepo.org is currently working on a mainline kernel (kernel-ml) for el6 that will be fully compatible with SL6. There is a thread here where he calls for expressions of interest: http://lists.elrepo.org/pipermail/elrepo/2011-July/000759.html http://elrepo.org/bugs/view.php?id=153 In all likelihood, elrepo would be looking to release kernel-3.0 (when released) packaged for el6 and this might provide a suitable option for you? Regards, Phil
Re: Heartbeat DRBD availability in SL 5.5
On 19/06/11 13:09, Bart Swedrowski wrote: On 19 June 2011 12:40, Randy Evansrevan...@gmail.com wrote: I know there are additional repositories that can be enabled which would provide Heartbeat and DRBD but I am confused as to why there is a difference in the base packages. I would, too, love to see DRBD packaged as a part of SL. Pretty much the only reason why few of the machines are still CentOS and not SL here... Dag has packaged and maintains drbd83 for el5 / el6 at elrepo.org: http://elrepo.org http://elrepo.org/tiki/kmod-drbd83 http://elrepo.org/tiki/drbd83-utils Hope that helps.
Re: hwmonitor or equivalent for SL 6 x86-64
On 18/06/11 02:10, Yasha Karant wrote: 2. The grub or whatever switch / configuration file so that the actual boot process and starting processes list (including any failures) is displayed to the console rather than simply some icon (spinning under noveau, progress bar under regular xorg including the Nvidia proprietary driver). Pressing F6 during boot shows the info for me. I've not found a way to get it with a grub config yet.
Re: Graphical boot, nvidia, compiz
On 13/06/11 17:52, Akemi Yagi wrote: On Mon, Jun 13, 2011 at 8:49 AM, Misc Thingsform...@gmail.com wrote: Hello, Finally got to installing the sl6.its wonderful to see its booting much faster then previous version (centos5.6). Here is the situation and a question : I have an Nvidia video card. by default it uses the nouveau driver. Unfortunately, I was not able to run compiz. I followed the instructions on their site ans installed the closed source (nvidia) driver. I also blacklisted and disables nouveau driver. That made compiz happy. But now the pretty graphical load is gone. The question is - how can I get it back :)? First, revert everything you have done. :) Especially make sure you do not have anything from Nvidia. Then install kmod-nvidia from ELRepo as detailed here: http://elrepo.org/tiki/kmod-nvidia and that page also describes how to restore plymouth graphical boot on EL6 with the nvidia driver under known issues. Regards, Phil
Re: RHEL/SL and iptables
On 16/04/11 20:34, Vaclav Mocek wrote: On 04/16/2011 08:13 PM, Nicolas Kovacs wrote: Hi, Until recently, I've only been using the system-config-securitylevel-tui utility, because it's easy to use while covering all my needs. Now I have to switch to a manual iptables configuration, because 1) the system-config-securitylevel-tui utility has been dumbed down, and 2) some of the things I want to do need a more fine-grained control. What's the most orthodox (e. g. clean) solution to configure iptables manually (in a script, somewhere) with SL ? Cheers, Niki Kovacs A custom script. Very nice how to for RH and Fedora could be find here: http://fedoraunity.org/Members/kanarip/iptables-howto Yes, definitely easiest to control iptables with a short/simple script IMHO. Also take a look at the CentOS Wiki iptables howto page which shows in detail how to implement such a script: http://wiki.centos.org/HowTos/Network/IPTables Once you've created your script, making changes to your firewall are as simple as making a quick edit to the script in your favourite text editor and (re)running the script.
Re: xrdb gone bad. xorg-x11-server-utils-7.1-5.el5_6.1 broken?
On 13/04/11 15:47, Alec T. Habig wrote: David M. Cooke writes: Several users started complaining today about various X apps, such as xterm and emacs, that no longer look the way they want. It looks like the resources they set in their .Xresources files are no longer set. Same in EL6. The changelog for this package says: * Wed Mar 16 2011 Adam Jacksona...@redhat.com 7.4-15.el6_0.1 - cve-2011-0465: Sanitize cpp macro expansion. (CVE 2011-0465) which sounds like something that could indeed break .Xresources parsing. Although in my case, not only old-style X apps lost their fonts marbles, but so did the KDE programs, menus, etc -- which I didn't think used the old-style X fonts at all. After wasting 15 minutes resetting fonts in many different places, X is usable again. I'm sure Murphy's Law says that this bug will be fixed tomorrow and we'll all have to re-reset things :) Thanks for your posts David and Alec. I thought I was losing my marbles when all my fonts went screwy on EL5/KDE so good to know the root cause.
Re: No success installing ATI Radeon HD5970 driver
On 16/03/11 20:02, Wil Irwin wrote: Hi Phil- I VERY much appreciate your suggestion and help. Sadly, these repo options didn't solve my problem. Hmm :-( Everything installed correctly (i.e., without error and a clean install report). However, I was unable to make any changes using the SL default 'display' GUI. I noted that elsewhere in the repo documentation (which I hastily ignored due to the excitement over your solution), the HD 5970 series was not included in the list of supported devices. I'm really unsure which models are supported by which driver - I can't seem to find this information in the ATI documentation. The list of supported devices in the elrepo.org documentation is for the older legacy driver, not the current release. All I can tell you is that when I go to the ATI driver download page, and enter your device, it says the current (11.2) driver supports your card. I have no idea when support was added. Most documentation only states that current cards are supported by the current driver. Am I missing something completely? I do have experience with Linux installations (not an expert by any means). And, specifically, have fought with display adaptor installations endlessly. Probably one of the most frustrating aspect of getting a new system up and running. Thanks again for any further guidance you can provide. I'm not an ATI user so it's difficult for me to offer much in the way of informed advice. Do you see any errors in your Xorg logs or anything else useful to go on? Reading back through the thread, about the only thing I can think to check is regarding your /etc/X11/xorg.conf file. By default, SL6 doesn't have an xorg.conf file. The elrepo.org packages will create a suitable xorg.conf file during the installation of the drivers. If you've already created one then the elrepo.org package will try to use that but if it's broken then it's not going to work. Thus I would suggest uninstalling the elrepo.org packages, make sure you (backup if necessary, and) delete /etc/X11/xorg.conf if it still exists and then reinstall the packages. Just a guess really.
Re: RT2860 drivers, kmod not available?
On 12/03/11 11:28, Phil Perry wrote: On 12/03/11 01:46, Victor Helsing wrote: SL6 is a great distribution, by the way. And congratulation to Urs for his excellent live CD/DVDs! I am trying to get the Ralink RT2860 wireless working on one of my systems. I installed the RT2860 firmware model (believe it was from epel or elrepo), but cannot find the kmod rt2860 which seems to go with it. There is some chatter about this module related to prior fedora releases. There is a mention of this being from the rpmfusion repository, but cannot find a workable version for el6/sl6. Anyone have any thoughts on this? I don't think it is related to SL6 itself. Victor Hi Victor, Yes, you are correct - it's not an SL6 issue specifically as the RT2860 drivers aren't included in the SL6 (and RHEL6) kernel. Elrepo.org have previously provided these drivers for SL5 but finding testers for them was notoriously difficult so we simply haven't ported them over to SL6 yet. Now we have a potential tester in you, we (elrepo.org) would be glad to knock up a package for you to test. Would that be OK with you? Regards, Phil Just to tie off this thread, there is now a driver for the RAlink RT2860 Wireless device available for SL6 at elrepo: http://elrepo.org/bugs/view.php?id=120 Many thanks to Victor for helping test the package.
Re: RT2860 drivers, kmod not available?
On 12/03/11 01:46, Victor Helsing wrote: SL6 is a great distribution, by the way. And congratulation to Urs for his excellent live CD/DVDs! I am trying to get the Ralink RT2860 wireless working on one of my systems. I installed the RT2860 firmware model (believe it was from epel or elrepo), but cannot find the kmod rt2860 which seems to go with it. There is some chatter about this module related to prior fedora releases. There is a mention of this being from the rpmfusion repository, but cannot find a workable version for el6/sl6. Anyone have any thoughts on this? I don't think it is related to SL6 itself. Victor Hi Victor, Yes, you are correct - it's not an SL6 issue specifically as the RT2860 drivers aren't included in the SL6 (and RHEL6) kernel. Elrepo.org have previously provided these drivers for SL5 but finding testers for them was notoriously difficult so we simply haven't ported them over to SL6 yet. Now we have a potential tester in you, we (elrepo.org) would be glad to knock up a package for you to test. Would that be OK with you? Regards, Phil
Re: No success installing ATI Radeon HD5970 driver
On 10/03/11 17:28, Wil Irwin wrote: Hi- I have tried multiple times to install the driver using the GUI installer and the subsequent steps. Installation appears to proceed and I can finish with aticonfig --initial. However, the driver doesn't appear to be applied. Scrolling down any webpage or document is very constipated, and dragging windows across the screen is also extremely constipated. In addition the GUI for Catalyst Control Panel will allow resolution, etc. changes, but they are not applied after a re-boot. I have also tried the command-prompt based install, with exactly the same results. I'm using the 11.2 driver released on 02/15/2011. I should also note the same problem (or at least similar) happened with SL5 and Ubuntu 10.x) The errors shown for fgl_glxgears, fglrxinfo, and glxinfo. uname -r; and the xorg.conf file are listed below. I am running SL6 with all updates and packages installed. Any suggestions would be VERY MUCH appreciated. Thanks, Wil Hi Wil, Can I suggest you try the ATI driver package for EL6 from elrepo.org: http://elrepo.org http://elrepo.org/tiki/kmod-fglrx I believe the elrepo.org repository might already be installed under SL6. Once you have elrepo installed, you can install the ATI drivers with: yum --enablerepo=elrepo install kmod-fglrx and if you need 32-bit application support on x86_64 then you should also install the fglrx-x11-drv-32bit package too. *Before* you install the elrepo packaged drivers, please uninstall the previous ATI installer drivers: sh /usr/share/ati/fglrx-uninstall.sh At the moment elrepo.org only has the 10.12 drivers for SL6 but I'll do my best to get those updated soon.
Re: apc or tripplite or something else
On 12/11/10 23:31, Bluejay Adametz wrote: Is APC (or some other make) preferred over tripplite as a linux friendly ups? Is everyone using nut or are the vendor supplied software good enough? I've got a couple of SL 5.0-with-recent-updates machines with late-model APC UPSs connected via USB, and the UPS parameters/status do show up in dbus. I haven't seen any comprehensive software to monitor these UPSs, but then I haven't looked real hard either. I've always used apcupsd to control my APC UPS, available from Dag's rpmforge repo. There's even some cgi scripts so you can monitor UPS status over http.
Re: TESTING - openafs update for SL5
On 14/07/10 20:06, Stephan Wiesand wrote: On Jul 8, 2010, at 19:11 , Dag Wieers wrote: If that is true we might have a discussion with Red Hat to see whether we can have those symbols as part of the kABI whitelist. Let's find out :-) There are symbols missing from the whitelist, so there was no way to use kABI-tracking modules cleanly. That being said, it probably would have worked. If someone has the time, it would be really interesting to force the module built for the SL5.0 GA kernel into -194.8.1 and see whether that works. The guy in charge at Red Hat (Jon Masters) seems very openminded, so talking to them is certainly worth the effort. I have my doubts though whether there's any chance to have the whitelist extended while it still matters. Jon requested we file bugs for missing symbols for the third party kmod drivers we have built. Please feel free to use the existing bug to report/log further symbols: https://bugzilla.redhat.com/show_bug.cgi?id=520891
Re: coretemp
On 05/29/2010 08:03 PM, Dr J wrote: g wrote: Dr J wrote: snip Now I can get fan speeds and voltages which were not available before... Any ideas??? do you have 'lm-sensors' and associated programs installed. easy way, open yum-ex, select 'all' and enter 'sensors' for filter. Thanks for the reply. Yes I do have lm_sensors and it is working..Iget results for theF71882FG module which gives fan speeds and voltages. An examination of /etc/sysconfig/lm-sensors shows MODULE_0=coretemp MODULE_1=f71882fg . Coretemp worked in SL5.4 but not in SL5.5 modprobe -l|grep coretemp shows: /lib/modules/2.6.18-194.3.1.el5/kernel/drivers/hwmon/coretemp.ko CPU is an i7-920 TA Joe Coretemp didn't exist in the 5.4 kernel so the only way you could have had it working was if you've installed the driver from a 3rd party repo - elrepo.org maybe? Redhat backported coretemp into el5.5 but it's still relatively old (from around kernel-2.6.26 IIRC), and I'm not sure it and/or lm_sensors in el5.5 supports i7 CPUs. I'd suggest you try the driver (and associated lm_sensors package dependency) from elrepo.org: http://elrepo.org http://elrepo.org/tiki/kmod-coretemp Hope that helps. Phil
Re: wireless USB question
Eve V. E. Kovacs wrote: We have a wireless USB device that we have been trying to get working on a linux box with a 32-bit SL5.3 OS. The device is an ASUS WL-167g USB 2.0. We have tried both the driver on the CD that came with the device, and a more recent version available on the ASUS website. In each case, the driver compiles and loads without errors (the kernel module is rt73), but when we try to bring up the wireless adapter, the system complains that the device cannot be found. Has anyone tried this device and got it to work successfully on linux? I wrote the report here and briefly had the device working: http://wiki.centos.org/HowTos/Laptops/Wireless#head-a7388039af96da5400e599133447452d2ca61fb5 I didn't use it for any length of time, just borrowed the device long enough to test it had basic connectivity and wrote it up. Hope that helps.
Re: Nvidia woes...
Alan Bartlett wrote: On 28 April 2010 14:10, Alan Bartlett a...@elrepo.org wrote: On 27 April 2010 21:54, Mark Stodola stod...@pelletron.com wrote: Hey everyone, I currently have deployed a number of SL 5.2 i386 machines. Mark, Further to my earlier message, I have re-read your initial sentence above. A SL 5.2 system will be using a kernel from the 2.6.18-92.x.y.el5 series. Unfortunately the kmod-nvidia[-*] packages that are available from ELRepo, although being kABI tracking, will only weak-link back to the 2.6.18-128.x.y.el5 kernel series (i.e. SL 5.3) and not, like many of the other packages, back to the original 2.6.18-8.x.y.el5 kernels. So having raised your hopes, I now have to dash them. Sorry. Regards, Alan. Correct for the current driver (kmod-nvidia) and 173 series (kmod-nvidia-173xx) legacy driver, but the older kmod-nvidia-96xx legacy driver is currently kABI compliant will all current EL5 kernels :)
Re: SL5.4 and Asus eee S101 netbook
Garrett Holmstrom wrote: ath9k is included in 5.5's kernel. If you're feeling adventurous you can grab the sources for the beta and compile them yourself. Or you can wait a while for SL 5.5's release. http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.5.b1/html/Release_Notes/#id3488732 You don't need to compile them yourself, Red Hat testing kernel binaries are available here: http://people.redhat.com/jwilson/el5/ Kernel -186.el5 shipped as part of RHEL5.5b1. Alternatively, as Alan Bartlett stated, grab the drivers from ELRepo. Hope that helps.
Re: ELRepo and kernel modules (was WIFI REALTEK RLT8187B)
On 01/13/2010 03:14 PM, Troy Dawson wrote: Alan Bartlett wrote: 2010/1/12 Akemi Yagi amy...@gmail.com: On Tue, Jan 12, 2010 at 2:08 PM, g gel...@bellsouth.net wrote: Akemi Yagi wrote: Just a note about the ndiswrapper package from the ELRepo repository. It comes with a kernel-version independent, kABI-tracking kernel module. i believe all packages from 'elrepo' are kernel independent. i have 2 packages from them that have gone thru 3 kernel updates and are working just fine like day they were first installed. Yes, all kmod packages from ELRepo are kernel independent and should survive kernel updates quietly. :) To expand upon Akemi's comment regarding kmod packages from ELRepo -- All kmod packages are built to be kernel independent, kABI tracking for all the released RHEL 5 kernels (unless otherwise stated). Hence ELRepo kmod packages are appropriate for all RHEL 5 based derivatives, i.e. Scientific Linux 5 and CentOS 5, as long as their kernels do not deviate from the ABI published by TUV. A brief note about ELRepo, for users of Scientific Linux. ELRepo is entirely independent of (and is not endorsed by) Red Hat and the CentOS project. It is, however, acknowledged by both and there is a communication / co-operation channel to the relevant kernel engineering team at Red Hat. The ELRepo admin team have significant experience with RHEL, Scientific Linux and CentOS. Alan. Hi Alan, Thank you for explanation. I have to admit that I hadn't looked at ELRepo before today, although I've heard of it. It looks very useful for people who need drivers. A couple of questions I see you have both nvidia-x11-drv as well as kmod-nvidia. Are these independant, or do you have to have both installed? I am somewhat new to kABI kernel modules. I know the theory, but not much else. In your experience with RHEL5, how often has RedHat broken or modified the ABI's, requiring you to update your kmod package? Troy Hi Troy, If I may be permitted to answer as maintainer of the ELRepo nvidia packages. Generally, our (elrepo's) kmod packages only provide the kernel module(s) (driver.ko), and associated depmod.d .conf entry. The nvidia package is a little different as there are also the accompanying proprietary X11 libs, in this case provided by the conventional nvidia-x11-drv RPM package. So to answer your question, kmod-nvidia requires nvidia-x11-drv, and vice versa, so they must both be installed. Your second question is an interesting one, and Alan may be better qualified to give a more technically correct explanation, but I'll do my best knowing he'll correct me where I slip up :) Generally, kABI should be consistent across all kernel releases within a Red Hat release. So, for example, the kABI of RHEL5 should not change throughout the life of the product. But as you may suspect, that is not always the case. We have built around 60 kmod packages, and from that experience we have found that the kABI is always consistent within an update release (e.g, 5.0, 5.1, 5.2 etc). For example, we have not, and would not expect to observe any kABI breakage for kernels released under the update release 5.4 (2.6.18-164.x). What we have observed is some breaking of the kABI *between* update releases. Generally, the vast majority of our packages work fine across all kernel update releases (5.0 through to 5.4, at present). However, there are some exceptions. Nvidia, for example, is one. The current kmod-nvidia release was built against kernel-2.6.18-128.el5 (5.3), and is not compatible with earlier kernel releases, suggesting that some kABI breakage occurred for the 5.3 release that affects kmod-nvidia. Interesting, kmod-nvidia works seamlessly going forward to 5.4 so in this instance there was no change in the kABI (affecting kmod-nvidia) between 5.3 and 5.4. In this instance we simply have a Requires: on the kmod-nvidia package for kernel = 2.6.18-128. If users are stuck on older kernels for any reason and need kmod-nvidia, then we could in theory build a version-release for them compiled against the kernel release required although such a situation hasn't arisen yet. Some other larger packages such as kmod-alsa and kmod-video4linux that provide hundreds of modules exhibit minor kABI breakage where, when built against the latest kernel, a few modules then don't weak-link against earlier kernels due to kABI breakage affecting only those modules. But for the vast majority of modules, the kABI is consistent as you would hope (expect), and a kmod package will work seamlessly across all kernel releases. In fact, I can't recall any other package affected by a change in the kABI. Finally, we would welcome you to join the elrepo mailing lists (and any other SL users). I don't know how many (non kABI-tracking) kmod type packages you currently have within SL (if any), but I would imagine the main benefit of kABI-tracking kmods for someone like yourself would be that you would only need
Re: ELRepo and kernel modules (was WIFI REALTEK RLT8187B)
On 01/13/2010 04:49 PM, Troy Dawson wrote: Phil Perry wrote: On 01/13/2010 03:14 PM, Troy Dawson wrote: Alan Bartlett wrote: 2010/1/12 Akemi Yagi amy...@gmail.com: On Tue, Jan 12, 2010 at 2:08 PM, g gel...@bellsouth.net wrote: Akemi Yagi wrote: Just a note about the ndiswrapper package from the ELRepo repository. It comes with a kernel-version independent, kABI-tracking kernel module. i believe all packages from 'elrepo' are kernel independent. i have 2 packages from them that have gone thru 3 kernel updates and are working just fine like day they were first installed. Yes, all kmod packages from ELRepo are kernel independent and should survive kernel updates quietly. :) To expand upon Akemi's comment regarding kmod packages from ELRepo -- All kmod packages are built to be kernel independent, kABI tracking for all the released RHEL 5 kernels (unless otherwise stated). Hence ELRepo kmod packages are appropriate for all RHEL 5 based derivatives, i.e. Scientific Linux 5 and CentOS 5, as long as their kernels do not deviate from the ABI published by TUV. A brief note about ELRepo, for users of Scientific Linux. ELRepo is entirely independent of (and is not endorsed by) Red Hat and the CentOS project. It is, however, acknowledged by both and there is a communication / co-operation channel to the relevant kernel engineering team at Red Hat. The ELRepo admin team have significant experience with RHEL, Scientific Linux and CentOS. Alan. Hi Alan, Thank you for explanation. I have to admit that I hadn't looked at ELRepo before today, although I've heard of it. It looks very useful for people who need drivers. A couple of questions I see you have both nvidia-x11-drv as well as kmod-nvidia. Are these independant, or do you have to have both installed? I am somewhat new to kABI kernel modules. I know the theory, but not much else. In your experience with RHEL5, how often has RedHat broken or modified the ABI's, requiring you to update your kmod package? Troy Hi Troy, If I may be permitted to answer as maintainer of the ELRepo nvidia packages. Generally, our (elrepo's) kmod packages only provide the kernel module(s) (driver.ko), and associated depmod.d .conf entry. The nvidia package is a little different as there are also the accompanying proprietary X11 libs, in this case provided by the conventional nvidia-x11-drv RPM package. So to answer your question, kmod-nvidia requires nvidia-x11-drv, and vice versa, so they must both be installed. Your second question is an interesting one, and Alan may be better qualified to give a more technically correct explanation, but I'll do my best knowing he'll correct me where I slip up :) Generally, kABI should be consistent across all kernel releases within a Red Hat release. So, for example, the kABI of RHEL5 should not change throughout the life of the product. But as you may suspect, that is not always the case. We have built around 60 kmod packages, and from that experience we have found that the kABI is always consistent within an update release (e.g, 5.0, 5.1, 5.2 etc). For example, we have not, and would not expect to observe any kABI breakage for kernels released under the update release 5.4 (2.6.18-164.x). What we have observed is some breaking of the kABI *between* update releases. Generally, the vast majority of our packages work fine across all kernel update releases (5.0 through to 5.4, at present). However, there are some exceptions. Nvidia, for example, is one. The current kmod-nvidia release was built against kernel-2.6.18-128.el5 (5.3), and is not compatible with earlier kernel releases, suggesting that some kABI breakage occurred for the 5.3 release that affects kmod-nvidia. Interesting, kmod-nvidia works seamlessly going forward to 5.4 so in this instance there was no change in the kABI (affecting kmod-nvidia) between 5.3 and 5.4. In this instance we simply have a Requires: on the kmod-nvidia package for kernel = 2.6.18-128. If users are stuck on older kernels for any reason and need kmod-nvidia, then we could in theory build a version-release for them compiled against the kernel release required although such a situation hasn't arisen yet. Some other larger packages such as kmod-alsa and kmod-video4linux that provide hundreds of modules exhibit minor kABI breakage where, when built against the latest kernel, a few modules then don't weak-link against earlier kernels due to kABI breakage affecting only those modules. But for the vast majority of modules, the kABI is consistent as you would hope (expect), and a kmod package will work seamlessly across all kernel releases. In fact, I can't recall any other package affected by a change in the kABI. Finally, we would welcome you to join the elrepo mailing lists (and any other SL users). I don't know how many (non kABI-tracking) kmod type packages you currently have within SL (if any), but I would imagine the main benefit of kABI-tracking kmods for someone like yourself would be that you
Re: WIFI REALTEK RLT8187B
On 01/12/2010 12:38 PM, feddds wrote: Hi everybody. Just ran SL 5.4 livecd on my wife laptop (a domestic brand named BANGHO here in Argentina) and did not detect its wifi card. Did not even appear using lspci command. I went to Windows and found this card. Is there a linux driver that I can use? or directly go for ndiswrapper? Googling found this: http://rtl-wifi.sourceforge.net/wiki/Installing Maybe in Dag repo could see any rlt8187b package. Report soon. Feddds. There is no native support for Realtek 8187B in RHEL/SL because the Linux 8187B driver requires the newer mac80211 stack (so you also won't find support in 3rd party repositories either). I would guess your best course of action would be to try with the Windows driver and ndiswrapper. Regards, Phil
Re: CentOS Project Administrator Goes AWOL
Serguei Mokhov wrote: On Thu, Jul 30, 2009 at 7:59 PM, Keith Lofstromkei...@kl-ic.com wrote: This affects us. Imagine that all the CentOS users show up to use Scientific Linux. Imagine all their maintainers and developers show up, too. This is a good thing for SL, isn't it? Increase the user base, I am sure Troy and Connie could use some help from the developers, and then lead to the world dominance of SL :) This affects us positively, IMHO, though perhaps there will be less competition. The CentOS Project isn't going anywhere. There is simply an issue whereby the person who controls the centos.org domain is being non-responsive and the matter is being dealt with openly. Worst case scenario, the project would have to flip to an alternative domain but the developers have made it clear it will continue and that full contingency plans are in place should they be needed. If there were only one rebuild project then there would be a single point of failure should that project then cease. Besides, diversity and competition are a good thing - each becomes stronger for it. Collaboration and/or shared knowledge in common areas are also attractive. Phil A CentOS and SL user
Re: updatedb or locate file
Felix Farcas wrote: Hello After installing SL 5.3 x86_64, custom version I do not find the updatedb command and I'm unable to locate any file. Perhaps I missed to install this packages. I do not know where to find them I looked on fr.rpmfind.net but could not find any clue. Could you please tell me where do I find this packages to install them. Are there any new ones? Thank you Felix The locate command is at /usr/bin/locate and updatedb is at /usr/bin/updatedb Both are provided by the mlocate package. For future reference, 'yum whatprovides */locate' will help with such issues.
Re: SELinux is preventing hp (hplip_t) read write to socket (cupsd_t).
Philip Goisman wrote: Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. snip Other than turning off SELinux, how may this be fixed? Is there an update coming which will fix this problem? As it says, by generating a local policy module to allow this access. There's a HowTo on the CentOS Wiki that covers generating custom SELinux policy modules (section 7) with examples: http://wiki.centos.org/HowTos/SELinux Hope that helps, Phil
Re: Updating to SL 5.3 issues
Avetisyan, Aram wrote: The only problem left is that the wireless is still grayed out. I tried yum install iwl\* and it installed the microcode for the 3945 and 5100 cards (in addition to the 4965 microcode which was already installed), but this didn't fix the problem. My /etc/modprobe.conf now contains only these three lines: alias wlan0 iwlagn options iwlagn swcrypto50=1 swcrypto=1 alias scsi_hostadapter ahci How are you controlling the device - with NetworkManager? Try stopping the network and wpa_supplicant services (at boot) and set the NetworkManager service to start at boot.
Re: Updating to SL 5.3 issues
Avetisyan, Aram wrote: Hello, I followed the instructions for updating to SL 5.3 (from SL 5.1 + latest yum updates) on scientificlinux.org. It did not give any errors during the update, but I think something went very wrong because now I have a rather long list of problems such as: 1) During every boot, I get this message: Bringing up interface wmaster0 Determining IP information for wmaster0... SIOCSIFFLAGS Operation not supported SIOCSIFFLAGS: Operation not supported The machine is frozen for about 2 minutes while it thinks about these SIOCSIFFLAGS after which it resumes booting. 2) The option to connect to wireless networks through Network Manager is grayed out. I have an Intel 4965AGN wireless card which worked perfectly fine before I tried updating, but now it doesn't seem to see the networks anymore -- the settings include a list of all of the connections with correct names and passwords, but the system acts as if there is no network in range. I think these two issues are related to the updated driver for iwl4965 in 5.3. SL5.2 used the iwl4965 driver whereas 5.3 uses the new iwlagn driver. They use *different* firmware, so a user updating from 5.2 - 5.3 with previously working wireless will experience the issues you describe if the correct firmware is not installed. In /etc/firmware you will need iwlwifi-4965-2.ucode (note the -2 revision is required by the new iwlagn driver). RPMforge has the correct firmware packages (yum install iwl4965-firmware). I'm not sure what SL firmware packages are available nor what firmwares these packages contain. Hope that helps, Phil
Re: Question about files within rpms in SL(C)
Vladimir Fekete wrote: Hi *, I'm using SL(C) for a while. Since then I fight with following problem. Is there any normal human way how to find package from repository which contains specific file ? (For example, I'm looking for RPM which has xrdb inside) YUM is not good enough for this - it does not go through content of packages nor has this information stored in any database (afaik). yum whatprovides \*xrdb
