[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
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
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
[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] 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
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
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
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
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
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
[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] 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
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] 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] 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
[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] Thunderbird in CentOS 7.4
On 28/09/17 04:19, Alice Wonder wrote: 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 I have no problem using a self-signed cert on my own private mail server, although admittedly I'm using POP, not IMAP. Have you imported your certificate(s) in thunderbird? Preferences > Advanced > Certificates ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Thunderbird in CentOS 7.4
On 09/27/2017 11:14 PM, Phil Perry wrote: On 28/09/17 04:19, Alice Wonder wrote: 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 I have no problem using a self-signed cert on my own private mail server, although admittedly I'm using POP, not IMAP. Have you imported your certificate(s) in thunderbird? Preferences > Advanced > Certificates When Thundirbird first attempts it offers to import. Under older version it only asks once, and when I import, it's fine until I replace the certificate (once a year, cert is good for three years but I generate new once a year - I just make it good for three in case life gets in the way). The nee thunderbird continually asks but still fails to connect. However as soon as I switched back to the older version, it didn't even need to ask because I had already made an exception for that certificate. Old thunderbird works as expected, new doesn't. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
