Description of problem:<br />
Opened x48 (version 0.6.4 compiled from source on same host, and recompiled again after first incident of this crash to ensure compatible versions of development packages were pulled-in).<br />
<br />
Version-Release number of selected component:<br />
xorg-x11-server-Xorg-1.19.5-5.1.el7_5<br />
<br />
Truncated backtrace:<br />
0: /usr/bin/X (xorg_backtrace+0x55) [0x561ff2818625]<br />
1: /usr/bin/X (0x561ff266a000+0x1b23b9) [0x561ff281c3b9]<br />
2: /lib64/libpthread.so.0 (0x7fa4ca483000+0xf6d0) [0x7fa4ca4926d0]<br />
3: /usr/bin/X (miHandleValidateExposures+0x29) [0x561ff2810e19]<br />
4: /usr/bin/X (0x561ff266a000+0xe14d2) [0x561ff274b4d2]<br />
5: /usr/bin/X (0x561ff266a000+0xe26e8) [0x561ff274c6e8]<br />
6: /usr/bin/X (0x561ff266a000+0xdd289) [0x561ff2747289]<br />
7: /usr/bin/X (0x561ff266a000+0x78592) [0x561ff26e2592]<br />
8: /usr/bin/X (FreeResource+0xde) [0x561ff26e316e]<br />
9: /usr/bin/X (0x561ff266a000+0xe1bf1) [0x561ff274bbf1]<br />
10: /usr/bin/X (0x561ff266a000+0xe237b) [0x561ff274c37b]<br />
11: /usr/bin/X (0x561ff266a000+0xe0bd7) [0x561ff274abd7]<br />
12: /usr/bin/X (ReparentWindow+0x217) [0x561ff26ef897]<br />
13: /usr/bin/X (0x561ff266a000+0x4defc) [0x561ff26b7efc]<br />
14: /usr/bin/X (0x561ff266a000+0x53b2b) [0x561ff26bdb2b]<br />
15: /usr/bin/X (0x561ff266a000+0x57bca) [0x561ff26c1bca]<br />
16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fa4ca0d8445]<br />
17: /usr/bin/X (0x561ff266a000+0x41c9e) [0x561ff26abc9e]
↧
0015411: [abrt] xorg-x11-server-Xorg: Xorg server crashed
↧
0005105: Bogus accounts threaten webite
Forum moderators have been battling spammers creating bogus accounts by the thousands using automated "bots". The only way moderators currently have to attack the problem is by a laborious process of searching for such accounts and selecting them for deletion. This has been working, although at the cost of considerable time to perform the operations; however, such accounts are currently being created at a rate of thousands per day making deletion of 50 at a time via the web interface a practical impossibility.<br />
<br />
Our approach has been to delete all "Inactive" accounts more than 7 days old (these are being created at a rate of about 1 per minute) and "Active" accounts with no posts and either no logins, or with no logins in the last 30 days. The latter are the rapidly growing problem, and more than 40,000 accounts with zero posts created between 7 and 30 days ago currently exist. Account creation at this rate will likely bring the site down if the situation is not dealt with soon.<br />
<br />
Proposed approach:<br />
<br />
1. Implement some automated way of deleting accounts as described above.<br />
2. Implement captcha or some other mechanism in the account creation process to foil the bots.
↧
↧
0004826: 5.6 missing from torrent.centos.org
The torrents themselves are operating, but the directories and .torrent files are missing from torrent.centos.org.
↧
0008239: [RFE] include installer images in update composes
Currently package upgrades are provided through the upgrade repo, but this does not coveri nstaller images.<br />
<br />
The problem is that bugs which affect anaconda are never landing in any installer image, so currently I need to wait for the next minor release to get an installer image updated.<br />
<br />
I'd love to see regular updates of the<br />
- boot.iso<br />
- netboot.iso<br />
- pxeboot initrd, vmlinuz and squashfs images<br />
- efi boot image<br />
<br />
The regular updates will help to enable the CI for oVirt Node (and Engine) which are using CentOS.
↧
0017818: systemctl restart ceph.osd@X results in issue
Running "systemctl restart <a href="mailto:ceph-osd@3">ceph-osd@3</a>" it complains about /var/lib/ceph/osd/ceph-3 missing.. and it is BUT if I do the following:<br />
<br />
[<a href="mailto:root@node1">root@node1</a> osd]# pwd<br />
/var/lib/ceph/osd<br />
[<a href="mailto:root@node1">root@node1</a> osd]# ln -s ../4242410a-e8d8-11ea-a7d6-001b21d6d88c/osd.3<br />
<br />
it resolves the issue.. It seems like the systemctl script is expecting the "old" location but the new version of ceph puts these files in the FSID of the cluster (the cluster ID) AND also expects the osd name and not the "ceph-3" name (ie: osd.3 vs ceph-3).<br />
<br />
I'm guessing some package needs to be updated to match up ceph somehow?<br />
<br />
Also when it actually does restart with my work around the process looks completely different:<br />
ceph 3278 3251 1 10:04 ? 00:01:12 /usr/bin/ceph-osd -n osd.0 -f --setuser ceph --setgroup ceph --default-log-to-file=false --default-log-to-stderr=true --default-log-stderr-prefix=debug <br />
ceph 3400 3381 0 10:04 ? 00:00:37 /usr/bin/ceph-osd -n osd.2 -f --setuser ceph --setgroup ceph --default-log-to-file=false --default-log-to-stderr=true --default-log-stderr-prefix=debug <br />
ceph 3454 3423 0 10:04 ? 00:00:32 /usr/bin/ceph-osd -n osd.1 -f --setuser ceph --setgroup ceph --default-log-to-file=false --default-log-to-stderr=true --default-log-stderr-prefix=debug <br />
ceph 14467 1 0 10:42 ? 00:00:27 /usr/bin/ceph-osd -f --cluster ceph --id 3 --setuser ceph --setgroup ceph<br />
<br />
you can see the last entry has different params.. i'm guessing it'll be deprecated soon?
↧
↧
0017767: Firefox update 78.3.0-1 breaks sound (32bit)
Latest firefox update from 68.12.0-1 --> 78.3.0-1 breaks sound in HTML5 and Flash Videos. There is no sound icon on the tabs and no sound is reproduced.
↧
0017813: Add config_cfs_bandwith to aarch64 kernel builds.
This is a sister bug to:<br />
<a href="https://github.com/raspberrypi/linux/issues/3387">https://github.com/raspberrypi/linux/issues/3387</a><br />
<br />
I originally reported this to CRI-O here:<br />
<a href="https://github.com/cri-o/cri-o/issues/4307">https://github.com/cri-o/cri-o/issues/4307</a><br />
<br />
<br />
Essentially, without config_cfs_bandwith enabled in the kernel, docker/cri-o/kubernetes doesn't function on CentOS 8 aarch64 images due to '/sys/fs/cgroup/cpu/cpu.cfs_quota_us' missing.
↧
0017437: wireguard not working on kernel 5.4.42
wireguard stops working after kernel-update from 5.4.28 to 5.4.42
↧
0017819: [abrt] dnf: python2.7 killed by SIGSEGV
Version-Release number of selected component:<br />
dnf-4.0.9.2-1.el7_6<br />
<br />
Truncated backtrace:<br />
Thread no. 1 (10 frames)<br />
#0 ??<br />
#1 _dl_init_internal at /lib64/ld-linux-x86-64.so.2<br />
#2 dl_open_worker at /lib64/ld-linux-x86-64.so.2<br />
#3 _dl_catch_error at /lib64/ld-linux-x86-64.so.2<br />
#4 _dl_open at /lib64/ld-linux-x86-64.so.2<br />
#5 dlopen_doit at dlopen.c:66<br />
#6 _dl_catch_error at /lib64/ld-linux-x86-64.so.2<br />
#7 _dlerror_run at dlerror.c:163<br />
#8 __dlopen at dlopen.c:87<br />
#9 _PyImport_GetDynLoadFunc at /usr/src/debug/Python-2.7.5/Python/dynload_shlib.c:135
↧
↧
0017820: iPXE sanboot centos 8 iscsi volume fails due to lacking of iscsi_ibft.ko
iPXE sanboot centos 8 iscsi volume fails due to lacking of iscsi_ibft.ko.<br />
<br />
<br />
sanboot failed og:<br />
[ 9.798081] random: 7 urandom warning(s) missed due to ratelimiting<br />
[ 69.839050] dracut-initqueue[533]: Warning: dhcp for interface enp2s0 failed<br />
[ 69.952293] dracut-initqueue[533]: RTNETLINK answers: File exists<br />
[ 70.029839] dracut-initqueue[533]: iscsiadm: Could not get list of targets from firmware. (err 21)<br />
[ 70.032780] dracut-initqueue[533]: Warning: iscsiadm: Could not get list of targets from firmware.<br />
[ 70.674042] dracut-initqueue[533]: Error: inet address is expected rather than "0.0.1.".<br />
[ 70.704573] dracut-initqueue[533]: iscsiadm: Could not get list of targets from firmware. (err 21)<br />
[ 70.708265] dracut-initqueue[533]: Warning: iscsiadm: Could not get list of targets from firmware.<br />
[ 223.746155] dracut-initqueue[533]: Warning: dracut-initqueue timeout - starting timeout scripts<br />
Stopping Open-iSCSI...<br />
[ OK ] Stopped Open-iSCSI.<br />
Stopping iSCSI UserSpace I/O driver...<br />
[ OK ] Stopped iSCSI UserSpace I/O driver.<br />
Starting iSCSI UserSpace I/O driver...<br />
[ OK ] Started iSCSI UserSpace I/O driver.<br />
Starting Open-iSCSI...<br />
[ OK ] Started Open-iSCSI.<br />
[ 226.040617] dracut-initqueue[533]: iscsiadm: Could not get list of targets from firmware. (err 21)<br />
[ 226.044474] dracut-initqueue[533]: Warning: iscsiadm: Could not get list of targets from firmware.<br />
[ 226.712573] dracut-initqueue[533]: Warning: dracut-initqueue timeout - starting timeout scripts
↧
0017822: pam_tty_audit.so does not function in 8.2.2004 or 8.1.1911
Brand new installation of CentOS 8.2.2004/8.1.1911, and modified password-auth, system-auth, and sshd in pam.d to include session required pam_tty_audit.so enable=*. Example pam.d\sshd config below:<br />
<br />
#%PAM-1.0<br />
auth substack password-auth<br />
auth include postlogin<br />
account required pam_sepermit.so<br />
account required pam_nologin.so<br />
account include password-auth<br />
password include password-auth<br />
# pam_selinux.so close should be the first session rule<br />
session required pam_selinux.so close<br />
session required pam_loginuid.so<br />
session required pam_tty_audit.so enable=*<br />
# pam_selinux.so open should only be followed by sessions to be executed in the user context<br />
session required pam_selinux.so open env_params<br />
session required pam_namespace.so<br />
session optional pam_keyinit.so force revoke<br />
session optional pam_motd.so<br />
session include password-auth<br />
session include postlogin<br />
<br />
If I log in with my account, sudo over to root, and execute command line options such as ls, top, cd /, etc. I DO NOT get entries in the audit.log with type=USER_TTY. NOTE: I have this running and tested on a new CentOS 7.8 installation as well on production systems.
↧
0017823: After 24 (or more hours) audio becomes crackley,
When running youtube (in firefox or chrome) or vlc, after 24 hours logged in, the audio starts crackling after one track ends and the next begins. closing the browser or vlc does not fix the problem, however, logging out and back in may fix it, but rebooting does fix it.
↧
0017824: sbc-devel package not available
The sbc-devel package is not available.<br />
<br />
This is needed for rebuilding Wireshark (similar to bug #16504 for libsmi-devel), especially since we have local custom dissectors.
↧
↧
0017825: iab ( abbrerevation feature ) - seems to be broken.
My .vimrc has some 'iab' abbrevations, and I'm not able to get this feature to work on either RHEL or Centos 8.
↧
0017652: Add wireguard to kernel-plus (c8)
WireGuard was merged into Linux 5.6. The source code has been backported to kernels 3.10 to 5.5 and is available from the wireguard-linux-compat.git repository. Procedure to build it is described in [1].<br />
<br />
Note also that regular kernel users can use ELRepo's kmod-wireguard to get this functionality [2].<br />
<br />
[1] <a href="https://www.wireguard.com/compilation/">https://www.wireguard.com/compilation/</a><br />
[2] <a href="http://elrepo.org/tiki/tiki-index.php?page=kmod-wireguard">http://elrepo.org/tiki/tiki-index.php?page=kmod-wireguard</a>
↧
0017826: CentOS 7 with SCL enabled only provides PHP 7.3.11
Hi Everyone,<br />
<br />
My apologies if this is the wrong place to report this issue.<br />
<br />
We have a CentOS 7 VM with Red Hat's SCL enabled. It runs our website and wiki at <a href="https://www.cryptopp.com">https://www.cryptopp.com.</a> SCL is enabled so we can get an updated Apache, Python, PHP and friends.<br />
<br />
Our current Mediawiki is 1.34. 1.34 is _not_ a Long Term Support (LTS) release. We want to migrate to Mediawiki 1.35. 1.35 is a LTS release.<br />
<br />
We cannot migrate to Mediawiki 1.35 at the moment because CentOS 7 and SCL only provides PHP 7.3.11. Mediawiki 1.35 requires PHP 7.3.19.<br />
<br />
Our request is, please bump PHP's version to 7.3.19 so we can install Mediawiki 1.35.<br />
<br />
Also see <a href="https://www.mediawiki.org/wiki/Talk:MediaWiki_1.35">https://www.mediawiki.org/wiki/Talk:MediaWiki_1.35.</a> It asks Mediawiki to downgrade their PHP requirements.
↧
0014584: console.apps.ci.centos.org containers stuck in creating
Hey Brian,<br />
I know we've pinged you a bit about this lately on irc, but wanted to get some formal tracking. We are still seeing this issue:<br />
<a href="https://console.apps.ci.centos.org:8443/console/project/continuous-infra/browse/pods/rpmbuild-274-build?tab=details">https://console.apps.ci.centos.org:8443/console/project/continuous-infra/browse/pods/rpmbuild-274-build?tab=details</a><br />
At time of writing, that container has been creating for over 4 hours. It seems every time you fix the issue, however you do it, it fixes itself for a few hours then we have to ping you again, so here I am =|<br />
<br />
Thanks!
↧
↧
0017828: Please make Judy-devel available in CentOS 8
Per <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1854339">https://bugzilla.redhat.com/show_bug.cgi?id=1854339</a> please can Judy-devel be provided in the devel repo:<br />
<br />
<a href="https://src.fedoraproject.org/rpms/Judy">https://src.fedoraproject.org/rpms/Judy</a>
↧
0017830: System does not recognize LUKS devices in dracut boot process
System has two identical SSDs configured as RAID0 and encrypted. After the latest update, system cannot boot and the dracut reports:<br />
- /dev/xxxx/root does not exist<br />
- /dev/xxxx/swap does not exist<br />
- crypto LUKS UUID xxx not found<br />
where xxxx stands for the machine designation or the actual UUID<br />
<br />
blkid finds:<br />
- /dev/sdb TYPE="isw_raid_member"<br />
- /dev/sda TYPE="isw_raid_member"<br />
- /dev/md126 PTTYPE="PMBR"<br />
where sda and sdb are the identically sized RAID0 members. There are two additional harddisks recognized but not relevant to the boot process.<br />
<br />
Further, the grub2 commandline lists the two LUKS disks as rd.md.uuid=xxx (for each disk) and then rd.luks.uuid=xxx for the LUKS partition which is not recognized in the dracut boot process.<br />
<br />
If I remove both of the rd.md.uuid statements and replace with a single rd.md=0 the machine boots, I enter the password and everything seems to work EXCEPT only one of the two disks have been unlocked and clearly they are not in RAID0 mode anymore.<br />
<br />
Two questions:<br />
- Can I work around this and boot in RAID0 mode and decrypt both harddisks until a fix has been released?<br />
- Can we get a fix for this very serious bug quickly?<br />
<br />
Thank you.
↧
0017829: ca-certificate refresh from NSS
Is it possible to refresh the default ca-certificates package for supported CentOS versions with the latest NSS roots?<br />
<br />
Specifically, we would like to ensure these two roots from NSS 3.54 (26 June 2020) are included in the package:<br />
<br />
Microsoft ECC Root Certificate Authority 2017<br />
SHA-256 Fingerprint: 358DF39D764AF9E1B766E9C972DF352EE15CFAC227AF6AD1D70E8E4A6EDCBA02<br />
<br />
Microsoft RSA Root Certificate Authority 2017<br />
SHA-256 Fingerprint: C741F70F4B2A8D88BF2E71C14122EF53EF10EBA0CFA5E64CFA20F418853073E0
↧