Discuss

discuss@lists.centos.org

8 participants
34745 discussions

Re: [CentOS] lshw in centos 7 withdrawn
by david 15 Jan '18

15 Jan '18

John-- Thanks for the suggestion. I finally had a chance to get to the system in question, It was the only one of many that exhibited the USB hang. I tried a reboot with the two USB disks disconnected. Everything worked. I plugged them in, and then did both "lsusb -v" and "lshw", and again, everything worked. Continuing my test: Reboot with both drives plugged in: all worked. Power off, wait 1 minute for everything to quiet down, power on: all worked. So, I can't reproduce the problem. I guess I have to blame cosmic rays or those nasty gremlins that inhabit our IC's. :-) Or is it related to the annoying spin-down and spin-up delay of external USB disks. I have issues with the spin-up delay on other CentOS platforms, and have managed to find a kludge to avoid it most of the time. Windows 10 seems to handle the delay well. Thanks for your idea. At least it led me to "lsusb -v". David At 05:33 PM 1/11/2018, Stephen John Smoogen wrote: >On 11 January 2018 at 20:23, david <david(a)daku.org> wrote: > > Folks > > > > I've been running lshw for years in both Centos 6 and Centos 7, yet just > > recently it started hanging. Neither a Control^C nor a "kill" of the > > process cured the hang; only a reboot. > > > >Is this just one system or a range of boxes? I just ran it on 2 >different ones running CentOS 7 and it worked fine there. If it is >just one particular hardware then look through the lshw man page and >try the versions of something like > >lshw -disable usb > >to see if it still happens. [It might require other tests also.] > > > > When I run it by hand from the command line, it displays stuff on the next > > line overwriting it with things like PCI, USB. And USB is the last thing I > > see. A Control-C does not unlock it. > > > > I am running lshw-B.02.18-7.el7.x86_64. The CPU is an Intel I7-3770K, > > running CentOS 7.4.1708 > > > > Is there any idea? Is there some alternate program that could list the > > hardware? > > > > Thanks > > > > David > >

2 4

el7 systemd :: usage of AssertPathExists
by Adrian Sevcenco 15 Jan '18

15 Jan '18

Hi! I am trying to use AssertPathExists in a systemd unit but it seems it not working. Does anyone have problems with this? i have this in unit : AssertPathExists= AssertPathExists=/etc/mlsensor/mlsensor.properties but then when i start the service i get no errors : 26225 /usr/bin/java -Xms16m -Xmx32m -DMLSENSOR_HOME=/tmp -Djava.util.logging.config.class=lia.Monitor.monitor.LoggerConfigClass -Dlia.Monitor.ConfigURL=file:/etc/mlsensor/mlsensor.properties -jar /usr/share/java/mlsensor/MLSensor.jar i can't modify the java application, i am just doing an systemd unit for it... Anyone have any experience making systemd unit fail if the configuration file is not in place? Thank you! Adrian

2 2

CentOS Linux 7 (1708) AltArch i386 Kernel
by Johnny Hughes 13 Jan '18

13 Jan '18

Red Hat no longer maintains the i386 kernel for RHEL 7.4. We have been using a modified kernel until this latest meltdown / spectre release (*kernel-3.10.0-693.11.6.el7*). This latest release does not build on i386/i686 and we can't figure out how to make it work. Build try: https://buildlogs.centos.org/c7.1708.u.i386/kernel/20180109171431/3.10.0-69… SRPM: http://people.centos.org/hughesjr/kernel-3.10.0-693.11.6.el7.centos.plus.sr… In the mean time, people running the altarch i386 distribution can the latest i386 experimental kernel .. use the repo file from here (bottom of the page, 'CentOS-Experimental.repo' to '/etc/yum.repo.d/' ) to get it: https://wiki.centos.org/SpecialInterestGroup/AltArch/i386 We could use some community help in: 1. Making the 3.10.0-693.11.6.el7.centos.plus.i386 build. 2. Testing the 4.9.75.el7.centos.i686 kernel from the experimental repo on the i386 arch. Please post info on this thread in the mailing list. In the past the Springdale Linux distro has had i386 kernels as well, but they have not updated any since the 7.4 release (a couple behind us), so they haven't gotten it to build either. If we can not get a working backported kernel-3.10.0-693.11.6.el7, I'll push a newer 4.9.x LTS kernel from the experimental repo as an update to the i386 AltArch updates repository. Let's set a timeout of next Friday as the drop dead fix date for kernel-3.10.0-693.11.6.el7 .. if we can't get one to build, we'll push the latest LTS kernel from kernel.org it the i386 AltArch updates repo. Thanks, Johnny Hughes

