Discuss

discuss@lists.centos.org

12 participants
34747 discussions

mlx4_0 Initializing and... (infiniband)
by lejeczek 06 Jan '17

06 Jan '17

... Initializing.. hi all, I've a a very basic setup, directly two boxes via two MHEH28-XTC and I cannot activate them. One peculiar thing is I get (randomly & !often): [85947.090496] AMD-Vi: Event logged [ [85947.090539] IO_PAGE_FAULT device=09:00.7 domain=0x0000 address=0x00000000f6ffb000 flags=0x0050] [85947.298509] AMD-Vi: Event logged [ [85947.298550] IO_PAGE_FAULT device=09:00.7 domain=0x0000 address=0x00000000f6ffb000 flags=0x0050] which is the card itself, judging by the device id Would you have and share some thoughts please? $ ./flint/mstflint -d 09:00.0 q # for both cards -W- Running quick query - Skipping full image integrity checks. Image type: FS2 FW Version: 2.9.1000 Device ID: 25408 Description: Node Port1 Port2 Sys image GUIDs: 0008f104039a62a0 0008f104039a62a1 0008f104039a62a2 0008f104039a62a3 MACs: 000000000000 000000000001 VSD: PSID: MT_04A0110001 $ ibstat CA 'mlx4_0' CA type: MT25408 Number of ports: 2 Firmware version: 2.9.1000 Hardware version: a0 Node GUID: 0x0008f104039a08dc System image GUID: 0x0008f104039a08df Port 1: State: Initializing Physical state: LinkUp Rate: 10 Base lid: 1 LMC: 0 SM lid: 1 Capability mask: 0x0259086a Port GUID: 0x0008f104039a08dd Link layer: InfiniBand Port 2: State: Down Physical state: Polling Rate: 10 Base lid: 0 LMC: 0 SM lid: 0 Capability mask: 0x0259086a Port GUID: 0x0008f104039a08de Link layer: InfiniBand in opensm log: Jan 06 17:00:28 817185 [F6D5A700] 0x01 -> sm_mad_ctrl_send_err_cb: ERR 3113: MAD completed in error (IB_TIMEOUT): SubnGet(NodeInfo), attr_mod 0x0, TID 0x1cd1 Jan 06 17:00:28 817200 [F6D5A700] 0x01 -> sm_mad_ctrl_send_err_cb: ERR 3120 Timeout while getting attribute 0x11 (NodeInfo); Possible mis-set mkey?

1 0

does your kdump work?
by lejeczek 06 Jan '17

06 Jan '17

hi all mine does not, and I've tampered with it in many ways, cannot get it to work. best, L.

1 0

Firefox Issue
by Chris Olson 06 Jan '17

06 Jan '17

Everyone is back at work and starting to use computers on our smallest network which has Internet access through a rather old Linksys router. Two systems were left on and screen-locked over the extra long weekend. There does not appear to have been any Internet access interruption in our absence. A Firefox browser on one system was left pointing to a commonly used web site: https://www.yahoo.com/. This Yahoo web page was not displayed when the user unlocked the screen and brought up the browser from the task bar. Instead, a site located at the link https://gaibacoupontec.com was displayed with a message indicating that there was an urgent Firefox update required. There was a button to download and to install the update. I killed the Firefox browser rather than getting rid of it with the X in the upper right hand corner. This event has the aroma of an unwanted cyber intrusion, which is why I killed the browser. I have also copied and stored the full URL displayed in the browser, but have only included the first part "https://gaibacoupontec.com" here so as not to tempt anyone to risk access. Is it possible that a new Firefox flaw has been detected and is being exploited for malicious purposes?

6 5

OpenSCAP failures to to OS version?
by Noam Bernstein 05 Jan '17

05 Jan '17

Hi - I’m running the OpenSCAP STIG profile on a new CentOS 7.1611 installation, and I get a few failures that look like this (output from openscap scan —verbosity INFO). I suspect this is because the openscap module is not accepting CentOS 7 as RHEL 7 for rules purposes, despite an early check for "Community Enterprise Operating System 7” which succeeds. 1. Am I correct in why it’s failing? 2. Is this a bug, or an accepted behavior given that CentOS isn’t actually RHEL? Noam I: oscap: Evaluating XCCDF rule 'accounts_password_pam_retry'. I: oscap: Evaluating definition 'oval:org.open-scap.cpe.rhel:def:7': Red Hat Enterprise Linux 7. I: oscap: Definition 'oval:org.open-scap.cpe.rhel:def:7' evaluated as false. I: oscap: Evaluating definition 'oval:org.open-scap.cpe.rhel:def:1007': Community Enterprise Operating System 7. I: oscap: Definition 'oval:org.open-scap.cpe.rhel:def:1007' evaluated as true. I: oscap: Adding external variable oval:ssg-var_password_pam_retry:var:1. I: oscap: Evaluating definition 'oval:ssg-accounts_password_pam_retry:def:1': Set Password retry Requirements. I: oscap: Criteria are extended by definition 'oval:ssg-installed_OS_is_rhel6:def:1'. I: oscap: Evaluating definition 'oval:ssg-installed_OS_is_rhel6:def:1': Red Hat Enterprise Linux 6. I: oscap: Definition 'oval:ssg-installed_OS_is_rhel6:def:1' evaluated as false. I: oscap: Evaluating textfilecontent54 test 'oval:ssg-test_password_pam_cracklib_retry:tst:1': check the configuration of /etc/pam.d/system-auth. I: oscap: Querying textfilecontent54 object 'oval:ssg-obj_password_pam_cracklib_retry:obj:1', flags: 0. I: oscap: Creating new syschar for textfilecontent54_object 'oval:ssg-obj_password_pam_cracklib_retry:obj:1'. I: probe_textfilecontent54: Opening file '/etc/pam.d/system-auth'. I: oscap: State 'oval:ssg-state_password_pam_retry:ste:1' references external_variable 'oval:ssg-var_password_pam_retry:var:1'. I: oscap: Test 'oval:ssg-test_password_pam_cracklib_retry:tst:1' requires that at least one object defined by 'oval:ssg-obj_password_pam_cracklib_retry:obj:1' exists on the system. I: oscap: 0 objects defined by 'oval:ssg-obj_password_pam_cracklib_retry:obj:1' exist on the system. I: oscap: No item matching object 'oval:ssg-obj_password_pam_cracklib_retry:obj:1' was found on the system. (flag=does not exist) I: oscap: Test 'oval:ssg-test_password_pam_cracklib_retry:tst:1' evaluated as false. I: oscap: Criteria are extended by definition 'oval:ssg-installed_OS_is_rhel7:def:1'. I: oscap: Evaluating definition 'oval:ssg-installed_OS_is_rhel7:def:1': Red Hat Enterprise Linux 7. I: oscap: Definition 'oval:ssg-installed_OS_is_rhel7:def:1' evaluated as false. I: oscap: Evaluating textfilecontent54 test 'oval:ssg-test_password_pam_pwquality_retry:tst:1': check the configuration of /etc/pam.d/system-auth. I: oscap: Querying textfilecontent54 object 'oval:ssg-obj_password_pam_pwquality_retry:obj:1', flags: 0. I: oscap: Creating new syschar for textfilecontent54_object 'oval:ssg-obj_password_pam_pwquality_retry:obj:1'. I: probe_textfilecontent54: Opening file '/etc/pam.d/system-auth'. I: oscap: State 'oval:ssg-state_password_pam_retry:ste:1' references external_variable 'oval:ssg-var_password_pam_retry:var:1'. I: oscap: Test 'oval:ssg-test_password_pam_pwquality_retry:tst:1' requires that at least one object defined by 'oval:ssg-obj_password_pam_pwquality_retry:obj:1' exists on the system. I: oscap: 1 objects defined by 'oval:ssg-obj_password_pam_pwquality_retry:obj:1' exist on the system. I: oscap: All items matching object 'oval:ssg-obj_password_pam_pwquality_retry:obj:1' were collected. (flag=complete) I: oscap: In test 'oval:ssg-test_password_pam_pwquality_retry:tst:1' all of the collected items must satisfy these states: 'oval:ssg-state_password_pam_retry:ste:1'. I: oscap: Entity 'subexpression'='3' of item '106534257' matches corresponding entity in state 'oval:ssg-state_password_pam_retry:ste:1'. I: oscap: Item '106534257' compared to state 'oval:ssg-state_password_pam_retry:ste:1' with result true. I: oscap: Test 'oval:ssg-test_password_pam_pwquality_retry:tst:1' evaluated as true. I: oscap: Criteria are extended by definition 'oval:ssg-installed_OS_is_fedora:def:1'. I: oscap: Evaluating definition 'oval:ssg-installed_OS_is_fedora:def:1': Installed operating system is Fedora. I: oscap: Definition 'oval:ssg-installed_OS_is_fedora:def:1' evaluated as false. I: oscap: Evaluating textfilecontent54 test 'oval:ssg-test_password_pam_pwquality_retry:tst:1': check the configuration of /etc/pam.d/system-auth. I: oscap: Test 'oval:ssg-test_password_pam_pwquality_retry:tst:1' evaluated as true. I: oscap: Definition 'oval:ssg-accounts_password_pam_retry:def:1' evaluated as false.

1 0

Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
by lakhera2017 05 Jan '17

05 Jan '17

I am trying to copy(~7TB of data using rsync) between two server in same data center in the backend its using EMC VMAX3 After copying ~30-40GB of data multipath start failing Dec 15 01:57:53 test.example.com multipathd: 360000970000196801239533037303434: Recovered to normal mode Dec 15 01:57:53 test.example.com multipathd: 360000970000196801239533037303434: remaining active paths: 1 Dec 15 01:57:53 test.example.com kernel: sd 1:0:2:20: [sdeu] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [root@test log]# multipath -ll |grep -i fail |- 1:0:0:15 sdq 65:0 failed ready running - 3:0:0:15 sdai 66:32 failed ready running We are using default multipath.conf HBA driver version 8.07.00.26.06.8-k HBA model QLogic Corp. ISP8324-based 16Gb Fibre Channel to PCI Express Adapter OS: CentOS 64-bit/2.6.32-642.6.2.el6.x86_64 Hardware:Intel/HP ProLiant DL380 Gen9 Already verified this solution and checked with EMC everything looks good https://access.redhat.com/solutions/438403 Some more info - There is no drop/error packet on the network side. Filesystem is mounted with noatime,nodiratime Filesystem ext4(Already tried xfs but same error) LVM is in striped mode(Started with linear option and then converted to striped) Already disabled THP echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled Whenever multipath start failing process goes to D state System firmware upgraded Tried with latest version of qlogic driver Tried with different scheduler(noop,deadline,cfq) Tried with different tuned profile(enterprise-storage) Vmcore collected during the time of issue I am able to collect vmcore during the time of issue KERNEL: /usr/lib/debug/lib/modules/2.6.32-642.6.2.el6.x86_64/vmlinux DUMPFILE: vmcore [PARTIAL DUMP] CPUS: 36 DATE: Fri Dec 16 00:11:26 2016 UPTIME: 01:48:57 LOAD AVERAGE: 0.41, 0.49, 0.60 TASKS: 1238 NODENAME: test.example.com RELEASE: 2.6.32-642.6.2.el6.x86_64 VERSION: #1 SMP Wed Oct 26 06:52:09 UTC 2016 MACHINE: x86_64 (2297 Mhz) MEMORY: 511.9 GB PANIC: "BUG: unable to handle kernel NULL pointer dereference at 0000000000000018" PID: 15840 COMMAND: "kjournald" TASK: ffff884023446ab0 [THREAD_INFO: ffff88103def4000] CPU: 2 STATE: TASK_RUNNING (PANIC) -- View this message in context: http://centos.1050465.n5.nabble.com/Result-hostbyte-DID-ERROR-driverbyte-DR… Sent from the CentOS mailing list archive at Nabble.com.

2 2

puppetmaster after updating to 7.3
by Fred Wittekind 05 Jan '17

05 Jan '17

Any one else having issues starting the puppetmaster service after updating to 7.3? Looks like a SELinux issue, I couldn't find an existing bug report, but, seems like I shouldn't be the first one to trip on this issue. # grep puppet audit.log | audit2allow #============= puppetmaster_t ============== allow puppetmaster_t puppetagent_exec_t:file { execute execute_no_trans getattr ioctl open read }; selinux-policy-3.13.1-102.el7_3.7.noarch selinux-policy-targeted-3.13.1-102.el7_3.7.noarch puppet-server-3.6.2-3.el7.noarch (from EPEL) puppet-3.6.2-3.el7.noarch (from EPEL)

2 2

CentOS-announce Digest, Vol 143, Issue 3
by centos-announce-request＠centos.org 05 Jan '17

05 Jan '17

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. Release for CentOS 7.3.1611 on ARM64/AArch64 (Jim Perrin) ---------------------------------------------------------------------- Message: 1 Date: Wed, 4 Jan 2017 11:45:51 -0600 From: Jim Perrin <jperrin(a)centos.org> To: centos-announce(a)centos.org, Conversations around CentOS on ARM hardware <arm-dev(a)centos.org> Subject: [CentOS-announce] Release for CentOS 7.3.1611 on ARM64/AArch64 Message-ID: <f1f44f97-e8e0-da6f-3afc-9a168b37b3ea(a)centos.org> Content-Type: text/plain; charset=utf-8 I am pleased to announce the general availability of CentOS Linux 7 (1611) for AArch64/ARM64 machines. == Changes The kernel has been rebased from 4.2.0 to 4.5.0, and includes several patches recently merged into the upstream. The kernel patches and modifications can be found at https://git.centos.org/summary/sig-altarch!kernel.git in the sig-altarch7-aarch64 branch. == Download You can download new images and isos via http://mirror.centos.org/altarch/7/isos/aarch64/ Images and sha256sums: 1513f5325accfd32ac7973a9b24e401c829ece24da78e24d021e507e877f930e CentOS-7-aarch64-Everything.iso f7ae6bae6c2cc177134d7f8f3808e0f457537c4cd48a119620f50d18ff7bb908 CentOS-7-aarch64.img.xz 48776338f8c8994a9499f07e3af847253cf7235c6aac635a8418a2028ec675cf CentOS-7-aarch64-NetInstall.iso f7ae6bae6c2cc177134d7f8f3808e0f457537c4cd48a119620f50d18ff7bb908 CentOS-7-aarch64-rolling.img.xz 238b1ebf22a0ff894064e6ed2ac35ee02a6503657a40ad51f2eee7afc8229e75 CentOS-7-aarch64-rootfs-7.3.1611.tar.xz == Known Issues 1. Mustang based boards must be on the most recent firmware version, otherwise the network may lose connectivity when using 4.5.0-19+ based kernels. Please ensure your hardware is running the most recent firmware available to avoid network issues. 2. Merlin based boards should be on the most recent firmware version, in order to take full advantage of recent kernel improvements. 3. Some ThunderX based boards have been reported to have MAC address inconsistency when using older firmware versions. Please make sure you have the most recent firmware applied to your hardware to avoid network issues. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ------------------------------ Subject: Digest Footer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce ------------------------------ End of CentOS-announce Digest, Vol 143, Issue 3 ***********************************************

1 0

7.3: Gnome workspaces mirrored
by Gerhard Schneider 05 Jan '17

05 Jan '17

An user is using 2 displays and configured Gnome to "Static Workspaces only on primary display on" using gnome-tweak-tool Till 7.2 it was working as expected. After upgrading to 7.3 the content on the primary screen gets mirrored to all workspaces. When switching to "Static Workspaces only on primary display off" everything is working as expected on 7.3, too. Any ideas? Thank you in advance! Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail: gs(a)ilsb.tuwien.ac.at Structural Biomechanics (E317) Tel.: +43 1 58801 31716 TU Wien / Vienna / Austria Fax: +43 1 58801 31799 A-1060 Wien, Getreidemarkt 9/BE02 http://www.ilsb.tuwien.ac.at/~gs/

2 1

ghostscript update breaks evince
by Robert Nichols 05 Jan '17

05 Jan '17

Today's ghostscript.x86_64 0:8.70-21.el6_8.1 update causes evince to refuse to display any postscript file. Running evince from a terminal session, I see the errors: invalidaccess -7 invalidaccess -7 invalidaccess -7 ** (evince:1252): WARNING **: Error rendering thumbnail Downgrading to ghostscript.x86_64 0:8.70-21.el6 corrects the problem. Anyone else seeing this? -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.

5 5

[OT] Network Attached Storage
by TE Dukes 05 Jan '17

05 Jan '17

Hello, Been thinking about either purchasing one of these or building my own. This will be for home use. I was looking at the QNAP 451+ or building (DYI NAS) one with FreeNAS. I also found that CentOS has a NAS project. Not sure which way to go. They would cost about the same. One would be proprietary and the other open source. I like open source. This for home use. Thought I'd start out with 2, 4TB drives, maybe 3 so I could implement RAID 5. I have four computers to backup. TIA

10 14

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss