Discuss

discuss@lists.centos.org

5 participants
34752 discussions

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

Re: [CentOS] Nvidia maximum pixel clock issue in, , kmod-nvidia-384.98
by Alexander Wiedergold 10 Jan '18

10 Jan '18

To: CentOS mailing list <centos(a)centos.org> Thema: Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98 Dear All, Start BIOS Configuration and go to Graphic Configuration change On Board VGA to PCI Express x16 Automatic is VGA on Board Bis bald Alexander Am 09.01.2018 um 13:00 schrieb centos-request(a)centos.org: > Send CentOS mailing list submissions to > centos(a)centos.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.centos.org/mailman/listinfo/centos > or, via email, send a message with subject or body 'help' to > centos-request(a)centos.org > > You can reach the person managing the list at > centos-owner(a)centos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CentOS digest..." > > > Today's Topics: > > 1. Re: CentOS 7.4 fails to boot as Xen PV guest: resurfaces (now > also) with centosplus kernel 693.11.6.el7 (Johnny Hughes) > 2. Re: Nvidia maximum pixel clock issue in kmod-nvidia-384.98 > (Phil Perry) > 3. C6 KPTI cpuinfo flag? (Robert Arkiletian) > 4. Re: C6 KPTI cpuinfo flag? (isdtor) > 5. Cent OS 7.3 Shared library issue (Aman Sharma) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 8 Jan 2018 06:46:31 -0600 > From: Johnny Hughes <johnny(a)centos.org> > To: centos(a)centos.org > Subject: Re: [CentOS] CentOS 7.4 fails to boot as Xen PV guest: > resurfaces (now also) with centosplus kernel 693.11.6.el7 > Message-ID: <dda9a351-3260-647c-b4f0-5c00f6b3bfd5(a)centos.org> > Content-Type: text/plain; charset="utf-8" > > On 01/08/2018 12:38 AM, Akemi Yagi wrote: >> On Sun, Jan 7, 2018 at 12:07 PM, David Groep <davidg(a)nikhef.nl> wrote: >> >>> Dear all, >>> >>> Maybe I'm the only one - so before filing it as a bug: it appears that >>> the latest set of kernel patches in 3.10.0-693.11.6.el7 makes issue >>> 0013763 "CentOS 7.4 kernel (3.10.0-693*) fails to boot as Xen PV guest" >>> re-surface *also* with the CentOS PLUS kernel. But maybe in a >>> different way ... >>> >>> Thanks to the (great!) quick work on making the plus kernel available >>> (in #14330, thanks for that!) I was able to test the following >>> combinations: >>> >>> - 3.10.0-693.11.6.el7.centos.plus works fine on XenServer 7 HVM guests >>> - 3.10.0-693.11.1.el7.centos.plus works fine on XenServer 7 XenPV guests >>> - 3.10.0-693.11.6.el7.centos.plus crashes on boot for XS7 XenPV guests >>> immediately after the boot stage where the PS/2 drivers are loaded >>> >>> Crashing does not depend on the amount of VM memory or #cores/sockets. >>> Also, the tell-tale "mm/vmalloc.c" failure output is no longer present. >>> The system 'just' crashes (with the kernel log lines as below) around the >>> time of the i8042 controller probing. >>> >>> Obviously the stock upstream 3.10.0-693.11.6.el7 crashes as well for >>> XS7 XenPV guests, but that was to be expected as per 0013763. >>> It crashes in the same way, around the time of the i8042 probes. >>> >>> Can anyone (maybe bill_mcgonigle?) reproduce the issue? >>> Did the KPTI patches break the XenPV fixes in CentOS Plus per 13763? >>> Or is this a new XenPV issue? >>> >> ?You may want to be watching the centos-virt mailing list. Xen-related >> issues are discussed there. >> >> This thread: >> >> ? >> https://lists.centos.org/pipermail/centos-virt/2018-January/005716.html >> >> ?has a response from Johnny Hughes with a possible solution. >> > And specifically, this message has links to the 4.9.75 x86_64 kernel > that will boot and run as a Xen PV kernel: > > https://lists.centos.org/pipermail/centos-virt/2018-January/005721.html > > Also, the latest Xen Dom0 kernel 4.9.75 kernel will also boot a DomU Xen > PV. That kernel is still in testing, and also requires the latest > linux-firmware rpms: > > https://buildlogs.centos.org/centos/7/virt/x86_64/ > > or > > https://buildlogs.centos.org/centos/6/virt/x86_64/ > > > (And your xen version ... xen-44/, xen-46/, xen-48/) > > Those kernels should be signed released to the main Xen repo sometime > this week. > > And as someone has mentioned in another thread (Phil Perry), please read > Greg K-H's (the Kernel.org LTS maintainer, he is in charge of the 4.9.x > LTS tree that we use for the above kernels): > > http://www.kroah.com/log/blog/2018/01/06/meltdown-status/ > > Thanks, > Johnny Hughes > > >

1 0

Audio Output Timer Utility
by Chris Olson 09 Jan '18

09 Jan '18

We have several CentOS 6.x systems that are incorporated into suites of special test equipment. One of the requirements for these systems is that they be kept up to date and they are kept up to date using yum once per week or more frequently, as needed. All of our CentOS 6.x systems have at least 2TB system disks and were installed with essentially everything that was available on the DVD at the time of initial setup. One of our programs is currently in Beta Test which includes both command line and GUI operator inputs and responses. The functional testing requires operator inputs or responses within certain time frames. This timing has usually been implemented with a stopwatch that is operated by a test director. Other timing options would beneficial for complex testing scenarios One of our test directors suggested that we use a digital count- down timer with audio outputs to prompt test operators for their inputs or responses at appropriate times. We have not found such a utility on our CentOS 6 distribution. If there is one available, we would appreciate any information that can be provided. Thanks.

2 2

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