3 3

update to Centos7.4: Failed to open \EFI\BOOT\grubx64.efi - Not Found
by johan.vermeulen7＠telenet.be 13 Jan '18

13 Jan '18

Hello All, updating from Centos7.3 to Centos7.4 rendered one of our laptops unbootable. EM: Failed to open \EFI\BOOT\grubx64.efi - Not Found Failed to load image \EFI\BOOT\grubx64.efi: Not Found start_image() returned Not Found How could this occur because of an update and how to fix this? What I tried is booting from centos usb, chroot to /mnt/sysimage and gave command: efibootmgr --create --label CentOS --disk /dev/sda1 --loader "\EFI\centos\shim.efi" This gave no EM, but booting remains impossible. I have to say I don't know whether to try grub2 of efibootmgr commands. Any help would be very much appreciated. Greetings, J.

3 3

FOSDEM Dojo update
by Rich Bowen 12 Jan '18

12 Jan '18

As you are no doubt aware, we are once again planning to hold a Dojo at the Marriott Grand Place on the Friday before FOSDEM starts - Friday, February 2, 2018. The schedule for the event may be found at https://wiki.centos.org/Events/Dojo/Brussels2018 and includes two tracks covering a wide variety of topics. Attendance at this event is free, but if you plan to attend please register - https://www.eventbrite.com/e/centos-dojo-at-fosdem-tickets-41309238043 - for planning and catering purposes. For those unable to attend, we will be recording (video) both tracks this year, and the sessions will be posted to YouTube as soon after the event as we can manage. See you in Brussels! -- Rich Bowen - rbowen(a)centosproject.org @RDOcommunity // @CentOSProject // @rbowen

1 0

Is kernel-3.10.0-693.11.6.el7 tested with old hardware?
by Gerhard Schneider 12 Jan '18

12 Jan '18

Today we tried to update machines w/ Core2 Duo E6750 from 3.10.0-693.11.1.el7.centos.plus to 3.10.0-693.11.6.el7.centos.plus and the machines did not boot due to a kernel panic. Before we dig any further I wanted to know if the 11.6 kernel has been tested on old hardware, too, or if the problem is well known but not documented (yet). 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

lshw in centos 7
by david 12 Jan '18

12 Jan '18

Folks I've been running lshw for years in both Centos 6 and Centos 7, yet just recently it started hanging. Neither a Control^C nor a "kill" of the process cured the hang; only a reboot. When I run it by hand from the command line, it displays stuff on the next line overwriting it with things like PCI, USB. And USB is the last thing I see. A Control-C does not unlock it. I am running lshw-B.02.18-7.el7.x86_64. The CPU is an Intel I7-3770K, running CentOS 7.4.1708 Is there any idea? Is there some alternate program that could list the hardware? Thanks David

3 2

CentOS 7 autofs flakyness
by m.roth＠5-cent.us 11 Jan '18

11 Jan '18

I have a user who couldn't get in via WinSCP to a server. Got him to log in via putty, and that was fine. But he still couldn't get in the other way. At my manager's suggestion, I restarted autofs... and everything worked. Note that his home director5y was already automounted via NFS, after he logged in via putty. We've seen other, similar oddities with NFS. Is anyone else seeing this, or have a clue? Btw, there were no errors showing in /var/log/messages, journal, I saw this in dmesg: task mount.nfs:83892 blocked for more than 120 seconds, but that was from four days ago, and my user just reported the problem yesterday, though he hadn't tried to use WinSCP in about a month. mark

2 1

1600x900 not available
by Sean Smith 11 Jan '18

11 Jan '18

My laptop is a Dell XPS-13 running CentOS 7. It has a 13" 1920x1080 screen and it's a bit difficult for my mid-40s eyesight. Fedora and Debian, on this laptop, give me the option of choosing 1600x900 which is much easier for me to read but CentOS doesn't show this resolution as available. I followed the steps I found in a post on stackexchange using xrandr, substituting 1600x900 where applicable and it worked but, once I rebooted, it went back to 1920x1080 with no 1600x900 option in settings-display. Is there a way I can add 1600x900 resolution the list of available resolutions in settings-display? Thanks, Sean

5 10

soft lockup after set multicast_router of bridge and it's port to 2
by wuzhouhui 10 Jan '18

10 Jan '18

OS: CentOS 6.5. After I set multicast_router of bridge and it's port to 2, like following: echo 2 > /sys/devices/virtual/net/eth81/bridge/multicast_router echo 2 > /sys/devices/virtual/net/bond2/brport/multicast_router Then soft lockup occured: Message from syslogd@node-0 at Jan 9 15:47:12 ... kernel:BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0] And the call trace is RIP: 0010:[<ffffffffa04f3608>] [<ffffffffa04f3608>] br_multicast_flood+0x88/0x140 [bridge] RSP: 0018:ffff88013bc038f0 EFLAGS: 00000246 RAX: ffff88404f816020 RBX: ffff88013bc03940 RCX: ffff88204e40a640 RDX: ffff882002b9ce01 RSI: ffff882002b9ce80 RDI: 0000000000000000 RBP: ffffffff8100bb93 R08: 0000000000000001 R09: 00000000ff09f4a1 R10: ffff88202c884070 R11: 0000000000000000 R12: ffff88013bc03870 R13: ffff882002b9ce80 R14: ffff88013bc03860 R15: ffffffff8151b225 FS: 0000000000000000(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00007fa11a942000 CR3: 0000000001a85000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a8d020) Stack: 880be7e100028813 ffff882002b9ce80 ffff882002b9ce80 ffffffffa04f3930 <d> 00000000880be7e1 ffff882002b9ce80 ffff882002b9ce80 ffff88200286c042 <d> ffff88202ae7c6e0 ffff882002b9ceb8 ffff88013bc03950 ffffffffa04f36d5 Call Trace: <IRQ> [<ffffffffa04f3930>] ? __br_forward+0x0/0xd0 [bridge] [<ffffffffa04f36d5>] ? br_multicast_forward+0x15/0x20 [bridge] [<ffffffffa04f4a34>] ? br_handle_frame_finish+0x144/0x2a0 [bridge] [<ffffffffa04fa938>] ? br_nf_pre_routing_finish+0x238/0x350 [bridge] [<ffffffffa04faedb>] ? br_nf_pre_routing+0x48b/0x7b0 [bridge] [<ffffffff8143ba57>] ? __kfree_skb+0x47/0xa0 [<ffffffff814734f9>] ? nf_iterate+0x69/0xb0 [<ffffffffa04f48f0>] ? br_handle_frame_finish+0x0/0x2a0 [bridge] [<ffffffff814736b6>] ? nf_hook_slow+0x76/0x120 [<ffffffffa04f48f0>] ? br_handle_frame_finish+0x0/0x2a0 [bridge] [<ffffffffa04f4d1c>] ? br_handle_frame+0x18c/0x250 [bridge] [<ffffffff81445709>] ? __netif_receive_skb+0x529/0x750 [<ffffffff814397da>] ? __alloc_skb+0x7a/0x180 [<ffffffff814492f8>] ? netif_receive_skb+0x58/0x60 [<ffffffff81449400>] ? napi_skb_finish+0x50/0x70 [<ffffffff8144ab79>] ? napi_gro_receive+0x39/0x50 [<ffffffffa016887f>] ? bnx2x_rx_int+0x83f/0x1630 [bnx2x] [<ffffffff810608dc>] ? perf_event_task_sched_out+0x4c/0x70 [<ffffffffa01698ae>] ? bnx2x_poll+0x23e/0x2f0 [bnx2x] [<ffffffff8144ac93>] ? net_rx_action+0x103/0x2f0 [<ffffffff8107a811>] ? __do_softirq+0xc1/0x1e0 [<ffffffff810e6b30>] ? handle_IRQ_event+0x60/0x170 [<ffffffff8100c30c>] ? call_softirq+0x1c/0x30 [<ffffffff8100fa75>] ? do_softirq+0x65/0xa0 [<ffffffff8107a6c5>] ? irq_exit+0x85/0x90 [<ffffffff8151b165>] ? do_IRQ+0x75/0xf0 [<ffffffff8100b9d3>] ? ret_from_intr+0x0/0x11 <EOI> [<ffffffff81016627>] ? mwait_idle+0x77/0xd0 [<ffffffff815176fa>] ? atomic_notifier_call_chain+0x1a/0x20 [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110 [<ffffffff814f6e3a>] ? rest_init+0x7a/0x80 [<ffffffff81c25f70>] ? start_kernel+0x405/0x411 [<ffffffff81c2533a>] ? x86_64_start_reservations+0x125/0x129 [<ffffffff81c25453>] ? x86_64_start_kernel+0x115/0x124 Does anyone know the reason?

1 1

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