Version-Release number of selected component:<br />
setroubleshoot-server-3.2.27.2-3.el7<br />
<br />
Truncated backtrace:<br />
analyze.py:294:prune:ValueError: list modified during sort<br />
<br />
Traceback (most recent call last):<br />
File "/usr/lib64/python2.7/site-packages/setroubleshoot/analyze.py", line 377, in auto_save_callback<br />
self.save()<br />
File "/usr/lib64/python2.7/site-packages/setroubleshoot/analyze.py", line 355, in save<br />
self.prune()<br />
File "/usr/lib64/python2.7/site-packages/setroubleshoot/analyze.py", line 294, in prune<br />
self.sigs.signature_list.sort(lambda a,b: cmp(a.last_seen_date, b.last_seen_date))<br />
ValueError: list modified during sort<br />
<br />
Local variables in innermost frame:<br />
self: <setroubleshoot.analyze.SETroubleshootDatabase object at 0x217dad0>
↧
0013142: [abrt] setroubleshoot-server: analyze.py:294:prune:ValueError: list modified during sort
↧
0015731: Sync buildlogs and mirrors for devtoolset-8 SCL
Please add synchronization for the devtoolset-8 collection.<br />
<br />
Buildlogs:<br />
sclo7-devtoolset-8-rh-testing|7/sclo/x86_64/rh/devtoolset-8/|7/sclo/x86_64/rh/|7/sclo/x86_64/rh/<br />
<br />
Mirrors:<br />
sclo7-devtoolset-8-rh-release|7/sclo/x86_64/rh/devtoolset-8/|7/sclo/x86_64/rh/|7/sclo/x86_64/rh/
↧
↧
0015732: SCL repository metadata isn't properly signed with SCLo GPG key
The repositories for SCLs do not appear to have the metadata signed with the SCLo GPG key anymore. This needs to be fixed. Potentially other repositories are affected, but this one was the one that was noticed immediately.
↧
0015733: SELinux is preventing /usr/sbin/plymouthd from 'map' accesses on the chr_file /dev/fb0.
Description of problem:<br />
SELinux is preventing /usr/sbin/plymouthd from 'map' accesses on the chr_file /dev/fb0.<br />
<br />
***** Plugin catchall (100. confidence) suggests **************************<br />
<br />
If you believe that plymouthd should be allowed map access on the fb0 chr_file by default.<br />
Then you should report this as a bug.<br />
You can generate a local policy module to allow this access.<br />
Do<br />
allow this access for now by executing:<br />
# ausearch -c 'plymouthd' --raw | audit2allow -M my-plymouthd<br />
# semodule -i my-plymouthd.pp<br />
<br />
Additional Information:<br />
Source Context system_u:system_r:plymouthd_t:s0<br />
Target Context system_u:object_r:framebuf_device_t:s0<br />
Target Objects /dev/fb0 [ chr_file ]<br />
Source plymouthd<br />
Source Path /usr/sbin/plymouthd<br />
Port <Unknown><br />
Host (removed)<br />
Source RPM Packages plymouth-0.8.9-0.31.20140113.el7.centos.x86_64<br />
Target RPM Packages <br />
Policy RPM selinux-policy-3.13.1-229.el7_6.6.noarch<br />
Selinux Enabled True<br />
Policy Type targeted<br />
Enforcing Mode Enforcing<br />
Host Name (removed)<br />
Platform Linux (removed) 3.10.0-957.1.3.el7.x86_64 #1 SMP<br />
Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64<br />
Alert Count 310<br />
First Seen 2019-01-01 00:09:59 +07<br />
Last Seen 2019-01-21 17:56:22 +07<br />
Local ID ba3501ef-ab79-48e0-a307-c7575b630f8c<br />
<br />
Raw Audit Messages<br />
type=AVC msg=audit(1548068182.224:1468910): avc: denied { map } for pid=12730 comm="plymouthd" path="/dev/fb0" dev="devtmpfs" ino=17809 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:framebuf_device_t:s0 tclass=chr_file permissive=0<br />
<br />
<br />
type=SYSCALL msg=audit(1548068182.224:1468910): arch=x86_64 syscall=mmap success=no exit=EACCES a0=0 a1=2b1100 a2=2 a3=1 items=0 ppid=1 pid=12730 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=plymouthd exe=/usr/sbin/plymouthd subj=system_u:system_r:plymouthd_t:s0 key=(null)<br />
<br />
Hash: plymouthd,plymouthd_t,framebuf_device_t,chr_file,map<br />
<br />
Version-Release number of selected component:<br />
selinux-policy-3.13.1-229.el7_6.6.noarch
↧
0015186: Cannot boot with kernel-2.6.32-754.3.5.el6.x86_64
After installing the recent kernel (kernel-2.6.32-754.3.5.el6.x86_64), my system can no longer boot. Grub comes up, I select the new kernel and the screen goes black with a white solid box cursor on the top left. At this point keyboard doesn't respond at all and the system just sits there. I've tried removing quiet from the kernel parameters to see if I could get some error messages but no additional messages are produced after selecting the latest kernel. Selecting the previous kernel works and brings the system back up.
↧
↧
0015628: [abrt] xorg-x11-server-Xorg: Xorg server crashed
Version-Release number of selected component:<br />
xorg-x11-server-Xorg-1.20.1-5.1.el7<br />
<br />
Truncated backtrace:<br />
0: /usr/bin/X (xorg_backtrace+0x55) [0x5623a7a8b185]<br />
1: /usr/bin/X (0x5623a78da000+0x1b4e09) [0x5623a7a8ee09]<br />
2: /lib64/libpthread.so.0 (0x7f5a617ef000+0xf5d0) [0x7f5a617fe5d0]<br />
3: /lib64/libc.so.6 (gsignal+0x37) [0x7f5a61458207]<br />
4: /lib64/libc.so.6 (abort+0x148) [0x7f5a614598f8]<br />
5: /lib64/libc.so.6 (0x7f5a61422000+0x2f026) [0x7f5a61451026]<br />
6: /lib64/libc.so.6 (0x7f5a61422000+0x2f0d2) [0x7f5a614510d2]<br />
7: /usr/lib64/xorg/modules/libexa.so (0x7f5a5c91e000+0x2500) [0x7f5a5c920500]<br />
8: /usr/lib64/xorg/modules/libexa.so (0x7f5a5c91e000+0x7237) [0x7f5a5c925237]<br />
9: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f5a5d98c000+0x5359d) [0x7f5a5d9df59d]<br />
10: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f5a5d98c000+0x54561) [0x7f5a5d9e0561]<br />
11: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f5a5d98c000+0x4dc30) [0x7f5a5d9d9c30]<br />
12: /usr/bin/X (AbortDDX+0x85) [0x5623a7975525]<br />
13: /usr/bin/X (0x5623a78da000+0x1bd772) [0x5623a7a97772]<br />
14: /usr/bin/X (0x5623a78da000+0x1be5dd) [0x5623a7a985dd]<br />
15: /usr/bin/X (0x5623a78da000+0x1b4e69) [0x5623a7a8ee69]<br />
16: /lib64/libpthread.so.0 (0x7f5a617ef000+0xf5d0) [0x7f5a617fe5d0]<br />
17: /lib64/libc.so.6 (gsignal+0x37) [0x7f5a61458207]<br />
18: /lib64/libc.so.6 (abort+0x148) [0x7f5a614598f8]<br />
19: /lib64/libc.so.6 (0x7f5a61422000+0x2f026) [0x7f5a61451026]<br />
20: /lib64/libc.so.6 (0x7f5a61422000+0x2f0d2) [0x7f5a614510d2]<br />
21: /usr/lib64/xorg/modules/libexa.so (0x7f5a5c91e000+0x2500) [0x7f5a5c920500]<br />
22: /usr/lib64/xorg/modules/libexa.so (0x7f5a5c91e000+0x7237) [0x7f5a5c925237]<br />
23: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f5a5d98c000+0x5359d) [0x7f5a5d9df59d]<br />
24: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f5a5d98c000+0x54561) [0x7f5a5d9e0561]<br />
25: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f5a5d98c000+0x4dc30) [0x7f5a5d9d9c30]<br />
26: /usr/bin/X (0x5623a78da000+0xac274) [0x5623a7986274]<br />
27: /usr/bin/X (0x5623a78da000+0xc88dc) [0x5623a79a28dc]<br />
28: /usr/bin/X (0x5623a78da000+0xe7bf8) [0x5623a79c1bf8]<br />
29: /usr/bin/X (0x5623a78da000+0x132d53) [0x5623a7a0cd53]<br />
30: /usr/bin/X (0x5623a78da000+0x604c4) [0x5623a793a4c4]<br />
31: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f5a614443d5]<br />
32: /usr/bin/X (0x5623a78da000+0x4a4ce) [0x5623a79244ce]
↧
0015734: [abrt] evolution: gdk_x11_device_manager_xi2_translate_event(): evolution killed by SIGSEGV
Version-Release number of selected component:<br />
evolution-3.28.5-2.el7<br />
<br />
Truncated backtrace:<br />
Thread no. 1 (6 frames)<br />
#0 gdk_x11_device_manager_xi2_translate_event at gdkdevicemanager-xi2.c:1711<br />
#1 _gdk_x11_event_translator_translate at gdkeventtranslator.c:51<br />
#2 gdk_event_source_translate_event at gdkeventsource.c:230<br />
#3 _gdk_x11_display_queue_events at gdkeventsource.c:341<br />
#4 gdk_display_get_event at gdkdisplay.c:438<br />
#10 gtk_main at gtkmain.c:1323
↧
0015735: Boot speed regression with 219-62.el7_6.2
We are seeing a significant boot speed regression with systems using systemd 219-62.el7_6.2 <br />
<br />
Starting with the standard 1809 upstream cloud image [1] we have upgraded to the latest 3.10.0-957.1.3.el7.x86_64 kernel and dracut-033-554.el7.<br />
<br />
We see standard initramfs boot times, measured between the two welcome outputs, of around 20s (leading timestamps from qemu console)<br />
<br />
---<br />
[00:00:08.819] Welcome to CentOS Linux 7 (Core) dracut-033-554.el7 (Initramfs)!<br />
[00:00:37.331] Welcome to CentOS Linux 7 (Core)!<br />
---<br />
<br />
Sample boot in vanilla.txt<br />
<br />
We then upgrade just systemd (to 219-62.el7_6.2) and regenerate the initramfs (logs in dracut.txt)<br />
<br />
The boot is then consistently slower; up to a minute<br />
<br />
---<br />
[00:00:05.598] Welcome to CentOS Linux 7 (Core) dracut-033-554.el7 (Initramfs)!<br />
[00:01:10.092] Welcome to CentOS Linux 7 (Core)!<br />
---<br />
<br />
The bulk of the time lost appears to be in this section seeming around device enumeration or similar<br />
<br />
For example; on a vanilla boot this section completes in a handful of seconds<br />
<br />
---<br />
[00:00:23.597] [ 22.180822] Floppy drive(s): fd0 is 2.88M AMI BIOS<br />
[00:00:23.733] [ 22.317691] FDC 0 is a S82078B<br />
[00:00:24.371] [ 22.955816] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI<br />
[00:00:24.372] [ 22.956397] e1000: Copyright (c) 1999-2006 Intel Corporation.<br />
[00:00:25.540] [ 24.124559] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11<br />
[00:00:25.871] [ 24.455781] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56<br />
[00:00:25.872] [ 24.456548] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection<br />
[00:00:25.972] [ 24.556354] scsi host0: ata_piix<br />
[00:00:25.983] [ 24.567042] scsi host1: ata_piix<br />
[00:00:25.987] [ 24.568560] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc040 irq 14<br />
[00:00:25.988] [ 24.572632] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc048 irq 15<br />
[00:00:26.151] [ 24.735266] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100<br />
[00:00:26.151] [ 24.735677] ata1.00: 16777216 sectors, multi 16: LBA48 <br />
[00:00:26.154] [ 24.736601] ata1.00: configured for MWDMA2<br />
[00:00:26.172] [ 24.756606] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100<br />
[00:00:26.174] [ 24.758058] ata2.00: configured for MWDMA2<br />
[00:00:26.182] [ 24.759598] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5<br />
[00:00:26.223] [ 24.807081] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5<br />
[00:00:26.728] [ 25.304171] sr 1:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray<br />
[00:00:26.728] [ 25.312774] cdrom: Uniform CD-ROM driver Revision: 3.20<br />
[00:00:26.827] [ 25.410954] sd 0:0:0:0: [sda] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)<br />
[00:00:26.834] [ 25.413448] sd 0:0:0:0: [sda] Write Protect is off<br />
[00:00:26.854] [ 25.438570] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA<br />
[00:00:26.875] [ 25.459216] sda: sda1<br />
[00:00:26.938] [ 25.512092] sd 0:0:0:0: [sda] Attached SCSI disk<br />
[00:00:27.437] [ OK ] Found device QEMU_HARDDISK 1.<br />
---<br />
<br />
but with the new systemd we consistently see this taking 30s or longer<br />
<br />
---<br />
[00:00:32.579] [ 31.849773] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI<br />
[00:00:32.581] [ 31.853670] e1000: Copyright (c) 1999-2006 Intel Corporation.<br />
[00:00:35.997] [ 35.257500] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11<br />
[00:00:36.355] [ 35.626662] Floppy drive(s): fd0 is 2.88M AMI BIOS<br />
[00:00:36.432] [ 35.701279] FDC 0 is a S82078B<br />
[00:00:38.522] [ 37.793928] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56<br />
[00:00:38.524] [ 37.796910] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection<br />
[00:00:38.916] [ 38.178057] scsi host0: ata_piix<br />
[00:00:39.058] [ 38.330017] scsi host1: ata_piix<br />
[00:00:39.080] [ 38.352710] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc040 irq 14<br />
[00:00:39.081] [ 38.353662] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc048 irq 15<br />
[00:00:39.243] [ 38.515027] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100<br />
[00:00:39.243] [ 38.515104] ata1.00: 16777216 sectors, multi 16: LBA48 <br />
[00:00:39.247] [ 38.517247] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100<br />
[00:00:39.249] [ 38.521332] ata1.00: configured for MWDMA2<br />
[00:00:39.281] [ 38.553352] ata2.00: configured for MWDMA2<br />
[00:00:39.347] [ 38.608707] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5<br />
[00:00:39.628] [ 38.900089] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 <------------ this long pause is very consistent!<br />
[00:00:56.392] [ 55.657487] sr 1:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray<br />
[00:00:56.394] [ 55.666568] cdrom: Uniform CD-ROM driver Revision: 3.20<br />
[00:00:57.374] [ 56.645341] sd 0:0:0:0: [sda] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)<br />
[00:00:57.449] [ 56.720919] sd 0:0:0:0: [sda] Write Protect is off<br />
[00:00:57.463] [ 56.735477] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA<br />
[00:00:57.623] [ 56.894502] sda: sda1<br />
[00:00:57.864] [ 57.136359] sd 0:0:0:0: [sda] Attached SCSI disk<br />
[00:00:58.858] [ OK ] Found device QEMU_HARDDISK 1.<br />
---<br />
<br />
Note the only thing that has changed is the upgrade of systemd and the regeneration of the initramfs. I have extracted both the old and new initramfs and compared them; the non-binary diff components are small and consist of <a href="http://paste.openstack.org/show/743145/">http://paste.openstack.org/show/743145/.</a> The other changes all just reflect the binary changes in the systemd tools.<br />
<br />
The "MountFlags=slave" in the udev service looked suspect; however reverting that change, regenerating the initramfs and rebooting showed no difference. <br />
<br />
<br />
<br />
<br />
[1] <a href="https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1809.qcow2">https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1809.qcow2</a>
↧
0015736: Problem with selection of keymap on installation process
When installing CentOS 6 an hour ago, while installing the system, it shows danger on root password and user account, but, top right you can select the keymap for typing. Imagine writing a password with special chars on that keymap but before selected language english and keymap spanish because in my country there are more expensive the keymaps from us.<br />
<br />
The problem is not able to change the keymap us to es for writing a password, then I must know where the chars are.<br />
<br />
I haven't researched enough, but I think it's happening.
↧
↧
0015531: [abrt] kernel: WARNING: CPU: 1 PID: 97 at drivers/gpu/drm/nouveau/nvif/vmm.c:71 nvif_vmm_put+0x86/0x90 [nouveau]
Version-Release number of selected component:<br />
kernel<br />
<br />
Truncated backtrace:<br />
WARNING: CPU: 1 PID: 97 at drivers/gpu/drm/nouveau/nvif/vmm.c:71 nvif_vmm_put+0x86/0x90 [nouveau]<br />
Modules linked in: tcp_lp fuse devlink ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp intel_rapl snd_hda_codec_hdmi iosf_mbi kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd joydev asus_wmi sparse_keymap rfkill i2c_i801 pcspkr snd_hda_codec_realtek snd_hda_codec_generic sg snd_hda_intel snd_hda_codec<br />
snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd mei_me soundcore lpc_ich mei ip_tables xfs libcrc32c sd_mod sr_mod cdrom crc_t10dif crct10dif_generic nouveau crct10dif_pclmul crct10dif_common crc32c_intel mxm_wmi serio_raw ttm e1000 i2c_algo_bit drm_kms_helper ahci syscopyarea sysfillrect sysimgblt fb_sys_fops libahci drm libata video r8169 mii drm_panel_orientation_quirks wmi dm_mirror dm_region_hash dm_log dm_mod<br />
CPU: 1 PID: 97 Comm: kworker/1:1 Kdump: loaded Not tainted 3.10.0-957.1.3.el7.x86_64 #1<br />
Hardware name: System manufacturer System Product Name/P8Z77-V LX2, BIOS 2204 08/23/2013<br />
Workqueue: events nouveau_cli_work [nouveau]<br />
Call Trace:<br />
[<ffffffffb1961e41>] dump_stack+0x19/0x1b<br />
[<ffffffffb1297648>] __warn+0xd8/0x100<br />
[<ffffffffb129778d>] warn_slowpath_null+0x1d/0x20<br />
[<ffffffffc060ed46>] nvif_vmm_put+0x86/0x90 [nouveau]<br />
[<ffffffffc06d8786>] nouveau_vma_del+0x76/0xa0 [nouveau]<br />
[<ffffffffc06d525a>] nouveau_gem_object_delete_work+0x3a/0x60 [nouveau]<br />
[<ffffffffc06cf7aa>] nouveau_cli_work+0xba/0xf0 [nouveau]<br />
[<ffffffffb12b9d4f>] process_one_work+0x17f/0x440<br />
[<ffffffffb12bade6>] worker_thread+0x126/0x3c0<br />
[<ffffffffb12bacc0>] ? manage_workers.isra.25+0x2a0/0x2a0<br />
[<ffffffffb12c1c31>] kthread+0xd1/0xe0<br />
[<ffffffffb12c1b60>] ? insert_kthread_work+0x40/0x40<br />
[<ffffffffb1974c37>] ret_from_fork_nospec_begin+0x21/0x21<br />
[<ffffffffb12c1b60>] ? insert_kthread_work+0x40/0x40
↧
0015737: Cannot boot ISO using Disk on Key
Trying to boot the latest CentOS on old IBM X3550 M3 servers shows an error (for 2 seconds)<br />
<br />
Failed to set MokListRT: Invalid Parameter<br />
Something has gone seriously wrong: import_mok_state() failed:<br />
Invalid Parameter<br />
<br />
And then the machine powers off.
↧
0015484: SELinux is preventing /usr/libexec/ibus-x11 from 'setattr' accesses on the directory cache.
Description of problem:<br />
entered (as su) yum update --disablerepo=c7-media<br />
SELinux is preventing /usr/libexec/ibus-x11 from 'setattr' accesses on the directory cache.<br />
<br />
***** Plugin catchall (100. confidence) suggests **************************<br />
<br />
If you believe that ibus-x11 should be allowed setattr access on the cache directory by default.<br />
Then you should report this as a bug.<br />
You can generate a local policy module to allow this access.<br />
Do<br />
allow this access for now by executing:<br />
# ausearch -c 'ibus-x11' --raw | audit2allow -M my-ibusx11<br />
# semodule -i my-ibusx11.pp<br />
<br />
Additional Information:<br />
Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023<br />
Target Context system_u:object_r:lib_t:s0<br />
Target Objects cache [ dir ]<br />
Source ibus-x11<br />
Source Path /usr/libexec/ibus-x11<br />
Port <Unknown><br />
Host (removed)<br />
Source RPM Packages ibus-1.5.17-2.el7.x86_64<br />
Target RPM Packages <br />
Policy RPM selinux-policy-3.13.1-192.el7_5.6.noarch<br />
Selinux Enabled True<br />
Policy Type targeted<br />
Enforcing Mode Enforcing<br />
Host Name (removed)<br />
Platform Linux (removed) 3.10.0-862.11.6.el7.x86_64 #1 SMP<br />
Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64<br />
Alert Count 47<br />
First Seen 2018-11-22 14:03:02 EST<br />
Last Seen 2018-11-22 14:05:21 EST<br />
Local ID 939cac64-a520-43eb-9c28-e444e0635b4a<br />
<br />
Raw Audit Messages<br />
type=AVC msg=audit(1542913521.450:663): avc: denied { setattr } for pid=5628 comm="ibus-x11" name="cache" dev="dm-0" ino=33617201 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=dir<br />
<br />
<br />
type=SYSCALL msg=audit(1542913521.450:663): arch=x86_64 syscall=chmod success=no exit=EACCES a0=10c6e70 a1=1ed a2=10c6e89 a3=1 items=0 ppid=1 pid=5628 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm=ibus-x11 exe=/usr/libexec/ibus-x11 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)<br />
<br />
Hash: ibus-x11,xdm_t,lib_t,dir,setattr<br />
<br />
Version-Release number of selected component:<br />
selinux-policy-3.13.1-192.el7_5.6.noarch
↧
0015738: diffrence between rhel7 yum group list ids and centos7 and listed ids that are not available, please synchronize with rhel
I found an issue that the yum group list ids are not identical between rhel7 and centos7.<br />
<br />
Then there are ids listed in centos7 that do not seem to work that do work on rhel and visa versa. <br />
<br />
Can we please synchronize the yum group list ids with rhel7, if they are broken lets keep them at least broken in the same ways?<br />
<br />
Thank you very much for all the hard work.<br />
<br />
I listed the information in the additional information, two systems one centos7 one rhel7
↧
↧
0014716: ntpd.service starts too soon in the boot process (before network) and fails to recover when network comes up
The default ntpd.service defines the unit dependency as:<br />
<br />
After=syslog.target ntpdate.service sntp.service <br />
<br />
This means that it can be started before NetworkManager starts up. When this happens, it's not able to resolve the server entries in /etc/ntp.conf and gets stuck in a bad state until it is restarted manually.
↧
0015216: 3.10.0-862.9.1.el7.x86_64 kernel panic and crash under hadoop environment
We have about 30 hadoop nodes(datanode, nodemanager, presto worker) with kernel 3.10.0-862.9.1.el7.x86_64 and these nodes randomly cause kernel panic and crash.<br />
Recently we setup kdump and can get vmcore.<br />
<br />
Here is the crash command result<br />
```<br />
crash> sys<br />
KERNEL: /usr/lib/debug/lib/modules/3.10.0-862.9.1.el7.x86_64/vmlinux<br />
DUMPFILE: vmcore [PARTIAL DUMP]<br />
CPUS: 40<br />
DATE: Fri Aug 24 03:27:27 2018<br />
UPTIME: 13 days, 19:27:57<br />
LOAD AVERAGE: 21.81, 18.43, 15.18<br />
TASKS: 2640<br />
NODENAME: SOMEHOST<br />
RELEASE: 3.10.0-862.9.1.el7.x86_64<br />
VERSION: #1 SMP Mon Jul 16 16:29:36 UTC 2018<br />
MACHINE: x86_64 (2199 Mhz)<br />
MEMORY: 255.9 GB<br />
PANIC: "BUG: unable to handle kernel paging request at 0000000025fc6f8b"<br />
crash> bt<br />
PID: 139574 TASK: ffff8e84016c8fd0 CPU: 23 COMMAND: "java"<br />
#0 [ffff8e842c88f618] machine_kexec at ffffffffb186178a<br />
#1 [ffff8e842c88f678] __crash_kexec at ffffffffb1913bf2<br />
#2 [ffff8e842c88f748] crash_kexec at ffffffffb1913ce0<br />
#3 [ffff8e842c88f760] oops_end at ffffffffb1f18738<br />
#4 [ffff8e842c88f788] no_context at ffffffffb1f0807e<br />
#5 [ffff8e842c88f7d8] __bad_area_nosemaphore at ffffffffb1f08115<br />
#6 [ffff8e842c88f828] bad_area_nosemaphore at ffffffffb1f08286<br />
#7 [ffff8e842c88f838] __do_page_fault at ffffffffb1f1b6f0<br />
#8 [ffff8e842c88f8a0] do_page_fault at ffffffffb1f1b8e5<br />
#9 [ffff8e842c88f8d0] page_fault at ffffffffb1f17758<br />
[exception RIP: find_busiest_group+869]<br />
RIP: ffffffffb18dc645 RSP: ffff8e842c88f980 RFLAGS: 00010807<br />
RAX: 0000000025fc7000 RBX: 0000000000000001 RCX: 0000000000000498<br />
RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000001<br />
RBP: ffff8e842c88fae8 R8: 00000000000006f7 R9: 0000000000000002<br />
R10: 000000000000049a R11: 0000000000000000 R12: ffff8e842c88fb48<br />
R13: ffff8e842c88f9b8 R14: 0000000000000000 R15: 0000000000000800<br />
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br />
#10 [ffff8e842c88faf0] load_balance at ffffffffb18dcde8<br />
#11 [ffff8e842c88fbd8] idle_balance at ffffffffb18ddc71<br />
#12 [ffff8e842c88fc30] __schedule at ffffffffb1f13f5f<br />
#13 [ffff8e842c88fcb0] schedule at ffffffffb1f14029<br />
#14 [ffff8e842c88fcc0] futex_wait_queue_me at ffffffffb1903d46<br />
#15 [ffff8e842c88fd00] futex_wait at ffffffffb1904a2b<br />
#16 [ffff8e842c88fe48] do_futex at ffffffffb1906786<br />
#17 [ffff8e842c88fed8] sys_futex at ffffffffb1906ca0<br />
#18 [ffff8e842c88ff50] system_call_fastpath at ffffffffb1f20795<br />
RIP: 00007fe50b5a1a82 RSP: 00007fe4cfaef5a0 RFLAGS: 00010206<br />
RAX: 00000000000000ca RBX: 0000000000000005 RCX: ffffffffff9882ec<br />
RDX: 00000000000005ad RSI: 0000000000000089 RDI: 00007fe504134954<br />
RBP: 00007fe4cfaf2ba0 R8: 00007fe504134928 R9: 00000000ffffffff<br />
R10: 00007fe4cfaf2b60 R11: 0000000000000202 R12: 00000000000005ad<br />
R13: 00007fe4cfaf2b60 R14: ffffffffffffff92 R15: 00007fe504134900<br />
ORIG_RAX: 00000000000000ca CS: 0033 SS: 002b<br />
```<br />
<br />
PID: 139574 is the normal hive job.<br />
<br />
Any suggestions?
↧
0015740: kernel memory leak when performing xenstore operations
The CentOS 6.10 kernels (and RHEL 6.10) all have a memory leak that occurs with every operation on the /proc/xen/xenbus file. These operations can happen whenever CentOS 6.10 is running as a VM on any Xen system (the open source Xen Project and XenServer).
↧
0012652: No HTTP Strict Transport Security (HSTS) or centos.org
As of writing, there is no HTTP Strict Transport Security (HSTS) for centos.org. Explanations at: <a href="https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security">https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security</a> - HSTS with long duration would be my personal expectation.
↧
↧
0012883: AWS CentOS 7 does not support i3 instance types
AWS announced released i3's yesterday. The Centos 7 AMI has not been updated yet and can't be used with an i3 instance type.<br />
<br />
AMI: <a href="https://aws.amazon.com/marketplace/pp/B00O7WM7QW">https://aws.amazon.com/marketplace/pp/B00O7WM7QW</a>
↧
0015743: etcd package included is downrev with known defects that affect CPU consumption
The etcd package distributed with the latest CentOS 7.6.1810 is still at etcd-3.2.22-1. This version of etcd contains two defects that cause large CPU consumption when the etcd server connection is lost: <a href="https://github.com/etcd-io/etcd/issues/9578">https://github.com/etcd-io/etcd/issues/9578</a> and <a href="https://github.com/etcd-io/etcd/issues/9740">https://github.com/etcd-io/etcd/issues/9740.</a> Fixes to correct the defects were merged into the etcd code base in June of 2018. <br />
<br />
When we use the 3.2.22 version of etcd with our application we launch the etcd proxy on several systems and the etcd server on one system. When we shut down the etcd server the CPU consumption on the systems running etcd proxy jumps to 223%.<br />
<br />
I'd like to request upgrading the version of etcd bundled with CentOS to eliminate this issue.
↧
0015744: libvirtd.service fails to start
Return of command<br />
<br />
# systemctl status libvirtd.service<br />
<br />
--------------------------------------------------------------------------------------------------------------------------------------------<br />
<br />
● libvirtd.service - Virtualization daemon<br />
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; disabled; vendor preset: enabled)<br />
Active: failed (Result: start-limit) since Thu 2019-01-24 21:54:04 EST; 1min 11s ago<br />
Docs: man:libvirtd(8)<br />
<a href="https://libvirt.org">https://libvirt.org</a><br />
Main PID: 21263 (code=exited, status=3)<br />
<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: Failed to start Virtualization daemon.<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: Unit libvirtd.service entered failed state.<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: libvirtd.service failed.<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: libvirtd.service holdoff time over, scheduling restart.<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: Stopped Virtualization daemon.<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: start request repeated too quickly for libvirtd.service<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: Failed to start Virtualization daemon.<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: Unit libvirtd.service entered failed state.<br />
Jan 24 21:54:04 CentOS7Server systemd[1]: libvirtd.service failed.<br />
<br />
--------------------------------------------------------------------------------------------------------------------------------------------<br />
<br />
Return of command<br />
<br />
# journalctl --no-pager -u libvirtd.service<br />
<br />
--------------------------------------------------------------------------------------------------------------------------------------------<br />
<br />
Jan 24 22:00:45 CentOS7Server systemd[1]: Starting Virtualization daemon...<br />
Jan 24 22:00:45 CentOS7Server libvirtd[21780]: 2019-01-25 03:00:45.783+0000: 21780: info : libvirt version: 4.5.0, package: 10.el7_6.3 (CentOS BuildSystem <<a href="http://bugs.centos.org>,">http://bugs.centos.org>,</a> 2018-11-28-20:51:39, x86-01.bsys.centos.org)<br />
Jan 24 22:00:45 CentOS7Server libvirtd[21780]: 2019-01-25 03:00:45.783+0000: 21780: info : hostname: CentOS7Server<br />
Jan 24 22:00:45 CentOS7Server libvirtd[21780]: 2019-01-25 03:00:45.783+0000: 21780: error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/lib64/libvirt/connection-driver/libvirt_driver_interface.so': libexslt.so.0: cannot open shared object file: No such file or directory<br />
Jan 24 22:00:45 CentOS7Server systemd[1]: libvirtd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED<br />
Jan 24 22:00:45 CentOS7Server systemd[1]: Failed to start Virtualization daemon.<br />
Jan 24 22:00:45 CentOS7Server systemd[1]: Unit libvirtd.service entered failed state.<br />
Jan 24 22:00:45 CentOS7Server systemd[1]: libvirtd.service failed.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service holdoff time over, scheduling restart.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Stopped Virtualization daemon.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Starting Virtualization daemon...<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21792]: 2019-01-25 03:00:46.066+0000: 21792: info : libvirt version: 4.5.0, package: 10.el7_6.3 (CentOS BuildSystem <<a href="http://bugs.centos.org>,">http://bugs.centos.org>,</a> 2018-11-28-20:51:39, x86-01.bsys.centos.org)<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21792]: 2019-01-25 03:00:46.066+0000: 21792: info : hostname: CentOS7Server<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21792]: 2019-01-25 03:00:46.066+0000: 21792: error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/lib64/libvirt/connection-driver/libvirt_driver_interface.so': libexslt.so.0: cannot open shared object file: No such file or directory<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Failed to start Virtualization daemon.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Unit libvirtd.service entered failed state.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service failed.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service holdoff time over, scheduling restart.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Stopped Virtualization daemon.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Starting Virtualization daemon...<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21813]: 2019-01-25 03:00:46.316+0000: 21813: info : libvirt version: 4.5.0, package: 10.el7_6.3 (CentOS BuildSystem <<a href="http://bugs.centos.org>,">http://bugs.centos.org>,</a> 2018-11-28-20:51:39, x86-01.bsys.centos.org)<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21813]: 2019-01-25 03:00:46.316+0000: 21813: info : hostname: CentOS7Server<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21813]: 2019-01-25 03:00:46.316+0000: 21813: error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/lib64/libvirt/connection-driver/libvirt_driver_interface.so': libexslt.so.0: cannot open shared object file: No such file or directory<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Failed to start Virtualization daemon.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Unit libvirtd.service entered failed state.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service failed.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service holdoff time over, scheduling restart.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Stopped Virtualization daemon.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Starting Virtualization daemon...<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21825]: 2019-01-25 03:00:46.565+0000: 21825: info : libvirt version: 4.5.0, package: 10.el7_6.3 (CentOS BuildSystem <<a href="http://bugs.centos.org>,">http://bugs.centos.org>,</a> 2018-11-28-20:51:39, x86-01.bsys.centos.org)<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21825]: 2019-01-25 03:00:46.565+0000: 21825: info : hostname: CentOS7Server<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21825]: 2019-01-25 03:00:46.565+0000: 21825: error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/lib64/libvirt/connection-driver/libvirt_driver_interface.so': libexslt.so.0: cannot open shared object file: No such file or directory<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Failed to start Virtualization daemon.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Unit libvirtd.service entered failed state.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service failed.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service holdoff time over, scheduling restart.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Stopped Virtualization daemon.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Starting Virtualization daemon...<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21837]: 2019-01-25 03:00:46.814+0000: 21837: info : libvirt version: 4.5.0, package: 10.el7_6.3 (CentOS BuildSystem <<a href="http://bugs.centos.org>,">http://bugs.centos.org>,</a> 2018-11-28-20:51:39, x86-01.bsys.centos.org)<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21837]: 2019-01-25 03:00:46.814+0000: 21837: info : hostname: CentOS7Server<br />
Jan 24 22:00:46 CentOS7Server libvirtd[21837]: 2019-01-25 03:00:46.814+0000: 21837: error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/lib64/libvirt/connection-driver/libvirt_driver_interface.so': libexslt.so.0: cannot open shared object file: No such file or directory<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Failed to start Virtualization daemon.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: Unit libvirtd.service entered failed state.<br />
Jan 24 22:00:46 CentOS7Server systemd[1]: libvirtd.service failed.<br />
Jan 24 22:00:47 CentOS7Server systemd[1]: libvirtd.service holdoff time over, scheduling restart.<br />
Jan 24 22:00:47 CentOS7Server systemd[1]: Stopped Virtualization daemon.<br />
Jan 24 22:00:47 CentOS7Server systemd[1]: start request repeated too quickly for libvirtd.service<br />
Jan 24 22:00:47 CentOS7Server systemd[1]: Failed to start Virtualization daemon.<br />
Jan 24 22:00:47 CentOS7Server systemd[1]: Unit libvirtd.service entered failed state.<br />
Jan 24 22:00:47 CentOS7Server systemd[1]: libvirtd.service failed.<br />
<br />
--------------------------------------------------------------------------------------------------------------------------------------------<br />
Return of command<br />
<br />
# systemctl start libvirtd.service<br />
<br />
--------------------------------------------------------------------------------------------------------------------------------------------<br />
<br />
Job for libvirtd.service failed because the control process exited with error code. See "systemctl status libvirtd.service" and "journalctl -xe" for details.<br />
<br />
--------------------------------------------------------------------------------------------------------------------------------------------<br />
<br />
Return of command<br />
<br />
# libvirtd<br />
<br />
--------------------------------------------------------------------------------------------------------------------------------------------<br />
<br />
2019-01-25 03:13:15.173+0000: 22586: info : libvirt version: 4.5.0, package: 10.el7_6.3 (CentOS BuildSystem <<a href="http://bugs.centos.org>,">http://bugs.centos.org>,</a> 2018-11-28-20:51:39, x86-01.bsys.centos.org)<br />
2019-01-25 03:13:15.173+0000: 22586: info : hostname: CentOS7Server<br />
2019-01-25 03:13:15.173+0000: 22586: error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/lib64/libvirt/connection-driver/libvirt_driver_interface.so': libexslt.so.0: cannot open shared object file: No such file or directory
↧