Re: [CentOS] elrepo kmod-nvidia issue with update

[Paul R. Ganci]

On 04/30/2018 05:20 PM, Chuck Campbell wrote:

when I do yum update, elrepo offers kmod-nvifdia, but yum does this:

--> Processing Dependency: kernel(sme_me_mask) = 0x17fbce60 for 
package: kmod-nvidia-390.48-2.el7_5.elrepo.x86_64
--> Processing Dependency: kernel(reservation_object_add_excl_fence) = 
0xea98efc0 for package: kmod-nvidia-390.48-2.el7_5.elrepo.x86_64
--> Processing Dependency: kernel(drm_vblank_init) = 0xdcd50a49 for 
package: kmod-nvidia-390.48-2.el7_5.elrepo.x86_64


repeatedly, then says:

 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


Is there a problem on my end or theirs?


I have the same problem. When I visited the elrepo archives there was a 
post about this problem.


http://lists.elrepo.org/pipermail/elrepo/2018-April/004222.html

It appears there is a kernel driver build incompatibility that will go 
away when RHEL 7.5 comes to CentOS. For the moment I am a just excluding 
this update. The post suggests there is a version in testing that fixes 
the problem but I did not see it there. It looked like it was removed. 
For the moment I suggest patience.


--
Paul (ga...@nurdog.com)
Cell: (303)257-5208
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] elrepo kmod-nvidia issue with update

[Chuck Campbell]

when I do yum update, elrepo offers kmod-nvifdia, but yum does this:

--> Processing Dependency: kernel(sme_me_mask) = 0x17fbce60 for package: 
kmod-nvidia-390.48-2.el7_5.elrepo.x86_64
--> Processing Dependency: kernel(reservation_object_add_excl_fence) = 
0xea98efc0 for package: kmod-nvidia-390.48-2.el7_5.elrepo.x86_64
--> Processing Dependency: kernel(drm_vblank_init) = 0xdcd50a49 for 
package: kmod-nvidia-390.48-2.el7_5.elrepo.x86_64


.

.

.

repeatedly, then says:

 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


Is there a problem on my end or theirs?


-chuck


--
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  (713)993-0671 ph.
|   and Integrated Interpretation   |  (713)993-0608 fax
448 W. 19th St. #325|Since 1992 |  (713)306-5794 cell
 Houston, TX, 77008 |  Chuck Campbell   | campb...@accelinc.com
|  President & Senior Geoscientist  |

 "Integration means more than having all the maps at the same scale!"

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Named log question

[Chuck Campbell]

Is this mis-configuration, or just noise in my log?

    29-Apr-2018 00:50:26.056 general: warning: managed-keys-zone: No 
DNSKEY RRSIGs found for '.': success: 1 Time(s)
    29-Apr-2018 00:50:26.120 general: warning: managed-keys-zone: No 
DNSKEY RRSIGs found for 'dlv.isc.org': success: 1 Time(s)


-chuck

--
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  (713)993-0671 ph.
|   and Integrated Interpretation   |  (713)993-0608 fax
448 W. 19th St. #325|Since 1992 |  (713)306-5794 cell
 Houston, TX, 77008 |  Chuck Campbell   | campb...@accelinc.com
|  President & Senior Geoscientist  |

 "Integration means more than having all the maps at the same scale!"

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Network Performance

[Pete Biggs]

> There were dozens of examples of such ftp tests with varying
> block sizes, bidirectional transfers, destination files on
> RAID storage, and a mix of some system loading programs run
> independently and during the network performance testing.
> Also archived were a full complement of network tests with
> what looks like the original ttcp and possibly newer versions.

ttcp morphed into iperf.

> 
> These utilities looked like they would work on our CentOS 6
> systems, but we did not find ttcp and the ftp tests failed.
> the piping from dd failed with a message indicating that:
> |dd was not a recognized file.

Try 

ftp> put |"dd if=/dev/zero bs=32768 count=8000" /dev/null

> We no longer have available CentOS systems with versions of
> the OS before CentOS 6.  Could there have been a change to
> ftp that will not allow a source file specified in this way
> or would this transfer method have never worked on Linux?
> 
It works, just the semantics are a bit different.

P.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Network Performance

[Nataraj]

On 04/30/2018 10:43 AM, Chris Olson wrote:
> ftp> 
> ftp> put "|dd if=/dev/zero bs=32768 count=8000" /dev/null
> 200 PORT command successful.
> 150 Binary data connection for /dev/null (IP Address).
> 8000+0 records in
> 8000+0 records out
> 226 Transfer complete.
> local: |dd if=/dev/zero bs=32768 count=8000 remote: /dev/null
> 262144000 bytes sent in 23 seconds (11081.79 Kbytes/s)
> ftp> 

Though I haven't tried this, my first guess would be your ftp server is
running in some kind of a chroot environment.  You would have to either
disable this for the test or put whatever programs and libraries are
needed inside the chroot environment.  You might also try specifying the
full path, i.e. /bin/dd.

Nataraj

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How do I get the kernel srpm?

[Jim Perrin]

On 04/27/2018 01:35 PM, Robert Heller wrote:
> I tried to follow the work flow shown in https://wiki.centos.org/Sources, but 
> it does not seem to work:
> 
> I did this:
> 
> mkdir CentOS
> pushd CentOS
> git clone https://git.centos.org/git/centos-git-common.git
> git clone https://git.centos.org/git/rpms/kernel.git
> pushd kernel/
> git checkout c6
> ../centos-git-common/get_sources.sh
> 
> And I got the message:
> 
> Missing metadata. Please run from inside a sources git repo
> 
> What am I missing?
>   
> 

The sources in git are c7 and newer. c6 isn't shipped in git like that.


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Network Performance

[Chris Olson]

One of our summer interns has stayed on working part time
on weekends during the school year.  This schedule presents
an opportunity for technical investigations and some needed
performance testing.  The last weekend assignment included
data rate testing on one specific network pathway.

Checking out previous network testing was the first assignment.
Some five year old, archived SPARC/Solaris and Intel/Solaris
network tests included ftp runs like the following:

ftp> 
ftp> put "|dd if=/dev/zero bs=32768 count=8000" /dev/null
200 PORT command successful.
150 Binary data connection for /dev/null (IP Address).
8000+0 records in
8000+0 records out
226 Transfer complete.
local: |dd if=/dev/zero bs=32768 count=8000 remote: /dev/null
262144000 bytes sent in 23 seconds (11081.79 Kbytes/s)
ftp> 

There were dozens of examples of such ftp tests with varying
block sizes, bidirectional transfers, destination files on
RAID storage, and a mix of some system loading programs run
independently and during the network performance testing.
Also archived were a full complement of network tests with
what looks like the original ttcp and possibly newer versions.

These utilities looked like they would work on our CentOS 6
systems, but we did not find ttcp and the ftp tests failed.
the piping from dd failed with a message indicating that:
|dd was not a recognized file.

We no longer have available CentOS systems with versions of
the OS before CentOS 6.  Could there have been a change to
ftp that will not allow a source file specified in this way
or would this transfer method have never worked on Linux?


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: thunderbird annoyance

[Nataraj]

On 04/27/2018 01:33 PM, m.r...@5-cent.us wrote:
> incoming-cen...@rjl.com wrote:
>> Is the folder that you have selected inside of an account whose email
>> address is exactly the same as the one that get's cc'ed?  I could see
>> where if the messages were forwarded to a different email account, it
>> would do this. If this is not the case, go into
>> edit->preferences->advanced-config->config editor (like the about:config
>> in firefox) and search for cc_ and see if any of those variables are
>> turned on.
>>
> Nothing, there, and looking for reply, I see
> mailnews.reply_to_self_check_all_ident;false
>
>  

Only other thing that comes to mind is to delete (or rename) your
.thunderbird directory and create a new profile from scratch.  Next
thing would be to file a bug report.  If your running this under CentOS,
then you might try a direct download from mozilla and then you'll know
weather to file a bug report with CentOS/Redhat or with Mozilla.  I
believe Redhat backports bug fixes into their released version of
firefox and thunderbird.  You could check the various bug databases
before filing a bug report.

Nataraj

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen DomU's randomly freezing

[George Dunlap]

On Mon, Apr 30, 2018 at 1:08 PM, Daz Day  wrote:
> Hi,
>
> I've tried hitting up the CentOS forums and thought I'd try here too as I
> don't seem to be getting any bites.
>
> We've been in the process of migrating all our hypervisors over to CentOS 7
> using Xen. Once we had a few up and running we started to notice that the
> DomU's would randomly freeze. They become unresponsive to any network
> traffic, stop consuming CPU resources on the hypervisor and it's not
> possible to log in to the console locally using:
> virsh console 
> We can sometimes get as far as typing a username and hitting return, but the
> DomU just hangs there. It doesn't seem to matter what Linux distro the DomU
> is running, it affects them all. The only way we can get them back is by
> destroying and recreating them (far from ideal!).
>
> After a bit of research and digging around, we eventually found these 2
> nuggets:
> https://wiki.gentoo.org/wiki/Xen#Xen_domU_hanging_with_kernel_4.3.2B
> https://www.novell.com/support/kb/doc.php?id=7018590
>
> They both advise adding the command line argument:
> gnttab_max_frames=256(the default is 32).
> We applied this change and all hypervisors rand stable for around a week
> until DomU's started freezing again (we've since tried even higher values,
> to no avail). More research later led me to
> https://bugs.centos.org/view.php?id=14258 and
> https://bugs.centos.org/view.php?id=14284 (which are essentially the same
> report). There hasn't really been any movement on these tickets
> unfortunately, but I have +1'd them.
>
> Have any others had issues with Xen and DomU's locking up in CentOS 7? Are
> there any other fixes/workarounds? If any additional info is needed that
> isn't already in the bug tickets or forum post, please let me know and I'll
> be happy to provide whatever is required (these freezes are happening at
> least once a day).
>
> Any help would be much appreciated and would mean my Ops guys could get a
> decent sleep!
> Cheers
> Darren

Darren,

Would you mind reposting this to xen-users, along with:

* The config file for your guests
* The output of `dmesg` from inside one of the guests before it hangs
* The output of `dmesg` run on your dom0 after one of these machine hangs

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] Problem with cr repo.

[me]

On Mon, 30 Apr 2018, Marek Blaha wrote:


I can achieve the same error by
removing /usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname
and creating the directory in the same location instead.
So solution can be just removing this directory (or just renaming it):

# mv /usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_
hostname
/usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname.backup

# yum update python-urllib3


That worked!!

Thanks for the help.

My only remaining question is what caused it. I suspect I will never know but
the fix was simple enough.

Regards,

--
Tom m...@tdiehl.org



M.

--
Marek Blaha 

Red Hat Czech s.r.o.
Software Engineer

On Mon, Apr 30, 2018 at 3:04 PM,  wrote:


Hi,

I am having a problem with yum update from the cr repo.
Below is the output of yum:

(vgeppetto2 pts4) # yum update
Loaded plugins: changelog, fastestmirror, priorities
Loading mirror speeds from cached hostfile
 * epel: mirror.cogentco.com
171 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package python-urllib3.noarch 0:1.10.2-3.el7 will be updated
---> Package python-urllib3.noarch 0:1.10.2-5.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved




===
 Package Arch
  Version
   Repository   Size



===
Updating:
 python-urllib3  noarch
  1.10.2-5.el7
  cr  102 k

Transaction Summary



===
Upgrade  1 Package

Total download size: 102 k
Is this ok [y/d/N]: y
Downloading packages:
python-urllib3-1.10.2-5.el7.noarch.rpm

  | 102 kB  00:00:00 Running
transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : python-urllib3-1.10.2-5.el7.noarch

  1/2 Error
unpacking rpm package python-urllib3-1.10.2-5.el7.noarch
error: unpacking of archive failed on file /usr/lib/python2.7/site-packag
es/urllib3/packages/ssl_match_hostname: cpio: rename
  Verifying  : python-urllib3-1.10.2-5.el7.noarch

  1/2
python-urllib3-1.10.2-3.el7.noarch was supposed to be removed but is not!
  Verifying  : python-urllib3-1.10.2-3.el7.noarch

  2/2

Failed:
  python-urllib3.noarch 0:1.10.2-3.el7
 python-urllib3.noarch 0:1.10.2-5.el7

Complete!
(vgeppetto2 pts4) #

Can someone look at this and tell me if this is a packaging problem or
a problem with my machine and how to fix it?

I ran yum clean metadata before the yum update run but no change.

Regards,


--
Tom m...@tdiehl.org
___
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 mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Problem with cr repo.

[Marek Blaha]

I can achieve the same error by
removing /usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname
and creating the directory in the same location instead.
So solution can be just removing this directory (or just renaming it):

# mv /usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_
hostname
/usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname.backup

# yum update python-urllib3

M.

--
Marek Blaha 

Red Hat Czech s.r.o.
Software Engineer

On Mon, Apr 30, 2018 at 3:04 PM,  wrote:

> Hi,
>
> I am having a problem with yum update from the cr repo.
> Below is the output of yum:
>
> (vgeppetto2 pts4) # yum update
> Loaded plugins: changelog, fastestmirror, priorities
> Loading mirror speeds from cached hostfile
>  * epel: mirror.cogentco.com
> 171 packages excluded due to repository priority protections
> Resolving Dependencies
> --> Running transaction check
> ---> Package python-urllib3.noarch 0:1.10.2-3.el7 will be updated
> ---> Package python-urllib3.noarch 0:1.10.2-5.el7 will be an update
> --> Finished Dependency Resolution
>
> Dependencies Resolved
>
> 
> 
> 
> ===
>  Package Arch
>   Version
>Repository   Size
> 
> 
> 
> ===
> Updating:
>  python-urllib3  noarch
>   1.10.2-5.el7
>   cr  102 k
>
> Transaction Summary
> 
> 
> 
> ===
> Upgrade  1 Package
>
> Total download size: 102 k
> Is this ok [y/d/N]: y
> Downloading packages:
> python-urllib3-1.10.2-5.el7.noarch.rpm
>
>   | 102 kB  00:00:00 Running
> transaction check
> Running transaction test
> Transaction test succeeded
> Running transaction
>   Updating   : python-urllib3-1.10.2-5.el7.noarch
>
>   1/2 Error
> unpacking rpm package python-urllib3-1.10.2-5.el7.noarch
> error: unpacking of archive failed on file /usr/lib/python2.7/site-packag
> es/urllib3/packages/ssl_match_hostname: cpio: rename
>   Verifying  : python-urllib3-1.10.2-5.el7.noarch
>
>   1/2
> python-urllib3-1.10.2-3.el7.noarch was supposed to be removed but is not!
>   Verifying  : python-urllib3-1.10.2-3.el7.noarch
>
>   2/2
>
> Failed:
>   python-urllib3.noarch 0:1.10.2-3.el7
>  python-urllib3.noarch 0:1.10.2-5.el7
>
> Complete!
> (vgeppetto2 pts4) #
>
> Can someone look at this and tell me if this is a packaging problem or
> a problem with my machine and how to fix it?
>
> I ran yum clean metadata before the yum update run but no change.
>
> Regards,
>
>
> --
> Tom m...@tdiehl.org
> ___
> 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] Problem with cr repo.

[me]

Hi,

I am having a problem with yum update from the cr repo.
Below is the output of yum:

(vgeppetto2 pts4) # yum update
Loaded plugins: changelog, fastestmirror, priorities
Loading mirror speeds from cached hostfile
 * epel: mirror.cogentco.com
171 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package python-urllib3.noarch 0:1.10.2-3.el7 will be updated
---> Package python-urllib3.noarch 0:1.10.2-5.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

===
 Package Arch   
 Version
 Repository   Size
===
Updating:
 python-urllib3  noarch 
 1.10.2-5.el7   
 cr  102 k

Transaction Summary
===
Upgrade  1 Package

Total download size: 102 k
Is this ok [y/d/N]: y
Downloading packages:
python-urllib3-1.10.2-5.el7.noarch.rpm  | 102 kB  00:00:00 
Running transaction check

Running transaction test
Transaction test succeeded
Running transaction
  Updating   : python-urllib3-1.10.2-5.el7.noarch  1/2 
Error unpacking rpm package python-urllib3-1.10.2-5.el7.noarch

error: unpacking of archive failed on file 
/usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname: cpio: 
rename
  Verifying  : python-urllib3-1.10.2-5.el7.noarch  1/2 
python-urllib3-1.10.2-3.el7.noarch was supposed to be removed but is not!

  Verifying  : python-urllib3-1.10.2-3.el7.noarch   

   2/2

Failed:
  python-urllib3.noarch 0:1.10.2-3.el7  
   python-urllib3.noarch 0:1.10.2-5.el7

Complete!
(vgeppetto2 pts4) #

Can someone look at this and tell me if this is a packaging problem or
a problem with my machine and how to fix it?

I ran yum clean metadata before the yum update run but no change.

Regards,


--
Tom m...@tdiehl.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-virt] Xen DomU's randomly freezing

[Daz Day]

Hi,

I've tried hitting up the CentOS forums and thought I'd try here too as I
don't seem to be getting any bites.

We've been in the process of migrating all our hypervisors over to CentOS 7
using Xen. Once we had a few up and running we started to notice that the
DomU's would randomly freeze. They become unresponsive to any network
traffic, stop consuming CPU resources on the hypervisor and it's not
possible to log in to the console locally using:
virsh console 
We can sometimes get as far as typing a username and hitting return, but
the DomU just hangs there. It doesn't seem to matter what Linux distro the
DomU is running, it affects them all. The only way we can get them back is
by destroying and recreating them (far from ideal!).

After a bit of research and digging around, we eventually found these 2
nuggets:
https://wiki.gentoo.org/wiki/Xen#Xen_domU_hanging_with_kernel_4.3.2B
https://www.novell.com/support/kb/doc.php?id=7018590

They both advise adding the command line argument:
gnttab_max_frames=256(the default is 32).
We applied this change and all hypervisors rand stable for around a week
until DomU's started freezing again (we've since tried even higher values,
to no avail). More research later led me to
https://bugs.centos.org/view.php?id=14258 and
https://bugs.centos.org/view.php?id=14284 (which are essentially the same
report). There hasn't really been any movement on these tickets
unfortunately, but I have +1'd them.

Have any others had issues with Xen and DomU's locking up in CentOS 7? Are
there any other fixes/workarounds? If any additional info is needed that
isn't already in the bug tickets or forum post, please let me know and I'll
be happy to provide whatever is required (these freezes are happening at
least once a day).

Any help would be much appreciated and would mean my Ops guys could get a
decent sleep!
Cheers
Darren
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt