[CentOS] Thunderbird in CentOS 7.4
With the current Thunderbird I can not connect to one of my IMAP servers that uses a self-signed cert. Virtually identical IMAP servers that use CA signed certs work I was a bit out of date when I updated to 7.4 and was running Thunderbird 45.6.x and it worked. When I connected from evolution (which I do not like) it worked. When I connected with my laptop still running 45.6.x it works. so - I rebuilt thunderbird 45.8.0 from 7.3 updates (newest that isn't 5x.x.x series) and did an --oldpackage update with RPM and it works again. When rebuilding the old thunderbird in mock I had to add the following: BuildRequires: dbus-glib-devel Either the build system used by CentOS automatically includes that, or a build dependency use to pull that it but no longer does. Anyway if anyone is having a similar problem, that's a solution. -=- This is what I see in the mail server log when current CentOS thunderbird tries to connect: Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=2600:1010:b064:f260:e83e:562d:2316:18df, lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48, session=--- Since it works with current evolution and with older thunderbird, I assume it is a bug in current thunderbird when the server is using a self-signed cert. Don't know if same thing happens on pop. I use IMAP on 143 using starttls ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] USB audio on Centos-7
On 27/09/17 13:31, Fred Smith wrote: Can you sense my frustration here? I'd appreciate any help that is actually helpful,... perhaps someone who reads this actually has one of these things and has made it work? thanks in advance! Fred Yes, I sense your frustration; I've had my fair share of it with bluetooth devices and I found a site *[0]* that helped me write a script to take control of my audio woes. Hopefully it helps you out. ak. [0]: http://terminalmage.net/2011/11/17/setting-a-usb-headset-as-the-default-pulseaudio-device.html ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SOLVED Centos 7 Mate desk top
On 09/27/17 18:18, Frank Cox wrote: On Wed, 27 Sep 2017 17:22:14 -0400 Pete Geenhuizen wrote: ~/.config/user-dirs.dirs Frank, Perfect, that was it. thanks a lot. Pete -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] firefox and D state
On 09/24/2017 02:26 AM, Michael Hennebry wrote: On Thu, 21 Sep 2017, ken wrote: On 09/20/2017 01:00 PM, Michael Hennebry wrote: Previously when firefox went catatonic to the point that I could not even scroll, its CPU usage had gone to 100%+. Now top tells me that firefox, Web Content (with a space) or sometimes kswap... has process state D, uninterruptable sleep. Any suggestions on how to deal? I had that problem... and yes, it was some site's page with wild or outright broken javascript. Installed NoScript, a Firefox add-on, and using that, severely limit what javascript can run. Since then I've been good. From here: https://addons.mozilla.org/en-US/firefox/addon/noscript/ ? Yes. It can also be accessed from within Firefox -> Tools -> Add-ons -> Extensions. Then search for it, etc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 Mate desk top
On Wed, 27 Sep 2017 17:22:14 -0400 Pete Geenhuizen wrote: > I restored parts of my C 6.9 home into C7.4 and now everything shows up > on my desktop and when I open a terminal it now opens up in [ user@host > ~ ]$ ~/.config/user-dirs.dirs -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Centos 7 Mate desk top
I upgraded to C 7.4 from C 6.9 on my laptop and all was well. As with C6 and the other C7 hosts that I have, if launch a terminal from the desktop it opens in [ user@host Desktop ]$ which is just fine. I restored parts of my C 6.9 home into C7.4 and now everything shows up on my desktop and when I open a terminal it now opens up in [ user@host ~ ]$ Obviously I overwrote the setting, that controls where the terminal opens. I've searched high and low but for the life of me I can't determine where that parameter is set. I've done some searches but haven't been able to get the right incantation that would yield an answer Does anyone know how I can resolve this dilemma? Thanks Pete -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
On 27/09/17 20:24, m.r...@5-cent.us wrote: Phil Perry wrote: On 27/09/17 16:49, m.r...@5-cent.us wrote: Hi, folks, Well, still more fun (for values of fun approaching zero): 1. Went to install CUDA 9.0... well, gee, there is *no* CUDA 9.0. Even though I installed the 9 repo, all that I get is 8. I've used their webform, and an waiting on a reply. 2. I remove all nvidia packages. 3. It appears that the kmod-nvidia is what I need; that's what nvidia-detect says. So I try to install... bzzt, thank you for playing. a: uname -a: 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux b: Installing : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Broadcast message from systemd-journ...@lyon.cit.nih.gov (Wed 2017-09-27 11:43:12 EDT): dracut[32409]: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut:/lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Working. This may take some time ... /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? /sbin/weak-modules: line 116: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 132: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 137: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory Unable to decompress /boot/initramfs-3.10.0-693.el7.x86_64.tmp: Unknown format /sbin/weak-modules: line 175: /tmp/weak-modules.oC1A7x/new_initramfs.img: No such file or directory rm: cannot remove '/tmp/weak-modules.oC1A7x/new_initramfs.img': No such file or directory mv: cannot stat '/boot/initramfs-3.10.0-693.el7.x86_64.tmp': No such file or directory Done. Installing : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 etckeeper: post transaction commit Verifying : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Verifying : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 Installed: kmod-nvidia.x86_64 0:384.90-1.el7_4.elrepo Dependency Installed: nvidia-x11-drv.x86_64 0:384.90-1.el7.elrepo Complete! Well, no it's not complete, and it's trying to install in the *previous* kernel, not the running one. kmod packages are a special class of package on RHEL that take advantage of the stable kernel ABI in Red Hat Enterprise Linux. When a kmod package is compiled against a kernel, the kernel module will be installed for that kernel and the weak-modules script will then weak link the module against all other kABI-compatible kernels installed on the system. This means that you do not need to rebuild the kernel module for each and every kernel update (or worse, delay updating your kernel whilst you wait for me to rebuild the module for you). Ok. I had thought it did. So yes, the module will likely be installed against a previous kernel, and maybe one that isn't even installed on your system. But it will weak link against your current kernel(s) providing none of the kernel symbols used by the module have changed between the kernel the module was built against and the current kernel in question. If you don't understand, just think of it as magic and be grateful you are running an Enterprise Linux kernel and not a fedora kernel. As to the earlier error messages, have you been playing with depmod? Where is your modules.dep for your installed kernels? Anyway, the magic described above has likely not worked correctly due to missing modules.dep, so I would uninstall the nvidia packages, sort out your kernel(s) / depmod information and try again once you have a sane system. Odd. The original kernel is installed, so I don't know why modules.dep wasn't there. I haven't had to run depmod before. Btw, about your previous email: nvidia-detect tells me to use kmod-nvidia for the K20c. When I go to the elrepo page about it, and follow the link, for the 340, I don't see it supporting them, but the non-legacy does. mark I would trust what nvidia-detect tells you. It is based on the definitive information provided by NVIDIA in their docs: http://us.download.nvidia.com/XFree86/Linux-x86_64/384.90/README/supportedchips.html ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
Ok... I've cleaned up, ran a depmod on the previous/original kernel, and reinstalled kmod-nvidia. Both the depmod and the install didn't find a modules.order and another one, but seemed to install fine. Now, I see that kmod-nvidia includes the nvidia-uvm-kmod, as well as cuda libraries. How do I test to see if it can see the Tesla cards? It used to be that I'd install cuda, build the samples, and run enum_gpu. When I rebuilt the other server, with a pair of M2090s, I could build the proprietary install, and install cuda, and then build the samples, and run bin/deviceQueryDrv. Is there something I can run that I can see that it sees the cards? I haven't found anything yet. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
Phil Perry wrote: > On 27/09/17 16:49, m.r...@5-cent.us wrote: >> Hi, folks, >> >> Well, still more fun (for values of fun approaching zero): >> >> 1. Went to install CUDA 9.0... well, gee, there is *no* CUDA 9.0. >> Even though I installed the 9 repo, all that I get is 8. I've >> used their webform, and an waiting on a reply. >> 2. I remove all nvidia packages. >> 3. It appears that the kmod-nvidia is what I need; that's what >> nvidia-detect says. So I try to install... bzzt, thank you >> for playing. >> >>a: uname -a: 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 >> 22:26:13 >> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux >>b: >>Installing : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 >> 1/2 >> >> Broadcast message from systemd-journ...@lyon.cit.nih.gov (Wed 2017-09-27 >> 11:43:12 EDT): >> >> dracut[32409]: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is >> missing. >> Did you run depmod? >> >> >> Message from syslogd@lyon at Sep 27 11:43:12 ... >> dracut:/lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did >> you run depmod? >> >> Message from syslogd@lyon at Sep 27 11:43:12 ... >> dracut: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. >> Did >> you run depmod? >> Working. This may take some time ... >> /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run >> depmod? >> /sbin/weak-modules: line 116: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: >> No such file or directory >> /sbin/weak-modules: line 132: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: >> No such file or directory >> /sbin/weak-modules: line 137: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: >> No such file or directory >> Unable to decompress /boot/initramfs-3.10.0-693.el7.x86_64.tmp: Unknown >> format >> /sbin/weak-modules: line 175: >> /tmp/weak-modules.oC1A7x/new_initramfs.img: >> No such file or directory >> rm: cannot remove '/tmp/weak-modules.oC1A7x/new_initramfs.img': No such >> file or directory >> mv: cannot stat '/boot/initramfs-3.10.0-693.el7.x86_64.tmp': No such >> file >> or directory >> Done. >>Installing : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 >> 2/2 >> etckeeper: post transaction commit >>Verifying : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 >> 1/2 >>Verifying : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 >> 2/2 >> >> Installed: >>kmod-nvidia.x86_64 0:384.90-1.el7_4.elrepo >> >> Dependency Installed: >>nvidia-x11-drv.x86_64 0:384.90-1.el7.elrepo >> >> Complete! >> >> Well, no it's not complete, and it's trying to install in the *previous* >> kernel, not the running one. >> > > kmod packages are a special class of package on RHEL that take advantage > of the stable kernel ABI in Red Hat Enterprise Linux. When a kmod > package is compiled against a kernel, the kernel module will be > installed for that kernel and the weak-modules script will then weak > link the module against all other kABI-compatible kernels installed on > the system. This means that you do not need to rebuild the kernel module > for each and every kernel update (or worse, delay updating your kernel > whilst you wait for me to rebuild the module for you). Ok. I had thought it did. > > So yes, the module will likely be installed against a previous kernel, > and maybe one that isn't even installed on your system. But it will weak > link against your current kernel(s) providing none of the kernel symbols > used by the module have changed between the kernel the module was built > against and the current kernel in question. If you don't understand, > just think of it as magic and be grateful you are running an Enterprise > Linux kernel and not a fedora kernel. > > As to the earlier error messages, have you been playing with depmod? > Where is your modules.dep for your installed kernels? Anyway, the magic > described above has likely not worked correctly due to missing > modules.dep, so I would uninstall the nvidia packages, sort out your > kernel(s) / depmod information and try again once you have a sane system. > Odd. The original kernel is installed, so I don't know why modules.dep wasn't there. I haven't had to run depmod before. Btw, about your previous email: nvidia-detect tells me to use kmod-nvidia for the K20c. When I go to the elrepo page about it, and follow the link, for the 340, I don't see it supporting them, but the non-legacy does. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
On 27/09/17 16:49, m.r...@5-cent.us wrote: Hi, folks, Well, still more fun (for values of fun approaching zero): 1. Went to install CUDA 9.0... well, gee, there is *no* CUDA 9.0. Even though I installed the 9 repo, all that I get is 8. I've used their webform, and an waiting on a reply. 2. I remove all nvidia packages. 3. It appears that the kmod-nvidia is what I need; that's what nvidia-detect says. So I try to install... bzzt, thank you for playing. a: uname -a: 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux b: Installing : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Broadcast message from systemd-journ...@lyon.cit.nih.gov (Wed 2017-09-27 11:43:12 EDT): dracut[32409]: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut:/lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Working. This may take some time ... /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? /sbin/weak-modules: line 116: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 132: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 137: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory Unable to decompress /boot/initramfs-3.10.0-693.el7.x86_64.tmp: Unknown format /sbin/weak-modules: line 175: /tmp/weak-modules.oC1A7x/new_initramfs.img: No such file or directory rm: cannot remove '/tmp/weak-modules.oC1A7x/new_initramfs.img': No such file or directory mv: cannot stat '/boot/initramfs-3.10.0-693.el7.x86_64.tmp': No such file or directory Done. Installing : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 etckeeper: post transaction commit Verifying : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Verifying : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 Installed: kmod-nvidia.x86_64 0:384.90-1.el7_4.elrepo Dependency Installed: nvidia-x11-drv.x86_64 0:384.90-1.el7.elrepo Complete! Well, no it's not complete, and it's trying to install in the *previous* kernel, not the running one. mark kmod packages are a special class of package on RHEL that take advantage of the stable kernel ABI in Red Hat Enterprise Linux. When a kmod package is compiled against a kernel, the kernel module will be installed for that kernel and the weak-modules script will then weak link the module against all other kABI-compatible kernels installed on the system. This means that you do not need to rebuild the kernel module for each and every kernel update (or worse, delay updating your kernel whilst you wait for me to rebuild the module for you). So yes, the module will likely be installed against a previous kernel, and maybe one that isn't even installed on your system. But it will weak link against your current kernel(s) providing none of the kernel symbols used by the module have changed between the kernel the module was built against and the current kernel in question. If you don't understand, just think of it as magic and be grateful you are running an Enterprise Linux kernel and not a fedora kernel. As to the earlier error messages, have you been playing with depmod? Where is your modules.dep for your installed kernels? Anyway, the magic described above has likely not worked correctly due to missing modules.dep, so I would uninstall the nvidia packages, sort out your kernel(s) / depmod information and try again once you have a sane system. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
On 27/09/17 07:56, Sorin Srbu wrote: -Original Message- From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Phil Perry Sent: den 26 september 2017 21:46 To: centos@centos.org Subject: Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4 On 26/09/17 18:40, m.r...@5-cent.us wrote: This is really frustrating. I've got a server with two K20c Tesla cards. I need to use the proprietary drivers to use the CUDA toolkit. Btw, I had no trouble at all with building for CentOS 7.3 I have what NVidia claims is the correct driver package, a 340 series. It appears to build, but then fails to load. The only error I see is "no such device", which makes no sense to me, esp. since it says nothing whatever else. I've gone through the install log, and there are a bunch of Note:, and warnings, but the later I think are all about comparing signed and unsigned integers. And lsmod shows no nvidia drivers registered, but the logs claims that Error: Driver 'nvidia' is already registered, aborting... Anyone got any ideas? mark You don't say which version of the 340 series driver you have tried. There was a bug with recent legacy releases that affected el7.4 kernels. We (elrepo) patched the driver to fix that on rhel7.4 releases. I'm not sure but it _may_ have been fixed in the 340.104 driver released last week - I've not bothered building it as the changelog only mentions "Improved compatibility with recent Linux kernels" which we patched/fixed in our the previous release and other issues which don't affect kmods on RHEL. So it sounds like a known issue which has already been fixed. If you don't want to use our packages, maybe take a look at the patch and try applying it to your build. Tested 340.76, 340.102, 340.104 (elrepo and proprietary). No luck over here with a GTX260 and the 64b-drivers. Will test some more, if still no luck, I'll just reinstall from scratch. The kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64.rpm driver should work for your card on el7.4. All previous releases in elrepo were for el7.3 (and earlier) and are not compatible with the el7.4 series kernel. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS-announce] Announcing the release of Gluster 3.12 on CentOS Linux 6 x86_64
I am happy to announce the General Availability of Gluster 3.12 for CentOS 6 on x86_64. These packages are following the upstream Gluster Community releases, and will receive monthly bugfix updates. Gluster 3.12 is a Long-Term-Maintenance release, and will receive updates for approximately 18 months. The difference between Long-Term-Maintenance and Short-Term-Maintenance releases is explained on the Gluster release schedule page: https://www.gluster.org/community/release-schedule/ Users of CentOS 6 can now simply install Gluster 3.12 with only these two commands: # yum install centos-release-gluster # yum install glusterfs-server The centos-release-gluster package is delivered via CentOS Extras repos. This contains all the metadata and dependency information, needed to install Gluster 3.12. The actual package that will get installed is centos-release-gluster312. Users of the now End-Of-Life Short-Term-Maintenance Gluster 3.11 will automatically get the update to Gluster 3.12, whereas users of Gluster 3.10 can stay on that Long-Term-Maintenance release for an other six months. Users of Gluster 3.8 will need to manually upgrade by uninstalling the centos-release-gluster38 package, and replacing it with either the Gluster 3.12 or 3.10 version. Additional details about the upgrade process are linked in the announcement from the Gluster Community: http://lists.gluster.org/pipermail/announce/2017-September/82.html We have a quickstart guide specifically built around the packages are available, it makes for a good introduction to Gluster and will help get you started in just a few simple steps, this quick start is available at https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart More details about the packages that the Gluster project provides in the Storage SIG is available in the documentation: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster The centos-release-gluster* repositories offer additional packages that enhance the usability of Gluster itself. Utilities and tools that were working with previous versions of Gluster are expected to stay working fine. If there are any problems, or requests for additional tools and applications to be provided, just send us an email with your suggestions. The current list of packages that is (planned to become) available can be found here: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs We welcome all feedback, comments and contributions. You can get in touch with the CentOS Storage SIG on the centos-devel mailing list (https://lists.centos.org ) and with the Gluster developer and user communities at https://www.gluster.org/mailman/listinfo , we are also available on irc at #gluster on irc.freenode.net, and on twitter at @gluster . Cheers, Niels de Vos Storage SIG member & Gluster maintainer signature.asc Description: PGP signature ___ CentOS-announce mailing list CentOS-announce@centos.org https://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CESA-2017:2795 Important CentOS 6 kernel Security Update
CentOS Errata and Security Advisory 2017:2795 Important Upstream details at : https://access.redhat.com/errata/RHSA-2017:2795 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 0ece8515a2a820dd68805f034238d315dc9bf7a3bd8979ab908914fff523535f kernel-2.6.32-696.10.3.el6.i686.rpm 6c0a44700f042cfbd024f7b22852a63626cd2023582b7e9033d473159cf9fe30 kernel-abi-whitelists-2.6.32-696.10.3.el6.noarch.rpm 0ee646bb30bc95b465839b76203c4371aea05c36f9fdc1a12ff5f59d716333e5 kernel-debug-2.6.32-696.10.3.el6.i686.rpm 6257147fd5d9d5e36f6e2c50e992c72d661a07ccfd8ffc6b02ecc81cdbdbb9e5 kernel-debug-devel-2.6.32-696.10.3.el6.i686.rpm 9a9ea42cdd6b6ce5b7f62a4972f2aeaf2f990eff124aa88fbb559a423525e959 kernel-devel-2.6.32-696.10.3.el6.i686.rpm 55f6c6bd63dabafd17488a612514c98ae9b37ee61d0be089be6363d80c3b45db kernel-doc-2.6.32-696.10.3.el6.noarch.rpm eb543c671ef9785795e3472c146c194a1b0cfbee829b0c7463f457b71f13dee2 kernel-firmware-2.6.32-696.10.3.el6.noarch.rpm 5454beb01c3d7cc4e6ccf7831ac0eb191ea2e44aaa53690c413fe44462c902b3 kernel-headers-2.6.32-696.10.3.el6.i686.rpm 9dfdf0318330bd2e6a082f0c2ffc0a52f4854ebd20da227462b03648294b7ace perf-2.6.32-696.10.3.el6.i686.rpm 083e8d2bfc51b686b8c7f263ce80f8df7ac02fb6f761d4881db2cf66b4651bd6 python-perf-2.6.32-696.10.3.el6.i686.rpm x86_64: 06e870bb5d57fefe461086e03173b75b2fa3d26b0662c0ed218272be4f62d870 kernel-2.6.32-696.10.3.el6.x86_64.rpm 6c0a44700f042cfbd024f7b22852a63626cd2023582b7e9033d473159cf9fe30 kernel-abi-whitelists-2.6.32-696.10.3.el6.noarch.rpm 0f372b21085376d6ebe881c445d0d4852e0df7c53a57def067cc3e202e62d254 kernel-debug-2.6.32-696.10.3.el6.x86_64.rpm 6257147fd5d9d5e36f6e2c50e992c72d661a07ccfd8ffc6b02ecc81cdbdbb9e5 kernel-debug-devel-2.6.32-696.10.3.el6.i686.rpm 2ac733e53bb15e042ac8391fea5b47808bbb3608037b8fc914131a1802aa3ac3 kernel-debug-devel-2.6.32-696.10.3.el6.x86_64.rpm d476497f262a01b016efde27d7cdc831c79bdbe1e0deb335e5d1f71f30b324e2 kernel-devel-2.6.32-696.10.3.el6.x86_64.rpm 55f6c6bd63dabafd17488a612514c98ae9b37ee61d0be089be6363d80c3b45db kernel-doc-2.6.32-696.10.3.el6.noarch.rpm eb543c671ef9785795e3472c146c194a1b0cfbee829b0c7463f457b71f13dee2 kernel-firmware-2.6.32-696.10.3.el6.noarch.rpm 303b8df4e585d9954b566329a16f2abab68783d82ebe619b5beb08fbb7b97f3d kernel-headers-2.6.32-696.10.3.el6.x86_64.rpm 5dcd16fdfe201473d29a27074942fa1d385edf1f0e8c36cfaaec0c42e0da073d perf-2.6.32-696.10.3.el6.x86_64.rpm 6b60c2094c7628db2dfe430250829584e5e5ae958eeebef91b06effe3791de94 python-perf-2.6.32-696.10.3.el6.x86_64.rpm Source: 6a35901d0c441f3bcfb438598e8658e497c406fab60c784a80b77c47d109c8e0 kernel-2.6.32-696.10.3.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #cen...@irc.freenode.net Twitter: @JohnnyCentOS ___ CentOS-announce mailing list CentOS-announce@centos.org https://lists.centos.org/mailman/listinfo/centos-announce
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
m.r...@5-cent.us wrote: Hi, folks, Well, still more fun (for values of fun approaching zero): 1. Went to install CUDA 9.0... well, gee, there is *no* CUDA 9.0. Even though I installed the 9 repo, all that I get is 8. I've used their webform, and an waiting on a reply. 2. I remove all nvidia packages. 3. It appears that the kmod-nvidia is what I need; that's what nvidia-detect says. So I try to install... bzzt, thank you for playing. If your intention is to use current NVIDIA drivers, you could try the download from their website. I´ve had good success with installing them directly from the download NVIDIA provides. I know we aren´t supposed to do that, but after using that for years and then using distribution-provided NVIDIA drivers, I went back to the NVIDIA package because that was far more trouble-free and continues to be so. When you get a new kernel and when some libraries are updated, you need to reinstall the NVIDIA drivers, but I can live with that. a: uname -a: 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux b: Installing : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Broadcast message from systemd-journ...@lyon.cit.nih.gov (Wed 2017-09-27 11:43:12 EDT): dracut[32409]: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut:/lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Working. This may take some time ... /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? /sbin/weak-modules: line 116: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 132: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 137: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory Unable to decompress /boot/initramfs-3.10.0-693.el7.x86_64.tmp: Unknown format /sbin/weak-modules: line 175: /tmp/weak-modules.oC1A7x/new_initramfs.img: No such file or directory rm: cannot remove '/tmp/weak-modules.oC1A7x/new_initramfs.img': No such file or directory mv: cannot stat '/boot/initramfs-3.10.0-693.el7.x86_64.tmp': No such file or directory Done. Installing : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 etckeeper: post transaction commit Verifying : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Verifying : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 Installed: kmod-nvidia.x86_64 0:384.90-1.el7_4.elrepo Dependency Installed: nvidia-x11-drv.x86_64 0:384.90-1.el7.elrepo Complete! Well, no it's not complete, and it's trying to install in the *previous* kernel, not the running one. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] tuned profile and i/o scheduler
Hi, is there a way to set the I/O scheduler via a tuned profile? If so, can the scheduler be set for different disks individually? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] USB audio on Centos-7
On Wed, Sep 27, 2017 at 02:06:35PM +1000, Kahlil Hodgson wrote: > Most of the useful audacity stuff is in their wiki: > > http://wiki.audacityteam.org/wiki/USB_mic_on_Linux > > seems like a good place to start. thanks, that probably is a good place to start. some of that may be pretty old, but I'm checking it out. One could wish it wasn't quite so terse, in spots. Fred -- Fred Smith -- fre...@fcshome.stoneham.ma.us Do you not know? Have you not heard? The LORD is the everlasting God, the Creator of the ends of the earth. He will not grow tired or weary, and his understanding no one can fathom. - Isaiah 40:28 (niv) - ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
Hi, folks, Well, still more fun (for values of fun approaching zero): 1. Went to install CUDA 9.0... well, gee, there is *no* CUDA 9.0. Even though I installed the 9 repo, all that I get is 8. I've used their webform, and an waiting on a reply. 2. I remove all nvidia packages. 3. It appears that the kmod-nvidia is what I need; that's what nvidia-detect says. So I try to install... bzzt, thank you for playing. a: uname -a: 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux b: Installing : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Broadcast message from systemd-journ...@lyon.cit.nih.gov (Wed 2017-09-27 11:43:12 EDT): dracut[32409]: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut:/lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Working. This may take some time ... /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? /sbin/weak-modules: line 116: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 132: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 137: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory Unable to decompress /boot/initramfs-3.10.0-693.el7.x86_64.tmp: Unknown format /sbin/weak-modules: line 175: /tmp/weak-modules.oC1A7x/new_initramfs.img: No such file or directory rm: cannot remove '/tmp/weak-modules.oC1A7x/new_initramfs.img': No such file or directory mv: cannot stat '/boot/initramfs-3.10.0-693.el7.x86_64.tmp': No such file or directory Done. Installing : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 etckeeper: post transaction commit Verifying : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Verifying : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 Installed: kmod-nvidia.x86_64 0:384.90-1.el7_4.elrepo Dependency Installed: nvidia-x11-drv.x86_64 0:384.90-1.el7.elrepo Complete! Well, no it's not complete, and it's trying to install in the *previous* kernel, not the running one. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] anaconda not installing to sda?
I'm having what appears at first glance to be a kickstart+anaconda issue on CentOS 7.4. As near as I can tell in the program.log in the anaconda environment, the partitioning instructions downloaded with the kickstart from cobbler appear to simply not be applied. Then /mnt/sysimage is not mounted, the logs are not copied to /mnt/sysimage/root and the installation stalls due to the anamon checking. (Also anaconda is trying to e2fsck /dev/loop devices which is puzzling.) If anybody has hints about what I would double-check or if you've resolved a similar issue I would be quite interested. More details: I see the same behaviour after cutting most items out of the cobbler kickstart template, however I confirm that /run/install/ks.cfg in the anaconda environment has the following: ignoredisk --only-use=sda zerombr bootloader --location=mbr clearpart --all part / --label="/" --fstype=ext4 --grow --asprimary program.log from the anaconda environment is here: https://gist.github.com/christopherwood/72f390d7e5788b9bc9e841d40c926895 The system does boot and install just fine from the CentOS 7.4 iso without being kickstarted. This is on vmware (esxi 6.0), I've tried with the paravirtual and lsi logic scsi controllers with the same result. I've tried different previously (CentOS 7.3) working cobbler profiles that do not work with 7.4 now. If I change the drive name (sda) to a ludicrous value anaconda simply errors, so at some level it's understanding about sda. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Phil Perry > Sent: den 26 september 2017 21:46 > To: centos@centos.org > Subject: Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4 > > On 26/09/17 18:40, m.r...@5-cent.us wrote: > > This is really frustrating. I've got a server with two K20c Tesla cards. I > > need to use the proprietary drivers to use the CUDA toolkit. Btw, I had no > > trouble at all with building for CentOS 7.3 > > > > I have what NVidia claims is the correct driver package, a 340 series. It > > appears to build, but then fails to load. The only error I see is "no such > > device", which makes no sense to me, esp. since it says nothing whatever > > else. > > > > I've gone through the install log, and there are a bunch of Note:, and > > warnings, but the later I think are all about comparing signed and > > unsigned integers. > > > > And lsmod shows no nvidia drivers registered, but the logs claims that > > Error: Driver 'nvidia' is already registered, aborting... > > > > Anyone got any ideas? > > > > mark > > > > You don't say which version of the 340 series driver you have tried. > > There was a bug with recent legacy releases that affected el7.4 kernels. > We (elrepo) patched the driver to fix that on rhel7.4 releases. I'm not > sure but it _may_ have been fixed in the 340.104 driver released last > week - I've not bothered building it as the changelog only mentions > "Improved compatibility with recent Linux kernels" which we > patched/fixed in our the previous release and other issues which don't > affect kmods on RHEL. > > So it sounds like a known issue which has already been fixed. If you > don't want to use our packages, maybe take a look at the patch and try > applying it to your build. Tested 340.76, 340.102, 340.104 (elrepo and proprietary). No luck over here with a GTX260 and the 64b-drivers. Will test some more, if still no luck, I'll just reinstall from scratch. -- //Sorin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Nicolas > Kovacs > Sent: den 26 september 2017 23:47 > To: centos@centos.org > Subject: Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4 > > Le 26/09/2017 à 19:59, Scott Robbins a écrit : > > Why not use the elrepo repo? They've worked flawlessly for me, both with > > legacy and new cards. > > I know this is weird, but I've had cases where the downloaded NVidia > driver worked and the ELRepo driver didn't, and the other way around. > > Details here: https://blog.microlinux.fr/nvidia-centos/ After upgrading from 7.3 to 7.4 the GUI won't start anymore. Using and Nvidia GTX260 with the elrepo drivers. Am investigating, but so far zip... Is the article above provided available in English? -- //Sorin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos