Discuss July 2018

discuss@lists.centos.org

105 participants
81 discussions

usb problem on Dell Latitude 3570
by johan.vermeulen7＠telenet.be 04 Jul '18

04 Jul '18

Hello All, after update to Centos7.5 all our Latitudes 3570 - some 150- suffer usb problems. Plug and play doesn't work any more, people need to insert usb devices - mouse, keyboard, eidreader - first and then boot in order to use them. dmesg | tail -n15 gives these EM: [ 25.164396] usb 1-8: device descriptor read/64, error -110 [ 25.418387] usb 1-8: new full-speed USB device number 6 using xhci_hcd [ 30.571460] usb 1-8: device descriptor read/64, error -110 [ 53.084387] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command [ 53.084435] xhci_hcd 0000:00:14.0: Timeout while waiting for stop endpoint command [ 53.285343] usb 1-8: device not accepting address 7, error -62 [ 58.300369] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300384] xhci_hcd 0000:00:14.0: Command completion event does not match command [ 58.300394] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300401] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300408] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300415] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300421] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300428] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300435] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300441] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event [ 58.300448] xhci_hcd 0000:00:14.0: ERROR mismatched command completion event Googling this is see some posts with similar problems, but none on Centos7 and none resolved. I suppose this is some driver-shift-update in Centos7.5. We are running MATE desktop, if that could be an issue.... Many thanks for any advise. Greetings, J.

2 3

ZFS on Linux repository
by Gionatan Danti 03 Jul '18

03 Jul '18

Hi list, we all know why ZFS is not included in RHEL/CentOS distributions: its CDDL license is/seems not compatible with GPL license. I'm not a layer, and I do not have any strong opinion on the matter. However, as a sysadmin, I found ZFS to be extremely useful, especially considering BTRFS sad state. I would *really* love to have ZFS on Linux more intergrated with current CentOS. From what I know (and I can go wrong, obviously), while the incompatible licenses prevent CentOS from shipping it, nothing should prevent to have a package for enabling *its repository*, better yet the kmod-enabled one. I was thiking to something as a ZFS SIG, where we can simply issue "yum install zfs-sig" and have the correct kmod-enabled repository enabled. I searched the list but I did not found anything regarding native ZFS. Any feedback on the matter is welcomed. Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti(a)assyoma.it - info(a)assyoma.it GPG public key ID: FF5F32A8

5 6

Re: [CentOS] [CentOS-announce] Announcing the release of Gluster 4.1 on CentOS Linux 6 x86_64
by wwp 03 Jul '18

03 Jul '18

Hello Niels, On Wed, 27 Jun 2018 16:45:37 +0200 Niels de Vos <ndevos(a)redhat.com> wrote: > I am happy to announce the General Availability of Gluster 4.1 for > CentOS 6 on x86_64. These packages are following the upstream Gluster > Community releases, and will receive monthly bugfix updates. > > Gluster 4.1 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/ Funny how for some people, 18 month means long-term. We're not supposed to be in the Android (smart) world, are we? Ironical but no disrespectful, I'd curious to read about it (how 18 month means long-term). Regards, -- wwp

2 1

LVM problems
by Thomas Schweikle 03 Jul '18

03 Jul '18

Hi! Folowing setup: 4x HD 500TB 1st: /boot 4GB, remaining part LVM 2nd, 3rd, 4th all LVM LVM volumes: - 30G /root - 8G /var - 8G /tmp - 200G /var/log/pgsql - 800G /var/spacewalk - 4G swap System boots into emergency mode because it does not find any of the logical volumes defined, because it does not enable the LVM volume group. Giving "lvm", then "vgchange -a y", followed by CTRL-D continues to boot to full multiuser mode. How can I make the system to enable the volume group and automatically boot to full multiuser mode? Looks there is something broken at some point and ths system does not enable the volume group. Any idea? -- Thomas

3 4

CentOS Pulse #1802 - The CentOS Newsletter, July, 2018
by Rich Bowen 03 Jul '18

03 Jul '18

We're pleased to publish another edition of the CentOS Newsletter. Once again, we cover latest releases, security updates, events, and reports from our SIGs (Special Interest Groups). You can read the newsletter at https://wiki.centos.org/Newsletter/1802 More information about the newsletter, and how you can contribute to future editions, is available at http://wiki.centos.org/Newsletter We always welcome comments and suggestions Enjoy the read. The Newsletter Team -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 0

Firefox 60.0.1.0 ESR Progress?
by Sean 02 Jul '18

02 Jul '18

Is there a way to track CentOS's progress on RHSA-2018-2113? https://access.redhat.com/errata/RHSA-2018:2113 Thanks!

2 1

Centos 7.5 on Vmware
by Gregory P. Ennis 02 Jul '18

02 Jul '18

Everyone, I am in the initial study phase of putting together a larger virtual server while using Centos 7.5 as the operating system of choice for the individual virtual machines. How do you all like VMware for this, or what other software allows for the development of virtural servers that use Centos 7.5 Thanks ahead of time for giving me a head start with your experiences!!!! -- Greg Ennis

5 6

cron.daily and others, not running
by wwp 02 Jul '18

02 Jul '18

Hello there, I've just noticed that scripts in /etc/cron.{daily,weekly,...} are not launched for several weeks (I noticed a `locate` not finding a recently added binary). Exactly, it's since June 02, and `# service cron status` says: Redirecting to /bin/systemctl status crond.service * crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2018-06-02 19:22:57 CEST; 4 weeks 1 days ago Main PID: 1379 (crond) Tasks: 1 Memory: 5.8M CGroup: /system.slice/crond.service `-1379 /usr/sbin/crond -n Jun 02 19:22:57 ladybug systemd[1]: Started Command Scheduler. Jun 02 19:22:57 ladybug systemd[1]: Starting Command Scheduler... Jun 02 19:22:57 ladybug crond[1379]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 73% if used.) Jun 02 19:22:57 ladybug crond[1379]: (CRON) INFO (running with inotify support) Jun 30 11:22:01 ladybug crond[1379]: (*system*) RELOAD (/etc/crontab) Jun 30 20:06:01 ladybug crond[1379]: (*system*) RELOAD (/etc/crontab) <eof> ----------- So, service is running but what could happen that makes /etc/cron.* not being fired? /etc/sysconfig/crond hasn't been touched and defines an empty CRONDARGS=. Stuff in /etc/crontab is running as expected, but it's maybe not related anyway. Regards, -- wwp

3 6

CentOS7/Mate Qt bugs/features?
by James Pearson 02 Jul '18

02 Jul '18

We have recently migrated from CentOS6/Gnome to CentOS7/Mate - and have noticed 'glitches' with some Qt applications that appears to be linked to the 'org.mate.Marco.general' 'compositing-manager' setting - and wondered how we 'fix' the issue ... Below is a PyQT4 python script that shows the issues: 1. With 'compositing-manager' set to 'true' (I believe the default setting): gsettings set org.mate.Marco.general compositing-manager true Running the script and the window background is transparent - which is fine However, if the pull down menu is selected and the 'Toggle' button pressed, the menu stays on the screen - and stays put even if the window is moved 2. With 'compositing-manager' set to 'false' : gsettings set org.mate.Marco.general compositing-manager false Running the script and the window background is no longer transparent - which is not good, but the pull down menu issue is fine ... We're using Nvidia cards with the Nvidia drivers - but I can also reproduce the issue on a Vmware player instance It would be good to know if anyone else can reproduce this with Mate ? Using CentOS7/Gnome3 works as expected (transparent background and pull down menu is fine) Anyone have any idea what the problem(s) might be and how to fix it/them ? Thanks James Pearson Python script: #!/usr/bin/python # # gsettings set org.mate.Marco.general compositing-manager true # # gsettings set org.mate.Marco.general compositing-manager false from PyQt4.QtGui import * from PyQt4 import QtCore import sys class MyWidget(QFrame): def __init__(self, parent=None): super(MyWidget, self).__init__(parent) self.setAttribute(QtCore.Qt.WA_TranslucentBackground) self.state = 1 self.combo = QComboBox() for a in ['A','B','C']: self.combo.addItem(a) self.btn = QPushButton("Toggle") self.btnClose = QPushButton("Close") self.btnClose.clicked.connect(self.close) layout = QVBoxLayout() layout.addWidget(self.combo) layout.addWidget(self.btn) layout.addWidget(self.btnClose) layout.setContentsMargins(50,50,50,50) self.setLayout(layout) self.btn.clicked.connect(self.updateComboState) def updateComboState(self): self.state = (self.state%2)+1 self.combo.setProperty("state", self.state) self.combo.style().unpolish(self.combo) self.combo.style().polish(self.combo) self.update() ss = """ *[state="1"] { background: rgb(50,50,100); } *[state="2"] { background: rgb(50,100,50); } """ if __name__ == "__main__": qapp = QApplication(sys.argv) myApp = MyWidget() myApp.setStyleSheet(ss) myApp.show() sys.exit(qapp.exec_())

2 4

C++11 and GCC 5+
by Alice Wonder 02 Jul '18

02 Jul '18

This may be common knowledge to some, but it was new to me. Libraries that use C++11 and are compiled with GCC 4.8.x that CentOS 7.x has are NOT binary compatible with GCC 5.x or newer. It seems to only effect C++11. What you have to do - create /opt/gcc55 (or whatever) Rebuild any libraries that use C++11 that you need in something compiled with GCC 5+ and install them within that prefix. Then point to them in that prefix when building what you need to build. -=- The Linux runtime linker seems to get it right (as long as you have /opt/gcc55/lib64 in path) and not load wrong version of library, so you don't need to use rpath. But you do need to have a version of the dependency compiled with the GCC you want available at both compile time and runtime. -=- I ran across this issue when building Audacity 2.2.2 - which does not build with GCC 4.8.5. The problem libraries: * flac * vamp-sjdk-plugin * wxGTK3 All three of those use C++11 and therefore needed to be rebuilt with GCC 5.5.0 (what I used for building Audacity) Just thought I'd pass it along.

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss July 2018