Re: [CentOS] long delay when logging in

[Digimer]

On 16/11/16 11:06 PM, Peter wrote:
> On 17/11/16 16:34, Digimer wrote:
>> Edit /etc/ssh/sshd_config
>>
>> Set:
>>
>> UseDNS no
>> GSSAPIAuthentication no
>>
>> Save, restart sshd, try again.
> 
> This will certainly stop the long timeout, but I prefer telling people
> to fix their DNS.  The long timeout is indicative of a DNS issue and
> turning off DNS for ssh is just masking the real problem.  I prefer to
> leave DNS on for ssh as it's a good indicator for me of when I have to
> fix something.
> 
> 
> Peter

It can also happen if the target has lost its internet connection, is
air-gapped or otherwise legitimately offline. Your point is valid,
though, if the Internet should be up.

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] long delay when logging in

[Peter]

On 17/11/16 16:34, Digimer wrote:
> Edit /etc/ssh/sshd_config
> 
> Set:
> 
> UseDNS no
> GSSAPIAuthentication no
> 
> Save, restart sshd, try again.

This will certainly stop the long timeout, but I prefer telling people
to fix their DNS.  The long timeout is indicative of a DNS issue and
turning off DNS for ssh is just masking the real problem.  I prefer to
leave DNS on for ssh as it's a good indicator for me of when I have to
fix something.


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

Re: [CentOS] long delay when logging in

[Digimer]

Edit /etc/ssh/sshd_config

Set:

UseDNS no
GSSAPIAuthentication no

Save, restart sshd, try again.

digimer

On 16/11/16 06:07 PM, Larry Martell wrote:
> I have a CentOS 7 system and when I login with putty or ssh there is a
> long delay before I get the password prompt. I ran ssh -v and I found
> that it gets up to this:
> 
> debug1: ssh_ecdsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> 
> and then it sits there for 1-2 minutes and then this output blasts out:
> 
> debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password
> debug1: Next authentication method: gssapi-keyex
> debug1: No valid Key exchange context
> debug1: Next authentication method: gssapi-with-mic
> debug1: Unspecified GSS failure.  Minor code may provide more information
> No Kerberos credentials available
> debug1: Unspecified GSS failure.  Minor code may provide more information
> No Kerberos credentials available
> debug1: Unspecified GSS failure.  Minor code may provide more information
> debug1: Unspecified GSS failure.  Minor code may provide more information
> No Kerberos credentials available
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/motor/.ssh/id_rsa
> debug1: Trying private key: /home/motor/.ssh/id_dsa
> debug1: Trying private key: /home/motor/.ssh/id_ecdsa
> debug1: Trying private key: /home/motor/.ssh/id_ed25519
> debug1: Next authentication method: password
> 
> And then the password prompt comes out. This happens no matter which
> user is logging in. It only happens on the 1 system. I have 5 others
> where the proceeds without the delay.
> 
> There are no disk or memory or any other errors in the logs.
> 
> 
> What could be causing it to delay like this?
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
> 


-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] long delay when logging in

[John R Pierce]

On 11/16/2016 3:07 PM, Larry Martell wrote:

I have a CentOS 7 system and when I login with putty or ssh there is a
long delay before I get the password prompt. I ran ssh -v and I found
that it gets up to this:

debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

and then it sits there for 1-2 minutes and then this output blasts out:


wild guess says someone is doing a reverse DNS lookup thats timing out.


--
john r pierce, recycling bits in santa cruz

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

Re: [CentOS] long delay when logging in

[Valeri Galtsev]

On Wed, November 16, 2016 5:07 pm, Larry Martell wrote:
> I have a CentOS 7 system and when I login with putty or ssh there is a
> long delay before I get the password prompt.

First thing I would check is that that system doesn't have unaccessible
DNS server listed in:

/etc/resolv.conf

(another thing, similarly DNS related: if you have caching name server on
that box, check if that doesn't cause delay the you see).

Valeri

> I ran ssh -v and I found
> that it gets up to this:
>
> debug1: ssh_ecdsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
>
> and then it sits there for 1-2 minutes and then this output blasts out:
>
> debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password
> debug1: Next authentication method: gssapi-keyex
> debug1: No valid Key exchange context
> debug1: Next authentication method: gssapi-with-mic
> debug1: Unspecified GSS failure.  Minor code may provide more information
> No Kerberos credentials available
> debug1: Unspecified GSS failure.  Minor code may provide more information
> No Kerberos credentials available
> debug1: Unspecified GSS failure.  Minor code may provide more information
> debug1: Unspecified GSS failure.  Minor code may provide more information
> No Kerberos credentials available
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/motor/.ssh/id_rsa
> debug1: Trying private key: /home/motor/.ssh/id_dsa
> debug1: Trying private key: /home/motor/.ssh/id_ecdsa
> debug1: Trying private key: /home/motor/.ssh/id_ed25519
> debug1: Next authentication method: password
>
> And then the password prompt comes out. This happens no matter which
> user is logging in. It only happens on the 1 system. I have 5 others
> where the proceeds without the delay.
>
> There are no disk or memory or any other errors in the logs.
>
>
> What could be causing it to delay like this?
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

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

[CentOS] long delay when logging in

[Larry Martell]

I have a CentOS 7 system and when I login with putty or ssh there is a
long delay before I get the password prompt. I ran ssh -v and I found
that it gets up to this:

debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

and then it sits there for 1-2 minutes and then this output blasts out:

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug1: Next authentication method: password

And then the password prompt comes out. This happens no matter which
user is logging in. It only happens on the 1 system. I have 5 others
where the proceeds without the delay.

There are no disk or memory or any other errors in the logs.


What could be causing it to delay like this?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 Boot Partition

[m . roth]

Matt wrote:
>>> What size is recommended for the /boot partition?  After doing a fresh
>>> install and lengthy backup restore I realized I only made it 200M.  Is
>>> this going to be a problem?
>>
>> Mine was about 500 MB and I removed some kernels because I got a warning
>> the partition was getting full.
>>
>> With only two kernels installed, 182 MB are used. I would suggest 1 GB
>> and I believe that is what CentOS 7.3 will do by default.
>
> Can I just change yum.conf with the setting installonly_limit=2 to
> limit kernels installed too two?

Sorry, but I don't advise that. A few years back we had a few machines
running fedora, and at, was it 17? - they added preupgrade, they were
building and stuffing a *lot* of stuff in /boot, and were recommending at
least 500M. We just went to a 1G /boot by default.

mark

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

Re: [CentOS] Centos 7 Boot Partition

[Paul Norton]

500 MB should be fine for the /boot partition. I believe that is the
default with minimal installations on both CentOS 6 and 7.


--
Paul Norton

On Wed, Nov 16, 2016 at 8:49 AM, John Hodrien 
wrote:

> On Wed, 16 Nov 2016, Matt wrote:
>
> Can I just change yum.conf with the setting installonly_limit=2 to
>> limit kernels installed too two?
>>
>
> I really wouldn't.  You can scrape by with that if you also make sure you
> don't have dracut-config-rescue installed, but you can find yourself
> struggling even with that, and so have to micromanage even further.
> Upgrade a
> kmod, watch /boot fill up, and find yourself in a bad place.
>
> If you only had it set to 200M, I'd reinstall now.  If you had it set to
> 500M,
> you'd cope.
>
> jh
>
> ___
> 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] Need help getting two NICs to work on CentOS 7

[Gordon Messmer]

On 11/16/2016 07:33 AM, Sean Son wrote:

No matter how many times I
restart the NetworkManager-dispatcher service, if I reboot the system, and
run a systemctl status NetworkManager-dispatcher.service, the service shows
as Inactive (Dead) even though it has been enabled.


That's normal.  It's a dbus-invoked service.  You don't need to manually 
enable it.  It runs a command when it's invoked, and then terminates.  
There isn't a daemon process associated with the service.



Also whenever I
reboot the VM, after logging into the GUI, I get a pop up that says failed
to activate network connection , yet I still have network connectivity.
Any ideas on what I can do to fix these things?


Not really.  The log might tell you why it thinks an interface wasn't 
successfully enabled.



   Also overall, because I am
using a static IP config for both NICs, is it better to just disable
NetworkManager and use network scripts instead?


Not generally.  If you find the old network service works better for 
your use case, it's available.  I use it on a small number of hosts 
where NM bugs interfere with normal operation, but I'm waiting for the 
7.3 updates (where NM has been rebased to a newer version) to see if I 
can stop doing that.

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

Re: [CentOS] Centos 7 Boot Partition

[John Hodrien]

On Wed, 16 Nov 2016, Matt wrote:


Can I just change yum.conf with the setting installonly_limit=2 to
limit kernels installed too two?


I really wouldn't.  You can scrape by with that if you also make sure you
don't have dracut-config-rescue installed, but you can find yourself
struggling even with that, and so have to micromanage even further.  Upgrade a
kmod, watch /boot fill up, and find yourself in a bad place.

If you only had it set to 200M, I'd reinstall now.  If you had it set to 500M,
you'd cope.

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

Re: [CentOS] Centos 7 Boot Partition

[Matt]

>> What size is recommended for the /boot partition?  After doing a fresh
>> install and lengthy backup restore I realized I only made it 200M.  Is
>> this going to be a problem?

>
> Mine was about 500 MB and I removed some kernels because I got a warning the
> partition was getting full.
>
> With only two kernels installed, 182 MB are used. I would suggest 1 GB and I
> believe that is what CentOS 7.3 will do by default.

Can I just change yum.conf with the setting installonly_limit=2 to
limit kernels installed too two?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and Kably lake: black screen

[Louis Lagendijk]

On Mon, 2016-11-14 at 06:48 -0600, Johnny Hughes wrote:
> On 11/12/2016 02:39 PM, Louis Lagendijk wrote:
> > 
> > On Sat, 2016-11-12 at 15:34 -0500, Fred Smith wrote:
> > > 
> > > On Sat, Nov 12, 2016 at 09:15:22PM +0100, Louis Lagendijk wrote:
> > > > 
> > > > 
> > > > I got a new laptop as my old one died: an HP Probook 470 G4. 
> > > > I installed Centos 7 1511.
> > > > The laptop has a Kaby Lake i5 CPU and an 
> > > > 01:00.0 3D controller: NVIDIA Corporation Device 134e (rev
> > > > a2). 
> > > > Fedora recognizes it as a GM108M/930MX. This may give some
> > > > hints,
> > > > but
> > > > it is not that the standard kernel does not support it, this
> > > > output
> > > > comes from the 4.8.7 mainline kernel which should support this
> > > > configuration? GM108 support was added in kernel 4.7, Kaby lake
> > > > support
> > > > was added in 4.5...
> > > > 
> > > > When I boot nothing shows up after the UEFI Grub menu: the
> > > > system
> > > > runs
> > > > but nothing is shown on the display, except for a non-blinking
> > > > cursor
> > > > in the upper left of the screen. I tried a number of things:
> > > > - Installed the latest ml-kernel from Elrepo (4.8.7-1)
> > > > - I also tried the following on the kernel commandline:
> > > > nomodeset i915.nomodeset=0 nouveau.modeset=0
> > > > Nothing changes the fact that there is no display.
> > > > 
> > > > I had to install Centos 7 using vnc as even a text install did
> > > > not
> > > > work
> > > > 
> > > > Does anybody have some idea what the cause could be and what to
> > > > try
> > > > next?
> > > 
> > > Did you try CTRL-ALT-F2 or -F3 ? perhaps X has just died (or not
> > > been
> > > properly started), but that would get you a text-mode consosle
> > > from
> > > which to work and experiment.
> > > 
> > > if that works, you could try typing "startx" (lose the quotes).
> > > which
> > > may provide informative errors. or not. 
> > > 
> > > YMMV
> > > 
http://mirror.centos.org/altarch/7/experimental/x86_64/> > > 
> > Thanks for your response, but...
> > No, tried it, but that did not work either unfortunately.
> > 
> 
> If you still have the machine available, try using the experimental
> kernel:
> 
> http://mirror.centos.org/altarch/7/experimental/x86_64/
> 
> Also, what graphic card does it use?


Hi Johnny,
Yes I still have the laptop. Too nice a machine to send back…

The experimental kernel cannot be installed due to a missing xorg-x11-
drv-vmmouse >= 14.0.0 package. Do you know where can I find that
package?

The graphic card may indeed be the problem as the laptop has both a HD
620 in the processor and a Nvidia device 134e (rev A2). with the Fedora
 25 kernel loaded, glxinfo reports that the i915 driver could not be
loaded and that Gallium 0.4 on llvmpipe is used.

The f25 beta kernel does work on Centos after updating xfs-progs and
linux-firmware from f25 Beta (but crashes at a reboot)

> 
> Thanks,
> Johnny Hughes
> 
> 
> 
> ___
> 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] Need help getting two NICs to work on CentOS 7

[Sean Son]

On Tue, Nov 15, 2016 at 10:55 AM, Gordon Messmer 
wrote:

> On 11/15/2016 06:07 AM, Sean Son wrote:
>
>> I have no network connectivity even
>> when I restart the network service.  Should I reenable NetworkManager now?
>>
>
>
> Yeah, the switch is just a test to see if the problem is specific to
> NetworkManager.  It seems that you have other problems as well.
>
> Before you do that, post the output of the following:
>
> ip route show
>
> ip route show table 300
>
> ip route show table 301
>
> ip rule show
>
> cat /etc/sysconfig/network-scripts/ifcfg-eth0
>
> cat /etc/sysconfig/network-scripts/route-eth0
>
> cat /etc/sysconfig/network-scripts/rule-eth0
>
> cat /etc/sysconfig/network-scripts/ifcfg-eth1
>
> cat /etc/sysconfig/network-scripts/route-eth1
>
> cat /etc/sysconfig/network-scripts/rule-eth1
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


Hello

I think i figured it out.   I had forgotten to install
NetworkManager-config-routing-rules and then enable and start the
NetworkManager-dispatcher service.   I tried that on a different test
machine and I am able to ping both of the IPs from another machine just
fine. Only a few things I have noticed:   No matter how many times I
restart the NetworkManager-dispatcher service, if I reboot the system, and
run a systemctl status NetworkManager-dispatcher.service, the service shows
as Inactive (Dead) even though it has been enabled.   Also whenever I
reboot the VM, after logging into the GUI, I get a pop up that says failed
to activate network connection , yet I still have network connectivity.
Any ideas on what I can do to fix these things?  Also overall, because I am
using a static IP config for both NICs, is it better to just disable
NetworkManager and use network scripts instead?



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

[CentOS-build-reports] Build Fail: glibc 2.17-157.el7.aarch64 on c7.1611.00.a64

[buildsys]

ROOT log: -( last 500 lines )-\n\n
DEBUG util.py:393:  openldap-2.4.40-13.el7.aarch64
DEBUG util.py:393:  rpm-build-libs-4.11.3-21.el7.aarch64
DEBUG util.py:393:  perl-srpm-macros-1-8.el7.noarch
DEBUG util.py:393:  kernel-headers-4.2.0-0.31.el7.1.aarch64
DEBUG util.py:393:  glibc-devel-2.17-157.el7.aarch64
DEBUG util.py:393:  gcc-c++-4.8.5-11.el7.centos.aarch64
DEBUG util.py:393:  util-linux-2.23.2-33.el7.aarch64
DEBUG util.py:393:  which-2.20-7.el7.aarch64
DEBUG util.py:515:  Child return code was: 0
DEBUG util.py:535:  child environment: None
DEBUG util.py:468:  Executing command: ['/bin/rpm', '-Uvh', '--nodeps', 
'/builddir/build/originals/glibc-2.17-157.el7.src.rpm'] with env {'LANG': 
'en_GB.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf 
"\x1b]0;\x07"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir', 'HOSTNAME': 'mock'} and 
shell False
DEBUG util.py:393:  Updating / installing...
DEBUG util.py:393:  glibc-2.17-157.el7

DEBUG util.py:515:  Child return code was: 0
DEBUG util.py:535:  child environment: None
DEBUG util.py:468:  Executing command: ['/bin/rpm', '-qpl', 
'/builddir/build/originals/glibc-2.17-157.el7.src.rpm'] with env {'LANG': 
'en_GB.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf 
"\x1b]0;\x07"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir', 'HOSTNAME': 'mock'} and 
shell False
DEBUG util.py:393:  glibc-2.17-c758a686-releng.tar.gz
DEBUG util.py:393:  glibc-2.17-c758a686.tar.gz
DEBUG util.py:393:  glibc-aa64-commonpagesize-64k.patch
DEBUG util.py:393:  glibc-aa64-setcontext.patch
DEBUG util.py:393:  glibc-aarch64-add-ptr_mangle-support.patch
DEBUG util.py:393:  glibc-aarch64-fpu-optional-trapping-exceptions.patch
DEBUG util.py:393:  glibc-aarch64-ifunc.patch
DEBUG util.py:393:  glibc-aarch64-rh1076760.patch
DEBUG util.py:393:  glibc-aarch64-syscall-rewrite.patch
DEBUG util.py:393:  glibc-arm-hardfloat-3.patch
DEBUG util.py:393:  glibc-cs-path.patch
DEBUG util.py:393:  glibc-fedora-__libc_multiple_libcs.patch
DEBUG util.py:393:  glibc-fedora-elf-ORIGIN.patch
DEBUG util.py:393:  glibc-fedora-elf-init-hidden_undef.patch
DEBUG util.py:393:  glibc-fedora-elf-rh737223.patch
DEBUG util.py:393:  glibc-fedora-gai-canonical.patch
DEBUG util.py:393:  glibc-fedora-getrlimit-PLT.patch
DEBUG util.py:393:  glibc-fedora-i386-tls-direct-seg-refs.patch
DEBUG util.py:393:  glibc-fedora-include-bits-ldbl.patch
DEBUG util.py:393:  glibc-fedora-ldd.patch
DEBUG util.py:393:  glibc-fedora-linux-tcsetattr.patch
DEBUG util.py:393:  glibc-fedora-localedata-rh61908.patch
DEBUG util.py:393:  glibc-fedora-localedef.patch
DEBUG util.py:393:  glibc-fedora-locarchive.patch
DEBUG util.py:393:  glibc-fedora-manual-dircategory.patch
DEBUG util.py:393:  glibc-fedora-nis-rh188246.patch
DEBUG util.py:393:  glibc-fedora-nptl-linklibc.patch
DEBUG util.py:393:  glibc-fedora-nscd.patch
DEBUG util.py:393:  glibc-fedora-ppc-unwind.patch
DEBUG util.py:393:  glibc-fedora-regcomp-sw11561.patch
DEBUG util.py:393:  glibc-fedora-streams-rh436349.patch
DEBUG util.py:393:  glibc-fedora-uname-getrlimit.patch
DEBUG util.py:393:  glibc-fix-test-write-buf-size.patch
DEBUG util.py:393:  glibc-gmake.patch
DEBUG util.py:393:  glibc-manual-update.patch
DEBUG util.py:393:  glibc-powerpc-ldbl_high.patch
DEBUG util.py:393:  glibc-ppc64le-01.patch
DEBUG util.py:393:  glibc-ppc64le-02.patch
DEBUG util.py:393:  glibc-ppc64le-03.patch
DEBUG util.py:393:  glibc-ppc64le-04.patch
DEBUG util.py:393:  glibc-ppc64le-05.patch
DEBUG util.py:393:  glibc-ppc64le-06.patch
DEBUG util.py:393:  glibc-ppc64le-07.patch
DEBUG util.py:393:  glibc-ppc64le-08.patch
DEBUG util.py:393:  glibc-ppc64le-09.patch
DEBUG util.py:393:  glibc-ppc64le-10.patch
DEBUG util.py:393:  glibc-ppc64le-11.patch
DEBUG util.py:393:  glibc-ppc64le-12.patch
DEBUG util.py:393:  glibc-ppc64le-13.patch
DEBUG util.py:393:  glibc-ppc64le-14.patch
DEBUG util.py:393:  glibc-ppc64le-15.patch
DEBUG util.py:393:  glibc-ppc64le-16.patch
DEBUG util.py:393:  glibc-ppc64le-17.patch
DEBUG util.py:393:  glibc-ppc64le-18.patch
DEBUG util.py:393:  glibc-ppc64le-19.patch
DEBUG util.py:393:  glibc-ppc64le-20.patch
DEBUG util.py:393:  glibc-ppc64le-21.patch
DEBUG util.py:393:  glibc-ppc64le-22.patch
DEBUG util.py:393:  glibc-ppc64le-23.patch
DEBUG util.py:393:  glibc-ppc64le-24.patch
DEBUG util.py:393:  glibc-ppc64le-25.patch
DEBUG util.py:393:  glibc-ppc64le-26.patch
DEBUG util.py:393:  glibc-ppc64le-27.patch
DEBUG util.py:393:  glibc-ppc64le-28.patch
DEBUG util.py:393:  glibc-ppc64le-29.patch
DEBUG util.py:393:  glibc-ppc64le-30.patch
DEBUG util.py:393:  glibc-ppc64le-31.patch
DEBUG util.py:393:  glibc-ppc64le-32.patch
DEBUG util.py:393:  glibc-ppc64le-33.patch
DEBUG util.py:393:  glibc-ppc64le-34.patch
DEBUG util.py:393:  glibc-ppc64le-35.patch
DEBUG util.py:393:  glibc-ppc64le-36.patch
DEBUG util.py:393:  glibc-ppc64le-37.patch
DEBUG util.py:393:  

[CentOS-build-reports] Build Fail: glibc 2.17-157.el7.aarch64 on c7.1611.00.a64

[buildsys]

ROOT log: -( last 500 lines )-\n\n
DEBUG util.py:393:  openldap-2.4.40-13.el7.aarch64
DEBUG util.py:393:  rpm-build-libs-4.11.3-21.el7.aarch64
DEBUG util.py:393:  perl-srpm-macros-1-8.el7.noarch
DEBUG util.py:393:  kernel-headers-4.2.0-0.31.el7.1.aarch64
DEBUG util.py:393:  glibc-devel-2.17-157.el7.aarch64
DEBUG util.py:393:  gcc-c++-4.8.5-11.el7.centos.aarch64
DEBUG util.py:393:  util-linux-2.23.2-33.el7.aarch64
DEBUG util.py:393:  which-2.20-7.el7.aarch64
DEBUG util.py:515:  Child return code was: 0
DEBUG util.py:535:  child environment: None
DEBUG util.py:468:  Executing command: ['/bin/rpm', '-Uvh', '--nodeps', 
'/builddir/build/originals/glibc-2.17-157.el7.src.rpm'] with env {'LANG': 
'en_GB.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf 
"\x1b]0;\x07"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir', 'HOSTNAME': 'mock'} and 
shell False
DEBUG util.py:393:  Updating / installing...
DEBUG util.py:393:  glibc-2.17-157.el7

DEBUG util.py:515:  Child return code was: 0
DEBUG util.py:535:  child environment: None
DEBUG util.py:468:  Executing command: ['/bin/rpm', '-qpl', 
'/builddir/build/originals/glibc-2.17-157.el7.src.rpm'] with env {'LANG': 
'en_GB.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf 
"\x1b]0;\x07"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir', 'HOSTNAME': 'mock'} and 
shell False
DEBUG util.py:393:  glibc-2.17-c758a686-releng.tar.gz
DEBUG util.py:393:  glibc-2.17-c758a686.tar.gz
DEBUG util.py:393:  glibc-aa64-commonpagesize-64k.patch
DEBUG util.py:393:  glibc-aa64-setcontext.patch
DEBUG util.py:393:  glibc-aarch64-add-ptr_mangle-support.patch
DEBUG util.py:393:  glibc-aarch64-fpu-optional-trapping-exceptions.patch
DEBUG util.py:393:  glibc-aarch64-ifunc.patch
DEBUG util.py:393:  glibc-aarch64-rh1076760.patch
DEBUG util.py:393:  glibc-aarch64-syscall-rewrite.patch
DEBUG util.py:393:  glibc-arm-hardfloat-3.patch
DEBUG util.py:393:  glibc-cs-path.patch
DEBUG util.py:393:  glibc-fedora-__libc_multiple_libcs.patch
DEBUG util.py:393:  glibc-fedora-elf-ORIGIN.patch
DEBUG util.py:393:  glibc-fedora-elf-init-hidden_undef.patch
DEBUG util.py:393:  glibc-fedora-elf-rh737223.patch
DEBUG util.py:393:  glibc-fedora-gai-canonical.patch
DEBUG util.py:393:  glibc-fedora-getrlimit-PLT.patch
DEBUG util.py:393:  glibc-fedora-i386-tls-direct-seg-refs.patch
DEBUG util.py:393:  glibc-fedora-include-bits-ldbl.patch
DEBUG util.py:393:  glibc-fedora-ldd.patch
DEBUG util.py:393:  glibc-fedora-linux-tcsetattr.patch
DEBUG util.py:393:  glibc-fedora-localedata-rh61908.patch
DEBUG util.py:393:  glibc-fedora-localedef.patch
DEBUG util.py:393:  glibc-fedora-locarchive.patch
DEBUG util.py:393:  glibc-fedora-manual-dircategory.patch
DEBUG util.py:393:  glibc-fedora-nis-rh188246.patch
DEBUG util.py:393:  glibc-fedora-nptl-linklibc.patch
DEBUG util.py:393:  glibc-fedora-nscd.patch
DEBUG util.py:393:  glibc-fedora-ppc-unwind.patch
DEBUG util.py:393:  glibc-fedora-regcomp-sw11561.patch
DEBUG util.py:393:  glibc-fedora-streams-rh436349.patch
DEBUG util.py:393:  glibc-fedora-uname-getrlimit.patch
DEBUG util.py:393:  glibc-fix-test-write-buf-size.patch
DEBUG util.py:393:  glibc-gmake.patch
DEBUG util.py:393:  glibc-manual-update.patch
DEBUG util.py:393:  glibc-powerpc-ldbl_high.patch
DEBUG util.py:393:  glibc-ppc64le-01.patch
DEBUG util.py:393:  glibc-ppc64le-02.patch
DEBUG util.py:393:  glibc-ppc64le-03.patch
DEBUG util.py:393:  glibc-ppc64le-04.patch
DEBUG util.py:393:  glibc-ppc64le-05.patch
DEBUG util.py:393:  glibc-ppc64le-06.patch
DEBUG util.py:393:  glibc-ppc64le-07.patch
DEBUG util.py:393:  glibc-ppc64le-08.patch
DEBUG util.py:393:  glibc-ppc64le-09.patch
DEBUG util.py:393:  glibc-ppc64le-10.patch
DEBUG util.py:393:  glibc-ppc64le-11.patch
DEBUG util.py:393:  glibc-ppc64le-12.patch
DEBUG util.py:393:  glibc-ppc64le-13.patch
DEBUG util.py:393:  glibc-ppc64le-14.patch
DEBUG util.py:393:  glibc-ppc64le-15.patch
DEBUG util.py:393:  glibc-ppc64le-16.patch
DEBUG util.py:393:  glibc-ppc64le-17.patch
DEBUG util.py:393:  glibc-ppc64le-18.patch
DEBUG util.py:393:  glibc-ppc64le-19.patch
DEBUG util.py:393:  glibc-ppc64le-20.patch
DEBUG util.py:393:  glibc-ppc64le-21.patch
DEBUG util.py:393:  glibc-ppc64le-22.patch
DEBUG util.py:393:  glibc-ppc64le-23.patch
DEBUG util.py:393:  glibc-ppc64le-24.patch
DEBUG util.py:393:  glibc-ppc64le-25.patch
DEBUG util.py:393:  glibc-ppc64le-26.patch
DEBUG util.py:393:  glibc-ppc64le-27.patch
DEBUG util.py:393:  glibc-ppc64le-28.patch
DEBUG util.py:393:  glibc-ppc64le-29.patch
DEBUG util.py:393:  glibc-ppc64le-30.patch
DEBUG util.py:393:  glibc-ppc64le-31.patch
DEBUG util.py:393:  glibc-ppc64le-32.patch
DEBUG util.py:393:  glibc-ppc64le-33.patch
DEBUG util.py:393:  glibc-ppc64le-34.patch
DEBUG util.py:393:  glibc-ppc64le-35.patch
DEBUG util.py:393:  glibc-ppc64le-36.patch
DEBUG util.py:393:  glibc-ppc64le-37.patch
DEBUG util.py:393:  

Re: [CentOS] Centos.org down??

[Syam G Krishnan]

woo!
now it's working for me
don't know why it was not working before
earlier i've tried from different networks and all from india

cheers,

On Wednesday 16 November 2016 04:06 PM, geo.inbox.ignored wrote:
> 
> 
> On 11/16/2016 03:44 AM, Syam G Krishnan wrote:
>> Hi guys,
>>
>> Is there any problem with www.centos.org?
>> It seems down for me, was trying since last two weeks.
>>>
> 
> an easy place to check;
> 
>   http://www.downforeveryoneorjustme.com/
> 
> 

-- 
Syam G Krishnan
GPG 4096R/FBB26E60
Red Hat India Pvt Ltd
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos.org down??

[Denisa Ruçaj]

Hey,

It wasn't working for me too till last night.
Now is accessible :)

On Wed, Nov 16, 2016 at 11:36 AM, geo.inbox.ignored <
geo.inbox.igno...@gmail.com> wrote:

>
>
> On 11/16/2016 03:44 AM, Syam G Krishnan wrote:
> > Hi guys,
> >
> > Is there any problem with www.centos.org?
> > It seems down for me, was trying since last two weeks.
> >>
>
> an easy place to check;
>
>   http://www.downforeveryoneorjustme.com/
>
>
> --
>
> peace out.
>
> tc,hago.
>
>
> CentOS GNU/Linux 6.8
> KDE 4.3.4
>
> g
> .
>
> =+=
> Tired of having your microsoft os hacked?
> Change to Linux os, used by microsoft hackers.
> =+=
> If Bill Gates got a dime for every time Windows crashes...
>  ...oh, wait. He does. THAT explains it!
> =+=
> in a world with out fences, who needs gates.
> =+=
> ___
> 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] Centos.org down??

[geo.inbox.ignored]

On 11/16/2016 03:44 AM, Syam G Krishnan wrote:
> Hi guys,
>
> Is there any problem with www.centos.org?
> It seems down for me, was trying since last two weeks.
>>

an easy place to check;

  http://www.downforeveryoneorjustme.com/


-- 

peace out.

tc,hago.


CentOS GNU/Linux 6.8
KDE 4.3.4

g
.

=+=
Tired of having your microsoft os hacked?
Change to Linux os, used by microsoft hackers.
=+=
If Bill Gates got a dime for every time Windows crashes...
 ...oh, wait. He does. THAT explains it!
=+=
in a world with out fences, who needs gates.
=+=
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos.org down??

[Louis Lagendijk]

On Wed, 2016-11-16 at 15:14 +0530, Syam G Krishnan wrote:
> Hi guys,
> 
> Is there any problem with www.centos.org?
> It seems down for me, was trying since last two weeks.
> 
> 
works for me now and has been working earlier this week when I needed
to download some install images. Must be something on your side.
Louis
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos.org down??

[Sorin Srbu]

> -Original Message-
> From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
> Behalf Of Syam G Krishnan
> Sent: den 16 november 2016 10:45
> To: centos@centos.org
> Subject: [CentOS] Centos.org down??
> 
> Hi guys,
> 
> Is there any problem with www.centos.org?
> It seems down for me, was trying since last two weeks.

It's you.

Works fine from Sweden.

Tried http://downforeveryoneorjustme.com/?

-- 
//Sorin

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

[CentOS] Centos.org down??

[Syam G Krishnan]

Hi guys,

Is there any problem with www.centos.org?
It seems down for me, was trying since last two weeks.


-- 
Syam G Krishnan
GPG 4096R/FBB26E60
Red Hat India Pvt Ltd
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos