[CentOS] Thunderbird in CentOS 7.4

2017-09-27 Thread Alice Wonder
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

2017-09-27 Thread Anthony K

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

2017-09-27 Thread Pete Geenhuizen

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

2017-09-27 Thread ken

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

2017-09-27 Thread Frank Cox
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

2017-09-27 Thread Pete Geenhuizen
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

2017-09-27 Thread Phil Perry

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

2017-09-27 Thread m . roth
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

2017-09-27 Thread m . roth
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

2017-09-27 Thread Phil Perry

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

2017-09-27 Thread Phil Perry

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

2017-09-27 Thread Niels de Vos
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

2017-09-27 Thread Johnny Hughes

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

2017-09-27 Thread hw

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

2017-09-27 Thread hw


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

2017-09-27 Thread Fred Smith
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

2017-09-27 Thread m . roth
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?

2017-09-27 Thread Christopher Wood
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

2017-09-27 Thread Sorin Srbu
> -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

2017-09-27 Thread Sorin Srbu
> -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