Rocky Linux BugTracker

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4885	[Rocky-Linux-9] rocky-release	major	always	2023-12-01 15:41	2023-12-01 15:41

Reporter:	Shashank Kumar	Platform:	Rocky Linux 9
Assigned To:		OS:	Rocky Linux 9
Priority:	urgent	OS Version:	9
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	module system_probe_policy 1.0; ' on line 1109: system_probe_policy.te:4:ERROR 'unrecognized character' at token '
Description:	module system_probe_policy 1.0; ' on line 1109: system_probe_policy.te:4:ERROR 'unrecognized character' at token ' During one chef execution I had to compile a system_probe_policy.te file which holds custom selinux policy, but when the command "make -C /etc/selinux/local -f /usr/share/selinux/devel/Makefile" ran it threw errors on all lines in the .te file.
Tags:
Steps To Reproduce:	During one chef execution I had to compile a system_probe_policy.te file which holds custom selinux policy, but when the command "make -C /etc/selinux/local -f /usr/share/selinux/devel/Makefile" ran it threw errors on all lines in the .te file.
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4522	[Rocky-Linux-8] kernel	major	always	2023-10-19 09:46	2023-12-01 02:56

Reporter:	Dominika Wanat	Platform:	el8
Assigned To:		OS:	Rocky Linux
Priority:	high	OS Version:	8.8
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	mdraid I/O hang during check/resync
Description:	We are experiencing a mdraid thread hang during the check/resync operations on the pools on our HPC storage cluster running on the kernel `4.18.0-477.21.1.el8_8`, which causes the IO to hang. In some cases, we can observe the following trace: ``` Oct 19 01:17:13 tscratch-oss03 kernel: INFO: task md3_raid6:2418 blocked for more than 120 seconds. Oct 19 01:17:13 tscratch-oss03 kernel: Tainted: G OE X --------- - - 4.18.0-477.21.1.el8_8.x86_64 #1 Oct 19 01:17:13 tscratch-oss03 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 19 01:17:13 tscratch-oss03 kernel: task:md3_raid6 state:D stack: 0 pid: 2418 ppid: 2 flags:0x80004000 Oct 19 01:17:13 tscratch-oss03 kernel: Call Trace: Oct 19 01:17:13 tscratch-oss03 kernel: __schedule+0x2d1/0x870 Oct 19 01:17:13 tscratch-oss03 kernel: ? raid5_wakeup_stripe_thread+0x98/0x220 [raid456] Oct 19 01:17:13 tscratch-oss03 kernel: schedule+0x55/0xf0 Oct 19 01:17:13 tscratch-oss03 kernel: raid5d+0x4a7/0x6c0 [raid456] Oct 19 01:17:13 tscratch-oss03 kernel: ? del_timer_sync+0x25/0x40 Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: ? md_register_thread+0xe0/0xe0 Oct 19 01:17:13 tscratch-oss03 kernel: md_thread+0x94/0x160 Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: kthread+0x134/0x150 Oct 19 01:17:13 tscratch-oss03 kernel: ? set_kthread_struct+0x50/0x50 Oct 19 01:17:13 tscratch-oss03 kernel: ret_from_fork+0x1f/0x40 Oct 19 01:17:13 tscratch-oss03 kernel: INFO: task jbd2/dm-0-8:4036 blocked for more than 120 seconds. Oct 19 01:17:13 tscratch-oss03 kernel: Tainted: G OE X --------- - - 4.18.0-477.21.1.el8_8.x86_64 #1 Oct 19 01:17:13 tscratch-oss03 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 19 01:17:13 tscratch-oss03 kernel: task:jbd2/dm-0-8 state:D stack: 0 pid: 4036 ppid: 2 flags:0x80004080 Oct 19 01:17:13 tscratch-oss03 kernel: Call Trace: Oct 19 01:17:13 tscratch-oss03 kernel: __schedule+0x2d1/0x870 Oct 19 01:17:13 tscratch-oss03 kernel: ? __wake_up_common_lock+0x89/0xc0 Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: schedule+0x55/0xf0 Oct 19 01:17:13 tscratch-oss03 kernel: jbd2_journal_commit_transaction+0x259/0x19f0 [jbd2] Oct 19 01:17:13 tscratch-oss03 kernel: ? newidle_balance+0x279/0x3c0 Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_task_switch+0x86/0x2e0 Oct 19 01:17:13 tscratch-oss03 kernel: ? lock_timer_base+0x67/0x90 Oct 19 01:17:13 tscratch-oss03 kernel: kjournald2+0xbd/0x270 [jbd2] Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: ? commit_timeout+0x10/0x10 [jbd2] Oct 19 01:17:13 tscratch-oss03 kernel: kthread+0x134/0x150 Oct 19 01:17:13 tscratch-oss03 kernel: ? set_kthread_struct+0x50/0x50 Oct 19 01:17:13 tscratch-oss03 kernel: ret_from_fork+0x1f/0x40 Oct 19 01:17:13 tscratch-oss03 kernel: INFO: task jbd2/dm-1-8:4037 blocked for more than 120 seconds. Oct 19 01:17:13 tscratch-oss03 kernel: Tainted: G OE X --------- - - 4.18.0-477.21.1.el8_8.x86_64 #1 Oct 19 01:17:13 tscratch-oss03 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 19 01:17:13 tscratch-oss03 kernel: task:jbd2/dm-1-8 state:D stack: 0 pid: 4037 ppid: 2 flags:0x80004080 Oct 19 01:17:13 tscratch-oss03 kernel: Call Trace: Oct 19 01:17:13 tscratch-oss03 kernel: __schedule+0x2d1/0x870 Oct 19 01:17:13 tscratch-oss03 kernel: schedule+0x55/0xf0 Oct 19 01:17:13 tscratch-oss03 kernel: md_write_start+0x14f/0x220 Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: raid5_make_request+0x93/0xe00 [raid456] Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: ? mempool_alloc+0x67/0x180 Oct 19 01:17:13 tscratch-oss03 kernel: ? do_wait_intr_irq+0xa0/0xa0 ct 19 01:17:13 tscratch-oss03 kernel: ? generic_make_request_checks+0x2a5/0x4f0 Oct 19 01:17:13 tscratch-oss03 kernel: ? dm_io_acct+0x49/0xe0 [dm_mod] Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: md_handle_request+0x128/0x1b0 Oct 19 01:17:13 tscratch-oss03 kernel: md_make_request+0x5b/0xb0 Oct 19 01:17:13 tscratch-oss03 kernel: generic_make_request_no_check+0x202/0x330 Oct 19 01:17:13 tscratch-oss03 kernel: submit_bio+0x3c/0x160 Oct 19 01:17:13 tscratch-oss03 kernel: ? bio_add_page+0x46/0x60 Oct 19 01:17:13 tscratch-oss03 kernel: submit_bh_wbc+0x16a/0x1a0 Oct 19 01:17:13 tscratch-oss03 kernel: jbd2_journal_commit_transaction+0x6b0/0x19f0 [jbd2] Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_task_switch+0x86/0x2e0 Oct 19 01:17:13 tscratch-oss03 kernel: kjournald2+0xbd/0x270 [jbd2] Oct 19 01:17:13 tscratch-oss03 kernel: ? finish_wait+0x80/0x80 Oct 19 01:17:13 tscratch-oss03 kernel: ? commit_timeout+0x10/0x10 [jbd2] Oct 19 01:17:13 tscratch-oss03 kernel: kthread+0x134/0x150 Oct 19 01:17:13 tscratch-oss03 kernel: ? set_kthread_struct+0x50/0x50 Oct 19 01:17:13 tscratch-oss03 kernel: ret_from_fork+0x1f/0x40 Oct 19 01:17:13 tscratch-oss03 kernel: INFO: task ll_ost02_000:4110 blocked for more than 120 seconds. Oct 19 01:17:13 tscratch-oss03 kernel: Tainted: G OE X --------- - - 4.18.0-477.21.1.el8_8.x86_64 #1 Oct 19 01:17:13 tscratch-oss03 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. ``` In some cases, this stack trace is not generated, and the problem is escalated to the upper storage layer, where Lustre informs us that it is unhealthy because of the RPC timeouts. We are confident that the mdraid layer causes the problem because we found a similar bug report on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.11/+bug/1942935 and the workaround presented there: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.11/+bug/1942935/comments/10 unlocks the IO on the affected pool and the Lustre restores to a healthy state. Unfortunately, applications on the HPC cluster are IO-sensitive, so even this solution causes many timeouts and crashed jobs. The above-mentioned bug report also has a reproducer and the patch proposition, which was never merged into the kernel mainline.
Tags:	io hang, kernel, mdraid
Steps To Reproduce:
Additional Information:
Attached Files:	redacted-trace-kvm.txt (25,465 bytes) 2023-11-24 04:02 https://bugs.rockylinux.org/file_download.php?file_id=1057&type=bug

Notes
(0005203) Perry MacDonald 2023-11-24 04:02	I think I might be running into a similar situation, though ours is with storage for a handful of KVM VMs. I've attached a copy of the traces I'm seeing in this similar situation. It appears to have started after upgrading to 8.8, we have 7 of these boxes in production currently but only two have been upgraded to 8.8. The others are running on 8.7 and have been stable. Hardware is a mix of Dell R7515 and R7525's with NVIDIA GPUs running 3-4 Windows VMs each as a makeshift VDI solution. Until now they have bee fairly reliable. Storage is 4x 2T 970 EVO Plus NVMe drives in a md raid 5 with xfs on top. Normally I would not run a config like this but latency/performance is the goal and these workstations can fairly easily be rebuilt. So far I've caught this issue once while a raid check was occuring, but I don't know for sure on the others. Currently this happens every few days to two weeks. When this hits, the VMs appear to lose access to their storage. The mount is still there and I can see the VM files, but as with the linked reports any attempts to interact with the array will hang. Hard reboot of the box is the only way out of it. So far I've tested adding nvme_core.default_ps_max_latency_us=0 after looking at some ASPM issue posts, but no change. I've also tweaked the group_thread_cnt to 6 and the stripe_cache_size to 8192. Seems to have improved performance, but still having this crash issue. Happy to provide more details if needed, been ongoing for a couple of months now so I may have missed some details.

(0005215) Perry MacDonald 2023-12-01 02:56	Further investigations and testing - looks like my issue may be unrelated to this one as https://access.redhat.com/solutions/7029392 (raid5_get_active_stripe deadlock) seems to line up better now that I've really dug into the trace. My apologies.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4852	[Rocky-Linux-9] kernel	major	always	2023-11-23 21:41	2023-11-23 21:41

Reporter:	Andreas Springer	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	After upgrade from kernel-5.14.0-284.30.1.el9_2 to kernel-5.14.0-362.8.1.el9_3, tpm2 is no longer detected
Description:	When booting up kernel-5.14.0-362.8.1.el9_3, drive encryption doesn't unlock automatically (via clevis), dmesg shows a line tpm_crb: probe of MSFT0101:00 failed with error 378 and ls /dev/tpm* comes back empty. Booting the older kernel, drive unlocks, /dev/tpm0 and /dev/tpmrm0 exist CPU is a Intel Celeron N5100 dmesg entries related to tpm (not sure where else I can get more information on what tpm it is): [ 0.000000] efi: ACPI=0x757d0000 ACPI 2.0=0x757d0014 TPMFinalLog=0x757d3000 SMBIOS=0x75c7b000 SMBIOS 3.0=0x75c7a000 MEMATTR=0x71190018 ESRT=0x720abe98 MOKvar=0x75c56000 RNG=0x75c7eb98 TPMEventLog=0x6fa1a018 [ 0.009419] ACPI: TPM2 0x00000000756BB000 00004C (v04 ALASKA A M I 00000001 AMI 00000000) [ 0.009445] ACPI: Reserving TPM2 table memory at [mem 0x756bb000-0x756bb04b]
Tags:
Steps To Reproduce:	1. Boot vmlinuz-5.14.0-362.8.1.el9_3.x86_64 2. Check dmesg output for error 378 3. Verify that ls /dev/tpm* shows no tpm devices
Additional Information:	Symptoms look identical to https://bugzilla.redhat.com/show_bug.cgi?id=2232888 although that refers to a much newer kernel.
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4753	[Rocky-Linux-9] fipscheck	text	always	2023-11-16 04:57	2023-11-21 23:46

Reporter:	Sagar Patil	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Openssl3 shows Red Hat Enterprise Linux 9 in list -providers
Description:	When Fips enabled in Rocky Linux we see Red Hat Enterprise Linux 9 under fips name . openssl list -providers Providers: base name: OpenSSL Base Provider version: 3.0.7 status: active default name: OpenSSL Default Provider version: 3.0.7 status: active fips name: Red Hat Enterprise Linux 9 - OpenSSL FIPS Provider version: 3.0.7-38f89367593abbfc status: active Is this expected or the name should be replaced with Rocky Linux in providers list?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0005149) Sagar Patil 2023-11-17 05:15	It was on Rocky Linux 9

(0005202) Louis Abel 2023-11-21 23:46	Thank you for the report. The FIPS provider is indeed provided by Red Hat, and thus that is how it's named. We do not see this as a branding issue. We do not maintain the provider that Red Hat works on themselves. Setting to needinfo, as the rest of the release engineering team will discuss this further down the road.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4390	[Rocky-Linux-8] General	minor	have not tried	2023-10-10 08:07	2023-11-21 13:44

Reporter:	Martin Litwora	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	AWS AMI support for the UEFI
Description:	RockyLinux8 images seems to be UEFI ready in AWS (eg. they have the efibootmgr package installed) but I'm not able to boot the instance as an UEFI. Possibly the issue is caused by the fact that the boot method for the AMI instance is not set: [cloudshell-user@ip-10-2-38-115 ~]$ aws ec2 describe-images --region us-east-1 --image-id ami-097104a26f5e1c26a { "Images": [ { "Architecture": "x86_64", "CreationDate": "2023-06-06T15:25:09.000Z", "ImageId": "ami-097104a26f5e1c26a", "ImageLocation": "aws-marketplace/Rocky-8-EC2-Base-8.8-20230518.0.x86_64-d6577ceb-8ea8-4e0e-84c6-f098fc302e82", :...skipping... { "Images": [ { "Architecture": "x86_64", "CreationDate": "2023-06-06T15:25:09.000Z", "ImageId": "ami-097104a26f5e1c26a", "ImageLocation": "aws-marketplace/Rocky-8-EC2-Base-8.8-20230518.0.x86_64-d6577ceb-8ea8-4e0e-84c6-f098fc302e82", "ImageType": "machine", "Public": true, "OwnerId": "679593333241", "PlatformDetails": "Linux/UNIX", "UsageOperation": "RunInstances", "ProductCodes": [ { "ProductCodeId": "cotnnspjrsi38lfn8qo4ibnnm", "ProductCodeType": "marketplace" } ], "State": "available", "BlockDeviceMappings": [ { "DeviceName": "/dev/sda1", "Ebs": { "DeleteOnTermination": true, "SnapshotId": "snap-01e9e7f8f03c4af12", "VolumeSize": 10, "VolumeType": "gp2", "Encrypted": false } } ], "Description": "Rocky-8-EC2-Base-8.8-20230518.0.x86_64", "EnaSupport": true, "Hypervisor": "xen", "ImageOwnerAlias": "aws-marketplace", "Name": "Rocky-8-EC2-Base-8.8-20230518.0.x86_64-d6577ceb-8ea8-4e0e-84c6-f098fc302e82", "RootDeviceName": "/dev/sda1", "RootDeviceType": "ebs", "VirtualizationType": "hvm", "DeprecationTime": "2025-06-06T15:25:09.000Z" } ] } There is missing "BootMode". Can you please add it to make the rocky UEFI ready? Set the BootMode to "uefi-preferred". https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launch-instance-boot-mode.html#UEFI-supported-types https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot-mode.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0004853) Neil Hanlon 2023-10-10 13:39	Hm, i will need to look into this. As far as I know, these are new options and have not been available for use before. There were previously only two options--BIOS or UEFI. You are correct that our images support both. I would recommend, in the mean time, that you clone the AMI and set this parameter yourself. I will look into setting this parameter for our 8.9 and 9.3 images in a month's time or so.

(0004859) Martin Litwora 2023-10-12 07:17	Thanks, Neil! Setting this parameter for 8.9/9.3 is sufficient for me.

(0005182) Neil Hanlon 2023-11-19 21:58	https://git.resf.org/sig_core/toolkit/commit/ca358f61174be9e176e949210676153eac1f5ebf

(0005189) Neil Hanlon 2023-11-21 13:44	All set - thank you!

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4786	[Rocky-Linux-9] fio	minor	always	2023-11-17 09:47	2023-11-17 09:47

Reporter:	tyree chow	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	The performance of rantrim on nvme ssd is significantly worse than upstream linux kernel.
Description:	Recently, I replaced my server's kernel with rocky's 5.14.0-162.18.1.el9_1 (downloaded from https://oraclelinux.pkgs.org/9/ol9-baseos-latest-x86_64/kernel-5.14.0-162.18.1.el9_1.x86_64.rpm.html ). Then I used Fio to perform stress testing on my NVME SSD and compared the performance with Upstream's Linux 5.14.0 kernel. When using the randtrim command, I found that randtrim performed significantly lower in rocky than upstream. The result of IOPS of randtrim on Rocky's 5.13 is around 50k while it is 240k in upstream's kernel.
Tags:
Steps To Reproduce:	The running command of fio is below: fio -filename=/dev/nvme0n1 -direct=1 -ioengine=libaio -rw=randtrim -bs=4k -iodepth=64 -numjobs=8 -group_reporting -name=randtrimfob --norandommap --randrepeat=0 --ramp_time=5 -runtime=30
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4754	[Rocky-Linux-8] crypto-policies	minor	always	2023-11-16 09:50	2023-11-16 09:50

Reporter:	Susanne ---	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Crypto-policies Option "min rsa size" not working in RockyLinux 8
Description:	Hello, regadless of the Crypto-policy set, it is possible to login with a rsa 1024 key. I think this is possibly due to the OpenSSH version installed in RockyLinux 8. The "min rsa size" in the Crypto-Policies set the value for the option "RequiredRSASize" in OpenSSH configuration, but this option was just implemented in OpenSSH version 9.0. Fedora 37 has implemented the patch openssh-server-8.8p1-7.fc37 which fixed the issue.
Tags:
Steps To Reproduce:	- generate an rsa 1024 key and copy this to the server ssh-keygen -t rsa -b 1024 -f ~/.ssh/cp_rsa1024 ssh-copy-id -i ~/.ssh/crypt_1024rsa.pub root@rocky8 - set crypto-policy to something bigger then LEGACY update-crypto-policies --set Default reboot - login with the 1024key ssh -i ~/.ssh/crypt_1024rsa root@root@rocky8 -v expected behavior: debug1: Offering public key: .ssh/crypt_1024rsa RSA SHA256:hkpFBRW/y76PZlG903lf1POqZ90DQfFoRfpqFqD/BwY explicit, debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password, debug1: Next authentication method: password root@root@rocky8 password actual behavior: debug1: Next authentication method: publickey debug1: Offering public key: .ssh/crypt_1024rsa RSA SHA256:hkpFBRW/y76PZlG903lf1POqZ90DQfFoRfpqFqD/BwY explicit, debug1: Server accepts key: .ssh/crypt_1024rsa RSA SHA256:hkpFBRW/y76PZlG903lf1POqZ90DQfFoRfpqFqD/BwY explicit, debug1: Authentication succeeded (publickey). Authenticated to rocky8 ([...]:22).
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4720	[Rocky-Linux-9] pam	minor	always	2023-11-09 16:58	2023-11-14 17:07

Reporter:	Andy Wang	Platform:	x86_64
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9.2
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	pam_echo.so echoes the message twice for sshd
Description:	The pam_echo module in sshd's configuration should result in the specified text to be printed upon connecting to the machine via SSH. However, on Rocky Linux 9, the message is duplicated. My `/etc/pam.d/sshd`: ``` #%PAM-1.0 auth substack password-auth auth include postlogin account optional pam_echo.so foobar account required pam_sepermit.so account required pam_nologin.so account include password-auth password include password-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session required pam_namespace.so session optional pam_keyinit.so force revoke session optional pam_motd.so session include password-auth session include postlogin ```
Tags:
Steps To Reproduce:	1. Edit `/etc/pam.d/sshd`, add line `account optional pam_echo.so foobar` under the existing `auth include postlogin` line 2. SSH into the machine 3. "foobar" will be printed to stderr twice
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4623	[Rocky-Linux-9] kernel	minor	always	2023-10-27 01:47	2023-10-27 14:33

Reporter:	Tuan Hoang	Platform:	x86_64
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9.2
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Stock kernel packages missing
Description:	I'm developing 3rd party driver packages for EL9.2 (i.e. elrepo) and went to install the stock kernel-devel-5.14.0-284.11.1.el9_2.x86_64, but the package cannot be found in the DNF repos. sudo dnf makecache --refresh sudo dnf install kernel-devel-5.14.0-284.11.1.el9_2.x86_64 I was expecting them to be here, but it appears that only the latest errata kernel-devel package is there. https://download.rockylinux.org/pub/rocky/9/AppStream/x86_64/os/Packages/k/ I was able to locate a signed copy of the RPM from here: https://download.rockylinux.org/pub/rocky/9/AppStream/x86_64/kickstart/Packages/k/ Can you please restore at least the stock EL9.2 kernel packages (5.14.0-284.11.1.el9_2) to the DNF repos?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0005017) Lukas Magauer 2023-10-27 09:16	Hey there! This is a current limitation of Peridot, which only keeps the latest package in the official repos. Of course this will be changed, but takes time. For the moment skip is hosting a additive mirror, which also keeps the old versions: https://skiprocky.linuxdn.org/rocky9_archive/9.2/AppStream/x86_64/

(0005018) Tuan Hoang 2023-10-27 14:33	Thanks for the update and the mirror site!

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4622	[Rocky Linux Build System] General	minor	always	2023-10-27 01:32	2023-10-27 01:32

Reporter:	hirofumi minami	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[ 8.829764] I/O error, dev sr0, sector 8 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Description:	Microsoft azure ,market place kit has a small bugs. in boot these message scream too many .... console log puncture. [ 8.813952] sr 0:0:0:2: [sr0] tag#85 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s [ 8.818343] sr 0:0:0:2: [sr0] tag#85 Sense Key : Not Ready [current] [ 8.821937] sr 0:0:0:2: [sr0] tag#85 Add. Sense: Medium not present - tray open [ 8.825773] sr 0:0:0:2: [sr0] tag#85 CDB: Read(10) 28 00 00 00 00 02 00 00 02 00 [ 8.829764] I/O error, dev sr0, sector 8 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [ 8.834774] Buffer I/O error on dev sr0, logical block 1, async page read [ 9.013066] sdb: sdb1
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4621	[Cloud] General	minor	always	2023-10-26 17:29	2023-10-26 23:45

Reporter:	Cavan Morris	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	AWS AMI x86 support for AMD nano and micro instances
Description:	Rocky x86 images in the AWS AMI marketplace appear to have arbitrary instance size limits. Rocky Linux 8 (Official) and Rocky Linux 9 (Official) do not support nano or micro instances. https://aws.amazon.com/marketplace/pp/prodview-2otariyxb3mqu?sr=0-1&ref_=beagle&applicationId=AWS-EC2-Console https://aws.amazon.com/marketplace/pp/prodview-ygp66mwgbl2ii?sr=0-2&ref_=beagle&applicationId=AWS-EC2-Console Rocky Linux 9 with LVM supports nano but not micro instances. https://aws.amazon.com/marketplace/pp/prodview-yjxmiuc6p5jzk?sr=0-3&ref_=beagle&applicationId=AWS-EC2-Console This doesn't appear to be a technical
Tags:
Steps To Reproduce:	Attempt to create a Rocky instance and see that the micro/nano instance types are not available.
Additional Information:
Attached Files:

Notes
(0004989) Cavan Morris 2023-10-26 23:45	This issue doesn't have anything to do with AMD. I don't know how I put that in the title, but I can't figure out how to edit it.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4557	[Rocky-Linux-8] libwebp	feature	always	2023-10-23 17:34	2023-10-23 17:34

Reporter:	Stefan Neufeind	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Provide libwebp-tools for Rocky 8
Description:	On Rocky 9 it is available through the CRB-repo. For Rocky 8 unfortunately only through the Devel-repo (not intended for regular use). But the deps are mostly available through AppStream anyway. Could this be exposed through a "normal" repo Rocky 8 as well?
Tags:	repository
Steps To Reproduce:
Additional Information:	https://pkgs.org/search/?q=libwebp-tools
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4555	[Rocky-Linux-8] osbuild	crash	always	2023-10-22 15:55	2023-10-22 16:06

Reporter:	Daniel Milnes	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Building Rocky 8 images calls Rocky 9 target and fails
Description:	It appears to currently be impossible to build a Rocky 8 image using osbuild. On a fresh install of Rocky 8 with a very simple template, osbuild tries to run a rocky9 osbuild step. It can't find this step within the bwrap environment, so the build fails. I believe this is related to Rocky's patchset, as I cannot replicate this issue on RHEL 8.8. To test this, replace the `distro` with `rhel-88`. Attaching strace to the worker does not appear to provide any additional information.
Tags:
Steps To Reproduce:	1. Set up Rocky 8.8 2. Install osbuild dnf install osbuild-composer composer-cli -y 3. Start osbuild systemctl enable --now osbuild-local-worker.socket systemctl enable --now osbuild-composer.socket 4. Submit the blueprint attached to this ticket composer-cli blueprints push <path> 5. Start a build composer-cli compose start rocky-8-base qcow2 --size 20000 6. Watch the journal and wait for the exception osbuild-worker[29124]: time="2023-10-22T15:42:19Z" level=info msg="build pipeline results:\n" jobId=40174b1f-1076-441b-a529-fed2ae190d1b osbuild-worker[29124]: time="2023-10-22T15:42:19Z" level=info msg=" org.osbuild.rpm failure:" jobId=40174b1f-1076-441b-a529-fed2ae190d1b osbuild-worker[29124]: time="2023-10-22T15:42:19Z" level=info msg=" bwrap: execvp /run/osbuild/runner/org.osbuild.rocky9: No such file or directory" jobId=40174b1f-1076-441b-a529-fed2ae190d1b osbuild-worker[29124]: time="2023-10-22T15:42:19Z" level=info msg=" " jobId=40174b1f-1076-441b-a529-fed2ae190d1b osbuild-worker[29124]: time="2023-10-22T15:42:19Z" level=error msg="osbuild job failed: osbuild build failed" jobId=40174b1f-1076-441b-a529-fed2ae190d1b osbuild-worker[29124]: time="2023-10-22T15:42:19Z" level=info msg="Job '40174b1f-1076-441b-a529-fed2ae190d1b' (osbuild) finished"
Additional Information:	Package versions: # rpm -qa \| grep osbuild osbuild-composer-dnf-json-75-1.el8.rocky.0.2.x86_64 python3-osbuild-81-1.el8.rocky.0.2.noarch osbuild-lvm2-81-1.el8.rocky.0.2.noarch osbuild-composer-core-75-1.el8.rocky.0.2.x86_64 osbuild-selinux-81-1.el8.rocky.0.2.noarch osbuild-luks2-81-1.el8.rocky.0.2.noarch osbuild-ostree-81-1.el8.rocky.0.2.noarch osbuild-composer-75-1.el8.rocky.0.2.x86_64 osbuild-81-1.el8.rocky.0.2.noarch osbuild-composer-worker-75-1.el8.rocky.0.2.x86_64 OSBuild Blueprint: name = "rocky-8-base" version = "1.0.0" distro = "rocky-88" groups = [ { name = "Core" }, ]
Attached Files:

Notes
(0004951) Daniel Milnes 2023-10-22 16:06	Additionally, this bug does not appear to be present building Rocky 8 from Rocky 9. This is especially weird, as the patch that adds Rocky 8 support is common between releases (https://git.rockylinux.org/staging/rpms/osbuild-composer/-/blob/r9/SOURCES/0001-Add-Rocky-Linux-8-and-9-Support.patch?ref_type=heads).

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4490	[Rocky Linux Build System] General	minor	always	2023-10-17 09:33	2023-10-17 09:33

Reporter:	hirofumi minami	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	cannot migrate from locky linux 8.8 to 9.2.
Description:	Direct migration from CentOS7 to lockyLinux 8.8 was successful, but I cannot migrate from locky linux 8.8 to 9.2. REPOSITORY https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-gpg-keys-9.0-2.3.el9.noarch.rpm and other 2 rom is 404 not found https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-gpg-keys-9.2-1.6.el9.noarch.rpm https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-release-9.2-1.6.el9.noarch.rpm https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-repos-9.2-1.6.el9.noarch.rpm is found your web but dnf install epel-release The GPG keys listed for the "Rocky Linux 8 - Extras" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository.. Failing package is: epel-release-8-18.el8.noarch please collect kit miss or suggest upgrade way , scripts regards!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4456	[Rocky-Linux-8] grub2	minor	always	2023-10-16 10:49	2023-10-16 10:49

Reporter:	Dieter Kvasnicka	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Cannot install package grub2-pc if /efi is not mounted
Description:	The package grub2-pc-1:2.02-148.el8_8.1.rocky.0.3.x86_64 tries to create the subdirectory /boot/loader/entries/ Unfortunately, on systems without EFI (e.g. some virtualization platforms) * /efi does not exist * the link /boot/efi -> ../efi/loader fails * /boot/loader/entries cannot be created * the packages fails (without saying much sensible information)
Tags:	Install, yum
Steps To Reproduce:	if necessary: umount /efi rmdir /efi dnf install grub2-pc
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2938	[Rocky-Linux-8] dnf	major	always	2023-04-19 20:55	2023-10-03 21:38

Reporter:	Dylan Bartos	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	i686 Security Errata not included in updateinfo.xml
Description:	Similar to Issue 2608. The security errata for x86_64 does not include any packages for i686. Example advisory: RLSA-2023:1405. Errata HTTP site: https://errata.build.resf.org/RLSA-2023:1405. This site shows multiple packages for i686. When opening the updateinfo.xml and reviewing content for RLSA-2023:1405, none of the i686 packages are present. The same errata at Redhat RHSA-2023:1405 does include the i686 packages in the updateinfo.xml. Searching for the string 'i686' in the updateinfo.xml file returns no results. I suspect all packages are missing the i686 errata. This results in dependency resolution failures whenever you have both i686 and x86_64 versions of the package installed on a dnf upgrade --advisory RLSA-2023:1405 command: Error: Problem 1: openssl-devel-1:1.1.1k-7.el8_6.i686 has inferior architecture - cannot install both openssl-devel-1:1.1.1k-9.el8_7.x86_64 and openssl-devel-1:1.1.1k-7.el8_6.x86_64 - cannot install the best update candidate for package openssl-devel-1:1.1.1k-7.el8_6.i686 - cannot install the best update candidate for package openssl-devel-1:1.1.1k-7.el8_6.x86_64 Problem 2: openssl-libs-1:1.1.1k-7.el8_6.i686 has inferior architecture - cannot install both openssl-libs-1:1.1.1k-9.el8_7.x86_64 and openssl-libs-1:1.1.1k-7.el8_6.x86_64 - cannot install the best update candidate for package openssl-libs-1:1.1.1k-7.el8_6.i686 - cannot install the best update candidate for package openssl-libs-1:1.1.1k-7.el8_6.x86_64 ------- FROM ROCKY ERRATA ------- <pkglist> <collection short="rocky-linux-8-x86-64-baseos-rpms"> <name>rocky-linux-8-x86-64-baseos-rpms</name> <package name="openssl" arch="x86_64" epoch="1" version="1.1.1k" release="9.el8_7" src="openssl-1.1.1k-9.el8_7.src.rpm"> <filename>openssl-1.1.1k-9.el8_7.x86_64.rpm</filename> <sum type="sha256">9a938d81016ef3c3e733e4769e188999fbbfcdec71318a4698e1040d28867770</sum> </package> <package name="openssl-devel" arch="x86_64" epoch="1" version="1.1.1k" release="9.el8_7" src="openssl-1.1.1k-9.el8_7.src.rpm"> <filename>openssl-devel-1.1.1k-9.el8_7.x86_64.rpm</filename> <sum type="sha256">7b1d407a69745004f56fa33cd2d345f1a84f9e8710ded5e0265dacbd4cc4e150</sum> </package> <package name="openssl-libs" arch="x86_64" epoch="1" version="1.1.1k" release="9.el8_7" src="openssl-1.1.1k-9.el8_7.src.rpm"> <filename>openssl-libs-1.1.1k-9.el8_7.x86_64.rpm</filename> <sum type="sha256">1773916c99960d474e56f6ee2e7f2b94a3fa536a5fe12e4445bea0e34ea6ba01</sum> </package> <package name="openssl-perl" arch="x86_64" epoch="1" version="1.1.1k" release="9.el8_7" src="openssl-1.1.1k-9.el8_7.src.rpm"> <filename>openssl-perl-1.1.1k-9.el8_7.x86_64.rpm</filename> <sum type="sha256">aac00ecf8f661033d59a38fa9944b36780c0e5bc64fb7f00c1ae2a249b8840ab</sum> </package> </collection> </pkglist> ------- FROM REDHAT ERRATA ------- <pkglist> <collection short="rhel-8-for-x86_64-baseos-rpms__8_0_default"> <name>rhel-8-for-x86_64-baseos-rpms__8_0_default</name> <package src="openssl-1.1.1k-9.el8_7.src.rpm" name="openssl-libs" epoch="1" version="1.1.1k" release="9.el8_7" arch="x86_64"> <filename>openssl-libs-1.1.1k-9.el8_7.x86_64.rpm</filename> <sum type="sha256">91fc219ef2fabee25069ebb5d119463d510f9794fd42e94fe5f2af43cfa9c95c</sum> </package> <package src="openssl-1.1.1k-9.el8_7.src.rpm" name="openssl-libs" epoch="1" version="1.1.1k" release="9.el8_7" arch="i686"> <filename>openssl-libs-1.1.1k-9.el8_7.i686.rpm</filename> <sum type="sha256">28dc2c167f1d417ef843e57dffd5e2f6921a8599847f98805cecff45b12c2890</sum> </package> <package src="openssl-1.1.1k-9.el8_7.src.rpm" name="openssl-perl" epoch="1" version="1.1.1k" release="9.el8_7" arch="x86_64"> <filename>openssl-perl-1.1.1k-9.el8_7.x86_64.rpm</filename> <sum type="sha256">0ff606b23a716cf95770adc5e25f73ed80a775f8d9a1e52cb94d952cae4f075e</sum> </package> <package src="openssl-1.1.1k-9.el8_7.src.rpm" name="openssl-devel" epoch="1" version="1.1.1k" release="9.el8_7" arch="i686"> <filename>openssl-devel-1.1.1k-9.el8_7.i686.rpm</filename> <sum type="sha256">5aaeadf179b270b0eadc3dc9c1e107aa5a9b0f205ca81a0807b23e7c62c1c812</sum> </package> <package src="openssl-1.1.1k-9.el8_7.src.rpm" name="openssl" epoch="1" version="1.1.1k" release="9.el8_7" arch="x86_64"> <filename>openssl-1.1.1k-9.el8_7.x86_64.rpm</filename> <sum type="sha256">ef476eb36d94df6a2625364169ae48c85cd040b473a4d6c8bc10455a45535b2c</sum> </package> <package src="openssl-1.1.1k-9.el8_7.src.rpm" name="openssl-devel" epoch="1" version="1.1.1k" release="9.el8_7" arch="x86_64"> <filename>openssl-devel-1.1.1k-9.el8_7.x86_64.rpm</filename> <sum type="sha256">00ade765ab49f06ee61929bf94ab8636b7f5007e9438a1e920d68db964715a59</sum> </package> </collection> </pkglist>
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003466) Dylan Bartos 2023-05-22 16:59	PR Filed for proposed solution https://github.com/resf/distro-tools/pull/9

(0003635) Louis Abel 2023-06-02 20:07	This should be fixed in the current version of the errata toolkit as the PR is merged.

(0004786) Dylan Bartos 2023-10-03 21:38	The current published errata at http://dl.rockylinux.org/pub/rocky/8/BaseOS/x86_64/os/repodata/ does not include i686 packages, this issue needs to be re-reviewed.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4258	[Rocky Linux SIG] General	minor	always	2023-09-19 03:21	2023-09-28 21:45

Reporter:	Miroslav Suchy	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	RPM-GPG-KEY-rockyinfra is expired
Description:	The GPG key https://dl.rockylinux.org/pub/rocky/RPM-GPG-KEY-rockyinfra has expired at 2023-05-17.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0004753) Neil Hanlon 2023-09-28 21:45	Thank you for the report. I've renewed this key and will get it updated on the download site. We're also checking what, if anything, is still using this key.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4291	[Rocky-Linux-8] nodejs	minor	always	2023-09-19 14:07	2023-09-19 15:57

Reporter:	s mile	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	nodejs version affected by multiple vulnerabilities.
Description:	The latest version of nodejs provided on all mirrors seems to be 18.16.1, which is affected by multiple vulnerabilities. Newer versions of nodejs escpecially the most recent of 18.18.0 as provides by nodejs.org are not available in the repository. The vulnerabilities as reported by Nessus are: - Permissions policies can be bypassed via Module._load (CVE-2023-32002) - Permission model bypass by specifying a path traversal sequence in a Buffer (CVE-2023-32004) - process.binding() can bypass the permission model through path traversal (CVE-2023-32558) - Permissions policies can impersonate other modules in using module.constructor.createRequire() (CVE-2023-32006) - Permissions policies can be bypassed via process.binding (CVE-2023-32559) - fs.statfs can retrive stats from files restricted by the Permission Model (CVE-2023-32005) - fs.mkdtemp() and fs.mkdtempSync() are missing getValidatedPath() checks (CVE-2023-32003)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0004654) Skip Grube 2023-09-19 15:57	Hi, thanks for your report! Rocky Linux's stated goal is 100% version/patch parity with the upstream RHEL (Red Hat Enterprise Linux). Once an update is issued there, the Rocky project then follows suit very quickly. I see that most of these have not yet been addressed in RHEL, like: https://access.redhat.com/security/cve/cve-2023-32002 . Others don't seem to affect the RHEL NodeJS, and therefore will also not affect the Rocky packages either, like: https://access.redhat.com/security/cve/cve-2023-32558 . Many of these CVEs seem to only affect NodeJS's experimental new security policy system. I'd speculate the lack of urgency around some of these updates is due to most enterprise customers not relying on the new system. But that's only my personal view of the situation - I don't know much about NodeJS all told. Thanks, hope this helps, - Skip

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
82	[Rocky-Linux-8] dnf	minor	always	2022-02-03 09:43	2023-09-16 12:07

Reporter:	Alex Corcoles	Platform:
Assigned To:	Release Engineering	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	dnf needs-restart does not work well on Raspberry Pi
Description:	Hi, I think I got the update that supposedly fixes #190. dnf needs-restart now checks the uptime by looking at the mtime of /proc/1. This might work on other environments, but on a Raspberry Pi 4, this file has an mtime of 1970 and I cannot even touch it to fix it. So dnf needs-restart is completely borked there. Help? Álex
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000096) Alex Corcoles 2022-02-03 10:02	To be clear, I think the bug is the mtime on /proc/1 on a Raspberry Pi. On other systems it's apparently the boot time.

(0000113) Skip Grube 2022-05-03 14:46	Just adding an update here: I'm 99.9% certain this is because the Raspberry Pi has no internal clock, and so it defaults to Jan 1, 1970 (epoch) when the system does its early boot. I'm still pondering this issue, but I don't really have a good solution right now. Best bet as a workaround (for now) is to patch that DNF plugin to use a different source for system boot time. I would expect this same behavior on any system with no internal clock, a dead CMOS battery, etc. Still brainstorming if there's a better solution to this.

(0000115) Alex Corcoles 2022-05-03 16:48	Yeah, I had no idea that the RPI has no clock :( Everything fits that explanation, IMHO. My only concern is that I don't think RHEL 8 supports any hardware with a "malfunctioning" clock, so they might be hesitant to patch the DNF plugin to do the proper thing (although I think that's the most correct solution). I am happy to file a bug (to the CentOS 8 bug tracker, corresponding to the DNF plugin RPM, I assume?) and see how that plays out. (If you have a more direct communication with upstream, maybe you want to report that yourself?) Thinking out a little bit, the other options I can think of: * Do something similar to fake-hwclock. However, fake-hwclock specifically seems to be a systemd service, so I think it would be too late for this to work. And I didn't see anything like a kernel command-line parameter that lets you set a custom time. * Find a way to change the mtime of /proc/1 when the date is set via NTP. I only thought to remount /proc, but that doesn't seem to change anything * Create an alternate package just for Rocky Linux 8 / RPI that overrides the DNF plugin. I think this option is worse than all other proposals. Let me know your thoughts. If I don't hear anything, I'll file a bug to CentOS 8 Stream python3-dnf-plugins-core in 1-2 days. Cheers, Álex

(0000116) Alex Corcoles 2022-05-05 18:19	I filed https://bugzilla.redhat.com/show_bug.cgi?id=2082295 , following the instructions at https://github.com/rpm-software-management/dnf-plugins-core#bug-reporting-etc .

(0004324) Alex Corcoles 2023-08-10 18:18	In case anyone is serious, this likely is fixed in EL9: https://gitlab.com/redhat/centos-stream/rpms/dnf-plugins-core/-/blob/c9s/0006-Fix-boot-time-derivation-for-systems-with-no-rtc.patch?ref_type=heads

(0004621) Alex Corcoles 2023-09-16 12:07	Dang, I updated to Rocky 9 and I get: $ sudo dnf needs-restarting -r Core libraries or services have been updated since boot-up: * dbus * dbus-broker * glibc * linux-firmware * systemd after a reboot :(

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4225	[Rocky-Linux-9] selinux-policy	minor	always	2023-09-15 09:14	2023-09-15 09:14

Reporter:	Jamie Burchell	Platform:	Linux
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9.2
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	logrotate cannot read directories labelled httpd_sys_content_t
Description:	I store log files for individual virtual hosts in /var/www/vhosts/foo/log which has a directory label of httpd_log_t. SELinux denies access to read the vhosts directory: type=AVC msg=audit(1694646003.329:8073): avc: denied { read } for pid=32077 comm="logrotate" name="vhosts" dev="vda1" ino=335544449 scontext=system_u:system_r:logrotate_t:s0 tcontext=unconf Using this logrotate config: /var/log/php-fpm/log /var/www/vhosts//log/*log { missingok notifempty sharedscripts delaycompress postrotate /bin/kill -SIGUSR1 `cat /run/php-fpm/php-fpm.pid 2>/dev/null` 2>/dev/null \|\| true endscript }
Tags:
Steps To Reproduce:	Create the above directory structure with logrotate config and trigger the systemd timer for logrotate.
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4193	[Rocky-Linux-9] kernel	crash	always	2023-09-12 15:10	2023-09-12 15:10

Reporter:	ALIREZA DM	Platform:	vmware 12.64bit
Assigned To:		OS:	windows
Priority:	normal	OS Version:	10
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	kernel panic
Description:	Rocky Linux version 9.2 and version 9 is not installed in VMWare virtual machine and gives an error "kernel panic"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	panic.png (33,954 bytes) 2023-09-12 15:10 https://bugs.rockylinux.org/file_download.php?file_id=991&type=bug

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4192	[Rocky-Linux-9] General	major	always	2023-09-12 09:25	2023-09-12 09:25

Reporter:	Sistemi Arcadja	Platform:
Assigned To:		OS:
Priority:	high	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Error installing virtualbox guest additions (6.0.24.r139119 - Qt.5.6.1) on rocky linux 9.2
Description:	I tried to install the virtualbox guest additions on rocky linux 9.2 (updated 09/11/2023) but I received the following error: ----------- Verifying archive integrity... All good. Uncompressing VirtualBox 6.0.24 Guest Additions for Linux........ VirtualBox Guest Additions installer Removing installed version 6.0.24 of VirtualBox Guest Additions... Copying additional installer modules ... Installing additional modules ... VirtualBox Guest Additions: Starting. VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules. This may take a while. VirtualBox Guest Additions: To build modules for other installed kernels, run VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version> VirtualBox Guest Additions: or VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all VirtualBox Guest Additions: Building the modules for kernel 5.14.0-284.25.1.el9_2.x86_64. VirtualBox Guest Additions: Look at /var/log/vboxadd-setup.log to find out what went wrong ValueError: File context for /opt/VBoxGuestAdditions-6.0.24/other/mount.vboxsf already defined modprobe vboxguest failed The log file /var/log/vboxadd-setup.log may contain further information. ----------- in the log file I saw: ----------- gcc -Wp,-MMD,/tmp/vbox.0/.VBoxGuest.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong "-Wimplicit-fallthrough=5" -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-stack-clash-protection -g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -fno-inline-functions-called-once -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -Wno-declaration-after-statement -fno-pie -include /tmp/vbox.0/include/VBox/VBoxGuestMangling.h -I./include -I/tmp/vbox.0/ -I/tmp/vbox.0/include -I/tmp/vbox.0/r0drv/linux -D__KERNEL__ -DMODULE -DRT_WITHOUT_PRAGMA_ONCE -DVBOX -DRT_OS_LINUX -DIN_RING0 -DIN_RT_R0 -DIN_GUEST -DIN_GUEST_R0 -DIN_MODULE -DRT_WITH_VBOX -DVBGL_VBOXGUEST -DVBOX_WITH_HGCM -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_AMD64 -DMODULE -DKBUILD_BASENAME='"VBoxGuest"' -DKBUILD_MODNAME='"vboxguest"' -D__KBUILD_MODNAME=kmod_vboxguest -c -o /tmp/vbox.0/VBoxGuest.o /tmp/vbox.0/VBoxGuest.c ; ./tools/objtool/objtool --hacks=jump_label --hacks=noinstr --orc --retpoline --rethunk --static-call --uaccess --module /tmp/vbox.0/VBoxGuest.o In file included from /tmp/vbox.0/include/iprt/types.h:34, from /tmp/vbox.0/r0drv/linux/the-linux-kernel.h:37, from /tmp/vbox.0/VBoxGuest-linux.c:36: /tmp/vbox.0/include/iprt/stdarg.h:47:12: fatal error: stdarg.h: File o directory non esistente 47 \| # include <stdarg.h> \| ^~~~~~~~~~ compilation terminated. make[2]: * [scripts/Makefile.build:321: /tmp/vbox.0/VBoxGuest-linux.o] Errore 1 make[2]: * Attesa per i processi non terminati.... In file included from /tmp/vbox.0/include/iprt/types.h:34, from /tmp/vbox.0/VBoxGuestInternal.h:33, from /tmp/vbox.0/VBoxGuest.c:54: /tmp/vbox.0/include/iprt/stdarg.h:47:12: fatal error: stdarg.h: File o directory non esistente 47 \| # include <stdarg.h> \| ^~~~~~~~~~ compilation terminated. make[2]: * [scripts/Makefile.build:321: /tmp/vbox.0/VBoxGuest.o] Errore 1 make[1]: * [Makefile:1923: /tmp/vbox.0] Error 2 make: *** [/tmp/vbox.0/Makefile-footer.gmk:117: vboxguest] Error 2 Could not find the X.Org or XFree86 Window System, skipping. modprobe vboxguest failed ----------- I then tried to search for the stdarg.h file to see if it was not present on the server but the result was the following: ----------- /opt/VBoxGuestAdditions-6.0.24/src/vboxguest-6.0.24/vboxguest/include/iprt/stdarg.h /opt/VBoxGuestAdditions-6.0.24/src/vboxguest-6.0.24/vboxsf/include/iprt/stdarg.h /opt/extra/stdarg.h /usr/include/c++/11/tr1/stdarg.h /usr/lib/gcc/x86_64-redhat-linux/11/include/cross-stdarg.h /usr/lib/gcc/x86_64-redhat-linux/11/include/stdarg.h /usr/share/man/man0p/stdarg.h.0p.gz /usr/src/kernels/5.14.0-284.11.1.el9_2.x86_64/include/linux/stdarg.h /usr/src/kernels/5.14.0-284.25.1.el9_2.x86_64/include/linux/stdarg.h ----------- I would like to point out that the kernel version in use on the virtual server is 5.14.0-284.25.1.el9_2.x86_64 and the virtualbox version installed on the physical server is 6.0.24.r139119. Online I saw that some people suggested switching to virtualbox 6.1.X, but since it is a production server that hosts online services I am not allowed to shut down the system to perform the update. Are there any patches or alternative procedures that allow me to install the virtualbox guest additions on rocky linux 9.2? Thank you.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3367	[Cloud] General	minor	always	2023-05-25 23:53	2023-09-07 02:53

Reporter:	Andy Botting	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Vagrant Libvirt image is 404
Description:	Currently, trying to bring up a libvirt-based box with Vagrant using the tag rockylinux/8 gives a 404. From the details at: https://app.vagrantup.com/rockylinux/boxes/8, v7 was release 6 months ago, but is should now be updated to v8 to match Rocky Linux release 8.8. For 8.7, the mirror says: This content has been moved to the Rocky Linux Vault https://dl.rockylinux.org/vault/rocky/8.7/ Vagrant box launch details: Bringing machine 'rocky8' up with 'libvirt' provider... ==> rocky8: Box 'rockylinux/8' could not be found. Attempting to find and install... rocky8: Box Provider: libvirt rocky8: Box Version: >= 0 ==> rocky8: Loading metadata for box 'rockylinux/8' rocky8: URL: https://vagrantcloud.com/rockylinux/8 ==> rocky8: Adding box 'rockylinux/8' (v7.0.0) for provider: libvirt rocky8: Downloading: https://vagrantcloud.com/rockylinux/boxes/8/versions/7.0.0/providers/libvirt.box Download redirected to host: dl.rockylinux.org An error occurred while downloading the remote file. The error message, if any, is reproduced below. Please fix this error and try again.
Tags:
Steps To Reproduce:	$ vagrant box add --provider libvirt rockylinux/8 ==> box: Loading metadata for box 'rockylinux/8' box: URL: https://vagrantcloud.com/rockylinux/8 ==> box: Adding box 'rockylinux/8' (v7.0.0) for provider: libvirt box: Downloading: https://vagrantcloud.com/rockylinux/boxes/8/versions/7.0.0/providers/libvirt.box Download redirected to host: dl.rockylinux.org An error occurred while downloading the remote file. The error message, if any, is reproduced below. Please fix this error and try again. The requested URL returned error: 404
Additional Information:
Attached Files:

Notes
(0004592) Neil Hanlon 2023-09-07 02:53	URLs were updated to point to vault.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3301	[Rocky-Linux-8] General	major	always	2023-05-22 18:20	2023-09-07 02:52

Reporter:	Stephen Corbesero	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	AWS AMI support for m7g.* (graviton) instance types
Description:	The Rocky Linux 8 - aarch64 (Official) (Ver resf-rl8-20230215) can not be launched on the m7g.* (graviton) instance types that were recently released. Rocky Linux 9 - aarch64 also can not be launched on those instance types.
Tags:	AWS
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003467) Stephen Corbesero 2023-05-22 18:58	In fact, it would be nice if they could be available for all the 7g. instance types.

(0004591) Neil Hanlon 2023-09-07 02:52	Hello, Apologies for the extreme latency in handling this request. It got lost in my queue. This has been taken care of, and all future releases should be all set for future instance types. Best, Neil

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
102	[Cloud] General	major	always	2022-05-17 03:46	2023-09-07 02:45

Reporter:	David Monro	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	8.6 Generic cloud image is missing sudo, has selinux disabled...
Description:	The Rocky 8.6 generic cloud image at https://download.rockylinux.org/pub/rocky/8.6/images/Rocky-8-GenericCloud-8.6-20220515.x86_64.qcow2 appears to have some major issues. * It doesn't have sudo installed * selinux appears to be disabled by default I doubt these changes are intentional?
Tags:
Steps To Reproduce:	Add the image to an openstack environment and launch it. Log in as the rocky user. Attempt to sudo and you get back command not found, getenforce returns Disabled.
Additional Information:	It is noticeable that this image is considerably smaller than the 8.5 version.
Attached Files:

Notes
(0000170) Neil Hanlon 2022-05-17 03:53	Thank you for the report. You're right the image seems not very functional. I did basic smoke tests on it, but clearly need to validate some more. I'll rebuild this in the morning and check what's going on.

(0000176) Martin Nix 2022-05-20 11:59	Also of note here is that the cloud image is missing LVM support at boot for the root filesystem by default (I know that is probably not minimal but in my estimation it is essential for most instances)

(0000180) Ian Walker 2022-05-23 09:45	The majority of cloud images do not have LVM in them, at least as far as I have seen with all downloaded images over the past few years that I've used with Openstack. Usually an image has a single standard partition, since cloud-init manages the images, and if an instance is resized, then it uses growpart to increase the disk partition. If the image has an LVM partition, then chances are this isn't going to work.

(0000182) Martin Nix 2022-05-24 10:33	Thanks Ian - but I've found the opposite to be true. Our use case is the same in Openstack, we have been using Centos images (from the Centos qcow resource at https://cloud.centos.org/centos/7/images) and more recently the Rocky image in question. From 7.2 right up to and including 8.5 LVM for the root file system was enabled by default and works completely as expected with growpart. The problem we have now with this image is partly to do with growpart failing due specifically due to LVM being missing (makes this image a special case to work around for our build system) For now I've taken the 8.5 image (which works absolutely fine) and updated it to 8.6 using virt tools (as a workaround)

(0000183) Ian Walker 2022-05-24 10:49	Martin, OK good to know :) I know previously a lot of the centos/rhel/sles jeos images that I used were standard images, hadn't seen anything with lvm yet, so if that's the case, fair enough :)

(0000184) TREVOR BENSON 2022-05-25 00:00	@marnixgb I've seem the same as you in most cases. @iwalker Which image are you referring to? The latest x86_64 image at https://cloud.centos.org/centos/7/images, CentOS-7-x86_64-GenericCloud-2111.qcow2 does not have any `lvm2` RPMs installed by default. Neither does the rhel-8.5-x86_64-kvm_password.qcow2 image available from redhat.com. I have not used the ppc64le or the aarch64 images, so am not sure they handle disks the same way. Are you sure the image wasn't customized first, or a cloud-init configuration is installing them for you?

(0000185) TREVOR BENSON 2022-05-25 00:02	You can ignore the _password on the qcow image. I just happened to use virt-customize really quickly to set the password of root for a quick confirmation test without modifying the original image.

(0000186) Ian Walker 2022-05-25 07:01	@Trevor Benson I used the official images downloaded from CentOS, RHEL, Debian, Ubuntu. To date I didn't see these images with LVM installed, let alone with LVM partitions (but they were images pre December 2021 - not downloaded new ones since). But if things change and they start to use LVM like @Martin said then fair enough. I only mentioned, because if the majority of other images do not have it, then Rocky can also be without LVM as well. It doesn't make a huge difference, since growpart will resize it anyway.

(0000187) Steve Brasier 2022-05-25 13:24	Also doesn't appear to have `hostname` installed.

(0000188) TREVOR BENSON 2022-05-25 15:26	@iwalker I got the @'s backwards in my message. I was intending to @ you that I saw the same as you (no lvm) in many images from upstream. Sorry for the confusion by swapping the @'s in the note.

(0000189) Martin Nix 2022-05-26 08:00	First off apologies on the LVM front - I saw something and jumped to a conclusion (the wrong one) that was incorrect as it turns out : On images of 8.5 and prior the filesystem is created by anaconda as below : [root@test85 ~]# lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT vda └─vda1 xfs 4c90d825-f649-4c1b-97b8-11f283331ef5 / vdb swap 50020188-cb9d-4df7-8e0e-2391886d4978 [SWAP] [root@test85 ~]# cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun Nov 14 18:50:49 2021 # # Accessible filesystems, by reference, are maintained under '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info. # # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. # UUID=4c90d825-f649-4c1b-97b8-11f283331ef5 / xfs defaults 0 0 /dev/vdb none swap sw,comment=cloudconfig 0 0 On the 8.6 image the filesystem is as below (quite different) : [root@test86 ~]# lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT vda ├─vda1 vfat EFI 49AB-A4B4 ├─vda2 └─vda3 xfs root ebb44e1a-2801-4e1e-a8c5-921204153736 / vdb swap b2e2ed61-7ca0-4c82-a2e7-fa945ec59adc [SWAP] [root@test86 ~]# cat /etc/fstab /dev/vdb none swap sw,comment=cloudconfig 0 0 I have bought up two test machines, one 8.5 and one 8.6, from the stock qcow2 images and got together the below list - these are the packages that were in 8.5 but are no longer in 8.6. There are no packages in 8.6 that did not exist in 8.5. abattis-cantarell-fonts.noarch audit.x86_64 authselect-compat.x86_64 authselect-libs.x86_64 authselect.x86_64 cairo-gobject.x86_64 cairo.x86_64 c-ares.x86_64 cronie-anacron.x86_64 cronie.x86_64 crontabs.noarch crypto-policies-scripts.noarch dejavu-fonts-common.noarch dejavu-sans-mono-fonts.noarch dmidecode.x86_64 dracut-config-rescue.x86_64 elfutils-debuginfod-client.x86_64 fontconfig.x86_64 fontpackages-filesystem.noarch gdk-pixbuf2.x86_64 geolite2-city.noarch geolite2-country.noarch gnupg2-smime.x86_64 gobject-introspection.x86_64 groff-base.x86_64 grubby.x86_64 hardlink.x86_64 hdparm.x86_64 hostname.x86_64 hwdata.noarch initscripts.x86_64 irqbalance.x86_64 kbd-legacy.noarch kbd-misc.noarch kbd.x86_64 kernel-tools-libs.x86_64 kernel-tools.x86_64 kpartx.x86_64 less.x86_64 libappstream-glib.x86_64 libdaemon.x86_64 libdhash.x86_64 libestr.x86_64 libfastjson.x86_64 libldb.x86_64 libmaxminddb.x86_64 libnl3-cli.x86_64 libnl3.x86_64 libpipeline.x86_64 libsecret.x86_64 libsoup.x86_64 libsss_autofs.x86_64 libsss_certmap.x86_64 libsss_idmap.x86_64 libsss_nss_idmap.x86_64 libsss_sudo.x86_64 libstemmer.x86_64 libsysfs.x86_64 libtalloc.x86_64 libtdb.x86_64 libteam.x86_64 libtevent.x86_64 libuser.x86_64 libX11-common.noarch libX11.x86_64 libXau.x86_64 libxcb.x86_64 libXext.x86_64 libxkbcommon.x86_64 libXrender.x86_64 lmdb-libs.x86_64 logrotate.x86_64 lshw.x86_64 lsscsi.x86_64 man-db.x86_64 memstrack.x86_64 microcode_ctl.x86_64 mozjs60.x86_64 NetworkManager-team.x86_64 NetworkManager-tui.x86_64 newt.x86_64 numactl-libs.x86_64 oddjob-mkhomedir.x86_64 oddjob.x86_64 openssl-pkcs11.x86_64 PackageKit-glib.x86_64 PackageKit.x86_64 parted.x86_64 passwd.x86_64 pciutils-libs.x86_64 pigz.x86_64 pinentry.x86_64 pixman.x86_64 platform-python-pip.noarch policycoreutils-python-utils.noarch polkit-pkla-compat.x86_64 polkit.x86_64 prefixdevname.x86_64 python3-cairo.x86_64 python3-decorator.noarch python3-gobject-base.x86_64 python3-gobject.x86_64 python3-linux-procfs.noarch python3-netifaces.x86_64 python3-perf.x86_64 python3-pexpect.noarch python3-ptyprocess.noarch python3-pydbus.noarch python3-pyudev.noarch python3-slip-dbus.noarch python3-slip.noarch python3-syspurpose.x86_64 python3-systemd.x86_64 python3-unbound.x86_64 rocky-logos.x86_64 rpm-plugin-selinux.x86_64 rpm-plugin-systemd-inhibit.x86_64 rsyslog.x86_64 selinux-policy.noarch selinux-policy-targeted.noarch setroubleshoot-plugins.noarch setroubleshoot-server.x86_64 sg3_utils-libs.x86_64 sg3_utils.x86_64 shared-mime-info.x86_64 slang.x86_64 sscg.x86_64 sssd-client.x86_64 sssd-common.x86_64 sssd-kcm.x86_64 sssd-nfs-idmap.x86_64 sudo.x86_64 teamd.x86_64 timedatex.x86_64 trousers-lib.x86_64 trousers.x86_64 tuned.noarch unbound-libs.x86_64 virt-what.x86_64 xkeyboard-config.noarch

(0000190) Ian Walker 2022-05-26 16:07	Seems strange, normally images are a single disk, and yet this mentioned vda for the main partition and vdb for swap (unless that was added later and not part of the initial Rocky image). As with all the other images I've mentioned, they were all single disks and partitions, no swap, so I think the Rocky image doesn't need this second disk or swap for that matter, it can only be more problematic this way. Generally, if I spin up an instance on Openstack or wherever (eg: other vps hosting platforms that spin up from an image), it's easy enough to add swap using fallocate and dropping the file on the main disk partition.

(0000191) Martin Nix 2022-05-27 07:22	You can safely ignore the vdb entries - they are a product of bringing up instances in openstack where the swap is defined in the flavor (which we do as standard through TerraForm) I was trying to illustrate that the regular partitioning standard that occurs at init typically is not happening in this case (with 8.6)

(0000229) Jere Kataja 2022-06-03 18:05	Also to note that static IP assignment with generic cloud image fails with 8.6. With 8.5 it worked normally. Might be related to the same deficiencies listed above.

(0000230) Neil Hanlon 2022-06-03 18:37	Hi all, Thank you for the reports here and for your patience. I've got some new images cooking and should have them up later tonight! The short resolution is, as I should have known, "If it ain't broke, don't fix it" (:

(0000231) Juha Rajamaki 2022-06-04 03:53	Please consider also one more thing in the new image creation. It is that "virsh console" does not work to a VM running 8.6 image on kvm hypervisor. I think it is because it is missing "console=ttyS0" in the kernel command line, but has "rhgb" which means graphical console. The console of 8.6 works when viewed through the graphical console of OpenStack but for most users it is important that "virsh console" would work as it has always been in earlier images. Rocky 8.5: $ dmesg \|grep -i boot_image [ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/boot/vmlinuz-4.18.0-348.el8.0.2.x86_64 root=UUID=4c90d825-f649-4c1b-97b8-11f283331ef5 ro console=ttyS0,115200n8 no_timer_check net.ifnames=0 crashkernel=auto Rocky 8.6: $ dmesg \|grep -i boot_image [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-372.9.1.el8.x86_64 root=UUID=ebb44e1a-2801-4e1e-a8c5-921204153736 ro rhgb selinux=0 audit=0 rw

(0000233) Jere Kataja 2022-06-07 06:40	Apologies for pestering Neil but any guesstimate for when you would have new images available to download? :-)

(0000250) Jere Kataja 2022-07-07 06:04	Noticed that there is a new image available (20220702.0) and in our tests the x86_64 version at least appears to be working as expected: - Static IP assignment working - virsh console access working - Ansible deployment in general (included sudo etc.) working Thanks!

(0000252) David Monro 2022-07-08 00:13	Looks good to me, deploys just like 8.5 through our ansible/openstack (which the original image did not). Cheers David

(0000253) Neil Hanlon 2022-07-08 00:40	Excellent news. Thank you everyone for your extreme patience with getting this fixed. In the future this will not be a problem.

(0000254) Martin Nix 2022-07-08 08:14	Looks good but I would just like to add - the image really needs virt-sparsify applied The original image is 2674917376, applying a sparsify myself brings that down to 1402798080 - that's a pretty epic difference

(0000255) Neil Hanlon 2022-07-11 01:59	Thanks Martin - I've compressed them by default. The new ones will come out sometime this week, pre-compressed. https://git.resf.org/sig_core/toolkit/commit/1f9468092453d9025fe57b570c615617f1904f0e

(0000315) Steve Brasier 2022-08-02 13:09	Any progress on sparsified images please? https://download.rockylinux.org/pub/rocky/8/images/ only seems to have the `..0702` images still.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2080	[Cloud] General	major	always	2023-02-03 16:25	2023-09-07 02:45

Reporter:	Louis Abel	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Updating cloud-init on current AMI's change rocky to cloud-user
Description:	Due to changes made upstream by Red Hat and fixes made by us, the "rocky" user is being changed to "cloud-user" on update, and thus breaking user workflows. Keeping it as "cloud-user" is the intention, but our images should be using the "rocky" user and not be overwritten. https://forums.rockylinux.org/t/rocky-9-cloud-init-update-changes-default-user/8770/3
Tags:
Steps To Reproduce:	* Deploy EC2 or Azure AMI * dnf update * Lose access
Additional Information:	This happens on 8.7 and 9.1
Attached Files:

Notes
(0004589) Neil Hanlon 2023-09-07 02:45	this was resolved upstream.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3268	[Rocky Services] Mirror Manager	major	always	2023-05-20 17:17	2023-09-07 02:44

Reporter:	Taketo Kabe	Platform:	x86_64
Assigned To:	Neil Hanlon	OS:	Rocky Linux
Priority:	normal	OS Version:	9.2
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	devel repository mirror not working
Description:	devel repository is correctly mirrored to mirror sites, but mirrors.rockylinux.org seems to have trouble handing out mirrorlist for devel repository.
Tags:
Steps To Reproduce:	[kabe@rocky9 kernel-r9]$ LANG=C dnf --disablerepo=\* --enablerepo=devel list Rocky Linux 9 - Devel WARNING! FOR BUILDROOT ON 74 B/s \| 62 B 00:00 Error: Failed to download metadata for repo 'devel': Cannot prepare internal mirrorlist: No URLs in mirrorlist
Additional Information:	[kabe@rocky9 kernel-r9]$ more /etc/yum.repos.d/rocky-devel.repo # rocky-devel.repo # # devel and no-package-left-behind [devel] name=Rocky Linux $releasever - Devel WARNING! FOR BUILDROOT ONLY DO NOT LEAVE ENABLED mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=devel-$releasever$rltype #baseurl=http://dl.rockylinux.org/$contentdir/$releasever/devel/$basearch/os/ gpgcheck=1 enabled=0 countme=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 [devel-debug] name=Rocky Linux $releasever - Devel Debug WARNING! FOR BUILDROOT ONLY DO NOT LEAVE ENABLED mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=devel-$releasever-debug$rltype #baseurl=http://dl.rockylinux.org/$contentdir/$releasever/devel/$basearch/debug/ tree/ gpgcheck=1 enabled=0 countme=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 [devel-source] name=Rocky Linux $releasever - Devel Source WARNING! FOR BUILDROOT ONLY DO NOT LEAVE ENABLED mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=devel-$releasever-source$rltype #baseurl=http://dl.rockylinux.org/$contentdir/$releasever/devel/source/tree/ gpgcheck=1 enabled=0 countme=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9
Attached Files:

Notes
(0003433) Neil Hanlon 2023-05-20 17:49	Thank you for the report! This should be resolved now. We were missing a redirect for these repositories. Best, Neil

(0003434) Taketo Kabe 2023-05-20 17:58	Issue seems to be solved. We could close this report.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3037	[Rocky-Linux-8] General	major	always	2023-04-25 02:23	2023-09-07 02:43

Reporter:	haruto okamoto	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	immediate	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	AWS AMI support for AMD instances x2idn
Description:	Rocky Linux8 should work out of the box on the newer x2idn instance on AWS if enabled on the current AMIs. Could you please make x2idn available in the AWS marketplace?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	2023-04-25_11h22_39.png (20,578 bytes) 2023-04-25 02:23 https://bugs.rockylinux.org/file_download.php?file_id=793&type=bug

Notes
(0003037) Neil Hanlon 2023-04-25 02:25	Thanks for the report. We just resolved an issue related to these instance types with AWS support. I've put in the request to add these instance types and they should be available shortly.

(0003038) Neil Hanlon 2023-04-25 02:31	Well, unfortunately we are still having the same problem. I've re-opened the ticket with AWS Marketplace Support. The issues identified in the following table must be resolved before you can complete this request. If you need help, [contact us](https://aws.amazon.com/marketplace/management/contact-us/?#) to submit a support request. Issues found (2) ----------------- \| Description \| Recommended action \| \| --- \| --- \| \| INVALID\_INPUT \| Remove invalid dimension key 'bmn-sf1.metal' for Metered dimension. \| \| INVALID\_INPUT \| Remove invalid dimension key 'hpc6id.32xlarge' for Metered dimension. \|

(0003039) haruto okamoto 2023-04-25 02:43	Thank you for your prompt response! I understand that you have deleted the demension key and requested it again to support. Thank you very much.

(0003040) haruto okamoto 2023-04-25 04:37	Thank you for your communication with AWS support. We have agreed with AWS on a startup date for x2idn and as that date is approaching, we would appreciate a response as soon as possible. we are using Marketplace official AMI `ami-01c6603b0b5d545ec (Rocky-8-ec2-8.5-20211114.2.x86_64-d6577ceb-8ea8-4e0e-84c6-f098fc302e82)` in production, it would be great if x2idn could be launched with it. thank you.

(0004357) satoshi iwashita 2023-08-16 10:01	Hello. It seems that ami-01c6603b0b5d545ec does not support x2idn yet. Do you have any updates on this? https://aws.amazon.com/marketplace/pp/prodview-2otariyxb3mqu?ref_=beagle#pdp-reviews

(0004358) satoshi iwashita 2023-08-16 10:01	Hello. It seems that ami-01c6603b0b5d545ec does not support x2idn yet. Do you have any updates on this? https://aws.amazon.com/marketplace/pp/prodview-2otariyxb3mqu?ref_=beagle#pdp-reviews

(0004359) Neil Hanlon 2023-08-16 14:47	I am pretty sure I resolved this back in April, but I've found those dimensions were once again missing. I will open a ticket with AWS if this regresses again.

(0004360) satoshi iwashita 2023-08-17 01:39	I received following email from AWS and I checked succeed launch ec2 from ami-01c6603b0b5d545ec with x2idn. Thank you for your response. --- Greetings from AWS Marketplace, Thank you for subscribing to Rocky Linux 8 (Official). We're writing to inform you that Rocky Linux added new instance types to Rocky Linux 8 (Official) on AWS Marketplace. As a current customer, your subscription to the product and existing instances are unaffected. You can now launch the product with the following instance types: x2iedn.xlarge x2iedn.2xlarge x2iedn.4xlarge x2iedn.8xlarge x2iedn.16xlarge x2iedn.24xlarge x2iedn.32xlarge x2iedn.metal x2idn.16xlarge x2idn.24xlarge x2idn.32xlarge x2idn.metal

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4028	[Account Services] General	minor	N/A	2023-08-29 22:54	2023-09-02 03:50

Reporter:	Paul Newell	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	yum/dnf thinks clamav-freshclam obsolete but no documentation at ClamAV of such
Description:	On a fully updated Rock 9.2 system, I run yum/dnf check-updates in the evening of 28aug23. It tells me that a new clamav is available and that it is obsoleting freshclam. There is no notice of freshclam being obsoleted at clamav website or anywhere online. Given freshclam is the way the database/signatures get updated, this strikes me as "this doesn't feel right". Given that Clamav site has nothing, I am wondering if these is something in the packaging for dnf/yum that isn't right Screenshot of what I am seeing included. Any thoughts? Thanks in advance
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	yum_check-update_28aug23.png (105,608 bytes) 2023-08-29 22:54 https://bugs.rockylinux.org/file_download.php?file_id=961&type=bug

Notes
(0004461) Louis Abel 2023-08-30 00:14	This behavior appears to be normal. https://src.fedoraproject.org/rpms/clamav/blob/epel9/f/clamav.spec#_198 - clamav-freshclam (which is the name of the package) obsoletes clamav-update, which was the original name of the package. This makes sure that clamav-update is sufficiently replaced by clamav-freshclam. The clamav packages are not provided by Rocky Linux. They are provided by EPEL. Further questions about clamav (and other EPEL packages) should come here: https://discussion.fedoraproject.org/ - General Rocky Linux questions should come here: https://forums.rockylinux.org Closing as not a bug.

(0004492) Paul Newell 2023-09-02 03:50	Louis: The only reason I am re-opening this case is to thank you for explaining what is going on. I have never seen this message (?new to dnf?) and mis-read it as "obsoleting freshclam" rather than "freshclam obsoletes clamav-update". All I can say is "opps" and accept the egg on my face. Once again, Thanks, Paul ps: i will let you close bug to make sure you get this reply from me

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3565	[Rocky-Linux-8] kernel	crash	always	2023-06-09 06:57	2023-09-01 17:57

Reporter:	Wessel Sandkuijl	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	KVM live migrate of Rocky Linux 8.8 VM crashes/reboots VM
Description:	I've updated a few VM's from Rocky Linux 8.7 to 8.8. Live migrating these 8.8 VM's now causes a reboot of the VM instead of a regular live migrate. This issue doesn't happen with Rocky Linux 8.7. I'm using XCP-ng as virtualisation platform. The team of XCP-ng is able to replicate this issue. I've tried updating the xe-tools to the latest version available on github (7.20.2-1), this didn't solve the issue. I've done some testing and it looks to be kernel related. The stock Rocky Linux 8.8 kernel (4.18.0-477.13.1.el8_8.x86_64) causes the reboot to happen. Upgrading the kernel to kernel-lt (5.4.245-1.1.el8.elrepo.x86_64) allows the VM to be live-migrated again without reboot/crash.
Tags:
Steps To Reproduce:	Install VM with stock Rocky Linux 8.8 on XCP-ng, live migrate this VM.
Additional Information:
Attached Files:	image.png (10,243 bytes) 2023-08-09 17:35 https://bugs.rockylinux.org/file_download.php?file_id=925&type=bug

Notes
(0003796) Wessel Sandkuijl 2023-06-09 08:19	Apologies for the mistake in the title. KVM should be Xen.

(0003829) Wessel Sandkuijl 2023-06-10 07:16	To give a quick update, apparently this is caused by a missing patch in kernel versions starting with 4.18.0-466.el8. The very competent folks at XCP-ng figured this out: https://xcp-ng.org/forum/topic/7420/live-migrate-of-rocky-linux-8-8-vm-crashes-reboots-vm/12.

(0003961) Jamie Schnaitter 2023-07-03 18:12	I can confirm that we also face this issue at my institution, using XCP-ng as the hypervisor. Is there any prospect on when the patch will be ported into Rocky? As the above link shows, the necessary patch is in 4.18.0-488

(0003994) Louis Abel 2023-07-04 04:56	The bugzilla that notes this fix for -488 (in stream) as noted in the changelog is here: https://bugzilla.redhat.com/show_bug.cgi?id=2187810 - However it is set to private, so it is unclear when it will make it downstream to us. We do not generally make own backports to these. We will need to wait this week or next for the patch to become available from Red Hat.

(0004291) Raf van de Vreugde 2023-08-09 16:49	Problem still persist with the latest Citrix HyperVisor 8.2CU1 patchlevel XS82ECU1045! Rocky Linux 8.8 latest version Linux ... 4.18.0-477.15.1.el8_8.x86_64 #1 SMP Wed Jun 28 15:04:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

(0004292) Louis Abel 2023-08-09 16:50	4.18.0-477.15.1.el8_8 is not the latest kernel. Please update to 4.18.0-477.21.1.el8_8.

(0004293) Raf van de Vreugde 2023-08-09 17:35	Installed the latest updates, latest kernel Linux srv-mon-060 4.18.0-477.21.1.el8_8.x86_64 #1 SMP Tue Aug 8 21:30:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux but after migration still a probable problem (no reboot) -> see attached screenshot

(0004490) Akemi Yagi 2023-09-01 17:57	Assuming the fix will be in el8.9, a temporary solution may be to use elrepo's kernel-lt (or kernel-ml) as the submitter indicated. dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm dnf --enablerepo=elrepo-kernel install kernel-lt

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3829	[Rocky-Linux-9] mod_proxy_cluster	major	always	2023-07-20 17:08	2023-08-30 11:40

Reporter:	Marco Benuzzi	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	shipped version don't works
Description:	I'm preparing a Rocky 9 server to substitute an old CentOS 7. This server has an httpd with mod_cluster to balance backend JBoss machines. I've installed using dnf: - httpd Version: 2.4.53 Release: 11.el9_2.5 - mod_proxy_cluster Version: 1.3.18 Release: 1.el9 The configuration of httpd is more or less the same of the old CentOS 7 machine. The mod_cluster status page shows all the JBoss nodes. But any HTTP request receives HTTP 503 Service Unavailable. The message in the HTTP error log is proxy: CLUSTER: (balancer://cluster). All workers are in error state After a long debugging without success, I finally downloaded the mod_proxy_cluster sources from https://github.com/modcluster/mod_proxy_cluster.git and compiled enabling extended debug message to dig what is happining. But, using the compiled version of mod_proxy_cluster, all is working as expected. It seems that the mod_proxy_cluster shipped is broken.
Tags:
Steps To Reproduce:
Additional Information:	original configuration LoadModule proxy_cluster_module /usr/lib64/httpd/modules/mod_proxy_cluster.so LoadModule cluster_slotmem_module /usr/lib64/httpd/modules/mod_cluster_slotmem.so LoadModule manager_module /usr/lib64/httpd/modules/mod_manager.so LoadModule advertise_module /usr/lib64/httpd/modules/mod_advertise.so modified configuration LoadModule proxy_cluster_module modules.modcluster/mod_proxy_cluster.so LoadModule manager_module modules.modcluster/mod_manager.so LoadModule advertise_module modules.modcluster/mod_advertise.so LoadModule lbmethod_cluster_module modules.modcluster/mod_lbmethod_cluster.so Note that in the last version of mod_proxy_cluster mod_cluster_slotmem is substitued by mod_lbmethod_cluster
Attached Files:	cluster-status.png (99,555 bytes) 2023-08-29 15:49 https://bugs.rockylinux.org/file_download.php?file_id=958&type=bug comment1.txt (2,451 bytes) 2023-08-29 15:49 https://bugs.rockylinux.org/file_download.php?file_id=959&type=bug attachments.tar.gz (13,555 bytes) 2023-08-29 15:55 https://bugs.rockylinux.org/file_download.php?file_id=960&type=bug

Notes
(0004126) Louis Abel 2023-07-20 23:33	We do not have enough reproduction steps. Please provide the configuration you are using with httpd so we can effectively reproduce your issue. Setting to needinfo.

(0004456) Marco Benuzzi 2023-08-29 15:49	To repoduce the problem I've created a VM with 3 network cards and installed Rocky Linux 9.2 minimal. My IP addresses are: - IP1 192.168.122.80 used for apache - IP2 192.168.122.186 used for jboss node 1 - IP3 192.168.122.235 used for jboss node 2 After first boot: - dnf update - dnf install httpd mod_proxy_cluster java-1.8.0-openjdk-devel - in /etc/sysconfig/selinux change SELINUX=permissive - firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="IP1/24" accept' - reboot Configure httpd - put httpd.conf in /etc/httpd/conf - in /etc/httpd/conf/httpd.conf change lines 2 and 3 (Listen) and lines 75 and 93 (VirtualHost) with your IP1 [don't change ports] - mv /etc/httpd/mod_proxy_cluster.conf.sample /etc/httpd/conf.modules.d/10-cluster.conf - in /etc/httpd/conf.modules.d/00-proxy.conf comment line 8 #LoadModule proxy_balancer_module modules/mod_proxy_balancer.so Download JBoss EAP 6.3 and unzip in two directories (node1 and node2) Configure JBoss node1 - put standalone.conf in ~/node1/bin and change line 50 THISIP=192.168.122.186 with your IP2 - put standalone.xml in ~/node1/standalone/configuration and change line 433 proxy-list="192.168.122.80:81" with your IP1 [don't change port] - put jboss-helloworld.war in ~/node1/standalone/deployments/ - touch ~/node1/standalone/deployments/jboss-helloworld.war.dodeploy Configure JBoss node2 - put standalone.conf in ~/node2/bin and change line 50 THISIP=192.168.122.186 with your IP3 - put standalone.xml in ~/node2/standalone/configuration and change line 433 proxy-list="192.168.122.80:81" with your IP1 [don't change port] - put jboss-helloworld.war in ~/node2/standalone/deployments/ - touch ~/node2/standalone/deployments/jboss-helloworld.war.dodeploy Start services: - systemctl start httpd - ~/node1/bin/standalone.sh - ~/node2/bin/standalone.sh Checks: - apache is running http://IP1/server-status - cluster is running http://IP1/cluster-status (see cluster-status.png) - application is running on node1 http://IP2:8080/jboss-helloworld - application is running on node2 http://IP3:8080/jboss-helloworld - no error messages in /var/log/httpd/cluster_error_log Test application on cluster http://IP1/jboss-helloworld HTTP status 503 service unavailable For each request a error i written in /var/log/httpd/error_log [Tue Aug 29 17:47:41.978206 2023] [:error] [pid 17034:tid 17077] proxy: CLUSTER: (balancer://cluster). All workers are in error state

(0004457) Marco Benuzzi 2023-08-29 15:51	Missed attachments

(0004458) Marco Benuzzi 2023-08-29 15:52	Missed attachments (zipped)

(0004459) Marco Benuzzi 2023-08-29 15:54	I got error submitting with attachment...

(0004460) Marco Benuzzi 2023-08-29 15:55	Trying with tar.gz

(0004465) Marco Benuzzi 2023-08-30 11:38	I've tested with mod_proxy_cluster compiled from sources. With version 1.3.x there is always the same problem. The only version that works is the 2.x

(0004466) Marco Benuzzi 2023-08-30 11:40	Note that in Centos 7 with httpd 2.4.6 and mod_proxy_cluster 1.3.1 all is working well.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4029	[Rocky-Linux-9] General	major	always	2023-08-30 08:22	2023-08-30 09:00

Reporter:	zhang yx	Platform:
Assigned To:	Louis Abel	OS:
Priority:	high	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Unable to restart Rocky due to systemd configuration in wsl
Description:	``` PS C:\Windows\system32> wsl --version WSL 版本： 1.2.5.0 内核版本： 5.15.90.1 WSLg 版本： 1.0.51 MSRDC 版本： 1.2.3770 Direct3D 版本： 1.608.2-61064218 DXCore 版本： 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows 版本： 10.0.19045.3324 ``` ``` PS C:\Windows\system32> wsl --import RockyLinux_9_2 F:\VirtualMachine\WSL\RockyLinux_9_2 F:\VirtualMachine\Rocky-9-Container-Base.latest.x86_64.tar.xz --version 2 正在导入，这可能需要几分钟时间。操作成功完成。 PS C:\Windows\system32> wsl -d RockyLinux_9_2 ``` ``` [root@DESKTOP-J0D4A9V system32]# vi /etc/wsl.conf [root@DESKTOP-J0D4A9V system32]# cat /etc/wsl.conf [boot] systemd=true [root@DESKTOP-J0D4A9V system32]# [root@DESKTOP-J0D4A9V system32]# exit logout ``` ``` PS C:\Windows\system32> wsl --list --verbose NAME STATE VERSION * OracleLinux_9_1 Stopped 2 RockyLinux_9_2 Stopped 2 ``` ``` PS C:\Windows\system32> wsl -d RockyLinux_9_2 灾难性故障 Error code: Wsl/Service/CreateInstance/E_UNEXPECTED ```
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	1.png (110,839 bytes) 2023-08-30 08:22 https://bugs.rockylinux.org/file_download.php?file_id=962&type=bug 2.png (93,365 bytes) 2023-08-30 08:22 https://bugs.rockylinux.org/file_download.php?file_id=963&type=bug 3.png (92,157 bytes) 2023-08-30 08:22 https://bugs.rockylinux.org/file_download.php?file_id=964&type=bug 4.png (85,457 bytes) 2023-08-30 08:22 https://bugs.rockylinux.org/file_download.php?file_id=965&type=bug

Notes
(0004464) Louis Abel 2023-08-30 09:00	WSL is not directly supported by the project. Those who use Rocky Linux in WSL can better assist you. You are recommended to ask for assistance at https://forums.rockylinux.org or https://chat.rockylinux.org Setting to needinfo.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4027	[Rocky-Linux-8] shim	minor	always	2023-08-29 21:38	2023-08-30 08:23

Reporter:	Amy Crate	Platform:
Assigned To:	Sherif Nagy	OS:
Priority:	normal	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	aarch64 shim is not signed by microsoft
Description:	The rocky linux ARM shims on both version 8 and 9 are signed only by the Rocky Enterprise Software Foundation, not by Microsoft.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0004462) Sherif Nagy 2023-08-30 08:21	We are planning to sign our ARM shim with microsoft and we are working on building a secureboot signing infrastructure for other architectures as well, however at this moment, we don't have an exact time. You may load the RESF cert into the mok and enable secureboot until we sign the ARM shim with Microsoft cert.

(0004463) Sherif Nagy 2023-08-30 08:23	Confirmed and we are well aware of this.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3964	[Rocky-Linux-9] gnupg2	minor	N/A	2023-08-18 21:00	2023-08-18 21:00

Reporter:	Neil Hanlon	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	9.2
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	gunpg2 missing runtime requires on openldap-compat, for some reason
Description:	upstream's gnupg2 has a dynamic (linker-time) Requires for ``` liblber-2.4.so.2()(64bit) libldap_r-2.4.so.2()(64bit) ``` but these are missing from the rocky version, despite the package being available
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3928	[Rocky-Linux-8] NetworkManager	minor	always	2023-07-27 19:06	2023-07-27 19:06

Reporter:	Wayne Johnson	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	NetworkManager fails to run dispatcher scripts during DHCP lease renewal (action dhcp4-change)
Description:	On Rocky 8 and Rocky 9, NetworkManager only runs the dispatcher scripts on startup or a connectivity change, it does not run them during a lease renewal (dhcp4-change). It was also reported here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1147 el7 and earlier ran dispatchers on dhcp4-change.
Tags:
Steps To Reproduce:	See https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1147
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3796	[Rocky-Linux-8] systemd	major	always	2023-07-17 14:27	2023-07-18 10:34

Reporter:	Ash Ak	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Systemd--user does not inherit user umask set at login - defaults to 0022,
Description:	When logged into a GNOME session, all applications opened using the GUI ie gedit, fileexplorer do not use the system set umask but default to a umask value of 022. This works fine from a login shell with the correct permissions when creating a file in the users home directory, when a file is created from the gui the umask is different and results in incorrect permissions.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0004060) Louis Abel 2023-07-18 01:54	Thank you for the report. This (unfortunately) sounds like normal behavior of systemd --user. In theory pam_umask can be used to set this, but it may not get inherited down the process tree. I would recommend trying this, replacing <<UID>> and <<UMASK>> as needed. % mkdir -p /etc/systemd/system/user@<<UID>>.service.d % cat > /etc/systemd/system/user@<<UID>>.service.d/umask.conf<<EOF [Service] UMask=<<UMASK>> EOF % systemctl daemon-reload After that, log out and back in. Or restart the system if all else fails.

(0004093) Ash Ak 2023-07-18 10:34	Hi Louis, Thanks for the reply, have tried that and several other configurations but none seem to work. as you mention this is normal behaviour for Rocky 8.8, it does not seem to be present in other distro ie centos 7 which seems to inherit and keep the umask. It is important that umask is retained within a profile for all services/processes for consistency. We have tested pam_umask which also does not work. This definately seems like a bug as the umask should be inherited from the global user setting. Could you please elaborate on normal behavious as i have not seen this previously. We should be able to change this but it seems regardless of where we apply the umask setting, child processes do not inherit the umask. Do you know if the same behaviour is experienced in previous releases of Rocky Linux?

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3730	[Rocky-Linux-9] 389-ds-base	crash	always	2023-07-03 11:35	2023-07-03 14:22

Reporter:	Apurba Ghosh	Platform:	Web Platform
Assigned To:	Neil Hanlon	OS:	Rocky Linux
Priority:	urgent	OS Version:	9
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Installation not Started
Description:	While starting to Download Rocky Linux 9 for AARCH(arm64) platform, pressing any button doesen't start download while it isn't the case for any other Rocky linux Versions. Please look into the Matter as Early as Possible
Tags:	installation
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003928) Neil Hanlon 2023-07-03 14:22	closed via https://github.com/rocky-linux/rockylinux.org/pull/544 thank you!

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3664	[Rocky-Linux-9] kernel	block	always	2023-06-22 10:45	2023-06-22 10:45

Reporter:	Matt Heck	Platform:	x86_64
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9.2
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Presence of XFS on secondary SATA SSD in /etc/fstab breaks cryptsetup for primary NVME partition
Description:	This took a while to figure out, and I haven't identified the root cause, but it is 100% reproducible on this system. System contains: A: (1) WD Black NVME device with boot (unecnrypted), EFI (unencrypted), and LVM2 PV (LUKS encrypted) partitions B: (1) Samsung 2 TB SSD on SATA, partitioned as XFS (unencrypted) C: (1) additional rotary HDD on SATA, incidental, no apparent effect on this issue if enabled or disabled D: (2) optical drives on SATA (Blu-Ray recorders). The encrypted LVM2 PV, when decrypted, expands to a single volume group containing / and /home logical volumes which are not recursively encrypted (that is, the PV itself is the only cryptsetup operation required). OBSERVED: 1. Rocky 9.1 boots normally WHETHER OR NOT (B) is enabled in /etc/fstab. 2. Rocky 9.2 boots ONLY if (B) is DISABLED in /etc/fstab 3. Under Rocky 9.2, if (B) is ENABLED in /etc/fstab, password entry for (A) FAILS and booting FAILS. 4. Under Rocky 9.2, if (B) is DISABLED in /etc/fstab, password entry for (A) SUCCEEDS and the system boots. SUMMARY: Presence or absence of a COMPLETELY UNRELATED SATA SSD breaks LUKS password entry (or some other part of decryption that has the same appearance, and causes a re-prompt for the password) on the primary NVME boot drive.
Tags:
Steps To Reproduce:	"All devices" below refers to: A: (1) WD Black NVME device with boot (unecnrypted), EFI (unencrypted), and LVM2 PV (LUKS encrypted) partitions B: (1) Samsung 2 TB SSD on SATA, partitioned as XFS (unencrypted) C: (1) additional rotary HDD on SATA, incidental, no apparent effect on this issue if enabled or disabled D: (2) optical drives on SATA (Blu-Ray recorders). BASELINE 1. Boot the system into 9.1 with all devices enabled in /etc/fstab. 2. Enter the password to decrypt the LUKS encrypted NVME partition containing the LVM2 PV. 3. Observe successful password entry and successful boot. FAILURE 1. Boot the system into 9.2 with all devices enabled in /etc/fstab, 2. Enter the password to decrypt the LUKS encrypted NVME partition containing the LVM2 PV. 3. Observe FAILURE to boot-- cryptsetup repeatedly prompts for password until failure. CLUE 1. Boot the system into 9.2 with all devices EXCEPT THE SATA SSD enabled in /etc/fstab, 2. Enter the password to decrypt the LUKS encrypted NVME partition containing the LVM2 PV. 3. Observe successful password entry and successful boot.
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2740	[Rocky-Linux-9] kernel	major	always	2023-03-23 09:04	2023-06-08 13:32

Reporter:	michal michal	Platform:	x86_64
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	cgroups v2 io.max not applied from parent folder
Description:	io.max cgroup v2 limit seems to be applied only from the lowest level of cgroup configuration. We have the following structur for a process: $ cat /proc/9439/cgroup 0::/dir1/dir2/dir3/dir4 Setting io.max limit in dir1, dir2 or dir3 has no effect. Such as this config has no effect: echo "253:0 rbps=50971520" > /sys/fs/cgroup/dir1/dir2/dir3/io.max However setting the limit in dir4 properly works: echo "253:0 rbps=50971520" > /sys/fs/cgroup/dir1/dir2/dir3/dir4/io.max $ cat /sys/fs/cgroup/dir1/dir2/dir3/dir4/cgroup.controllers cpuset cpu io memory hugetlb pids rdma misc
Tags:	kernel
Steps To Reproduce:
Additional Information:	uname -a Linux hostname 5.14.0-162.18.1.el9_1.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 1 22:02:24 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Attached Files:

Notes
(0003730) michal michal 2023-06-08 09:40	Here's a good way to replicate this on a clean installation: cd /sys/fs/cgroup/ echo +io > cgroup.subtree_control mkdir disktest cd disktest/ echo "8:0 wbps=1097150" > io.max echo $$ > cgroup.procs cd ~ dd if=/dev/zero of=sample bs=30M count=1 oflag=direct On Rocky Linux 9.1, the io limit is not applied # uname -a Linux cg-rocky 5.14.0-162.18.1.el9_1.cloud.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 1 19:45:58 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/rocky-release Rocky Linux release 9.1 (Blue Onyx) On Debian and CentOS, the limit is properly applied. # uname -a Linux cg-debian 5.10.0-22-cloud-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64 GNU/Linux # cat /etc/debian_version 11.7 # uname -a Linux cg-centos.c.1234.internal 5.14.0-307.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Wed May 3 06:16:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/centos-release CentOS Stream release 9

(0003763) michal michal 2023-06-08 13:32	Can no longer reproduce with # uname -a Linux instance-1 5.14.0-284.11.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Tue May 9 17:09:15 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Can be closed

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3533	[Rocky-Linux-8] kernel	block	sometimes	2023-06-02 20:25	2023-06-02 20:36

Reporter:	Stuart Gathman	Platform:	X86_64
Assigned To:	Louis Abel	OS:	Rocky Linux
Priority:	urgent	OS Version:	8.8
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	kernel-4.18.0-477.10.1.el8_8.x86_64 locks up qemu-kvm with heavy virtio
Description:	qemu-kvm becomes frozen and unkillable on heavy virtio with multiple devices. kill -9 is ineffective. ps -ef hangs, ps -el does not (because it doesn't need to access process memory). atop on host hangs and requires kill -9 virsh destroy doesn't work either naturally. All other vms and host continue to work normally (unless you manage to lock up another vm). top on host shows 'D' and 0.0 cpu for wedged qemu-kvm process To reset: 1. Shutdown all working vms. 2. systemctl poweroff 3. There will be a long time while systemd tries to kill qemu-kvm. Finally after maybe 10mins it will time out and report on the console that it can't unmount /oldroot (because qemu-kvm has it open for process image). There should be no more disk activity (hopefully your server has an activity light). At this point, you can hold the power button down to force power off. 4. Power on again Mitigation: Install kernel-4.18.0-425.19.2.el8_7.x86_64 as default boot. This is reported as stable. I am testing it now. From a Fedora 36 guest: May 29 20:35:20 matrix.gathman.org kernel: Sending NMI from CPU 1 to CPUs 0: May 29 20:38:19 matrix.gathman.org kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: May 29 20:38:19 matrix.gathman.org kernel: rcu: 0-...0: (6 ticks this GP) idle=85fc/1/0x4000000000000000 softirq=274821528/274821529 fqs=1289617 May 29 20:38:19 matrix.gathman.org kernel: (detected by 1, t=5460152 jiffies, g=584688457, q=2153 ncpus=2)
Tags:	kernel, qemu-kvm
Steps To Reproduce:	Boot from kernel-4.18.0-477.10.1.el8_8.x86_64 and run a qemu-kvm guest os with 2 or more virtio disks. Do something like run a backup of 10+ G from one disk to the other.
Additional Information:
Attached Files:

Notes
(0003637) Louis Abel 2023-06-02 20:31	This issue is occurring on an old version of -477 kernel. Please attempt to get the same results using kernel 4.18.0-477.13.1.el8_8. Setting to need info.

(0003638) Stuart Gathman 2023-06-02 20:32	The journal from f36 guest was obtained after resetting the host and restarting the vm, then running journalctl -b-3 to see what the last journal entries were. (There were a few more reboots of vm to fsck filesystems, etc) The host had a stacktrace in dmesg about when the vm froze, but I forgot to save it. :-( (Being in a hurry to get services back up)

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3499	[Rocky-Linux-9] python3	major	always	2023-06-02 12:36	2023-06-02 16:01

Reporter:	Brian Murrell	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	python3 missing debug{info,source} packages
Description:	Rocky LInux 9 does not seem to have debug{info,source} packages for python[3[.9]] as far as I can tell. They don't seem to be available in https://rocky-linux-northamerica-northeast1.production.gcp.mirrors.ctrliq.cloud/pub/rocky/9/BaseOS/x86_64/debug/tree/Packages/p/ for example. AlmaLinux 9 does seem to have them in https://repo.almalinux.org/vault/9/BaseOS/debug/x86_64/Packages/ though. Why are these not available on Rocky Linux 9? Or are they somewhere I have not looked yet?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003631) Louis Abel 2023-06-02 16:01	http://dl.rockylinux.org/pub/rocky/9/devel/x86_64/debug/tree/Packages/p/ You can find them in the devel repository debug tree, until we can address some of our yumrepofs bugs surrounding this.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3433	[Rocky-Linux-9] General	block	have not tried	2023-05-31 19:28	2023-05-31 19:30

Reporter:	David Chorlian	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Boots to read-only root file system -- possible nfs problem
Description:	From dmesg: [ 8.804124] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery d irectory [ 8.804321] NFSD: Using legacy client tracking operations. [ 8.804323] NFSD: starting 90-second grace period (net f0000000) [ 99.436469] nfsd4: failed to purge old clients from recovery directory
Tags:	kernel
Steps To Reproduce:	Repeats message on reboot. Becasue I cannot get system to fully functional state, I cannot attempt to reproduce the problem by disconnecting the power cords.
Additional Information:	Probably resulted from power failure. There was one NFS client, mounting mutliple ZFS directories.
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
86	[Rocky-Linux-8] subscription-manager	minor	always	2022-03-26 00:38	2023-05-28 08:49

Reporter:	Lukas Magauer	Platform:
Assigned To:	Release Engineering	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	SELinux is preventing rhsmcertd-worke from create access on the directory repos
Description:	Looks like I found a bug in rhsm. First, I hope it's okay to open an issue here first, to document, as tracking down the issue might take a longer time. I saw on one of my systems weird SELinux messages, and then further searched on others as well, so I'm sure it comes down to the following environmental setup: - Rocky Linux 8.5 with the latest packages installed to date - Hosted on VMware ESXi 7.0U3c - Servers are configured against a Katello 4.3 instance, which serves the repos - Servers have different repos connected, but it looks to only be happening with the AppStream repo - Servers with the error and also servers without the error have totally different module streams enabled and I don't see it appearing to be in connection with that - Server also have pretty much different packages installed And finally here is the information from sealert: # sealert -l a1a79840-7651-4d36-ad6c-941801221c8b SELinux is preventing rhsmcertd-worke from create access on the directory repos. *** Plugin catchall (100. confidence) suggests ************************ If you believe that rhsmcertd-worke should be allowed create access on the repos directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rhsmcertd-worke' --raw \| audit2allow -M my-rhsmcertdworke # semodule -X 300 -i my-rhsmcertdworke.pp Additional Information: Source Context system_u:system_r:rhsmcertd_t:s0 Target Context system_u:object_r:rpm_var_lib_t:s0 Target Objects repos [ dir ] Source rhsmcertd-worke Source Path rhsmcertd-worke Port <Unknown> Host r8-ntopng-prod.fritz.box Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-3.14.3-80.el8_5.2.noarch Local Policy RPM selinux-policy-targeted-3.14.3-80.el8_5.2.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name r8-ntopng-prod.fritz.box Platform Linux r8-ntopng-prod.fritz.box 4.18.0-348.el8.0.2.x86_64 #1 SMP Sun Nov 14 00:51:12 UTC 2021 x86_64 x86_64 Alert Count 1 First Seen 2022-03-25 23:14:57 CET Last Seen 2022-03-25 23:14:57 CET Local ID a1a79840-7651-4d36-ad6c-941801221c8b Raw Audit Messages type=AVC msg=audit(1648246497.243:698): avc: denied { create } for pid=182053 comm="rhsmcertd-worke" name="repos" scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir permissive=0 Hash: rhsmcertd-worke,rhsmcertd_t,rpm_var_lib_t,dir,create After seeing that output, I further searched in the rhsm.log file, which clearly shows from where the error is coming: # cat /var/log/rhsm/rhsm.log \| grep ERROR 2022-03-20 04:07:28,326 [ERROR] rhsmcertd-worker:1938239:MainThread @profile.py:145 - Unable to create sack object: Cannot create persistdir "/var/lib/dnf/repos/appstream-62ae9a0bbea44fbe": Permission denied 2022-03-20 08:07:28,402 [ERROR] rhsmcertd-worker:2097608:MainThread @profile.py:145 - Unable to create sack object: Cannot create persistdir "/var/lib/dnf/repos/appstream-62ae9a0bbea44fbe": Permission denied I was already searching for this error in RedHat's Bugzilla, but only found similar once which don't appear to be the same issue https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc=SELinux%20is%20preventing%20rhsmcertd-worke&short_desc_type=allwordssubstr That's everything I found out up to now, if I can add more input, will off course do that Unfortunately I can't test it with RHEL 8 right now as I don't have any commercial licenses I could add to Katello. Maybe somebody else could help on that part. Thank you in advance!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003533) Lukas Magauer 2023-05-28 08:49	This was fixed by an upstream change to the subscription-manager SELinux policies.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
87	[Rocky-Linux-8] anaconda	minor	always	2021-10-14 18:35	2023-05-28 08:47

Reporter:	Lukas Magauer	Platform:
Assigned To:	Infrastructure Team	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Anaconda is unable to use mirrorlist or metalink as installation source on the first try
Description:	While working on the test suites in OpenQA we discovered an issue with the Graphical Mirrorlist Installation.
Tags:
Steps To Reproduce:	- Start the graphical installer and select the language - Configure the network and clock - Go in the "Installation Source" spoke and add either the [mirrorlist](mirrors.rockylinux.org/mirrorlist?repo=rocky-BaseOS-8.4&arch=x86_64) or the [metalink](mirrors.rockylinux.org/metalink?repo=rocky-BaseOS-8.4&arch=x86_64) - Switch the URL type to the correct type - Click done After these steps the main screen will look like attachment_1 After another click on the "Install Source" spoke and going back with the done button, the mirrorlist/metalink gets loaded and accepted as source.
Additional Information:	## Expected behavior The mirrorlist/metalink gets directly recognized and used ## Further information found - The problem looks to be that the BaseOS gets loaded by the mirrorlist/metalink but Anaconda is unable to find the linked AppStream repo (picture after this post) - This problem does not occur if a repolist URL is used I hope this is enough information, if something is missing or I can help with the troubleshooting, please just give me a note in MM. Thanks, Lukas
Attached Files:	attachment_1.png (90,093 bytes) 2022-05-03 08:03 https://bugs.rockylinux.org/file_download.php?file_id=8&type=bug graphical-mirrorlist-installation-source-error_smaller.png (443,114 bytes) 2022-05-03 08:03 https://bugs.rockylinux.org/file_download.php?file_id=9&type=bug

Notes
(0000106) Lukas Magauer 2021-10-14 18:41	Install Source Error Anaconda log from OpenQA with error

(0000107) Louis Abel 2021-10-14 19:14	I am unsure this is something that Release Engineering can fix. The .treeinfo is configured correctly as you can point to a direct mirror (such as dl.rl.o or anything that comes up in the list for your region) and it just works. The mirrorlist is behaving as it should as well, because dnf functions properly. As this behavior only occurs while trying to use a mirror through anaconda, it will require Neil to assist looking into it, who is on vacation.

(0000108) Lukas Magauer 2021-10-14 22:52	Okay I'm totally at you, this shouldn't be that high on the priority list, we thought maybe something for 8.5. It just looked like a bug in Anaconda to us. But maybe it is also just a configuration thing about the MirrorManager.

(0000109) Louis Abel 2021-10-14 23:09	It could be either one. In 8.5 there is an anaconda version bump, so perhaps it has some fixes if it's not our mirror manager. https://kojidev.rockylinux.org/koji/buildinfo?buildID=12442

(0000110) Lukas Magauer 2021-10-15 14:49	I had access to another 8.5-beta system with anaconda 33.16.5.4, and I know that there it still doesn't work. Same behavior as with our 8.4 image. As this is kind of a minor problem, I set it to that now.

(0000111) Neil Hanlon 2021-10-19 22:20	Oh goody. Anaconda debugging!

(0003532) Lukas Magauer 2023-05-28 08:47	This has been fixed a long time ago. (with the release of 8.6 I think)

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3334	[Rocky-Linux-9] kernel	minor	have not tried	2023-05-24 05:49	2023-05-24 06:10

Reporter:	steven Lee	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Vulnerability Check
Description:	Are Rocky Linux versions 8, 9 safe for vulnerabilities(CVE-2023-32233)?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003499) Louis Abel 2023-05-24 06:10	Please see the following: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2023-32233 https://access.redhat.com/solutions/7012508 Setting to needinfo.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3269	[Rocky-Linux-9] containers-common	major	always	2023-05-20 18:13	2023-05-20 18:15

Reporter:	Udayendu Kar	Platform:	Rocky Linux 8.8
Assigned To:		OS:	8
Priority:	high	OS Version:	8.8
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	"pulling image: rpc error: code = Unknown desc = invalid policy in \"/etc/containers/policy.json\": Unknown key \"keyPaths\""
Description:	[preflight] Pulling images required for setting up a Kubernetes cluster [preflight] This might take a minute or two, depending on the speed of your internet connection [preflight] You can also perform this action in beforehand using 'kubeadm config images pull' error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR ImagePull]: failed to pull image registry.k8s.io/kube-apiserver:v1.26.5: output: time="2023-05-20T23:11:21+05:30" level=fatal msg="pulling image: rpc error: code = Unknown desc = invalid policy in \"/etc/containers/policy.json\": Unknown key \"keyPaths\"" , error: exit status 1 [ERROR ImagePull]: failed to pull image registry.k8s.io/kube-controller-manager:v1.26.5: output: time="2023-05-20T23:11:39+05:30" level=fatal msg="pulling image: rpc error: code = Unknown desc = invalid policy in \"/etc/containers/policy.json\": Unknown key \"keyPaths\"" , error: exit status 1 [ERROR ImagePull]: failed to pull image registry.k8s.io/kube-scheduler:v1.26.5: output: time="2023-05-20T23:11:57+05:30" level=fatal msg="pulling image: rpc error: code = Unknown desc = invalid policy in \"/etc/containers/policy.json\": Unknown key \"keyPaths\"" , error: exit status 1 [ERROR ImagePull]: failed to pull image registry.k8s.io/kube-proxy:v1.26.5: output: time="2023-05-20T23:12:15+05:30" level=fatal msg="pulling image: rpc error: code = Unknown desc = invalid policy in \"/etc/containers/policy.json\": Unknown key \"keyPaths\"" , error: exit status 1 [ERROR ImagePull]: failed to pull image registry.k8s.io/pause:3.9: output: time="2023-05-20T23:12:34+05:30" level=fatal msg="pulling image: rpc error: code = Unknown desc = invalid policy in \"/etc/containers/policy.json\": Unknown key \"keyPaths\"" , error: exit status 1 [ERROR ImagePull]: failed to pull image registry.k8s.io/etcd:3.5.6-0: output: time="2023-05-20T23:12:52+05:30" level=fatal msg="pulling image: rpc error: code = Unknown desc = invalid policy in \"/etc/containers/policy.json\": Unknown key \"keyPaths\"" , error: exit status 1 [ERROR ImagePull]: failed to pull image registry.k8s.io/coredns/coredns:v1.9.3: output: time="2023-05-20T23:13:10+05:30" level=fatal msg="pulling image: rpc error: code = Unknown desc = invalid policy in \"/etc/containers/policy.json\": Unknown key \"keyPaths\"" , error: exit status 1 [preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...` To see the stack trace of this error execute with --v=5 or higher
Tags:	imagepull, kubernetes, policy
Steps To Reproduce:	Make sure to have the following version of 'containers-common' package is installed in the system: # rpm -qi containers-common Name : containers-common Epoch : 2 Version : 1 Release : 64.module+el8.8.0+1265+fa25dd7a Architecture: x86_64 Install Date: Sat May 20 23:08:59 2023 Group : Unspecified Size : 521080 License : ASL 2.0 Signature : RSA/SHA256, Wed May 17 03:08:41 2023, Key ID 15af5dac6d745a60 Source RPM : containers-common-1-64.module+el8.8.0+1265+fa25dd7a.src.rpm Build Date : Wed May 17 02:52:24 2023 Build Host : ord1-prod-x86build005.svc.aws.rockylinux.org Relocations : (not relocatable) Packager : infrastructure@rockylinux.org Vendor : Rocky Summary : Common configuration and documentation for containers Description : This package contains common configuration files and documentation for container tools ecosystem, such as Podman, Buildah and Skopeo. It is required because the most of configuration files and docs come from projects which are vendored into Podman, Buildah, Skopeo, etc. but they are not packaged separately. Then try to pull the required container images for kubernetes cluster configuration using the below command: # kubeadm config images pull The above command will fail with the error message as mentioned in the issue description.
Additional Information:	To fix this issue, the '/etc/containers/policy.json' file has to be updated with the following content: { "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "docker": { "registry.access.redhat.com": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" } ], "registry.redhat.io": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" } ] }, "docker-daemon": { "": [ { "type": "insecureAcceptAnything" } ] } } }
Attached Files:

Notes
(0003435) Udayendu Kar 2023-05-20 18:15	The default 'policy.json' file is looking like the below which is causing the issue: { "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "docker": { "registry.access.redhat.com": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPaths": ["/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release", "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta"] } ], "registry.redhat.io": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPaths": ["/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release", "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta"] } ] }, "docker-daemon": { "": [ { "type": "insecureAcceptAnything" } ] } } }

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3203	[Rocky-Linux-8] General	minor	always	2023-05-08 13:30	2023-05-19 19:15

Reporter:	Alex Botelho	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Syncing RL8 PowerTools Repository Warns: "Incoming and existing advisories have the same id but different timestamps and ..."
Description:	Full error: "Incoming and existing advisories have the same id but different timestamps and non-intersecting package lists. It is likely that they are from two different incompatible remote repositories. E.g. RHELX-repo and RHELY-debuginfo repo. Ensure that you are adding content for the compatible repositories. To allow this behavior, set ALLOW_AUTOMATIC_UNSAFE_ADVISORY_CONFLICT_RESOLUTION = True (q.v.) in your configuration. Advisory id: RLSA-2022:1763" This happens when I sync the repository using Pulp 3.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003202) Lukas Magauer 2023-05-08 13:43	Hi Alex! Thank you for the hint about this! Two questions: - Which repo are you syncing? (/pub/8/x86_64/os/PowerTools?) - Which pulp 3 version are you using?

(0003203) Alex Botelho 2023-05-08 13:55	Hopefully the below outputs have all the information you required and more: [LIVE] fiction1:~ # pulp shell Starting Pulp3 interactive shell... pulp> status { "versions": [ { "component": "core", "version": "3.23.0", "package": "pulpcore", "domain_compatible": true }, { "component": "ansible", "version": "0.16.1", "package": "pulp-ansible", "domain_compatible": false }, { "component": "certguard", "version": "1.5.8", "package": "pulp-certguard", "domain_compatible": false }, { "component": "container", "version": "2.14.3", "package": "pulp-container", "domain_compatible": false }, { "component": "deb", "version": "2.20.1", "package": "pulp_deb", "domain_compatible": false }, { "component": "file", "version": "1.12.0", "package": "pulp-file", "domain_compatible": false }, { "component": "maven", "version": "0.3.3", "package": "pulp-maven", "domain_compatible": false }, { "component": "python", "version": "3.8.0", "package": "pulp-python", "domain_compatible": false }, { "component": "rpm", "version": "3.19.1", "package": "pulp-rpm", "domain_compatible": false } ], "database_connection": { "connected": true }, "redis_connection": { "connected": false }, "storage": { "total": 1029930151936, "used": 848088887296, "free": 138854281216 }, "domain_enabled": false } pulp> rpm remote show --name RockyLinux8-PowerTools { "pulp_href": "/pulp/api/v3/remotes/rpm/rpm/c641cbb5-89b1-462b-99fc-f1d53e32b697/", "pulp_created": "2022-11-10T15:43:19.621879Z", "name": "RockyLinux8-PowerTools", "url": "https://mirror.esecuredata.com/rocky-linux/8/PowerTools/x86_64/os/", "ca_cert": null, "client_cert": null, "tls_validation": true, "proxy_url": null, "pulp_labels": {}, "pulp_last_updated": "2022-11-10T15:43:19.621939Z", "download_concurrency": 30, "max_retries": null, "policy": "immediate", "total_timeout": null, "connect_timeout": null, "sock_connect_timeout": null, "sock_read_timeout": null, "headers": null, "rate_limit": null, "hidden_fields": [ { "name": "client_key", "is_set": false }, { "name": "proxy_username", "is_set": false }, { "name": "proxy_password", "is_set": false }, { "name": "username", "is_set": false }, { "name": "password", "is_set": false } ], "sles_auth_token": null } Cheers!

(0003204) Alex Botelho 2023-05-08 13:56	Looking back at my logs, we did not have this error last week. It appears as if this repo updated on May 4th, so it looks to have been a very recently introduced problem.

(0003205) Lukas Magauer 2023-05-08 14:16	Thank you for this detailed output, looks like pulp 3.23 got another good check :) We are / I am using Katello 4.8 for the checks, this is currently using pulp 3.22 with pulp-rpm 3.19.2 and it's not failing on me there, As far as I understand it, the error says, that the issuing date of the errata must have changed, and this is what pulp sees as an anomaly, hence disallows it. Will need to either do a quick setup or compare against the history, as I don't really see the issue in the metadata up to now. Or one of the devs will take a look 👍🏻

(0003206) Alex Botelho 2023-05-08 15:47	Cheers! We use the Pulp 3 container, which is fairly good at quickly getting Pulp 3 going.

(0003207) Lukas Magauer 2023-05-08 17:08	You are for sure right there! Was like half an hour to spin up and sync! One more question, I guess you are syncing via a schedule, which sync_policy are you using? Because the default looks to be additive (preserve existing and add), I recently heard from the Katello team, that the preferred option is mirror_complete nowadays for yum repos, I have been using mirror_content_only for a long time, maybe this gives the difference needed. (additive is generally not desired for yum repos)

(0003400) Alex Botelho 2023-05-19 19:15	Hi Lukas, Yes scheduled sync is using all the default parameters for syncing, of which additive is the default. For others referencing this bug report: https://docs.pulpproject.org/pulp_rpm/workflows/create_sync_publish.html Considering distribution repositories like Rocky Linux have proper errata information, I may consider tweaking our sync scripts to enable mirroring for some repos. The problem of course is this parameter is not saved in Pulp's database, and I would require storing a separate per-repository/remote configuration file, which is very awkward to manage. I would not want to enable mirroring across the board, as some upstreams are very aggressive in their purging of old package versions, which means they would be cutting off a safe rollback method in case of bad package versions. Cheers

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3136	[Rocky-Linux-9] General	major	random	2023-05-02 21:15	2023-05-16 15:23

Reporter:	Graham Leggett	Platform:
Assigned To:	Neil Hanlon	OS:	Rocky
Priority:	normal	OS Version:	9.1
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	IPv6 unreliable - Failed to download metadata for repo 'baseos'
Description:	IPv6 sometimes works, sometimes does not. From time to time on an IPv6 only host, dnf fails as follows: Rocky Linux 9 - BaseOS 0.0 B/s \| 0 B 00:40 Errors during downloading metadata for repository 'baseos': - Curl error (6): Couldn't resolve host name for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9 [Could not resolve host: mirrors.rockylinux.org] Error: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9 [Could not resolve host: mirrors.rockylinux.org]
Tags:
Steps To Reproduce:	Run "dnf update" on an IPv6 only host.
Additional Information:
Attached Files:

Notes
(0003169) Graham Leggett 2023-05-03 10:09	Looks like the failure is limited to when the unbound resolver is locally installed and used.

(0003170) Neil Hanlon 2023-05-03 12:37	We've had some intermittent reports of this but have not been able to nail down a root cause. How is your IPv6 traffic handled? Is it a direct allocation, or via a 646 tunnel broker like HE.net? Do you have any firewall rules on your network that would be preventing ICMP6 and/or PMTU traffic from flowing?

(0003171) Graham Leggett 2023-05-03 13:32	It's an IPv6 only host in a datacentre (specifically Hetzner in DE). IPv6 works if the DNS points at a Mikrotik router. As soon as DNS is changed to point at a locally installed copy of the unbound nameserver, we fail. Looking at https://dnssec-analyzer.verisignlabs.com/mirrors.rockylinux.org it seems fastly fails DNSSEC checks. I wonder if resolvers are interpreting this as "DNS name not configured securely, pretend it does not exist".

(0003172) Neil Hanlon 2023-05-03 14:03	Thanks for the info, that's helpful. Let me reach out to Fastly and see if they have some thoughts here. DNSSEC is an ongoing project for us as an infrastructure team, too, but I'm not able to give an ETA at this time.

(0003173) Graham Leggett 2023-05-03 14:50	In theory DNSSEC missing isn't an error, but if DNSSEC is misconfigured then resolution attempts will throw an error. Very odd that a CDN doesn't do DNSSEC.

(0003334) Zulu Echo 2023-05-16 15:23	We have also been working on an ipv6 only network and had this problem on all of our rockylinux installations. We were running Nat64 with ipv6 on the inside and only ipv4 on the external network connection. By simply using the "-6" parameter with dnf, we succesfully updated without any further issues. I.E. "dnf -6 update" Hope this helps someone.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3169	[Rocky-Linux-8] libsoup	major	always	2023-05-04 08:39	2023-05-04 08:39

Reporter:	Benoît Monin	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	soup WebSocket server asserts when a client is closing the connection
Description:	On rocky linux 8.7, a websockets server implemented with libsoup asserts (SIGABRT) when a client closes the connection. This is similar to the problem reported upstream in issue 181 (https://gitlab.gnome.org/GNOME/libsoup/-/issues/181). The libsoup rpm is based on 2.62.3 tarball plus 3 patches for websockets that are causing the issue. Backporting upstream commit 87e8c2ab (https://gitlab.gnome.org/GNOME/libsoup/-/commit/87e8c2ab9f3bc79befb0e3b25ec513cfd36fefe9) fixes it
Tags:
Steps To Reproduce:	Upstream issue 181 have a code example of the problem.
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3103	[Cloud] General	major	always	2023-04-29 17:24	2023-04-30 05:07

Reporter:	Azhar Patel	Platform:
Assigned To:		OS:
Priority:	high	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky-8-OCP-8.7-20230215.0.x86_64.8.7.2 Does not Boot (Oracle Cloud)
Description:	Rocky-8-OCP-8.7-20230215.0.x86_64.8.7.2 does not boot in Oracle Cloud. It seems that the image may be broken.
Tags:
Steps To Reproduce:	Initialize an instance using Rocky-8-OCP-8.7-20230215.0.x86_64.8.7.2
Additional Information:
Attached Files:

Notes
(0003136) Brian Clemens 2023-04-30 05:07	This is a known issue stemming from an odd BIOS / UEFI setup on OCI. Remediation is in progress (CC @neil)

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3070	[Rocky-Linux-8] emacs	minor	have not tried	2023-04-28 05:49	2023-04-28 06:53

Reporter:	Jason Vas Dias	Platform:
Assigned To:	Louis Abel	OS:
Priority:	high	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	inappropriate byte compiler warnings with use of '-l' option appearing only with new update to emacs-26.1-7.el8_7.1.x86_64
Description:	For years now I have used this alias to turn off font-lock when I am running emacs in a character mode terminal: alias Ed='emacs -nw -l ~/emacs-text-mode.el' Note, emacs's -l option , from manual: -l file, --load=file Load the lisp code in the file file. Note, it says 'Load', not 'Compile' - yet now, whenever I load emacs-text-mode.el in this way (not using Emacs's 'M-x load-file' command), the emacs screen splits and I get a message in a new 'Compile-Log' buffer window with the message: Warning (bytecomp): Unused lexical variable `start' My emacs_text_mode.el file does not contain the text 'start' . Without my emacs_test_mode.el file, Emacs renders text illegibly in dark colors on my black terminal if the file has any recognized "syntax". So now with latest update I can read or edit text in character terminal mode emacs without closing this extra new unwanted 'Compile-Log' buffer . On Emacs 27.1 (Fedora), and on Emacs 28.2 (latest build on Fedora), and on your previous Emacs release prior to the update I applied a few days ago , this does not happen, with the same emacs-text-mode.el . Now I have to build Emacs-28.2 and roll it out to our cluster of 10 Rocky hosts because of this. Please restore behavior of previous emacs-1:26.1-7.el8 release as regards using the '-l' option - files loaded during initialization should not be byte compiled, they should be interpreted, like '.emacs' .
Tags:
Steps To Reproduce:	See above - load a file that does not define 'start' with the '-l' option.
Additional Information:
Attached Files:	emacs-text-mode.el.txt (1,323 bytes) 2023-04-28 06:07 https://bugs.rockylinux.org/file_download.php?file_id=859&type=bug

Notes
(0003103) Jason Vas Dias 2023-04-28 06:05	the emacs-text-mode.el file in question

(0003104) Jason Vas Dias 2023-04-28 06:07	your bug reporter is not up to the job - it does not let me attach a '.el' file !

(0003105) Louis Abel 2023-04-28 06:53	Thank you for the report. Recently emacs was updated from upstream (Red Hat) that fixes a latex injection vulnerability. You can see the patch here: https://git.rockylinux.org/staging/rpms/emacs/-/commit/41d37acd47e7e6ac3110ec90dc6cb6d32ba7c181 https://bugzilla.redhat.com/show_bug.cgi?id=2180544 https://access.redhat.com/errata/RHSA-2023:1930 I admit I am not an emacs user, however the behavior you are describing is likely an unintended consequence of the vulnerability patch. I don't have a way of reproducing this myself without more information, so if you can describe your environment and how you run your terminal, we can try to reproduce this and figure out next steps for this report. Note that due to the nature of it being a security update, reverting this will likely not happen. If we find that this is reproducible, you may report this issue to bugzilla.redhat.com or we can report it for you. Setting to NEEDINFO

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3004	[Rocky Linux SIG] General	block	always	2023-04-22 18:27	2023-04-22 19:33

Reporter:	Gibbs Tan	Platform:
Assigned To:		OS:
Priority:	high	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Image fail to boot on Raspberry Pi 3 (Rocky Linux 9.1)
Description:	Image written to SD card unable to boot successfully to login prompt on Raspberry Pi 3 Model B v1.2. Cause is due to brcmfmac module crashes. Consequently, several services (for example, Security Auditing Service) fail to start. Link: https://dl.rockylinux.org/pub/sig/9/altarch/aarch64/images/RockyLinuxRpi_9.1.img.xz Image Datetime: 28-Nov-2022 15:26
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2972	[Alternative Architectures] General	minor	always	2023-04-21 20:34	2023-04-21 20:34

Reporter:	Dan Heath	Platform:	Raspberry Pi CM4
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	8
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky 8 uart serial console configuration missing/incomplete
Description:	When attempting to use the implemented console configuration provided, the console port selected is incorrect. Also uart is not enabled although a console is setup.
Tags:
Steps To Reproduce:	- attach uart cable (I'm using the ADAFRUIT Industries 954 USB-to-TTL Serial Cable) - start uart session on client (screen /dev/ttyUSB0 115200 on connecting host) - boot Raspberry Pi using Rocky Linux RockyRpi_8.7.img installed on usb storage Result is no console output is produced on the console session.
Additional Information:	The following changes followed by a reboot resolve this issue for me: Update /boot/cmdline.txt: Original: console=ttyAMA0,115200 console=tty1 root=PARTUUID=13381799-03 rootfstype=ext4 elevator=deadline rootwait Updated: console=serial0,115200 console=tty1 root=PARTUUID=13381799-03 rootfstype=ext4 elevator=deadline rootwait Create /boot/config.txt and adding the following: [cm4] enable_uart=1
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2971	[Alternative Architectures] General	minor	always	2023-04-21 20:33	2023-04-21 20:33

Reporter:	Dan Heath	Platform:	Raspberry Pi CM4
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	8
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky 8 uart serial console configuration missing/incomplete
Description:	When attempting to use the implemented console configuration provided, the console port selected is incorrect. Also uart is not enabled although a console is setup.
Tags:
Steps To Reproduce:	- attach uart cable (I'm using the ADAFRUIT Industries 954 USB-to-TTL Serial Cable) - start uart session on client (screen /dev/ttyUSB0 115200 on connecting host) - boot Raspberry Pi using Rocky Linux RockyRpi_8.7.img installed on usb storage Result is no console output is produced on the console session.
Additional Information:	The following changes followed by a reboot resolve this issue for me: Update /boot/cmdline.txt: Original: console=ttyAMA0,115200 console=tty1 root=PARTUUID=13381799-03 rootfstype=ext4 elevator=deadline rootwait Updated: console=serial0,115200 console=tty1 root=PARTUUID=13381799-03 rootfstype=ext4 elevator=deadline rootwait Create /boot/config.txt and adding the following: [cm4] enable_uart=1
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2905	[Rocky-Linux-9] crash	block	always	2023-04-17 11:22	2023-04-18 05:16

Reporter:	shadon fan	Platform:	vmware esxi cluste
Assigned To:		OS:	Rocky Linux
Priority:	high	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky Linux 9 Failed to install or start in the Esxi Cluster
Description:	RockyLinux 9.1 fails to install or start the system in an Esxi Cluster. RockyLinux 8.7 in the same cluster does not fail.
Tags:
Steps To Reproduce:	1. new install - fail 2.1 Install RockyLinux9.1 on a non-clustered Esxi host and ensure can log in to the system. 2.2 Shutdown RockyLinux9.1, migrate to the cluster, and then cannot boot normally
Additional Information:
Attached Files:	RockyLinux9.png (321,775 bytes) 2023-04-17 11:22 https://bugs.rockylinux.org/file_download.php?file_id=760&type=bug

Notes
(0002938) Lukas Magauer 2023-04-17 12:04	Hi shadon fan, which EVC mode is your machine/cluster using? This sounds very much like this problem here: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level

(0002971) shadon fan 2023-04-18 02:59	Hi Lukas Magauer, The EVC mode is Intel® "Merom" Generation The Esxi cluster include the following cpus: Intel(R) Xeon(R) X5650, E5-2697 v2, E5-2670, and E5-2640 v4

(0002972) Lukas Magauer 2023-04-18 05:16	Okay yes this is definitely the problem, you need at least EVC mode "Nehalem" to make Rocky Linux 9 work. (SSE 4.2 is required) https://kb.vmware.com/s/article/1005764 Could you verify please, thank you!

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2476	[Rocky Services] Mail list	minor	always	2023-03-03 05:20	2023-04-16 01:35

Reporter:	Brian Clemens	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Hyperkitty missing libraries
Description:	On loading any thread, only the first message is visible. The replies fail to load. Looks like missing libraries based on the console messages: GEThttps://lists.resf.org/static/hyperkitty/libs/jquery/smoothness/jquery-ui-1.13.1.min.css [HTTP/2 404 Not Found 175ms] GEThttps://lists.resf.org/static/hyperkitty/libs/jquery/jquery-ui-1.13.1.min.js [HTTP/2 404 Not Found 189ms] Loading failed for the <script> with source “https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-ui-1.13.1.min.js”. GQJ4YMZQ5YCU5OFOUX4ITKTS75P6W5HU:702:1 jQuery.Deferred exception: $(...).autocomplete is not a function setup_tags@https://lists.resf.org/static/CACHE/js/output.da7ecd7e6bf6.js:84:184 @https://lists.resf.org/archives/list/rocky@lists.resf.org/thread/GQJ4YMZQ5YCU5OFOUX4ITKTS75P6W5HU/:713:9 e@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:30038 Deferred/then/l/</t<@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:30340 setTimeout handlerDeferred/then/l/<@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:30549 c@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:28327 fireWith@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:29072 fire@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:29108 c@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:28327 fireWith@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:29072 ready@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:32045 B@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:31824 EventListener.handleEvent@https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:32193 @https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:220 @https://lists.resf.org/static/hyperkitty/libs/jquery/jquery-3.6.0.min.js:2:225 undefined jquery-3.6.0.min.js:2:31593 Uncaught TypeError: $(...).autocomplete is not a function setup_tags https://lists.resf.org/static/CACHE/js/output.da7ecd7e6bf6.js:84 <anonymous> https://lists.resf.org/archives/list/rocky@lists.resf.org/thread/GQJ4YMZQ5YCU5OFOUX4ITKTS75P6W5HU/:713 jQuery 13 output.da7ecd7e6bf6.js:84:184
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2806	[Rocky-Linux-9] General	minor	always	2023-03-30 13:45	2023-04-02 22:56

Reporter:	Tito Sacchi	Platform:	x86_64
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	A patch for the source package `grub2` causes a segfault in `grub2-mkstandalone` when called with a specific CLI option.
Description:	Running `grub2-mkstandalone -o ./grubx64.efi --disable-shim-lock -O x86_64-efi` on an up-to-date Rocky Linux 9.1 system causes a segfault in `grub2-mkstandalone`. I've build the grub2 package from the .src.rpm file and I've tracked this down with GDB to the following bug: the patch 0191-grub-install-support-embedding-x509-certificates.patch is missing a `break;` statement after line 504 of util/grub-install-common.c (disable_shim_lock = 1;). Execution falls through when the `--disable-shim-lock` option is passed on the cmdline and xstrdup is called when arg = NULL, because `--disable-shim-lock` does not take an argument.
Tags:
Steps To Reproduce:	Execute `grub2-mkstandalone -o ./grubx64.efi --disable-shim-lock -O x86_64-efi`.
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2773	[Alternative Architectures] General	minor	always	2023-03-29 21:00	2023-04-02 22:55

Reporter:	Dan Heath	Platform:	Raspberry Pi CM4
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	8
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky 8 doesn't enable USB keyboard by default when using nvme storage
Description:	When using nvme storage only the keyboard/mouse are not enabled for use. However when using a USB storage the keyboard/mouse are available.
Tags:
Steps To Reproduce:	- boot Raspberry Pi using Rocky Linux RockyRpi_8.7.img installed on usb storage - dd the Rocky Linux image RockyRpi_8.7.img onto an nvme - reboot Raspberry Pi booting only from nvme Result is keyboard/mouse fail to respond.
Additional Information:	Creating /boot/config.txt and adding the following appears to solve the issue in my testing: [cm4] otg_mode=1
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1453	[Cloud] General	minor	always	2022-12-14 08:46	2023-03-23 18:27

Reporter:	Myunghoon Suk	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	I want to install kernel-debuginfo-4.18.0-425.3.1.el8.cloud.x86_64, but I got an error
Description:	I have Rocky Linux 8.7 with kernel-debuginfo-4.18.0-425.3.1.el8.cloud.x86_64. For crash utility, I tried to install kernel-debuginfo. But I got kernel-debuginfo-4.18.0-425.3.1.el8, not cloud version. So I download kernel-debuginfo-4.18.0-425.3.1.el8.cloud.x86_64.rpm, and then do this: # dnf install kernel-debuginfo-4.18.0-425.3.1.el8.cloud.x86_64.rpm #dnf install kernel-debuginfo-4.18.0-425.3.1.el8.cloud.x86_64.rpm Last metadata expiration check: 1:52:56 ago on Tue 13 Dec 2022 09:30:09 PM UTC. Error: Problem: conflicting requests - nothing provides kernel-debuginfo-common-x86_64 = 4.18.0-425.3.1.el8.cloud needed by kernel-debuginfo-4.18.0-425.3.1.el8.cloud.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) I couldn't find matched could version, kernel-debuginfo-common-4.18.0-425.3.1.el8.cloud.x86_64 from cloud-kernel repo. How to install kernel-debuginfo-4.18.0-425.3.1.el8.cloud.x86_64 properly. I would expect I have this after correct version installation: /usr/lib/debug/lib/modules/4.18.0-425.3.1.el8.cloud.x86_64/vmlinux and then I would run crash utility like that: # crash /usr/lib/debug/lib/modules/4.18.0-425.3.1.el8.cloud.x86_64/vmlinux /var/crash/127.0.0.1-2022-12-13-01\:21\:41/vmcore But if I install non-cloud version, kernel-debuginfo-4.18.0-425.3.1.el8.x86_64, I will get an error: (due to version is not matched between vmlinux and vmcore) # crash /usr/lib/debug/lib/modules/4.18.0-425.3.1.el8.x86_64/vmlinux /var/crash/127.0.0.1-2022-12-13-01\:21\:41/vmcore crash 7.3.2-2.el8 Copyright (C) 2002-2022 Red Hat, Inc. Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005, 2011, 2020-2022 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... WARNING: kernel relocated [292MB]: patching 106351 gdb minimal_symbol values WARNING: kernel version inconsistency between vmlinux and dumpfile crash: seek error: kernel virtual address: ffff8e90cf215c40 type: "current_task (per_cpu)" crash: seek error: kernel virtual address: ffff8e90cf255c40 type: "current_task (per_cpu)" crash: seek error: kernel virtual address: ffff8e90cf295c40 type: "current_task (per_cpu) ...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0001784) Mustafa Gezen 2022-12-14 20:27	Hi, We caught a bug with how we handle debug artifacts for that project. We have a fix in the works (it should be pretty simple), I'll let you know when the new artifacts are live. Sorry for the inconvenience!

(0001785) Myunghoon Suk 2022-12-14 20:37	Thank you, Mustafa. Great. I am glad to hear that you have a fix. When can I expect the new artifacts are live? a few days or a couple of weeks? Thank you so much for your help!

(0001786) Mustafa Gezen 2022-12-14 20:38	Hi, I would expect a couple of days, let's say early next week just to be on the safe side, but I don't expect it to take too long. Thanks

(0001787) Myunghoon Suk 2022-12-14 20:41	Awesome! Looking forward to new artifacts live. Thank you!

(0002806) Myunghoon Suk 2023-03-23 18:27	Hello Mustafa, Do you have any timeline for new artifacts? Thank you.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2707	[Cloud] General	major	always	2023-03-22 17:42	2023-03-22 17:42

Reporter:	Escape Technology Development	Platform:	AWS
Assigned To:		OS:	Rocky
Priority:	normal	OS Version:	8.7
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky-8-EC2-8.7-* AMI missing in N. Virginia at AWS (other regions are fine)
Description:	In AWS Rocky 8.7 can be found via owner 792107900819 and name Rocky-8-EC2-8.7-, except for the N. Virginia region. There is a Rocky-8-EC2-Base-8.7- present, but not the expected Rocky-8-EC2-8.7-. Is there a particular reason why Rocky 8.7 (Rocky-8-EC2-8.7-) didn't get shipped out to N. Virginia, or is there a glitch in the distribution across AWS regions?
Tags:	AWS, N. Virginia, Rocky 8.7
Steps To Reproduce:	Log into AWS Switch to eu-west-1 (Ireland) List all AMIs in any Search for... Owner: 792107900819 Name: Rocky-8-EC2-8.7-* You'll see (currently) 2 results: Rocky-8-EC2-8.7-20221112.0.x86_64 Rocky-8-EC2-8.7-20221112.0.aarch64 Switching to any other region will give you results, except in N. Virginia...
Additional Information:
Attached Files:	AWS_NVirginia.png (47,507 bytes) 2023-03-22 17:42 https://bugs.rockylinux.org/file_download.php?file_id=694&type=bug AWS_Oregon.png (62,989 bytes) 2023-03-22 17:42 https://bugs.rockylinux.org/file_download.php?file_id=695&type=bug AWS_Ireland.png (58,165 bytes) 2023-03-22 17:42 https://bugs.rockylinux.org/file_download.php?file_id=696&type=bug

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2674	[Rocky Services] Mirror Manager	minor	always	2023-03-21 07:59	2023-03-21 07:59

Reporter:	Karsten Weiss	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Redundant rpms in Devel repo?
Description:	I've noticed that there are bit-identical i.e. redundant rpms of BaseOS/AppStrean rpms also stored in the Devel repo. Is there a reason for that? I've already tried several mirrors.
Tags:
Steps To Reproduce:	Examples: $ curl -o 1 https://mirror1.hs-esslingen.de/pub/Mirrors/rocky/8.7/BaseOS/x86_64/os/Packages/k/kernel-4.18.0-425.13.1.el8_7.x86_64.rpm $ curl -o 2 https://mirror1.hs-esslingen.de/pub/Mirrors/rocky/8.7/Devel/x86_64/os/Packages/k/kernel-4.18.0-425.13.1.el8_7.x86_64.rpm $ sha256sum 1 2 d4295895806bdc8fe95e5c95e7d9bab99bb044b9583b12d6373f50cfc7eb179c 1 d4295895806bdc8fe95e5c95e7d9bab99bb044b9583b12d6373f50cfc7eb179c 2 $ curl -o 3 https://mirror1.hs-esslingen.de/pub/Mirrors/rocky/8.7/AppStream/x86_64/os/Packages/l/libreoffice-core-6.4.7.2-12.el8_7.x86_64.rpm $ curl -o 4 https://mirror1.hs-esslingen.de/pub/Mirrors/rocky/8.7/Devel/x86_64/os/Packages/l/libreoffice-core-6.4.7.2-12.el8_7.x86_64.rpm $ sha256sum 3 4 3cbd9785ee4477918182a0d4b8771efcc1d520d53dc900c0318a29804204a9c8 3 3cbd9785ee4477918182a0d4b8771efcc1d520d53dc900c0318a29804204a9c8 4
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2642	[Rocky-Linux-9] systemd	block	always	2023-03-20 06:21	2023-03-20 06:21

Reporter:	Yanfei Xu	Platform:	aarch64
Assigned To:		OS:	RockyLinux
Priority:	urgent	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	initrd can't boot and failed at switch-root of systemd
Description:	When using initrd to boot RockyLinux, it always failed at switch-root service of systemd, then hung and can't boot into the real rootfs.
Tags:
Steps To Reproduce:	1. Set up a iscsi target to store the rootfs for iscsiboot. 2. Use dracut to create an initrd from rootfs directory. /usr/bin/dracut -v -m "base network iscsi nfs systemd-initrd systemd-networkd systemd-udevd systemd-modules-load systemd-journald systemd-integritysetup" --hostonly-mode "strict" --hostonly-nics "virtio-net" --no-early-microcode --install "/usr/bin/ping" --add-drivers "nfs nfsv4" --force-drivers "mfd-core configfs" --filesystem "ext4 xfs" ./initrd.img 5.10.45_xxx 3. Boot system with initrd. and Kernel command line is "systemd.log_level=debug systemd.log_target=console ip=192.168.0.2::192.168.0.1:255.255.255.0::eth0:off root=iscsi:192.168.0.1::::iqn.e2000:acx in itrdmem=0x440c000000,0x8000000 acpi=force rd.neednet=1" 4. boot failed and showed log: ------------------------- [ OK ] Reached target Switch Root. initrd-switch-root.service: AssertPathExists=/etc/initrd-release succeeded. Failed to read pids.max attribute of root cgroup, ignoring: No data available initrd-switch-root.service: Passing 0 fds to service initrd-switch-root.service: About to execute systemctl --no-block switch-root /sysroot initrd-switch-root.service: Forked systemctl as 305 initrd-switch-root.service: Changed dead -> start Starting Switch Root... systemd-journald.service: Got notification message from PID 261 (FDSTORE=1) initrd-switch-root.service: Executing: systemctl --no-block switch-root /sysroot systemd-journald.service: Added fd 12 (n/a) to fd store. Bus private-bus-connection: changing state UNSET → OPENING sd-bus: starting bus private-bus-connection on fds 27/27 (socket:[11846], socket:[11846])... Bus private-bus-connection: changing state OPENING → AUTHENTICATING Registering bus object implementation for path=/org/freedesktop/systemd1 iface=org.freedesktop.systemd1.Manager Registering bus object implementation for path=/org/freedesktop/systemd1/job iface=org.freedesktop.systemd1.Job Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Unit Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Automount Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Device Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Mount Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Path Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Scope Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Service Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Slice Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Socket Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Swap Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Target Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Timer Registering bus object implementation for path=/org/freedesktop/LogControl1 iface=org.freedesktop.LogControl1 Accepted new private connection. Bus private-bus-connection: changing state AUTHENTICATING → RUNNING Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=SwitchRoot cookie=1 repl y_cookie=0 signature=ss error-name=n/a error-message=n/a Sent message type=error sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=s error-name=org.freedesktop.DBus.Error.In validArgs error-message=Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing. Failed to process message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=SwitchRoot cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/a: Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing. Received SIGCHLD from PID 305 (systemctl). Child 305 (systemctl) died (code=exited, status=1/FAILURE) initrd-switch-root.service: Child 305 belongs to initrd-switch-root.service. initrd-switch-root.service: Main process exited, code=exited, status=1/FAILURE initrd-switch-root.service: Failed with result 'exit-code'. initrd-switch-root.service: Service will not restart (restart setting) initrd-switch-root.service: Changed start -> failed Bus private-bus-connection: changing state RUNNING → CLOSING Failed to send manager change signal: Connection reset by peer initrd-switch-root.service: Job 54 initrd-switch-root.service/start finished, result=failed [FAILED] Failed to start Switch Root. See 'systemctl status initrd-switch-root.service' for details. Startup finished in 3.536s (kernel) + 0 (initrd) + 17.843s (userspace) = 21.380s. initrd-switch-root.service: Unit entered failed state. initrd-switch-root.service: Triggering OnFailure= dependencies. emergency.target: Trying to enqueue job emergency.target/start/replace-irreversibly emergency.target: Installed new job emergency.target/start as 96 emergency.service: Installed new job emergency.service/start as 97 systemd-vconsole-setup.service: Installed new job systemd-vconsole-setup.service/start as 110 emergency.target: Enqueued job emergency.target/start as 96 initrd-switch-root.service: Triggering OnFailure= dependencies done. initrd-switch-root.service: Consumed 3ms CPU time. initrd-switch-root.service: Control group is empty. systemd-journald.service: Received EPOLLHUP on stored fd 12 (stored), closing. Bus private-bus-connection: changing state CLOSING → CLOSED Got disconnect on private connection. emergency.target: starting held back, waiting for: emergency.service Failed to read pids.max attribute of root cgroup, ignoring: No data available emergency.service: About to execute /usr/bin/plymouth --wait quit emergency.service: Forked /usr/bin/plymouth as 306 emergency.service: Changed dead -> start-pre emergency.service: Job 97 emergency.service/start finished, result=done emergency.target changed dead -> active emergency.target: Job 96 emergency.target/start finished, result=done systemd-vconsole-setup.service: ConditionPathExists=/dev/tty0 succeeded. Failed to read pids.max attribute of root cgroup, ignoring: No data available systemd-vconsole-setup.service: Passing 0 fds to service systemd-vconsole-setup.service: About to execute /usr/lib/systemd/systemd-vconsole-setup systemd-vconsole-setup.service: Forked /usr/lib/systemd/systemd-vcoReceived SIGCHLD from PID 308 ((in-shell)). Child 308 ((in-shell)) died (code=exited, status=0/SUCCESS) emergency.service: Child 308 belongs to emergency.service. emergency.service: Main process exited, code=exited, status=0/SUCCESS (success) emergency.service: Deactivated successfully. emergency.service: Service will not restart (restart setting) emergency.service: Changed running -> dead emergency.service: Consumed 873us CPU time. systemd-journald.service: Got notification message from PID 261 (WATCHDOG=1) systemd-journald.service: Got notification message from PID 261 (WATCHDOG=1) systemd-journald.service: Got notification message from PID 261 (WATCHDOG=1) systemd-journald.service: Got notification message from PID 261 (WATCHDOG=1)
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2641	[Rocky-Linux-9] systemd	block	always	2023-03-20 06:18	2023-03-20 06:18

Reporter:	Yanfei Xu	Platform:	aarch64
Assigned To:		OS:	RockyLinux
Priority:	urgent	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	initrd can't boot and failed at switch-root of systemd
Description:	When using initrd to boot RockyLinux, it always failed at switch-root service of systemd, then hung and can't boot into the real rootfs.
Tags:
Steps To Reproduce:	1. Set up a iscsi target to store the rootfs for iscsiboot. 2. Use dracut to create an initrd from rootfs directory. /usr/bin/dracut -v -m "base network iscsi nfs systemd-initrd systemd-networkd systemd-udevd systemd-modules-load systemd-journald systemd-integritysetup" --hostonly-mode "strict" --hostonly-nics "virtio-net" --no-early-microcode --install "/usr/bin/ping" --add-drivers "nfs nfsv4" --force-drivers "mfd-core configfs" --filesystem "ext4 xfs" ./initrd.img 5.10.45_xxx 3. Boot system with initrd. and Kernel command line is "systemd.log_level=debug systemd.log_target=console ip=192.168.0.2::192.168.0.1:255.255.255.0::eth0:off root=iscsi:192.168.0.1::::iqn.e2000:acx in itrdmem=0x440c000000,0x8000000 acpi=force rd.neednet=1" 4. boot failed and showed log: ------------------------- [ OK ] Reached target Switch Root. initrd-switch-root.service: AssertPathExists=/etc/initrd-release succeeded. Failed to read pids.max attribute of root cgroup, ignoring: No data available initrd-switch-root.service: Passing 0 fds to service initrd-switch-root.service: About to execute systemctl --no-block switch-root /sysroot initrd-switch-root.service: Forked systemctl as 305 initrd-switch-root.service: Changed dead -> start Starting Switch Root... systemd-journald.service: Got notification message from PID 261 (FDSTORE=1) initrd-switch-root.service: Executing: systemctl --no-block switch-root /sysroot systemd-journald.service: Added fd 12 (n/a) to fd store. Bus private-bus-connection: changing state UNSET → OPENING sd-bus: starting bus private-bus-connection on fds 27/27 (socket:[11846], socket:[11846])... Bus private-bus-connection: changing state OPENING → AUTHENTICATING Registering bus object implementation for path=/org/freedesktop/systemd1 iface=org.freedesktop.systemd1.Manager Registering bus object implementation for path=/org/freedesktop/systemd1/job iface=org.freedesktop.systemd1.Job Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Unit Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Automount Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Device Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Mount Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Path Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Scope Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Service Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Slice Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Socket Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Swap Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Target Registering bus object implementation for path=/org/freedesktop/systemd1/unit iface=org.freedesktop.systemd1.Timer Registering bus object implementation for path=/org/freedesktop/LogControl1 iface=org.freedesktop.LogControl1 Accepted new private connection. Bus private-bus-connection: changing state AUTHENTICATING → RUNNING Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=SwitchRoot cookie=1 repl y_cookie=0 signature=ss error-name=n/a error-message=n/a Sent message type=error sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=s error-name=org.freedesktop.DBus.Error.In validArgs error-message=Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing. Failed to process message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=SwitchRoot cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/a: Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing. Received SIGCHLD from PID 305 (systemctl). Child 305 (systemctl) died (code=exited, status=1/FAILURE) initrd-switch-root.service: Child 305 belongs to initrd-switch-root.service. initrd-switch-root.service: Main process exited, code=exited, status=1/FAILURE initrd-switch-root.service: Failed with result 'exit-code'. initrd-switch-root.service: Service will not restart (restart setting) initrd-switch-root.service: Changed start -> failed Bus private-bus-connection: changing state RUNNING → CLOSING Failed to send manager change signal: Connection reset by peer initrd-switch-root.service: Job 54 initrd-switch-root.service/start finished, result=failed [FAILED] Failed to start Switch Root. See 'systemctl status initrd-switch-root.service' for details. Startup finished in 3.536s (kernel) + 0 (initrd) + 17.843s (userspace) = 21.380s. initrd-switch-root.service: Unit entered failed state. initrd-switch-root.service: Triggering OnFailure= dependencies. emergency.target: Trying to enqueue job emergency.target/start/replace-irreversibly emergency.target: Installed new job emergency.target/start as 96 emergency.service: Installed new job emergency.service/start as 97 systemd-vconsole-setup.service: Installed new job systemd-vconsole-setup.service/start as 110 emergency.target: Enqueued job emergency.target/start as 96 initrd-switch-root.service: Triggering OnFailure= dependencies done. initrd-switch-root.service: Consumed 3ms CPU time. initrd-switch-root.service: Control group is empty. systemd-journald.service: Received EPOLLHUP on stored fd 12 (stored), closing. Bus private-bus-connection: changing state CLOSING → CLOSED Got disconnect on private connection. emergency.target: starting held back, waiting for: emergency.service Failed to read pids.max attribute of root cgroup, ignoring: No data available emergency.service: About to execute /usr/bin/plymouth --wait quit emergency.service: Forked /usr/bin/plymouth as 306 emergency.service: Changed dead -> start-pre emergency.service: Job 97 emergency.service/start finished, result=done emergency.target changed dead -> active emergency.target: Job 96 emergency.target/start finished, result=done systemd-vconsole-setup.service: ConditionPathExists=/dev/tty0 succeeded. Failed to read pids.max attribute of root cgroup, ignoring: No data available systemd-vconsole-setup.service: Passing 0 fds to service systemd-vconsole-setup.service: About to execute /usr/lib/systemd/systemd-vconsole-setup systemd-vconsole-setup.service: Forked /usr/lib/systemd/systemd-vcoReceived SIGCHLD from PID 308 ((in-shell)). Child 308 ((in-shell)) died (code=exited, status=0/SUCCESS) emergency.service: Child 308 belongs to emergency.service. emergency.service: Main process exited, code=exited, status=0/SUCCESS (success) emergency.service: Deactivated successfully. emergency.service: Service will not restart (restart setting) emergency.service: Changed running -> dead emergency.service: Consumed 873us CPU time. systemd-journald.service: Got notification message from PID 261 (WATCHDOG=1) systemd-journald.service: Got notification message from PID 261 (WATCHDOG=1) systemd-journald.service: Got notification message from PID 261 (WATCHDOG=1) systemd-journald.service: Got notification message from PID 261 (WATCHDOG=1)
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2608	[Rocky-Linux-8] General	major	always	2023-03-14 13:10	2023-03-14 18:19

Reporter:	Christian Hailer	Platform:
Assigned To:	Mustafa Gezen	OS:
Priority:	normal	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Security erratum not included in updateinfo.xml
Description:	Hello, the security erratum RLSA-2023:0835 is NOT included in the updateinfo.xml of the BaseOS repository, so tools like Katello for example won't import the erratum and therefore won't apply it automatically to registered systems. A few weeks ago I stumbled upon another erratum which wasn't included but I can't remember which one it was. Security scanners like Tenable complain about the unpatched packages, referencing the RLSA, and one has to update it manually. Regards, Christian
Tags:
Steps To Reproduce:	[root@web ~]# rpm -q python3-setuptools python3-setuptools-39.2.0-6.el8.noarch [root@web ~]# dnf update --security python3-setuptools Last metadata expiration check: 2:37:21 ago on Tue 14 Mar 2023 11:27:27 AM CET. No security updates needed for "python3-setuptools", but 1 update available Dependencies resolved. Nothing to do. Complete!
Additional Information:	Erratum URL: https://errata.rockylinux.org/RLSA-2023:0835 updateinfo as of March 14th 2023: https://download.rockylinux.org/pub/rocky/8/BaseOS/x86_64/os/repodata/6c54586935d021b3f5ab63045a9334023fc70886832a143350ab2801601a1e7d-updateinfo.xml.gz <data type="updateinfo"> <checksum type="sha256">6c54586935d021b3f5ab63045a9334023fc70886832a143350ab2801601a1e7d</checksum> <open-checksum type="sha256">a5daa908ad58412844d927d9c870c59c1202b8e18e2a7e770d192bc1606a0bce</open-checksum> <location href="repodata/6c54586935d021b3f5ab63045a9334023fc70886832a143350ab2801601a1e7d-updateinfo.xml.gz"/> <timestamp>1678233820</timestamp> <size>134364</size> <open-size>1177117</open-size> </data> XML file attached below
Attached Files:	6c54586935d021b3f5ab63045a9334023fc70886832a143350ab2801601a1e7d-updateinfo.xml.gz (134,364 bytes) 2023-03-14 13:10 https://bugs.rockylinux.org/file_download.php?file_id=661&type=bug

Notes
(0002773) Mustafa Gezen 2023-03-14 16:38	Hi Christian, Thank you for reporting this issue. We have deployed a fix to the errata system and the fixed version of updateinfo will be published shortly. https://github.com/resf/distro-tools/commit/6915813e2ddf3e1e8a4ebb0ef6d53fa89311ce92 Mustafa

(0002774) Christian Hailer 2023-03-14 17:39	Great, thanks a lot! I assume that all of the old missing errata will be included in the new version of updateinfo.xml as well and not only the new ones from now on, right? Best regards, Christian

(0002775) Mustafa Gezen 2023-03-14 18:19	Yes that is correct. Updateinfo has been regenerated to include older advisories that were missed.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2575	[Rocky-Linux-9] Packages	minor	always	2023-03-07 10:58	2023-03-07 11:18

Reporter:	alex welsh	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	modulemd versions are string, not int
Description:	The version field in a modulemd file should be an integer, it is currently a string. (see https://github.com/fedora-modularity/libmodulemd/blob/main/yaml_specs/modulemd_stream_v2.yaml#L65) This can cause issues with authentication: https://github.com/pulp/pulp_rpm/issues/2998
Tags:
Steps To Reproduce:	The problem can be seen with: curl -fsSL rockylinux.anexia.at/9.1/devel/x86_64/os/repodata/8d64e94b-4408-4f2a-a77b-3aae4d93ed8f-MODULES.yaml.gz \| gzip -d \| grep version or curl -fsSL rockylinux.anexia.at/9.1/devel/x86_64/os/repodata/8d64e94b-4408-4f2a-a77b-3aae4d93ed8f-MODULES.yaml.gz \| gzip -d \| grep version Older versions do not have this problem e.g. curl -fsSL rockylinux.anexia.at/8.7/AppStream/x86_64/os/repodata/01fa634a16e45ab9aa2894048a90689edf293648226e7c0783dc926b16e796b9-modules.yaml.gz \| gzip -d \| grep version:\| head The new version information is surrounded by quotes, making it a string.
Additional Information:
Attached Files:

Notes
(0002707) alex welsh 2023-03-07 11:18	Typo in Steps To Reproduce. The second command should be curl -fsSL rockylinux.anexia.at/9.1/AppStream/x86_64/os/repodata/02fa9664-23dd-4215-bf82-c9c3bfb2c54d-MODULES.yaml.gz \| gzip -d \| grep version

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2542	[Rocky-Linux-9] Packages	minor	always	2023-03-07 04:20	2023-03-07 04:20

Reporter:	Darrick Servis	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	/usr/bin/start-pulseaudio-x11 in package pulseaudio-module-x11 broken
Description:	Apologies if this is a bit messy. It's my first time reporting a bug here. viewing the users .xsesson-errors I came across: start-pulseaudio-x11: line 21: --start: command not found Looking at /usr/bin/start-pulseaudio-x11 shows: # probe to test if autospawn works, else resort to starting manually /usr/bin/pactl info > /dev/null 2>&1 \|\| --start "$@"
Tags:
Steps To Reproduce:	dnf -y install pulseaudio pulseaudio-libs && dnf -y group install xfce login to xfce open a terminal and run pactl info ctrl-c grep "--start" ~/.xsesson-errors
Additional Information:	This patch breaks it: https://git.rockylinux.org/staging/rpms/pulseaudio/-/blob/r8/SOURCES/pulseaudio-autostart.patch +# probe to test if autospawn works, else resort to starting manually +@PACTL_BINARY@ info > /dev/null 2>&1 \|\| @PA_BINARY@ --start "$@" + As PA_BINARY is not set when the package is compiled. rpmbuild/BUILD/pulseaudio-15.0/src/daemon/meson.build should also be patched to pass the PA_BINARY variable. below patch works for me on my end. --- meson.build.bak 2023-03-07 03:59:04.111363005 +0000 +++ meson.build 2023-03-07 03:59:40.837203535 +0000 @@ -38,6 +38,7 @@ if x11_dep.found() conf = configuration_data() conf.set('PACTL_BINARY', join_paths(bindir, 'pactl')) + conf.set('PA_BINARY', cdata.get_unquoted('PA_BINARY')) configure_file( input : 'start-pulseaudio-x11.in',
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2509	[Rocky-Linux-9] php	major	always	2023-03-03 15:13	2023-03-03 17:17

Reporter:	John Horne	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Unable to install PHP 8.1 from stream - no match for package/unable to resolve argument errors
Description:	I have tried to install PHP 8.1 onto Rocky 9.1 as a module onto two servers. Both servers failed to install PHP, giving the errors shown below.
Tags:
Steps To Reproduce:	From console, as root, run: dnf update dnf module reset php dnf module enable php:8.1 dnf module install php:8.1 The errors shown are: dnf module install php:8.1 Last metadata expiration check: 0:01:05 ago on Fri 03 Mar 2023 15:08:55 GMT. Unable to resolve argument php:8.1 No match for package php-cli Unable to resolve argument php:8.1 No match for package php-common Unable to resolve argument php:8.1 No match for package php-fpm Unable to resolve argument php:8.1 No match for package php-mbstring Unable to resolve argument php:8.1 No match for package php-xml Error: Problems in request: broken groups or modules: php:8.1, php:8.1, php:8.1, php:8.1, php:8.1
Additional Information:	Tried 'dnf module install php' and 'dnf module install php:8.1/common' both give the same errors.
Attached Files:

Notes
(0002677) Louis Abel 2023-03-03 17:17	Setting as resolved. Please wait for mirrors to sync. [root@awx ~]# dnf update php Extra Packages for Enterprise Linux 9 - x86_64 6.8 MB/s \| 14 MB 00:02 Rocky Linux 9 - BaseOS 2.5 MB/s \| 1.8 MB 00:00 Rocky Linux 9 - AppStream 1.8 MB/s \| 6.6 MB 00:03 Rocky Linux 9 - CRB 2.2 MB/s \| 2.1 MB 00:00 Rocky Linux 9 - Extras 25 kB/s \| 8.5 kB 00:00 Dependencies resolved. ================================================================================================================================================================ Package Architecture Version Repository Size ================================================================================================================================================================ Upgrading: php x86_64 8.1.8-1.module+el9.1.0+13171+4883e0c8 appstream 12 k php-cli x86_64 8.1.8-1.module+el9.1.0+13171+4883e0c8 appstream 3.5 M php-common x86_64 8.1.8-1.module+el9.1.0+13171+4883e0c8 appstream 667 k php-fpm x86_64 8.1.8-1.module+el9.1.0+13171+4883e0c8 appstream 1.8 M php-mbstring x86_64 8.1.8-1.module+el9.1.0+13171+4883e0c8 appstream 475 k php-opcache x86_64 8.1.8-1.module+el9.1.0+13171+4883e0c8 appstream 376 k php-pdo x86_64 8.1.8-1.module+el9.1.0+13171+4883e0c8 appstream 86 k php-xml x86_64 8.1.8-1.module+el9.1.0+13171+4883e0c8 appstream 142 k Transaction Summary ================================================================================================================================================================ Upgrade 8 Packages Total download size: 7.0 M Is this ok [y/N]: n

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2344	[Rocky-Linux-9] General	major	always	2023-02-24 13:46	2023-03-01 13:17

Reporter:	Antonio Di Bacco	Platform:	Intel
Assigned To:		OS:	Rocky Linux
Priority:	high	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	ping6 stops working after a few tries with EADDRNOTAVAIL error
Description:	ping6 -I ens6f0 ff02::1 stops working after a few pings.
Tags:	multicast, ping6, sendmsg, sendto
Steps To Reproduce:	Try to issue this command: ping6 -I ens6f0 ff02::1 After an average of 100 pings I start getting erro EADDRNOTAVAIL (in sendmsg) and the command doesn't work anymore: sendmsg(3, {msg_name={sa_family=AF_INET6, sin6_port=htons(58), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "ff02::1", &sin6_addr), sin6_scope_id=0}, msg_namelen=28, msg_iov=[{iov_base="\200\0\0\0\0\0\0\n\334\265\370c\0\0\0\0\302\261\6\0\0\0\0\0\20\21\22\23\24\25\26\27"..., iov_len=64}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=0x32}], msg_controllen=40, msg_flags=0}, 0) = -1 EADDRNOTAVAIL (Cannot assign requested address) recvmsg(3, {msg_namelen=28}, MSG_DONTWAIT\|MSG_ERRQUEUE) = -1 EAGAIN (Resource temporarily unavailable)
Additional Information:	The same happens using a python script to do the same. Ubuntu 20.04 and 22.04 is not affected.
Attached Files:

Notes
(0002641) Antonio Di Bacco 2023-03-01 13:17	The bug doesn't happen if the interface used for pinging is set to link-local mode.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2311	[Rocky Services] Mail list	block	have not tried	2023-02-22 20:43	2023-02-23 03:02

Reporter:	Neil Hanlon	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	immediate	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	New users cannot subscribe to lists due to erroneously requiring email verification
Description:	last upgrade removed the code which permitted this
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0002542) Neil Hanlon 2023-02-23 03:02	Resolved temporarily by changing email verification from mandatory to optional. we don't strictly _need_ verification as we only allow login via accounts.rockylinux.org - though I suppose we could revisit that... Something changed in how allauth handles this and my patch for autoverifying emails no longer works. i will have to redo it.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
892	[Cloud] General	major	always	2022-11-17 10:17	2023-02-17 03:57

Reporter:	Louis Abel	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky Linux 8.7 Generic Cloud only bootable with UEFI
Description:	A rebuild of the generic cloud images are required, as they don't boot UEFI. For some users this is problematic as some platforms default to BIOS boot.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0001323) David Monro 2022-11-29 04:14	Having pulled apart the image a bit, it looks completely different to the 8.6 one. I _think_ the problem is that there just isn't a grub.conf for the non-UEFI case?

(0001324) David Monro 2022-11-29 04:15	(I should have been clearer, the image does in fact boot, but drops straight to a grub prompt).

(0001325) Neil Hanlon 2022-11-29 04:37	Heya, could you give this a try? https://s3.us-east-2.amazonaws.com/resf-empanadas/buildimage-8.7-x86_64/Rocky-8-GenericCloud-Base-8.7-20221128.0.x86_64/1669672808/Rocky-8-GenericCloud-Base-8.7-20221128.0.x86_64.qcow2

(0001326) David Monro 2022-11-29 11:17	No, that exhibits the same behaviour, drops straight to a grub prompt

(0001651) Neil Hanlon 2022-12-08 17:28	I apologize for not updating this case. The image has been updated and should now work for UEFI and BIOS boot.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
144	[Cloud] General	block	always	2022-07-14 21:21	2023-02-17 03:56

Reporter:	Jean-François Landry	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky 9 OpenStack image has no installed BIOS GRUB boot sector
Description:	https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-GenericCloud-9.0-20220706.0.x86_64.qcow2 is not bootable on OpenStack using the standard, default BIOS compatibility classic method. The boot sector is empty. Looks like grub was never installed when provisioning the image. Here is the xxd output of the first 512 bytes of the image when converted to RAW (only contains the partition table): 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001c0: 0200 eeff ffff 0100 0000 ffff 3f01 0000 ............?... 000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.
Tags:
Steps To Reproduce:	Upload to OpenStack, attempt to launch an instance, the console stays stuck on "Booting from Hard Disk..."
Additional Information:
Attached Files:

Notes
(0000487) Louis Abel 2022-08-30 21:20	Hello. Please try the following images: http://dl.rockylinux.org/stg/rocky/9/images/x86_64/Rocky-9-GenericCloud-9.0-20220830.0.x86_64.qcow2 http://dl.rockylinux.org/stg/rocky/9/images/x86_64/Rocky-9-GenericCloud.latest.x86_64.qcow2

(0000491) Jean-François Landry 2022-08-31 15:57	Looks fine aside from a small locale / glibc langpack issue. According to localectl: System Locale: LANG=en_US.UTF-8 Installed glibc langpacks: glibc-minimal-langpack-2.34-28.el9_0.x86_64 Which results in warning when running sudo dnf update and likely other commands: "Failed to set locale, defaulting to C.UTF-8" Can be fixed by installing "glibc-langpack-en" or using "LANG=C.UTF-8" by default. Otherwise, the image boots in BIOS mode on openstack, cloud-init/growpart work, seems totally functional.

(0000492) Robert Cohen 2022-09-01 02:53	trivial issue. Since this image is for use in virtual environments, it would be nice to have the virt-what package installed by default since some software uses it to detect that this is a virtual environment.

(0000533) Fritz Elfert 2022-09-14 11:59	In addition to the missing glibc-langpack-en mentioned earlier, I just noticed another odd behavior with the new image Rocky-9-GenericCloud-9.0-20220830.0.x86_64.qcow2: With the old image, output of cloud-init was logged to the console (/dev/ttyS0) as well as to /var/log/cloud-init-output.log With the new image, logging of cloud-init on the console is gone. This affects automated provsioning of custom snapshots here, where we monitor a VMs console for specific patterns in order to detect errors in an early stage and then prevent out automated provisioning process from createing a possibly broken snapshot. I just tested current Alma9 in regards to that and it still produces cloud-init output on the console. Since both provide the same cloud-init package version, I assume this is not an issue of cloud-init itself but some side effect of a generic configuration change. Will test the same with rhel-baseos-9.0-x86_64-kvm.qcow2 from RedHat later. PS: I would look into your image-creation process myself, but I can't find any public (git?) repo. The only one that I found is https://github.com/rocky-linux/sig-cloud-instance-images but that one appears to be for docker. So: Where the heck are the scripts that you use for generating the official images?

(0000534) Neil Hanlon 2022-09-14 13:20	Working on new images this week which will address these concerns. I'll have to look into the cloud-init one a bit more, but that shouldn't be too hard. I suspect something going on with the console parameter. @Fritz regarding the scripts for image generation. we're moving things into our toolkit in a subproject. Specifically ,the image building script is here: https://git.resf.org/sig_core/toolkit/src/branch/devel/iso/empanadas/empanadas/scripts/build_image.py I need to work on some docs for usage, but largely that's how the images get generated in our semi-hand-fed pipeline.

(0000536) Louis Abel 2022-09-15 03:32	Hello. All kickstarts are here: https://git.resf.org/sig_core/kickstarts or the mirror here: https://github.com/rocky-linux/kickstarts The langpack* packages have always been excluded in our images since we started making them. This was a carry over from how CentOS does it (including in stream 9). We usually remove and add packages that we may feel that do or don't fit as well. For context with the locale piece: As far as I'm aware, the locale piece is actually a bug of cloud init that should be fixed in 22.2 (or a patched 22.1 that's currently in CentOS Stream 9). I did a hotfix for the next image we build to force the locale to be C.UTF-8 in the meantime. See this commit: https://git.resf.org/sig_core/kickstarts/commit/ebf7a38c6b3f81512daaf0f4938148c1a576750b As for the console portion, it's a strange case. We have tried to adjust the parameters in the kickstart bootloader line and we have also tried to use sed and grubby within %post to try to resolve the problem. What ends up happening with the changes we try is we no longer get any console on ttyS0, not even a login prompt. We have also tried to inherit a fedora-like configuration specifying `console=tty1 console=ttyS0,115200n8` at the end of the bootloader configuration, but still no dice. Even more interesting, you can run a few grubby commands after logging in to "fix" the issue, but it defeats the purpose of not being able to see the cloud init messages on first boot. As an aside, if you would like to try out how we build our images, you could try this (it may require you to make some directories or install packages on your host system; we also use Fedora in this example): git clone https://git.resf.org/sig_core/toolkit.git -b devel cd toolkit/iso/empanadas podman build --build-arg BRANCH=r9 -t empanadas:r9 -f Containerfile.imagefactory podman run -it --rm -e LIBVIRT_DEFAULT_URI -v /var/run/libvirt/:/var/run/libvirt/ -v /var/lib/imagefactory/:/var/lib/imagefactory/:rw --network host --security-opt label=disable --privileged --device fuse empanadas:r9 build-image --version 9 --type GenericCloud --debug This will leave an image in /var/lib/imagefactory/storage with a .body name. It'll be in raw format. You can then use this against virt-install or otherwise. I'll keep trying to look into where the issue is in the meanwhile. We are open to any suggestions or help as well to try to resolve the console issue.

(0000537) Louis Abel 2022-09-15 06:38	After a bit of work we believe we have the issues resolved. We'll have images built through the week/weekend and pushed to our mirrors and we'll notify when this happens. Resolved in the following commits: Remove kernel parameters from icicle configuration: https://git.resf.org/sig_core/toolkit/commit/eeae7ff5ab73f27229bbc578aeeb3750619101b9 Fixes grub2-pc package naming and removes sed in %post: https://git.resf.org/sig_core/kickstarts/commit/0a16a1b5cf1b3fbfe6bc8b95fcf19b645fef0389 Works around cloud-init bug that should be backported in 9.1's cloud-init or fixed in 22.2: https://git.resf.org/sig_core/kickstarts/commit/ebf7a38c6b3f81512daaf0f4938148c1a576750b Adds virt-what to package list: https://git.resf.org/sig_core/kickstarts/commit/008bf056b923231c0f9100fabef54d2d407c4304

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
160	[Cloud] General	major	always	2022-07-21 14:06	2023-02-17 03:56

Reporter:	Marco Giunta	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky 9 GenericCloud qcow2 image does not work
Description:	Rocky 9 GenericCloud qcow2 image does not work: when using it on oVirt or on a plain qemu-kvm it hangs on "Booting from hard disk" forever. Using the same configuration with a Rocky 8.6 GenericCloud qcow2 image, it works like a charm
Tags:
Steps To Reproduce:	Try to boot a qemu-kvm VM from Rocky 9 GenericCloud qcow2 image
Additional Information:	Image link: https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-GenericCloud-9.0-20220706.0.x86_64.qcow2
Attached Files:

Notes
(0000302) Neil Hanlon 2022-07-21 14:32	Hi Marco, I believe this is due to the current image not supporting BIOS boot. Could you attempt with a UEFI boot and see how that goes? I am working on preparing a new generic cloud image which supports BIOS booting. --Neil

(0000307) Marco Giunta 2022-07-22 08:02	> Could you attempt with a UEFI boot and see how that goes? using UEFI boot I'm able to start cloud image. Thanks for the hint ;-)

(0000464) Alex Garnett 2022-08-23 16:11	Hi, is there any update on this issue? Sorry for the bother, but it's holding up our integration. Thanks!

(0000470) Neil Hanlon 2022-08-25 14:14	Hi, No bother at all. I apologize for the latency. I am working on generating images now and will have them out this evening (including new Azure images for the folks on the forums). --neil

(0000486) Louis Abel 2022-08-30 21:20	Hello. Please try the following images: http://dl.rockylinux.org/stg/rocky/9/images/x86_64/Rocky-9-GenericCloud-9.0-20220830.0.x86_64.qcow2 http://dl.rockylinux.org/stg/rocky/9/images/x86_64/Rocky-9-GenericCloud.latest.x86_64.qcow2

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
90	[Containers] General	minor	always	2022-05-06 17:15	2023-02-17 03:54

Reporter:	Trevor Cooper	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	No guest additions in vagrant box for virtualbox provider
Description:	The latest RESF Official Vagrant box for Rocky Linux 8.5 virtualbox provider (box version 5.0.0) does not provide working VirtualBox Guest Additions preventing the use of advanced features of VirtualBox such as shared folders.
Tags:
Steps To Reproduce:	1. Download Official Rocky Linux Vagrant box for VirtualBox provider - `vagrant box add --provider virtualbox --box-version 5.0.0 rockylinux/8` 2. Create default Vagrantfile for the box - `vagrant init --box-version 5.0.0 rockylinux/8` 3. Provision a VM in VirtualBox using the downloaded box and generated Vagrantfile - `vagrant up` 4. When provisioned vagrant attempts to mount `$PWD` at `/vagrant` inside the VM but fails... ``` ==> default: Mounting shared folders... default: /vagrant => /Users/tcooper/boxes/official/rocky8u5 Vagrant was unable to mount VirtualBox shared folders. This is usually because the filesystem "vboxsf" is not available. This filesystem is made available via the VirtualBox Guest Additions and kernel module. Please verify that these guest additions are properly installed in the guest. This is not a bug in Vagrant and is usually caused by a faulty Vagrant box. For context, the command attempted was: mount -t vboxsf -o uid=1000,gid=1000,_netdev vagrant /vagrant The error output from the command was: mount: /vagrant: unknown filesystem type 'vboxsf'. ```
Additional Information:	Likely cause... The kickstart file used to provision the Vagrant box for VirtualBox provider attempts to install VirtualBox guest additions for running kernel (and fails) but needs to install guest additions for the kernel installed as a result of network install (which will change as the repo is updated). Examples from inside VM... ``` ➜ rocky8u5 vagrant ssh Last login: Fri May 6 16:58:49 2022 from 10.0.2.2 [vagrant@localhost ~]$ sudo grep -Ei "vbox additions" /root/anaconda-ks.cfg -B1 -A10 # Lets just make sure we have vbox additions installed sudo dnf -y install kernel-devel gcc make perl elfutils-libelf-devel wget -O /tmp/vboxadditions.iso https://download.virtualbox.org/virtualbox/6.1.32/VBoxGuestAdditions_6.1.32.iso sudo mkdir /media/VBoxGuestAdditions sudo mount -o loop,ro /tmp/vboxadditions.iso /media/VBoxGuestAdditions sudo sh /media/VBoxGuestAdditions/VBoxLinuxAdditions.run rm /tmp/vboxadditions.iso sudo umount /media/VBoxGuestAdditions sudo rmdir /media/VBoxGuestAdditions sudo dnf -y remove kernel-devel gcc make perl elfutils-libelf-devel [vagrant@localhost ~]$ find /lib/modules -name "vboxsf*" [vagrant@localhost ~]$ ``` I have a working box with VirtualBox Guest Additions installed in/via kickstart... 1. Init box - `vagrant init tcooper/rockylinux` 2. Provision VM - `vagrant up` 3. Verify Guest Additions ``` ➜ rocky8u5 vagrant ssh [vagrant@localhost ~]$ modinfo -F filename vboxsf /lib/modules/4.18.0-348.23.1.el8_5.x86_64/misc/vboxsf.ko [vagrant@localhost ~]$ mount -t vboxsf vagrant on /vagrant type vboxsf (rw,nodev,relatime,iocharset=utf8,uid=1000,gid=1000,_netdev) ``` Please provide repository for PR of the kickstart used to build the working vagrant box for virtualbox provider show above or add/use provided kickstart in this report.
Attached Files:

Notes
(0000259) Neil Hanlon 2022-07-12 03:13	Hi @tcooper - thank you for this. You can commit the updates here: https://git.resf.org/sig_core/kickstarts/ Let me know and I can run a new build!

(0000261) Trevor Cooper 2022-07-12 14:43	Issue created... https://git.resf.org/sig_core/kickstarts/issues/1

(0000262) Trevor Cooper 2022-07-12 15:08	Draft PR submitted... https://git.resf.org/sig_core/kickstarts/pulls/2 @neil please see comment in PR.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
125	[Mattermost] Accounts	major	always	2022-06-22 21:23	2023-02-17 03:52

Reporter:	Neil Hanlon	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Maximum users reached for rocky-linux team
Description:	User on forums reported an error signing up for Mattermost citing an error about the team being full. I investigated and found it was due to a default configuration setting of the maximum users a team can have: 7500. To rectify this, the configuration was edited on the fly using the mmctl command `mmctl config edit` to change the maximum. We do not currently have an ansible role controlling the infrastructure for our mattermost servers, so let's leave this open until we do, and can ensure we make sure to make that setting. Also going to file a bug to document the process to edit the database config in case of emergencies.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
71	[Cloud] General	minor	always	2022-03-22 14:14	2023-02-17 03:52

Reporter:	Ivan Baldo	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	AWS AMI support for AMD instances m6a, c6a, etc.
Description:	I guess it should work out of the box on the newer AMD server instances on AWS if enabled on the current AMIs. Thanks a lot for looking into this!!!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0002509) Neil Hanlon 2023-02-17 03:52	Heya, Apologies I didn't respond here, but this was taken care of. Best, Neil

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
70	[Cloud] General	minor	always	2022-02-04 10:46	2023-02-17 03:52

Reporter:	Neil Hanlon	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	rocky images in google cloud platform is created by rocky-linux-8-v20220126
Description:	Description of problem: The image in google cloud platform of rocky linux (rocky-linux-8-v20220126) is "created by": rocky-linux-8-v20220126 instead of rocky or rocky-linux If you compare this with others: - ubuntu images are created by Canonical - cenots-7 images are created by CentOS This is problem because tools like packer use hard coded list of projects/"created by" to search for public available images. I want to ask packer to add rocky to list of images to search for. But if every images of rocky has a different Creator this is not possible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000068) Neil Hanlon 2022-04-20 07:52	Neil Hanlon 2022-02-04 17:38:09 UTC Hi Rens, Thanks for your report. It appears that there was a recent commit [1] to the GoogleCompute packer plugin which added Rocky Linux in. I believe this patch should resolve the issues you are having. Can you confirm you're running the most recent version of the plugin? [1] https://github.com/hashicorp/packer-plugin-googlecompute/pull/78 Rens Sikma 2022-02-10 13:40:12 UTC Thanks, that works. Was running latest version of packer. But they moved logic for gcp to a plugin. And to use that i had to convert from the json syntax to HCL syntax. But i can confirm. that rocky works with packer if you use: packer-plugin-googlecompute version v1.0.10 Still think that would look nicer if packer images where created by rocky-linux instead of rocky-linux-8-v20220126. but everything works for me. Thanks for the help [tag] [reply] [−] Comment 3 Neil Hanlon 2022-02-10 14:16:30 UTC I'd be happy to pass some feedback over to the google team who is responsible for the image builds (they actually happen through some Google open source build/test software), but my understanding from them is that Terraform/other tools are supposed to act as a translation layer between these. That said, would you be able to share a sample terraform config so I can see what you're seeing w.r.t. the naming conventions? Best, Neil [tag] [reply] [−] Comment 4 Rens Sikma 2022-02-15 13:40:59 UTC Created attachment 108 [details] screenshot image gcp rocky [tag] [reply] [−] Comment 5 Rens Sikma 2022-02-15 13:41:46 UTC Created attachment 109 [details] screenshot image gcp normal [tag] [reply] [−] Comment 6 Rens Sikma 2022-02-15 13:47:33 UTC I am commenting on the naming convention of the "create by" collum of the image in gcp. I have attached 2 screenshots about what i mean: Most images have "created by" field with the name of the organization that created the distribution. such as Debian, Microsoft, google. Canonical But the image rocky-linux-8-v20220126 is "created by" rocky-linux-8-v20220126

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2245	[Rocky-Linux-8] scap-security-guide	minor	always	2023-02-16 21:03	2023-02-16 21:09

Reporter:	Stephan Ellis	Platform:	x84_64
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	8.7
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	CUI Securirty Profile will pass evaluation
Description:	When applying the security profile for NIST 800-171, everything works as expected except for two components. Producing an html report using the oscap tool, you will see that it's failing on the FIPS crypto policy settings and the chrony settings. Checking those settings by hand reveals that they are correct, but the profile evalutaion says they are not.
Tags:
Steps To Reproduce:	Install Rocky linux with the recommended partition scheme, using the Server software selection and the NIST 800-171 security profile. After install, run updates and then run fips-mode-setup --enable and restart. Then run oscap tool using the ssg-rl8-ds.xml scap content and the "cui" profile.
Additional Information:
Attached Files:	Screenshot from 2023-02-16 15-07-37.png (82,293 bytes) 2023-02-16 21:09 https://bugs.rockylinux.org/file_download.php?file_id=562&type=bug Screenshot from 2023-02-16 15-08-26.png (106,658 bytes) 2023-02-16 21:09 https://bugs.rockylinux.org/file_download.php?file_id=563&type=bug

Notes
(0002476) Stephan Ellis 2023-02-16 21:09	screen shots of the html report

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2179	[Rocky-Linux-9] gnome-shell	minor	always	2023-02-09 20:16	2023-02-11 21:29

Reporter:	Ashutosh Kumar	Platform:	Rocky Linux
Assigned To:		OS:	9.1
Priority:	low	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Chrome browser window has a border around it was on first launch.
Description:	When Google Chrome is opened after turning on a device, it has a white or grey border around its window. It is also present on other chromium browsers though I was not able to recreated in Fedora or Ubuntu. It occurs even when system title bar is used in Chrome. In the two images below, you can see that one of them has a square grey border around it.
Tags:	glitch, kernel
Steps To Reproduce:	1. Turn device on and login 2. Open Google Chrome
Additional Information:	It happens in both virtual machines and on my laptop when installed directly.
Attached Files:	406ca260-0b3f-4feb-acdd-d221f374b6c5.jpg (3,511,096 bytes) 2023-02-09 20:16 https://bugs.rockylinux.org/file_download.php?file_id=463&type=bug 350a5e06-e1f2-4ac7-ab2e-74770fa84ceb.jpg (2,639,440 bytes) 2023-02-09 20:16 https://bugs.rockylinux.org/file_download.php?file_id=464&type=bug Screenshot from 2023-02-10 22-23-49.png (158,443 bytes) 2023-02-10 21:27 https://bugs.rockylinux.org/file_download.php?file_id=496&type=bug Screenshot from 2023-02-10 22-30-33.png (101,738 bytes) 2023-02-10 21:35 https://bugs.rockylinux.org/file_download.php?file_id=497&type=bug image.png (1,139,167 bytes) 2023-02-11 20:08 https://bugs.rockylinux.org/file_download.php?file_id=529&type=bug

Notes
(0002377) Ashutosh Kumar 2023-02-09 20:19	Just wanted to mention that Fedora version was 36 and the Ubuntu version was 22.4.1 and Rocky Linux was updated completely as of 7 PM of10th February 2023.

(0002443) Ashutosh Kumar 2023-02-10 18:28	Hello, back here again. I tried kernel version 6.1.8 (kernel-ml) from elrepo for el9 and the borders do not show up! So there is probably some miscofiguration in the kernel

(0002444) Lukas Magauer 2023-02-10 20:38	Hi Ashutosh, I tried to reproduce this in a freshly installed Rocky Linux 9 machine (ESXi hosted VM), but I couldn't how did you install Google Chrome and how does your setup look like?

(0002445) Lukas Magauer 2023-02-10 20:40	Or is this only happening if you access the machine via RDP (as far as I can see it should be accessed by RDP)

(0002446) Ashutosh Kumar 2023-02-10 21:16	Hello Lukas, I installed chrome both via flathub and the official google-chrome-stable repo. Both had the same issue. Also, it used to happen when I had Rocky installed on my laptop. This is a Hyper-V VM. My setup in the image is just a pure Rocky install with workstation install and Rocky icons disabled. Also i had changed adwaita to dark using gnome tweaks. My laptop is an IdeaPad 5 Pro 14ACN6 with amd Ryzen 7 5800U with integrated graphics. This doesn't happen with firefox or any other app, but a kernel update from elrepo fixes it.

(0002447) Lukas Magauer 2023-02-10 21:27	Okay very interesting (thank you for the hint I completely forgot about the possibility the RDP heady being a Hyper-V session), so I made a screenshot of my test machine now, the left window is from the 1st party rpm and the right one from the flatpak from flathub.

(0002448) Lukas Magauer 2023-02-10 21:35	Or making it very apparent with Adwaita dark, the flatpak not handling the dark mode ^^ Up to now everything looks good here, what do you mean by disabling Rocky icons? (if nothing helps I will pull up a another machine on Hyper-V) I'm on kernel 5.14.0-162.12.1.el9_1.0.2 right now btw.

(0002449) Ashutosh Kumar 2023-02-11 05:47	Hello, by Rocky icons i meant the logo extension Rocky has on by default to show the logo on wallpaper. Also, I made a video showing the problem (I hope yt links are allowed): https://youtu.be/VsFtItlKUVc I used the flathub version of chrome for the video. I tried with the elrepo and the original kernel an you can see that all Rocky provided kernels are having the same border. This issue also happens inside virtualbox and on real machines when Rocky is installed on them.

(0002450) Ashutosh Kumar 2023-02-11 20:08	Just to add, this is also occuring in AlmaLinux. So this probably an RHEL issue, since both of these distros are bug-for-bug compatible.

(0002451) Lukas Magauer 2023-02-11 20:11	Could you spin up a CentOS Stream machine and look if it's also happening there? If no then it should be fixed by the next minor release

(0002452) Akemi Yagi 2023-02-11 20:21	If it is an upstream issue (RHEL or CentOS Stream), it should be reported to bugzilla.redhat.com. Use this link: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%209&version=CentOS%20Stream

(0002453) Ashutosh Kumar 2023-02-11 21:29	Ok, I will try using CentOS Stream in 7-8 hours and I will also report it in rhel bugzilla. Thanks!

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2146	[Rocky-Linux-8] ipa	trivial	always	2023-02-08 11:24	2023-02-08 11:24

Reporter:	Stefano Biagiotti	Platform:
Assigned To:		OS:
Priority:	low	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Typo in ipa.spec
Description:	'/var/log/ipaupgrade.lo doesn't exist' error during dnf update on Rocky Linux 8. Patch: # diff ipa.spec ipa.spec.new 1248c1248 < chmod 0600 /var/log/ipaupgrade.lo --- > chmod 0600 /var/log/ipaupgrade.log
Tags:
Steps To Reproduce:	# dnf update ipa-client ==================================================================================================================== Package Architecture Version Repository Size ==================================================================================================================== Upgrading: ipa-client x86_64 4.9.10-9.module+el8.7.0+1120+659f71b8 appstream 285 k ipa-client-common noarch 4.9.10-9.module+el8.7.0+1120+659f71b8 appstream 187 k ipa-common noarch 4.9.10-9.module+el8.7.0+1120+659f71b8 appstream 797 k python3-ipaclient noarch 4.9.10-9.module+el8.7.0+1120+659f71b8 appstream 691 k python3-ipalib noarch 4.9.10-9.module+el8.7.0+1120+659f71b8 appstream 761 k Riepilogo della transazione ==================================================================================================================== Aggiornati 5 pacchetti Dimensione totale dello scaricamento: 2.7 M Procedere [s/N]: y Scaricamento dei pacchetti: (1/5): ipa-client-common-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch.rpm 903 kB/s \| 187 kB 00:00 (2/5): ipa-client-4.9.10-9.module+el8.7.0+1120+659f71b8.x86_64.rpm 1.1 MB/s \| 285 kB 00:00 (3/5): ipa-common-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch.rpm 2.3 MB/s \| 797 kB 00:00 (4/5): python3-ipaclient-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch.rpm 4.2 MB/s \| 691 kB 00:00 (5/5): python3-ipalib-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch.rpm 4.7 MB/s \| 761 kB 00:00 -------------------------------------------------------------------------------------------------------------------- Totale 4.3 MB/s \| 2.7 MB 00:00 Esecuzione del controllo di transazione Controllo di transazione eseguito con successo. Test di transazione in corso Test di transazione eseguito con successo Transazione in corso Preparazione in corso : 1/1 Upgrading : ipa-common-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch 1/10 Upgrading : ipa-client-common-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch 2/10 Upgrading : python3-ipalib-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch 3/10 Upgrading : python3-ipaclient-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch 4/10 Upgrading : ipa-client-4.9.10-9.module+el8.7.0+1120+659f71b8.x86_64 5/10 Esecuzione scriptlet in corso: ipa-client-4.9.10-9.module+el8.7.0+1120+659f71b8.x86_64 5/10 chmod: impossibile accedere a '/var/log/ipaupgrade.lo': File o directory non esistente Pulizia : ipa-client-4.9.10-3.module+el8.7.0+1074+aae18f3a.x86_64 6/10 Pulizia : python3-ipaclient-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 7/10 Pulizia : python3-ipalib-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 8/10 Pulizia : ipa-common-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 9/10 Pulizia : ipa-client-common-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 10/10 Esecuzione scriptlet in corso: ipa-client-common-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 10/10 Verifica in corso : ipa-client-4.9.10-9.module+el8.7.0+1120+659f71b8.x86_64 1/10 Verifica in corso : ipa-client-4.9.10-3.module+el8.7.0+1074+aae18f3a.x86_64 2/10 Verifica in corso : ipa-client-common-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch 3/10 Verifica in corso : ipa-client-common-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 4/10 Verifica in corso : ipa-common-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch 5/10 Verifica in corso : ipa-common-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 6/10 Verifica in corso : python3-ipaclient-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch 7/10 Verifica in corso : python3-ipaclient-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 8/10 Verifica in corso : python3-ipalib-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch 9/10 Verifica in corso : python3-ipalib-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 10/10 Aggiornati: ipa-client-4.9.10-9.module+el8.7.0+1120+659f71b8.x86_64 ipa-client-common-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch ipa-common-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch python3-ipaclient-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch python3-ipalib-4.9.10-9.module+el8.7.0+1120+659f71b8.noarch Fatto!
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2113	[Rocky-Linux-9] nodejs	major	always	2023-02-06 12:42	2023-02-06 20:46

Reporter:	Nicolas FORMICHELLA	Platform:	x86_64
Assigned To:	Mustafa Gezen	OS:	Rocky Linux
Priority:	high	OS Version:	9.1
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	nodejs:18 module stream is broken
Description:	Trying to install the DNF module stream for Node.js doesn't succeed
Tags:	repository
Steps To Reproduce:	- `dnf module list nodejs` - `dnf module install nodejs`
Additional Information:	Install log ``` dnf module install nodejs:18 Last metadata expiration check: 0:01:30 ago on Mon Feb 6 12:30:30 2023. Unable to resolve argument nodejs:18 No match for package nodejs Unable to resolve argument nodejs:18 No match for package npm Error: Problems in request: broken groups or modules: nodejs:18, nodejs:18 ``` Installing other streams like `ruby` works fine Can also reproduce on rockylinux/rockylinux:9 docker image Can not reproduce on RL8.7
Attached Files:

Notes
(0002344) Mustafa Gezen 2023-02-06 16:40	Hi, Fix should be out shortly. Sorry for the inconvenience

(0002345) Mustafa Gezen 2023-02-06 20:46	Should be fixed now. Thanks for the report

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2047	[Rocky-Linux-9] kernel	major	always	2023-02-01 11:58	2023-02-01 11:58

Reporter:	Tony Che	Platform:
Assigned To:		OS:
Priority:	high	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Reproduced vulnerability cve-2022-4378
Description:	Hello guys! I Reproduce vulnerability cve-2022-4378 on latest version on Rocky 9
Tags:	cve, kernel
Steps To Reproduce:	yum update -y yum install git epel-release unzip tar dnf config-manager --set-enabled crb yum install autoconf automake m4 pkg-config yum install kernel-devel reboot git clone https://github.com/linux-test-project/ltp cd ltp make autotools ./configure make make install mv /opt/ltp/testcases/bin/cve-2022-4378 /root/ /root/cve-2022-4378 #server will reboot after that step useradd test cp /root/cve-2022-4378 /home/test/cve-2022-4378 chown -R test:test /home/test/cve-2022-4378 su test cd /home/test ./cve-2022-4378 #server will reboot after that step
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2015	[Rocky-Linux-9] flatpak	minor	always	2023-01-31 21:02	2023-01-31 21:02

Reporter:	Landon Manning	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	gnome taskbar icons not showing up for some flatpak apps
Description:	Using a fresh install of Rocky Workstation 9, I have installed several flatpaks via flathub. Each of these apps has a tray icon that should display in the gnome topbar, but not all of them do. The developer of "SyncThingy" was able to reproduce the issue here: https://github.com/zocker-160/SyncThingy/issues/14 Of the flatpaks I have tried (all from flathub), these are the results: Google Chrome - Displays correctly Telegram - Does not display SyncThingy - Does not display
Tags:
Steps To Reproduce:	1) Install Rocky Workstation 2) Enable flathub 3) Install a flatpak app that utilizes gnome topbar tray icons
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2014	[Rocky-Linux-9] gtk2	minor	always	2023-01-31 20:50	2023-01-31 20:50

Reporter:	Ryan Brothers	Platform:	docker
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	gtk2 dependencies
Description:	I don't believe the below is an issue directly with Rocky Linux, but I can reproduce the issue with it, and I was hoping you could help trace why it's happening. I am building a docker container with gtk2, and I noticed that the container size is much larger than what it should be. What's odd is that it's working fine if I run the rockylinux:9 docker image and install gtk2, but if I first run "dnf update systemd-libs", then the issue happens. In the below output, can you tell why the package count changes? Why does updating systemd-libs cause new weak dependencies to be installed? I realize that I can get around this by skipping the install of weak dependencies, but I'm trying to figure out what changed to cause this. Thanks for your help.
Tags:
Steps To Reproduce:	# docker run --rm -ti rockylinux:9 bash ## dnf install gtk2 ... Install 44 Packages Total download size: 12 M Installed size: 44 M ## dnf -y update systemd-libs ## dnf install gtk2 ... Install 198 Packages Total download size: 127 M Installed size: 469 M
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1948	[Rocky Linux Build System] General	minor	always	2023-01-30 06:29	2023-01-31 19:27

Reporter:	Holger Hees	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	order of the packages in the repository metadata is reversed between primary.xml and filelists.xml / other.xml
Description:	I'm using pulp to sync several repositories like rocky and others. Currently this is not possible anymore, because it looks like your metadata of your repository are out of order. For details you can check. https://github.com/pulp/pulp_rpm/issues/2836
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0002311) Thomas Menard 2023-01-31 08:05	I just wanted to add my voice to this issue. We are too using pulp for rocky linux repo mirroring and encounter the same issue. This is really impacting us (no new server install for now) as we don't use versionning feature on pulp. Maybe minor is not the right severity.... Thanks

(0002312) Louis Abel 2023-01-31 08:15	I would argue that the error being reported from pulp is incorrect. It has nothing to do with "out of order" metadata and more so the metadata itself being inconsistent. Between two pieces of the metadata, there are shared bits such as checksums. Unfortunately, you did not provide the error output you were seeing. But it is likely you were seeing two sha sums that were stated as "out of order" when instead the problem is that the sums are not matching between the primaries and file lists. This should be fixed and a sync should work normally. If you are syncing from a mirror, please give them time to sync. If you are syncing directly from dl.rl.o, it should work right away, assuming fastly cache has been purged in your respective pops.

(0002313) Holger Hees 2023-01-31 08:42	Message coming from pulp is "Msg: Parsing interrupted: Out of order metadata" I sync every hour from https://ftp.gwdg.de/pub/linux/rocky/9.1/BaseOS/x86_64/os/ The error happens from "Jan 27 07:00:00" until "Jan 31 08:00:00" Means the last sync at 09:00:00 was successful

(0002314) Holger Hees 2023-01-31 08:47	fullstack trace from pulp is --- pulp [579b6c3ff3a445f39715b8a9b722e74c]: pulpcore.tasking.pulpcore_worker:INFO: File "/usr/local/lib/python3.8/site-packages/pulpcore/tasking/pulpcore_worker.py", line 452, in _perform_task result = func(args, kwargs) File "/usr/local/lib/python3.8/site-packages/pulp_rpm/app/tasks/synchronizing.py", line 565, in synchronize repo_version = dv.create() or repo.latest_version() File "/usr/local/lib/python3.8/site-packages/pulpcore/plugin/stages/declarative_version.py", line 161, in create loop.run_until_complete(pipeline) File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete return future.result() File "/usr/local/lib/python3.8/site-packages/pulpcore/plugin/stages/api.py", line 225, in create_pipeline await asyncio.gather(futures) File "/usr/local/lib/python3.8/site-packages/pulpcore/plugin/stages/api.py", line 43, in __call__ await self.run() File "/usr/local/lib/python3.8/site-packages/pulp_rpm/app/tasks/synchronizing.py", line 856, in run await self.parse_repository_metadata(repomd, repomd_files) File "/usr/local/lib/python3.8/site-packages/pulp_rpm/app/tasks/synchronizing.py", line 908, in parse_repository_metadata await self.parse_packages( File "/usr/local/lib/python3.8/site-packages/pulp_rpm/app/tasks/synchronizing.py", line 1281, in parse_packages for pkg in parser.as_iterator():

(0002315) Holger Hees 2023-01-31 08:48	I missed the first line from the stack trace pulp [579b6c3ff3a445f39715b8a9b722e74c]: pulpcore.tasking.pulpcore_worker:INFO: Task 4f5a132d-1624-42e0-8d5f-1f6163b1c622 failed (Parsing interrupted: Out of order metadata: d2134ac3dc9c0b26098b6e5d50a51f2a47df3bd8b4801369f39a815c0cfdba10 vs cf36b2caa37bf0e45b7c3d456a4897c6ab645367e5286c28bcac77b92d6c9d04.

(0002316) Thomas Menard 2023-01-31 09:03	Here is our pulp output ``` an 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: pulp [d104d89f04454a76acbc94bbdf02e535]: pulpcore.tasking.pulpcore_worker:INFO: Task b94008d7-f7d3-4ac4-91cd-17169f4ede02 failed (Parsing interrupted: Out of order metadata: 786010ce275e9a122265d52515eb90784e036bdf68f2ed2d78d1de250016d3f0 vs be8f8f34a444f82e2d057d799e1eaf4c69197efeb1a46ecd2d4cc1a7ea37949f.) Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: pulp [d104d89f04454a76acbc94bbdf02e535]: pulpcore.tasking.pulpcore_worker:INFO: File "/usr/local/lib/pulp/lib64/python3.9/site-packages/pulpcore/tasking/pulpcore_worker.py", line 452, in _perform_task Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: result = func(args, kwargs) Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: File "/usr/local/lib/pulp/lib64/python3.9/site-packages/pulp_rpm/app/tasks/synchronizing.py", line 565, in synchronize Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: repo_version = dv.create() or repo.latest_version() Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: File "/usr/local/lib/pulp/lib64/python3.9/site-packages/pulpcore/plugin/stages/declarative_version.py", line 161, in create Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: loop.run_until_complete(pipeline) Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: File "/usr/lib64/python3.9/asyncio/base_events.py", line 642, in run_until_complete Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: return future.result() Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: File "/usr/local/lib/pulp/lib64/python3.9/site-packages/pulpcore/plugin/stages/api.py", line 225, in create_pipeline Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: await asyncio.gather(futures) Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: File "/usr/local/lib/pulp/lib64/python3.9/site-packages/pulpcore/plugin/stages/api.py", line 43, in __call__ Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: await self.run() Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: File "/usr/local/lib/pulp/lib64/python3.9/site-packages/pulp_rpm/app/tasks/synchronizing.py", line 856, in run Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: await self.parse_repository_metadata(repomd, repomd_files) Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: File "/usr/local/lib/pulp/lib64/python3.9/site-packages/pulp_rpm/app/tasks/synchronizing.py", line 908, in parse_repository_metadata Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: await self.parse_packages( Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: File "/usr/local/lib/pulp/lib64/python3.9/site-packages/pulp_rpm/app/tasks/synchronizing.py", line 1281, in parse_packages Jan 30 13:29:53 pulp01.it.pasteur.fr pulpcore-worker[3001341]: for pkg in parser.as_iterator(): ```

(0002318) Holger Hees 2023-01-31 10:37	my sentence "Means the last sync at 09:00:00 was successful " was wrong. It was just queued during this time and failed again.

(0002320) Matt Norwood 2023-01-31 14:34	Sync's for the Rocky 9.1 BaseOS are working again. Thank you so much!!!!

(0002321) Holger Hees 2023-01-31 19:23	looks for me good too!

(0002322) Louis Abel 2023-01-31 19:27	Good to hear! I appreciate the stack traces also, this helps us as well. We'll leave this ticket open for a little bit longer as everything syncs.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1651	[Rocky-Linux-9] selinux-policy	minor	always	2022-12-30 20:41	2023-01-31 09:49

Reporter:	Colin Simpson	Platform:	Rocky
Assigned To:		OS:	9
Priority:	normal	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Dovecot SELinux policy incomplete or unrequired
Description:	In Dovecot I don't want to hold users email folder in homedirectories, so I use a directory that is specified in the Postfix SELinux policy /var/spool/dovecot/. To be clear the config for this is: mail_location = mbox:/var/spool/dovecot/%u/:INBOX=/var/mail/%u This location doesn't exist by default, so unsure why it would be in the SELinux policy if not to centrally store users folder (or maybe I'm missing it's intended purpose completely). But specifying this sort of works except I need to amend the policy with: allow dovecot_t dovecot_spool_t:file map; So either: 1/ I miss the point of this location /var/spool/dovecot 2/ The SELinux policy needs amending for this location 3/ Or this location shouldn't be in the SELinux policy at all. I realise my config is probably unfashionable for dovecot, but there should be a way to achieve this with the SELinux policy.
Tags:
Steps To Reproduce:	Set in dovecot: mail_location = mbox:/var/spool/dovecot/%u/:INBOX=/var/mail/%u See the partial failures in audit.log
Additional Information:
Attached Files:

Notes
(0002317) Colin Simpson 2023-01-31 09:49	https://bugzilla.redhat.com/show_bug.cgi?id=2165863 Reported upstream

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1915	[Rocky-Linux-9] ca-certificates	major	always	2023-01-25 15:10	2023-01-30 00:39

Reporter:	Petr Kracik	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	ca-bundle.trust.crt contains expired CA certificates
Description:	We have monitoring script, which monitor /etc/pki/tls for expiring (or expired) certificates, after reinstall to Rocky 9 it start show expired certs in this (/etc/pki/tls/certs/ca-bundle.trust.crt) bundle. I randomly check some CA contained inthat file and really there are few certificates expired around 10 years ago. I've check mozilla CA bundle, but those CA does not seems to be there. So I do not know how they are came from. I found some source at /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
Tags:
Steps To Reproduce:	Install fresh minimal Rocky 9.1 (I did it from PXE)
Additional Information:	CA-Certificates package is latest available in el9 (by date of write of this report) # rpm -qa \|grep ca-certificates ca-certificates-2022.2.54-90.2.el9.noarch Check file /etc/pki/tls/certs/ca-bundle.trust.crt with openssl, first was expired 12 years ago # Issuer: C = AT, ST = Austria, L = Vienna, O = ARGE DATEN - Austrian Society for Data Protection, OU = A-CERT Certification Service, CN = A-CERT ADVANCED, emailAddress = info@a-cert.at # Validity # Not Before: Oct 23 14:14:14 2004 GMT # Not After : Oct 23 14:14:14 2011 GMT
Attached Files:

Notes
(0002245) Akemi Yagi 2023-01-30 00:39	What I can say is that the same file on RHEL systems has the same date range: $ openssl x509 -text -noout -in /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: C = AT, ST = Austria, L = Vienna, O = ARGE DATEN - Austrian Society for Data Protection, OU = A-CERT Certification Service, CN = A-CERT ADVANCED, emailAddress = info@a-cert.at Validity Not Before: Oct 23 14:14:14 2004 GMT Not After : Oct 23 14:14:14 2011 GMT while ca-bundle.crt shows: $ openssl x509 -text -noout -in /etc/pki/tls/certs/ca-bundle.crt Certificate: Data: Version: 3 (0x2) Serial Number: 6828503384748696800 (0x5ec3b7a6437fa4e0) Signature Algorithm: sha1WithRSAEncryption Issuer: CN = ACCVRAIZ1, OU = PKIACCV, O = ACCV, C = ES Validity Not Before: May 5 09:37:37 2011 GMT Not After : Dec 31 09:37:37 2030 GMT Therefore you may need to ask Red Hat why the two certificates are set up that way.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
279	[Cloud] General	major	always	2022-09-12 23:35	2023-01-24 06:43

Reporter:	Adam Augustine	Platform:	Amazon AMI
Assigned To:	Neil Hanlon	OS:	Rocky Linux x86_64
Priority:	normal	OS Version:	8.6
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky Linux AMI instances fail to configure network properly when in IPv6-only subnet in AWS
Description:	I am having trouble launching official Rocky AMI instances in AWS IPv6-only subnets. I have tried booting an Amazon Linux AMI and it works properly. I have tested 8.6, 9.0, x86_64 and aarch64. The instances will take many minutes to boot, throw many error messages, and will eventually fail the second "Status Check" with the error message "Instance reachability check failed". Here is the first system log message that differs substantially from the working Amazon AMI (with one line before and after for context): [ 10.676733] cloud-init[823]: Cloud-init v. 21.1-15.el8 running 'init-local' at Mon, 12 Sep 2022 20:05:47 +0000. Up 10.34 seconds. [ 10.681192] cloud-init[823]: 2022-09-12 20:05:48,274 - util.py[WARNING]: Getting data from <class 'cloudinit.sources.DataSourceEc2.DataSourceEc2Local'> failed [[0;32m OK [0m] Started Initial cloud-init job (pre-networking). The cloud-init process normally (based on the working Amazon AMI instance and other Rocky instances tested in a dual stack subnet) logs an "IPv4 Route Table" with many 169.254.x.y routes. On the failing Rocky instances no "IPv4 Route Table" is logged (see attached system logs). In the system logs there are also entries reporting attempts to access the assets and metadata server at 169.254.169.254: [ 12.865186] cloud-init[899]: 2022-09-12 20:05:50,230 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/latest/api/token' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /latest/api/token (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe4404f8128>: Failed to establish a new connection: [Errno 101] Network is unreachable',))] [ 13.648505] cloud-init[899]: 2022-09-12 20:05:51,234 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/latest/api/token' failed [1/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /latest/api/token (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe4404f8a20>: Failed to establish a new connection: [Errno 101] Network is unreachable',))] These messages repeat many times before the final error messages: [ 131.835862] cloud-init[899]: 2022-09-12 20:07:49,433 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/latest/api/token' failed [119/120s]: unexpected error [Attempted to set connect timeout to 0.0, but the timeout cannot be set to a value less than or equal to 0.] [ 138.843417] cloud-init[899]: 2022-09-12 20:07:56,440 - DataSourceEc2.py[WARNING]: IMDS's HTTP endpoint is probably disabled The instance then continues to boot and eventually presents a login prompt, however the hostname is simply "localhost" and there is no network connectivity. Eventually the error message "Instance reachability check failed" is reported on the "Status Check" tab of the instance page.
Tags:
Steps To Reproduce:	1) Create a VPC with and IPv6 CIDR block (using either your own or Amazon's IPv6 address space) 2) Create an IPv6 only subnet by creating a new subnet and checking the "IPv6 Only" box 3) Create a Rocky Linux instance and associate it with the IPv6 capable VPC and the IPv6-only subnet. 4) After approximately 10 minutes, the instance will complete the boot process, but will have "1/2 checks passed" in the "Status Check" column, and "Instance reachability check failed" in the "Status Check" tab of the instance details section. 5) The box will not be connected to the network Let me know if you want more specific details. The main bit is to have an IPv6 only subnet.
Additional Information:	I compared the /usr/lib/python3.6/site-packages/cloudinit/util.py (82200 bytes) on a Rocky 8.6 instance in a dual stack subnet vs /usr/lib/python2.7/site-packages/cloudinit/util.py (92995 bytes) on the Amazon AMI instance in the IPv6 only subnet. The Amazon version is not only larger but has additional copyright and author lines, which indicate to me that they are likely using a later version. Fixing the IPv6-only boot problem may just be as simple as updating to a later version of the cloud-init packages. Though I don't know that for certain (I don't know a lot about creating AMIs), it seemed a reasonable place to start. I have attached the system logs from various attempts, including a working Amazon AMI instance log, and three logs from non-working Rocky AMI instances. Let me know if you want anything additional.
Attached Files:	Working-AWS-AMI.log (50,547 bytes) 2022-09-12 23:35 https://bugs.rockylinux.org/file_download.php?file_id=199&type=bug non-working-Rocky8.6-x86-64.log (65,535 bytes) 2022-09-12 23:35 https://bugs.rockylinux.org/file_download.php?file_id=200&type=bug non-working-Rocky9.0-x86-64.log (45,417 bytes) 2022-09-12 23:35 https://bugs.rockylinux.org/file_download.php?file_id=201&type=bug non-working-Rocky8.6-aarch64.log (26,956 bytes) 2022-09-12 23:35 https://bugs.rockylinux.org/file_download.php?file_id=202&type=bug

Notes
(0000595) Neil Hanlon 2022-09-28 23:12	Looking to identify/fix if necessary and release update early October

(0002212) Neil Hanlon 2023-01-24 06:43	Verified. Opened upstream bug at https://bugzilla.redhat.com/show_bug.cgi?id=2163657 Patch at https://git.rockylinux.org/sig/cloud/patch/cloud-init/-/blob/r8/ROCKY/_supporting/9998-Add-Ec2-IPV6-IMDS.patch Test RPM: https://yumrepofs.build.resf.org/v1/projects/f91da90d-5bdb-4cf2-80ea-e07f8dae5a5c/repo/cloud-common/x86_64/Packages/e063cd0a-9a23-48da-85cd-f0e384fa96a4/5172d99a3a893e63/cloud-init-22.1-5.el8.cloud.0.1.0.1.noarch.rpm Will need to build an AMI with this included to validate.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1882	[Rocky-Linux-9] cups-filters	minor	random	2023-01-20 11:35	2023-01-20 11:35

Reporter:	Roger Sewell	Platform:
Assigned To:		OS:	rockylinux
Priority:	normal	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Endless messages from cupsd "Expiring subscriptions..."
Description:	/var/log/messages is full of messages of the above form. RedHat have a "solution" to this (maybe) at https://access.redhat.com/solutions/6214421 but won't allow me to read it. Can anybody tell me what the solution is ? It's also slowing down the whole machine. It's been happening to some extent since upgrading to 9.0, continued at the same low level after upgrading to 9.1 in December, but in the last 5 days has got massively worse. Thanks, Roger.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1684	[Cloud] General	minor	always	2023-01-02 05:04	2023-01-19 21:14

Reporter:	Neil Hanlon	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	AWS AMIs are not available in every region due to AWS quotas
Description:	there is a limit on public AMIs per region (25), which we are over in some regions. We need to script requesting increases these limits
Tags:
Steps To Reproduce:	e.g https://forums.rockylinux.org/t/us-east-1-missing-aws-ami/8416
Additional Information:
Attached Files:

Notes
(0002179) Neil Hanlon 2023-01-19 21:14	https://git.resf.org/sig_core/toolkit/src/commit/94b964ec70e4ea70dadff9c2f9954e0db8728ece/mangle/quotas.go

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1816	[Rocky-Linux-9] kernel	block	always	2023-01-12 12:43	2023-01-17 01:58

Reporter:	Zhen Zhang	Platform:
Assigned To:	Louis Abel	OS:
Priority:	immediate	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	vfree bad address lead by LTP test case
Description:	[ 1603.716647] ------------[ cut here ]------------ [ 1603.722384] Trying to vfree() bad address (0000000019d05582) [ 1603.729282] WARNING: CPU: 188 PID: 1368 at mm/vmalloc.c:2608 __vunmap+0x24d/0x280 [ 1603.738219] Modules linked in: brd overlay exfat loop cuse fuse binfmt_misc bonding tls esp6_offload esp6 esp4_offload esp4 intel_rapl_msr intel_rapl_common i10nm_edac nfit libnvdimm x86_pkg_temp_thermal coretemp kvm_intel iTCO_wdt pmt_crashlog pmt_te lemetry iTCO_vendor_support pmt_class intel_sdsi kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel irdma vfat rap l i40e cdc_ether ib_uverbs acpi_ipmi xfs intel_cstate qat_4xxx fat usbnet libcrc32c isst_if_mmio isst_if_mbox_pci intel_qat idx d mei_me i2c_i801 ipmi_si ib_core pcspkr joydev crc8 mii isst_if_common intel_uncore idxd_bus intel_vsec mei i2c_smbus i2c_ismt sg ipmi_devintf ipmi_msghandler wmi acpi_power_meter pinctrl_emmitsburg ip_tables ext4 mbcache jbd2 sd_mod t10_pi ast i2c_algo _bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helper ttm ice ahci libahci drm crc32 c_intel libata [ 1603.830317] CPU: 188 PID: 1368 Comm: kworker/188:1 Kdump: loaded Tainted: G S --------- --- 5.14.0-3.0.0.kwai .x86_64 #1 [ 1603.844929] Hardware name: Nettrix C/B0EA32, BIOS 0.9.1 08/02/2022 [ 1603.852424] Workqueue: events free_work [ 1603.857300] RIP: 0010:__vunmap+0x24d/0x280 [ 1603.862464] Code: 41 5d 41 5e e9 c4 33 03 00 31 d2 31 f6 48 c7 c7 ff ff ff ff e8 a4 c7 ff ff eb b2 48 89 fe 48 c7 c7 c0 cb 1 6 a5 e8 de 4a 73 00 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 4c 89 e6 48 c7 c7 e8 [ 1603.884591] RSP: 0018:ff2b2fb61c3c7e58 EFLAGS: 00010282 [ 1603.891021] RAX: 0000000000000000 RBX: 0000000000000bc0 RCX: 0000000000000000 [ 1603.899594] RDX: ff266b58bfb26880 RSI: ff266b58bfb19ca0 RDI: ff266b58bfb19ca0 [ 1603.908165] RBP: 0000000000000001 R08: 0000000000000000 R09: c0000000fffeffff [ 1603.916748] R10: 0000000000000001 R11: ff2b2fb61c3c7c68 R12: ff266adae1983bc0 [ 1603.925333] R13: 0000000000000000 R14: ff266b58bfb2a840 R15: ff266b58bfb27af0 [ 1603.933925] FS: 0000000000000000(0000) GS:ff266b58bfb00000(0000) knlGS:0000000000000000 [ 1603.943596] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1603.950660] CR2: 0000000000d47e08 CR3: 0000005e26410006 CR4: 0000000000771ee0 [ 1603.951430] LTP: starting fpathconf01 [ 1603.959289] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1603.972664] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1603.981328] PKRU: 55555554 [ 1603.984998] Call Trace: [ 1603.988373] free_work+0x21/0x30 [ 1603.992636] process_one_work+0x1cb/0x370 [ 1603.997772] worker_thread+0x30/0x390 [ 1604.002534] ? process_one_work+0x370/0x370 [ 1604.007884] kthread+0x13e/0x160 [ 1604.012176] ? set_kthread_struct+0x50/0x50 [ 1604.017518] ret_from_fork+0x1f/0x30 [ 1604.022188] ---[ end trace dac80ad3ede3eeb8 ]--- [ 1604.028048] ------------[ cut here ]------------
Tags:	kernel，ltp, vfree
Steps To Reproduce:	LTP fork14 case or #include <stdio.h> #include <unistd.h> #include <sys/mman.h> #define GIG 1024 * 1024 * 1024L #define EXTENT 16393 int main(void) { int i, r; void m; char buf[1024]; for (i = 0; i < EXTENT; i++) { m = mmap(NULL, (size_t) 1 1024 * 1024 * 1024L, PROT_READ \| PROT_WRITE, MAP_PRIVATE \| MAP_ANONYMOUS, 0, 0); if (m == (void *)-1) printf("MMAP Failed: %d\n", m); else printf("%d : MMAP returned %p\n", i, m); r = fork(); if (r == 0) { printf("%d: successed\n", i); return 0; } else if (r < 0) printf("FORK Failed: %d\n", r); else if (r > 0) wait(NULL); } return 0; }
Additional Information:
Attached Files:

Notes
(0002113) Louis Abel 2023-01-14 06:06	Hello, thank you for the report. Unfortunately there is not enough details provided on this bug report, such as kernel version, resources, among other information. As you may be aware, we are a downstream distribution of RHEL and are unable to resolve issues like this ourselves. We can however assist in submitting a bug report upstream for you if it is reproducible and repeatable. Based on "5.14.0-3.0.0.kwai.x86_64", this appears to be a custom kernel. Is this a custom built kernel you are using? If so, this is unsupported. Can this "test case" be repeated on a current running 9.1 kernel successfully? If so, it could be possible to report the issue to red hat.

(0002146) Zhen Zhang 2023-01-17 01:58	Yes，it's can repeated on rocky 9.1 with kernel-5.14.0-162.6.1.el9_1.0.1.x86_64.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1849	[Containers] General	minor	always	2023-01-15 21:23	2023-01-15 21:23

Reporter:	Strahil Nikolov	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Mismatch between registry.redhat.io/ubi9 python rpm packages and rockylinux:9 causing SSL errors
Description:	Due to missing python3-requests in the rockylinux:9 container image, i get the following error: HTTPSConnectionPool(host='<REPLACED>', port=443): Max retries exceeded with url: <TRUNCATED> (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1129)'))) This is quite confusing and difficult to troubleshoot as yum/dnf use the certs added via 'update-ca-trust'. The RH's registry.redhat.io/ubi9 has 'python3-requests' preinstalled and the issue is missing there,so I think it's worth considering adding it into the rockylinux:8 and rockylinux:9 images.
Tags:
Steps To Reproduce:
Additional Information:	Issue is observed on both v8 and v9 images
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1783	[Rocky-Linux-9] tigervnc	major	sometimes	2023-01-09 18:40	2023-01-09 18:40

Reporter:	Lana Deere	Platform:	x86_64
Assigned To:		OS:	rocky linux
Priority:	normal	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	bash in gnome-terminal command line editing broken under vnc
Description:	I have 9.1 installed on one machine with a VNC server set up as a service. I connect to that server from a CentOS7.9 machine on the same LAN. I start some gnome-terminals or xterms. In some of the gnome-terminals or most of the xterms, thing like del or left-arrow update the screen incorrectly, making them more or less unusable. Also, some of the time the shell prompt after commands complete does not get printed. An extra "enter" will make the missing prompt and the second one show up. Note that if I use ssh -X instead to display the terminals and use them the same way, I do not get this problem, so it seems more related to VNC than to the terminal programs.
Tags:
Steps To Reproduce:	Create gnome-terminals under VNC in the configuration described above. Do software development fixing spelling errors, editing commands use left-arrow, etc. Usually at least one of the gnome-terminals will break in the first few minutes of use.
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1750	[Rocky-Linux-9] [Repo] Extras	minor	always	2023-01-05 13:32	2023-01-05 17:48

Reporter:	Andrew Bauer	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Package conflict between rpmfusion-free-release found in Rocky Extras and RPMFusion
Description:	NOTE: As far as I can tell, the following change came from Rocky Linux, rather than an upstream source. Please advise if this is not the case. Beginning with Rocky Linux 9, rpmfusion-free-release was built with the %{dist} tag in Release. https://dl.rockylinux.org/pub/rocky/9/extras/source/tree/Packages/r/rpmfusion-free-release-9-1.el9.src.rpm Note, however, this is a change from Rocky Linux 8, which does not include the release tag. https://dl.rockylinux.org/pub/rocky/8/extras/source/tree/Packages/r/rpmfusion-free-release-8-0.1.src.rpm Note that the RPMFusion team does NOT include the %{dist} tag in their package: https://github.com/rpmfusion/rpmfusion-free-release/blob/el9/rpmfusion-free-release.spec#L6 This has caused the following package conflict, when attempting to use the subpackage(s) currently hosted only at RPMFusion and not Rocky Linux: >$ sudo dnf update >Last metadata expiration check: 0:11:34 ago on Sat Dec 31 08:09:12 2022. >Error: > Problem: package rpmfusion-free-release-tainted-9-1.noarch requires rpmfusion-free-release = 9-1, but none of the providers can be installed > - cannot install both rpmfusion-free-release-9-1.el9.noarch and rpmfusion-free-release-9-1.noarch > - cannot install both rpmfusion-free-release-9-1.noarch and rpmfusion-free-release-9-1.el9.noarch > - cannot install the best update candidate for package rpmfusion-free-release-tainted-9-1.noarch > - cannot install the best update candidate for package rpmfusion-free-release-9-1.noarch >(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) To avoid this issue both now and in the future, I would suggest building the rpmfusion-free package without making any changes to the upstream specfile, no matter how trivial. Would the Rocky team also include all subpackages (tainted and next) found within said specfile. Thank you.
Tags:
Steps To Reproduce:	1) dnf install rpmfusion-free-release (from Rocky Extras repo) 2) dnf install rpmfusion-free-release-tainted (from the RPMFusion repo) 3) dnf update
Additional Information:	In case you were wondering why RPMFusion does not build rpmfusion-free-release with the %{dist} macro in Release, I asked the same question and was told they are unwilling to change. See: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6545
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1751	[Desktop] General	major	always	2023-01-05 15:16	2023-01-05 15:16

Reporter:	Eric F	Platform:	Linux
Assigned To:		OS:	ocky Linux 8
Priority:	normal	OS Version:	8.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	RRL8 Xfce, segfault in Mousepad
Description:	The Xfce program “Mousepad” has a really strange behaviour in RL8. Well, it works fine - but, as soon as you scroll, using the mouse-wheel, like just 1 click… The window closes/app quits. Output in `dmesg`: [102290.530497] mousepad[82346]: segfault at 0 ip 0000000000000000 sp 00007ffc7785cf08 error 14 in mousepad[5581a9b42000+1000] [102290.530534] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. // Very annoying, when scrollling is kind of a muscle memory thing. :) - - - Since I installed RL8, using the Xfce version - I don't know if this is related to that RL Xfce-iso creation, or (prob) how Mousepad was built for epel. But I thought it's better to start here, and you can push it upwards, if needed. Best regards, · Eric
Tags:
Steps To Reproduce:
Additional Information:
System Description	Distro: Rocky Linux 8.7 (Xfce) Kernel: 4.18.0-425.3.1.el8.x86_64
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1717	[Cloud] General	tweak	always	2023-01-04 13:18	2023-01-05 09:55

Reporter:	Grzegorz Koper	Platform:
Assigned To:		OS:
Priority:	low	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky--GenericCloud-Base and Rocky--GenericCloud-LVM should use cloud-init instead of rocky user.
Description:	Hi, After installing latest Cloud based images I've noticed that "cloud-user" is being replaced by "rocky" user. ``` # rocky cloud user echo -e 'rocky\tALL=(ALL)\tNOPASSWD: ALL' >> /etc/sudoers sed -i 's/name: cloud-user/name: rocky/g' /etc/cloud/cloud.cfg ``` in https://git.rockylinux.org/rocky/kickstarts/-/blob/r9/Rocky-9-GenericCloud-Base.ks Following the discussions and changes here: https://github.com/canonical/cloud-init/pull/1639, https://github.com/canonical/cloud-init/pull/1887 I was hoping to see Rocky also be treated the same as other RHEL family distributions. Is there any reasoning for this change ? Could this be normalised ?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0002014) Neil Hanlon 2023-01-04 16:43	Hi, Thanks for the report! The discussion in the linked PR for cloud-init actually is a bit different; the choice was made to _not_ change the user to cloud-user, as that would affect all other Distros. The intent of the PR was only to fix a breakage, but keep everything else (largely) the same. I am not against looking into defaulting to cloud-user, but that is something I think we'll need to also discuss with other distributions that would be affected. Best, Neil

(0002047) Louis Abel 2023-01-05 00:22	Hello. I am the one who submitted the PR for cloud-init (1887). The change was to fix a problem that was caused by Red Hat that unfortunately hurt the configuration for EL derivatives that weren't RHEL or CentOS. And like Neil said, it keeps everything largely the same. As for the reasoning we've changed cloud-user to rocky, this was done for a couple of reasons: 1) Convenience 2) Users were already used to CentOS doing this before (changing cloud-user to centos) in their images We have always changed "cloud-user" to "rocky" on our cloud images via the kickstarts since our first release. If folks want to make their own custom generic images (based on our kickstarts or making their own), they can avoid changing cloud-user to rocky if they wish to. The images are out of convenience as well, but we keep all the kickstarts available for others to see how they're made but also to make their own if they wish to. From my POV, changing from our standard (rocky) to the cloud-init default (cloud-user) would create more issues than resolve for our users and hosting providers who have relied on our images. Changing it would likely cause confusion and a lot of noise (and endless requests to change it back).

(0002080) Grzegorz Koper 2023-01-05 09:55	Hey, Thanks for clarification and some context on mentioned changes. I should have been more clear. We build our cloud images using Disk Image Builder. Its using rocky-container element, which didn't change. Previously built images came with default cloud-init user. Image created_at \| 2022-11-08T12:14:10Z [cloud-user@gkoper-rocky-previous home]$ ls -latr total 12 drwxr-xr-x. 18 root root 4096 Jan 5 09:42 .. drwxr-xr-x. 3 root root 4096 Jan 5 09:42 . drwx------. 3 cloud-user cloud-user 4096 Jan 5 09:43 cloud-user Currently Image created_at \| 2022-11-28T13:22:47Z $ ssh cloud-user@10.0.3.163 The authenticity of host '10.0.3.163 (10.0.3.163)' can't be established. ECDSA key fingerprint is SHA256:i4ElHbym6njoD+E3rLCCXGR+pfbL5fPjt13AaQvGVsI. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.0.3.163' (ECDSA) to the list of known hosts. cloud-user@10.0.3.163: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). $ ssh rocky@10.0.3.163 [rocky@gkoper-rocky-current ~]$ [rocky@gkoper-rocky-current ~]$ cd /home [rocky@gkoper-rocky-current home]$ ls -latr total 12 drwxr-xr-x. 18 root root 4096 Jan 5 09:46 .. drwxr-xr-x. 3 root root 4096 Jan 5 09:46 . drwx------. 3 rocky rocky 4096 Jan 5 09:46 rocky [rocky@gkoper-rocky-current home]$ Something must have changed with the container being used with rocky-container element. Personally I think cloud-init seems reasonable default for all distributions that use cloud-init.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1618	[Rocky-Linux-9] clang	minor	N/A	2022-12-29 03:41	2022-12-29 03:48

Reporter:	Aliaksandr Zaitsau	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Build Clang with PGO
Description:	LLVM supports building Clang with PGO (https://llvm.org/docs/HowToBuildWithPGO.html). Using PGO for compilers has a huge impact on compiler performance. E.g. many distros are already building GCC (which also supports PGO builds) with PGO. I think for the users would be beneficial to have faster Clang binaries. Locally I usually build my own Clang version. According to my tests, it could bring up to 20% performance. Additionally, you could consider using LLVM BOLT as an additional optimization step, but I guess it should be discussed in another issue after the PGO implementation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0001948) Louis Abel 2022-12-29 03:48	Thank you for the report. This something we don't control. Ultimately upstream (red hat) would be the ones that would need to make this call. I would suggest opening a bug report as bugzilla.redhat.com (as you've done with Fedora https://bugzilla.redhat.com/show_bug.cgi?id=2156679) against CentOS Stream 9 if you wish to see pgo in Rocky Linux.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1585	[Rocky-Linux-9] NetworkManager	minor	always	2022-12-26 02:39	2022-12-26 02:39

Reporter:	Neel Chauhan	Platform:
Assigned To:		OS:
Priority:	high	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	"Manual" IPv4 and "Automatic" IPv6: no IPv6 address assigned
Description:	On Rocky Linux 9.1's NetworkManager, I normally use a "manual" static IPv4 address and an "automatic" IPv6 address. This is mainly since on residential ISPs, we don't get static IPv6 on most ISPs but IPv4 NAT is still static nevertheless. If I use "manual" IPv4 and "automatic" IPv6, I get no IPv6 address via SLAAC or DHCP. However, if I use "automatic" IPv4 and IPv6, I get both assigned. Even if a manual IPv4 is also set alongside automatic, I still get an IPv6, albeit with both static and DHCP v4.
Tags:
Steps To Reproduce:	1. Install Rocky 9.1 with minimal install. 2. Set up bridge 3. Set IP addresses on bridge, with "manual" and static IPv4 and "automatic" IPv6 4. Reboot 5. Only IPv4 on bridge interface with `ip addr`
Additional Information:	This is on a i7-12700 'server' and an Intel X550-T1 10 Gigabit NIC. My router runs OPNsense on a quad-port Chinese firewall box, and my ISP is CenturyLink using GPON/fiber and 6rd. This happens if I configure a bridge, which I use for virtual machines. Workaround: add a DHCP reservation on my OPNsense box to my static address. openSUSE Tumbleweed/Leap didn't have this issue with bridge and NM, even with the same OPNsense box. However, I'm switching to Rocky mainly due to the uncertainty around SUSE's ALP plan.
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1552	[Containers] General	minor	always	2022-12-17 02:05	2022-12-17 02:05

Reporter:	Louis Abel	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Vagrant images are only UEFI bootable
Description:	Some vagrant images seem to be UEFI only bootable. This bug is to track the new images that should be built to resolve it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1420	[Rocky-Linux-9] General	crash	always	2022-12-12 12:25	2022-12-12 16:01

Reporter:	Mark Stamos	Platform:	HP OMEN
Assigned To:		OS:	Rocky 9.1
Priority:	normal	OS Version:	9.1
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	sddm does not allow login
Description:	With a fresh install of Rocky 9.1 I attempt to install Plasma. This worked with 9.0 (instructions found on the web). All goes without error. Upon reboot after disabling gdm and enabling sddm, keyboard input is not possible. Randomly, the mouse may or may not move the cursor but even if the cursor moves clicking has no effect. Plasma was working fine on 9.0 but accepting the upgrade to 9.1 broke everything. Prior to 9.0 I was using Rocky 8.5 with plasma. I will attempt an install of 8.7 to see if that works. It would be nice if plasma was an option at install time so there would not be all these hoops to jump through to get a decent desktop.
Tags:
Steps To Reproduce:	Here are the commands used to install plasma. 2 dnf -y install epel-release 3 dnf config-manager --set-enabled crb 4 dnf -y update 5 dnf group -y install "KDE Plasma Workspaces" 10 sudo systemctl disable gdm 11 sudo systemctl enable sddm ---REBOOT
Additional Information:	Switching to another terminal I notice many messages involving the nouveau display driver. In a second attempt I installed the nvidia driver for my card. With that driver installed sddm does not even get activated. I am enabling sddm so that I can choose plasma. 01:00.0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3712 Flags: bus master, fast devsel, latency 0, IRQ 167 Memory at b3000000 (32-bit, non-prefetchable) [size=16M] Memory at a0000000 (64-bit, prefetchable) [size=256M] Memory at b0000000 (64-bit, prefetchable) [size=32M] I/O ports at 4000 [size=128] Expansion ROM at b4000000 [virtual] [disabled] [size=512K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Legacy Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [250] Latency Tolerance Reporting Capabilities: [258] L1 PM Substates Capabilities: [128] Power Budgeting <?> Capabilities: [420] Advanced Error Reporting Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1288	[Rocky-Linux-9] nginx	major	always	2022-12-03 19:44	2022-12-09 17:43

Reporter:	Stanis Trendelenburg	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Nginx package installs a broken logrotate configuration
Description:	When installing the nginx package via dnf, the default logrotate configuration that is installed alongside does not work, because the permissions on the log directory /var/log/nginx are too strict. This results in logs not being rotated properly: New logfiles are being created by logrotate, but nginx keeps writing to the old logfile(s). The directory /var/log/nginx is owned by user root, group root and has permissions "drwx------" (chmod 700). The main nginx process runs as root, but the worker processes run as the "nginx" user. The way nginx rotates logfiles is described here: https://nginx.org/en/docs/control.html#logs To rotate the logfiles, logrotate sends USR1 to the main process (this is correct). As described in the docs linked above, the main process then instructs the workers to reopen their log files, after making sure the logfiles belong to the nginx user. However, because of the restricitve permission on the parent directory, the workers cannot open the files. These lines appear in the main nginx error log (/var/log/nginx/error.log) after each log rotation: 2022/12/03 19:27:47 [emerg] 1110#1110: open() "/var/log/nginx/error.log" failed (13: Permission denied) 2022/12/03 19:27:47 [emerg] 1110#1110: open() "/var/log/nginx/access.log" failed (13: Permission denied) Suggestion: Change the permssions of the directory /var/log/nginx to this: user root, group nginx, chmod 710 (+x permission for group nginx). This is the minimal set of permissions required to make logrotate work.
Tags:
Steps To Reproduce:	I've uploaded a script here to reproduce the issue on a minimal Rocky 9 installation: https://gist.github.com/trendels/b72b8ebd87fabaddd27fa6ad5b859541 The script removes and re-installs nginx, sends an HTTP request to localhost, runs logrotate, and then sends another HTTP request. After this you can see that nginx keeps appending its logs to the same log file (the file created by logrotate stays at size 0).
Additional Information:
Attached Files:

Notes
(0001585) Stanis Trendelenburg 2022-12-03 20:05	For comparison, I also tested with the nginx package from the nginx.org repo: https://nginx.org/en/linux_packages.html#RHEL With this package log rotation works, the permission of /var/log/nginx are set to root:root, chmod 755

(0001684) Stanis Trendelenburg 2022-12-09 17:43	This bug was fixed a while ago in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1966367

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1123	[Rocky-Linux-9] kernel	major	always	2022-11-27 17:11	2022-11-29 21:33

Reporter:	Louis Abel	Platform:
Assigned To:	Sherif Nagy	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	9.1
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9.1
		Target Version:	9.1

Summary:	Kernel packages contain files with incorrect versions such as 600 instead of 644
Description:	x86_64 kernel built in the secure environment has produced packages that contain files with incorrect permissions such as 600, which make it difficult for users to properly build against the kernel sources.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0001321) Sherif Nagy 2022-11-28 23:22	New kernel has been built and being imported now, the problem should "hopefully" based on my quick test be fixed!

(0001356) Louis Abel 2022-11-29 21:33	5.14.0-162.6.1.el9_1.0.1.x86_64

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1156	[Rocky-Linux-9] chrony	major	always	2022-11-29 01:39	2022-11-29 02:06

Reporter:	Mike Ely	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	chrony-wait fails after upgrade from chrony-4.1-3 to 4.2-1
Description:	After upgrading chrony, the chrony-wait service enters a failed state and will not recover. # systemctl status chrony-wait × chrony-wait.service - Wait for chrony to synchronize system clock Loaded: loaded (/usr/lib/systemd/system/chrony-wait.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2022-11-28 17:21:09 PST; 8s ago Docs: man:chronyc(1) Process: 2657690 ExecStart=/usr/bin/chronyc -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1 (code=exited, status=217/USER) Main PID: 2657690 (code=exited, status=217/USER) CPU: 20ms Nov 28 17:21:09 server.example systemd[1]: Starting Wait for chrony to synchronize system clock... Nov 28 17:21:09 server.example systemd[2657690]: chrony-wait.service: Failed to set up user namespacing: No space left on device Nov 28 17:21:09 server.example systemd[2657690]: chrony-wait.service: Failed at step USER spawning /usr/bin/chronyc: No space left on device Nov 28 17:21:09 server.example systemd[1]: chrony-wait.service: Main process exited, code=exited, status=217/USER Nov 28 17:21:09 server.example systemd[1]: chrony-wait.service: Failed with result 'exit-code'. Nov 28 17:21:09 server.example systemd[1]: Failed to start Wait for chrony to synchronize system clock.
Tags:
Steps To Reproduce:	Check status of chrony-wait, observe that it is running and that chrony-4.1-3.el9.rocky.0.1.x86_64 is installed. "dnf in chrony" Observe that chrony-4.2-1.el9.rocky.1.0.x86_64.rpm is installed. Check status of chrony-wait, observe that it has failed as in the bug description.
Additional Information:	I have tried: Rebooting the host Setting selinux to permissive Verifying that plenty of free disk space exists. Merging any item that's enabled by default and can safely be merged from /etc/chrony.conf.rpmnew: ntsdumpdir /var/lib/chrony logdir /var/log/chrony Verified the existence of both paths above.
Attached Files:

Notes
(0001322) Mike Ely 2022-11-29 02:06	Setting max_user_namespaces to a nonzero value allows the service to start, but this is in conflict with the guidance issued to address CVE-2022-1015. As that issue appears to have been resolved, this is more of an errata IMHO.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1090	[Rocky-Linux-9] conntrack-tools	minor	always	2022-11-25 19:37	2022-11-25 19:37

Reporter:	Jacek Tomasiak	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	conntrack tools fail to add "unknown" protocol entries
Description:	Between version 1.4.4 and 1.4.5 of conntrack-tools (1.0.7 and 1.0.8 of libnetfilter_conntrack) upstream switched from libnfnetlink to libmnl for building and parsing netlink messages. This introduced regression in handling entries with protocols which are not natively supported by conntrack (e.g. igmp). Trying to create such entries resulted in "Operation failed: invalid parameters" errors. Upstream fix for this problem is already available at https://git.netfilter.org/libnetfilter_conntrack/commit/src/conntrack/build_mnl.c?id=45ec4b51e8290759e0d87d9405965be1352a4325
Tags:
Steps To Reproduce:	$ sudo conntrack -I -s 192.168.1.9 -d 101.168.1.9 -t 300 -p igmp expected output: conntrack v1.4.5 (conntrack-tools): 1 flow entries have been created. actual output: conntrack v1.4.5 (conntrack-tools): Operation failed: invalid parameters
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1057	[Rocky-Linux-8] rng-tools	minor	have not tried	2022-11-23 09:30	2022-11-25 14:55

Reporter:	Robert Sjöblom	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	rngd.service sometimes fails on upgrade from Rocky 8.6 to 8.7
Description:	On dnf update from 8.6 to 8.7, there appears to be an SELinux dependency problem for rngd. This is causing the service to fail since it appears to be updated before the SELinux package. From syslog: messages:Nov 23 06:10:28 hostname dracut[58625]: * Including module: rngd * messages:Nov 23 06:10:43 hostname rngd[1084]: [rdrand]: Shutting down messages:Nov 23 06:10:43 hostname rngd[1084]: [jitter]: Shutting down messages:Nov 23 06:10:43 hostname systemd[1]: rngd.service: Succeeded. messages:Nov 23 06:10:43 hostname rngd[63797]: Disabling 7: PKCS11 Entropy generator (pkcs11) messages:Nov 23 06:10:43 hostname rngd[63797]: Disabling 5: NIST Network Entropy Beacon (nist) messages:Nov 23 06:10:43 hostname rngd[63797]: User 'daemon' not found messages:Nov 23 06:10:43 hostname systemd[1]: rngd.service: Main process exited, code=exited, status=1/FAILURE messages:Nov 23 06:10:43 hostname systemd[1]: rngd.service: Failed with result 'exit-code'. messages:Nov 23 06:10:46 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from search access on the directory /var/lib/sss/mc/passwd. For complete SELinux messages run: sealert -l 3ca404aa-47da-4f94-959b-35d41eceaf96 messages:Nov 23 06:10:46 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from search access on the directory /var/lib/sss/mc/passwd.#012#012*** Plugin restorecon (99.5 confidence) suggests ********************#012#012If you want to fix the label. #012/var/lib/sss/mc/passwd default label should be sssd_public_t.#012Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.#012Do#012# /sbin/restorecon -v /var/lib/sss/mc/passwd#012#012* Plugin catchall (1.49 confidence) suggests **********************#012#012If you believe that rngd should be allowed search access on the passwd directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rngd' --raw \| audit2allow -M my-rngd#012# semodule -X 300 -i my-rngd.pp#012 messages:Nov 23 06:10:46 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from search access on the directory /var/lib/sss/mc/passwd. For complete SELinux messages run: sealert -l 3ca404aa-47da-4f94-959b-35d41eceaf96 messages:Nov 23 06:10:46 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from search access on the directory /var/lib/sss/mc/passwd.#012#012* Plugin restorecon (99.5 confidence) suggests ********************#012#012If you want to fix the label. #012/var/lib/sss/mc/passwd default label should be sssd_public_t.#012Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.#012Do#012# /sbin/restorecon -v /var/lib/sss/mc/passwd#012#012* Plugin catchall (1.49 confidence) suggests **********************#012#012If you believe that rngd should be allowed search access on the passwd directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rngd' --raw \| audit2allow -M my-rngd#012# semodule -X 300 -i my-rngd.pp#012 messages:Nov 23 06:10:47 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from search access on the directory /var/lib/sss/pipes/nss. For complete SELinux messages run: sealert -l 3ca404aa-47da-4f94-959b-35d41eceaf96 messages:Nov 23 06:10:47 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from search access on the directory /var/lib/sss/pipes/nss.#012#012* Plugin restorecon (99.5 confidence) suggests ********************#012#012If you want to fix the label. #012/var/lib/sss/pipes/nss default label should be sssd_public_t.#012Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.#012Do#012# /sbin/restorecon -v /var/lib/sss/pipes/nss#012#012* Plugin catchall (1.49 confidence) suggests **********************#012#012If you believe that rngd should be allowed search access on the nss directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rngd' --raw \| audit2allow -M my-rngd#012# semodule -X 300 -i my-rngd.pp#012 messages:Nov 23 06:10:47 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from read access on the file /etc/passwd. For complete SELinux messages run: sealert -l 2ab94b3a-95dc-466c-a32d-5162e4b6a8f3 messages:Nov 23 06:10:47 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from read access on the file /etc/passwd.#012#012* Plugin catchall (100. confidence) suggests **********************#012#012If you believe that rngd should be allowed read access on the passwd file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rngd' --raw \| audit2allow -M my-rngd#012# semodule -X 300 -i my-rngd.pp#012 messages:Nov 23 06:10:47 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from search access on the directory /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l d16511fa-16aa-4e70-a0a9-8125f4b8d336 messages:Nov 23 06:10:47 hostname setroubleshoot[63801]: SELinux is preventing /usr/sbin/rngd from search access on the directory /run/dbus/system_bus_socket.#012#012* Plugin catchall (100. confidence) suggests ************************#012#012If you believe that rngd should be allowed search access on the system_bus_socket directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rngd' --raw \| audit2allow -M my-rngd#012# semodule -X 300 -i my-rngd.pp#012 From dnf.rpm.log: 2022-11-23T06:09:56+0100 SUBDEBUG Upgrade: rng-tools-6.15-1.el8.x86_64 2022-11-23T06:10:43+0100 SUBDEBUG Upgraded: rng-tools-6.14-6.git.b2b7934e.el8_6.x86_64 ... 2022-11-23T06:12:47+0100 SUBDEBUG Upgraded: ipa-selinux-4.9.8-8.module+el8.6.0+1050+4989852e.noarch 2022-11-23T06:12:47+0100 SUBDEBUG Upgraded: rpm-plugin-selinux-4.14.3-24.el8_6.x86_64 2022-11-23T06:12:47+0100 SUBDEBUG Upgraded: selinux-policy-targeted-3.14.3-95.el8_6.4.noarch 2022-11-23T06:12:48+0100 SUBDEBUG Upgraded: selinux-policy-3.14.3-95.el8_6.4.noarch 2022-11-23T06:12:50+0100 SUBDEBUG Upgraded: python3-libselinux-2.9-5.el8.x86_64 2022-11-23T06:12:50+0100 SUBDEBUG Upgraded: libselinux-utils-2.9-5.el8.x86_64 2022-11-23T06:13:01+0100 SUBDEBUG Upgraded: libselinux-2.9-5.el8.x86_64 Here we can see rng-tools are upgraded before SELinux package.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0001222) Robert Sjöblom 2022-11-23 09:30	Restarting rngd after package SELinux has been upgraded succeeds

(0001255) Robert Sjöblom 2022-11-24 08:52	In some cases, restarting rngd fails with "can't find user daemon"; rngd is prevented from reading the file by selinux. Solution is to reinstall selinux-policy package, then restart rngd.

(0001256) Louis Abel 2022-11-24 09:39	I am unable to replicate this issue. After patching and rebooting an 8.6 system, rngd starts up as expected and there are no selinux errors. Reinstalling the selinux-policy package leads me to believe there's either a configuration issue or there is possibly an edge case you've ran into. Can you provide your entire dnf.rpm.log of the day you ran dnf update? [root@router scsi]# uname -r 4.18.0-372.26.1.el8_6.x86_64 [root@router scsi]# dnf update -y -q [root@router scsi]# rpm -q rng-tools rng-tools-6.15-1.el8.x86_64 [root@router scsi]# rpm -q selinux-policy selinux-policy-3.14.3-108.el8.noarch [root@router scsi]# systemctl status rngd ● rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2022-11-15 11:06:42 MST; 1 weeks 1 days ago Main PID: 333967 (rngd) Tasks: 5 (limit: 409620) Memory: 1.9M CGroup: /system.slice/rngd.service └─333967 /usr/sbin/rngd -f --fill-watermark=0 -x pkcs11 -x nist -D daemon:daemon Nov 15 11:06:42 router systemd[1]: Started Hardware RNG Entropy Gatherer Daemon. Nov 15 11:06:42 router rngd[333967]: Disabling 7: PKCS11 Entropy generator (pkcs11) Nov 15 11:06:42 router rngd[333967]: Disabling 5: NIST Network Entropy Beacon (nist) Nov 15 11:06:42 router rngd[333967]: Initializing available sources Nov 15 11:06:42 router rngd[333967]: [hwrng ]: Initialized Nov 15 11:06:42 router rngd[333967]: [rdrand]: Initialization Failed Nov 15 11:06:42 router rngd[333967]: [jitter]: Initializing AES buffer Nov 15 11:06:47 router rngd[333967]: [jitter]: Enabling JITTER rng support Nov 15 11:06:47 router rngd[333967]: [jitter]: Initialized Nov 15 11:06:47 router rngd[333967]: Process privileges have been dropped to 2:2 [root@router scsi]# init 6 [root@router ~]# systemctl status rngd ● rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-11-24 02:15:32 MST; 1min 15s ago Main PID: 1537 (rngd) Tasks: 5 (limit: 409712) Memory: 6.5M CGroup: /system.slice/rngd.service └─1537 /usr/sbin/rngd -f --fill-watermark=0 -x pkcs11 -x nist -D daemon:daemon Nov 24 02:15:32 router systemd[1]: Started Hardware RNG Entropy Gatherer Daemon. Nov 24 02:15:32 router rngd[1537]: Disabling 7: PKCS11 Entropy generator (pkcs11) Nov 24 02:15:32 router rngd[1537]: Disabling 5: NIST Network Entropy Beacon (nist) Nov 24 02:15:32 router rngd[1537]: Initializing available sources Nov 24 02:15:32 router rngd[1537]: [hwrng ]: Initialized Nov 24 02:15:32 router rngd[1537]: [rdrand]: Initialization Failed Nov 24 02:15:32 router rngd[1537]: [jitter]: Initializing AES buffer Nov 24 02:15:37 router rngd[1537]: [jitter]: Enabling JITTER rng support Nov 24 02:15:37 router rngd[1537]: [jitter]: Initialized Nov 24 02:15:37 router rngd[1537]: Process privileges have been dropped to 2:2 [root@router ~]# audit2why < /var/log/audit/audit.log [root@router ~]# [root@router ~]# grep -En 'rng\|selinux' /tmp/dnf.rpm.log 5:2022-11-24T01:56:03-0700 SUBDEBUG Upgrade: libselinux-2.9-6.el8.x86_64 44:2022-11-24T01:56:08-0700 SUBDEBUG Upgrade: libselinux-utils-2.9-6.el8.x86_64 95:2022-11-24T01:56:19-0700 SUBDEBUG Upgrade: libselinux-devel-2.9-6.el8.x86_64 144:2022-11-24T01:57:05-0700 SUBDEBUG Upgrade: python3-libselinux-2.9-6.el8.x86_64 196:2022-11-24T01:57:21-0700 SUBDEBUG Upgrade: rpm-plugin-selinux-4.14.3-24.el8_7.x86_64 197:2022-11-24T01:57:21-0700 SUBDEBUG Upgrade: selinux-policy-3.14.3-108.el8.noarch 198:2022-11-24T01:57:39-0700 SUBDEBUG Upgrade: selinux-policy-targeted-3.14.3-108.el8.noarch 247:2022-11-24T01:58:38-0700 SUBDEBUG Upgrade: ipa-selinux-4.9.10-3.module+el8.7.0+1074+aae18f3a.noarch 398:2022-11-24T02:05:30-0700 SUBDEBUG Upgrade: rng-tools-6.15-1.el8.x86_64 522:2022-11-24T02:06:20-0700 SUBDEBUG Upgraded: libselinux-devel-2.9-5.el8.x86_64 540:2022-11-24T02:06:22-0700 SUBDEBUG Upgraded: ipa-selinux-4.9.8-6.module+el8.6.0+797+07647629.noarch 582:2022-11-24T02:06:42-0700 SUBDEBUG Upgraded: rng-tools-6.14-6.git.b2b7934e.el8_6.x86_64 814:2022-11-24T02:08:36-0700 SUBDEBUG Upgraded: rpm-plugin-selinux-4.14.3-24.el8_6.x86_64 815:2022-11-24T02:08:36-0700 SUBDEBUG Upgraded: selinux-policy-targeted-3.14.3-95.el8_6.4.noarch 816:2022-11-24T02:08:37-0700 SUBDEBUG Upgraded: selinux-policy-3.14.3-95.el8_6.4.noarch 842:2022-11-24T02:08:39-0700 SUBDEBUG Upgraded: python3-libselinux-2.9-5.el8.x86_64 848:2022-11-24T02:08:39-0700 SUBDEBUG Upgraded: libselinux-utils-2.9-5.el8.x86_64 910:2022-11-24T02:08:56-0700 SUBDEBUG Upgraded: libselinux-2.9-5.el8.x86_64

(0001288) Robert Sjöblom 2022-11-25 14:55	We've only seen this issue on a few of the servers in the fleet, namely the postgres servers. We're currently running ~900 postgres servers, out of ~1600 machines total. Around 10 of them have been affected by this issue, so it seems likely that it's an edge condition of some kind. We use ansible to configure all our servers, and so they should be exactly similar in configuration. The servers we have seen this issue on were initially installed with CentOS 8, and later converted to Rocky using Rocky's conversion script. It's possible that it's related, but it's also a fact that the large majority of servers are in this state. We have much fewer new servers with a clean Rocky 8 install. When looking into the dnf rpm log during the upgrade window, we found an SELinux policy error due to a memory allocation failure. 2022-11-24T05:43:00+0100 SUBDEBUG Upgrade: selinux-policy-targeted-3.14.3-108.el8.noarch 2022-11-24T05:43:38+0100 INFO SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.31: Cannot allocate memory 2022-11-24T05:43:38+0100 SUBDEBUG Upgrade: sssd-dbus-2.7.3-4.el8_7.1.x86_64 The system journal at the same time shows the following: Nov 24 05:43:37 hostname kernel: load_policy: page allocation failure: order:4, mode:0x60c0c0(GFP_KERNEL\|__GFP_COMP\|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 Nov 24 05:43:37 hostname kernel: CPU: 1 PID: 2351056 Comm: load_policy Kdump: loaded Not tainted 4.18.0-372.9.1.el8.x86_64 #1 Nov 24 05:43:37 hostname kernel: Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Nov 24 05:43:37 hostname kernel: Call Trace: Nov 24 05:43:37 hostname kernel: dump_stack+0x41/0x60 Nov 24 05:43:37 hostname kernel: warn_alloc.cold.119+0x7b/0x111 Nov 24 05:43:37 hostname kernel: ? _cond_resched+0x15/0x30 Nov 24 05:43:37 hostname kernel: ? __alloc_pages_direct_compact+0x157/0x160 Nov 24 05:43:37 hostname kernel: __alloc_pages_slowpath+0xc7e/0xcc0 Nov 24 05:43:37 hostname kernel: ? type_read+0x160/0x160 Nov 24 05:43:37 hostname kernel: __alloc_pages_nodemask+0x2db/0x310 Nov 24 05:43:37 hostname kernel: kmalloc_order+0x28/0x90 Nov 24 05:43:37 hostname kernel: kmalloc_order_trace+0x1d/0xa0 Nov 24 05:43:37 hostname kernel: ? type_read+0x160/0x160 Nov 24 05:43:37 hostname kernel: __kmalloc+0x1ff/0x250 Nov 24 05:43:37 hostname kernel: ? type_read+0x160/0x160 Nov 24 05:43:37 hostname kernel: hashtab_init+0x5d/0x80 Nov 24 05:43:37 hostname kernel: policydb_read+0x2e3/0x1230 Nov 24 05:43:37 hostname kernel: security_load_policy+0xa8/0x5e0 Nov 24 05:43:37 hostname kernel: ? copy_user_generic_unrolled+0x32/0xc0 Nov 24 05:43:37 hostname kernel: sel_write_load+0xde/0x1a0 Nov 24 05:43:37 hostname kernel: vfs_write+0xa5/0x1a0 Nov 24 05:43:37 hostname kernel: ksys_write+0x4f/0xb0 Nov 24 05:43:37 hostname kernel: do_syscall_64+0x5b/0x1a0 Nov 24 05:43:37 hostname kernel: entry_SYSCALL_64_after_hwframe+0x65/0xca Nov 24 05:43:37 hostname kernel: RIP: 0033:0x7fa9bd1f2bc8 Nov 24 05:43:37 hostname kernel: Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 4b 2a 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 Nov 24 05:43:37 hostname kernel: RSP: 002b:00007ffe2428f228 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 Nov 24 05:43:37 hostname kernel: RAX: ffffffffffffffda RBX: 00007ffe2428f230 RCX: 00007fa9bd1f2bc8 Nov 24 05:43:37 hostname kernel: RDX: 0000000000833419 RSI: 00007fa9af240000 RDI: 0000000000000004 Nov 24 05:43:37 hostname kernel: RBP: 0000000000000004 R08: 000055cc2d2e22a0 R09: 00007fa9bd252d40 Nov 24 05:43:37 hostname kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9af240000 Nov 24 05:43:37 hostname kernel: R13: 0000000000833419 R14: 000000000000000f R15: 0000000000000003 Nov 24 05:43:37 hostname kernel: Mem-Info: Nov 24 05:43:37 hostname kernel: active_anon:17640 inactive_anon:182469 isolated_anon:0 active_file:812856 inactive_file:1292224 isolated_file:0 unevictable:0 dirty:6 writeback:0 slab_reclaimable:170338 slab_unreclaimable:66719 mapped:57643 shmem:41017 pagetables:4920 bounce:0 free:135449 free_pcp:0 free_cma:0 Nov 24 05:43:37 hostname kernel: Node 0 active_anon:70560kB inactive_anon:729876kB active_file:3251424kB inactive_file:5168896kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:230572kB dirty:24kB writeback:0kB shmem:164068kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 12288kB writeback_tmp:0kB kernel_stack:8400kB pagetables:19680kB all_unreclaimable? no Nov 24 05:43:37 hostname kernel: Node 0 DMA free:13312kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Nov 24 05:43:37 hostname kernel: lowmem_reserve[]: 0 2768 15745 15745 15745 Nov 24 05:43:37 hostname kernel: Node 0 DMA32 free:434312kB min:11972kB low:14964kB high:17956kB active_anon:7344kB inactive_anon:347200kB active_file:655228kB inactive_file:936252kB unevictable:0kB writepending:16kB present:3129152kB managed:2867008kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Nov 24 05:43:37 hostname kernel: lowmem_reserve[]: 0 0 12977 12977 12977 Nov 24 05:43:37 hostname kernel: Node 0 Normal free:94172kB min:55544kB low:69428kB high:83312kB active_anon:63216kB inactive_anon:382852kB active_file:2596196kB inactive_file:4232836kB unevictable:0kB writepending:8kB present:13631488kB managed:13297412kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Nov 24 05:43:37 hostname kernel: lowmem_reserve[]: 0 0 0 0 0 Nov 24 05:43:37 hostname kernel: Node 0 DMA: 04kB 08kB 016kB 032kB 064kB 0128kB 0256kB 0512kB 11024kB (U) 22048kB (UM) 24096kB (M) = 13312kB Nov 24 05:43:37 hostname kernel: Node 0 DMA32: 240384kB (UME) 220938kB (UME) 955116kB (UME) 29332kB (UME) 064kB 0128kB 0256kB 0512kB 01024kB 02048kB 04096kB = 435088kB Nov 24 05:43:37 hostname kernel: Node 0 Normal: 82674kB (UMEH) 11928kB (UMEH) 240316kB (UMEH) 39132kB (UH) 1064kB (H) 3128kB (H) 0256kB 0512kB 01024kB 02048kB 04096kB = 94588kB Nov 24 05:43:37 hostname kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB Nov 24 05:43:37 hostname kernel: Node 0 hugepages_total=2400 hugepages_free=287 hugepages_surp=0 hugepages_size=2048kB Nov 24 05:43:37 hostname kernel: 2140592 total pagecache pages Nov 24 05:43:37 hostname kernel: 65 pages in swap cache Nov 24 05:43:37 hostname kernel: Swap cache stats: add 217664, delete 217599, find 49323/56024 Nov 24 05:43:37 hostname kernel: Free swap = 1385212kB Nov 24 05:43:37 hostname kernel: Total swap = 2064380kB Nov 24 05:43:37 hostname kernel: 4194157 pages RAM Nov 24 05:43:37 hostname kernel: 0 pages HighMem/MovableOnly Nov 24 05:43:37 hostname kernel: 149212 pages reserved Nov 24 05:43:37 hostname kernel: 0 pages hwpoisoned Nov 24 05:43:37 hostname kernel: SELinux: failed to load policy Nov 24 05:43:38 hostname dnf-automatic[2350061]: SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.31: Cannot allocate memory Nov 24 05:43:38 hostname dnf-automatic[2350061]: load_policy: Can't load policy: Cannot allocate memory Nov 24 05:43:38 hostname dbus-daemon[1100]: [system] Reloaded configuration Nov 24 05:43:38 hostname dbus-daemon[1100]: [system] Reloaded configuration Nov 24 05:43:38 hostname dbus-daemon[1100]: [system] Reloaded configuration Nov 24 05:43:38 hostname dbus-daemon[1100]: [system] Reloaded configuration Nov 24 05:43:40 hostname dbus-daemon[1100]: [system] Reloaded configuration Nov 24 05:43:40 hostname dbus-daemon[1100]: [system] Reloaded configuration Nov 24 05:43:41 hostname systemd-udevd[2351902]: Using default interface naming scheme 'rhel-8.0'. Nov 24 05:43:42 hostname systemd[1]: Reloading. Nov 24 05:43:43 hostname systemd[1]: Reloading. Nov 24 05:43:47 hostname NetworkManager[1238]: <info> [1669265027.8825] manager: kernel firmware directory '/lib/firmware' changed Due to this server being a database host, we have allocated hugepages and disabled overcommit. We have 2400 2048 kB memory allocated for hugepages and 11076044 kB available for userspace applications (CommitLimit). Total memory on the machine is, according to /proc/meminfo, 16179780 kB which should leave 188536 kB for the kernel. Perhaps this is not enough? Here's our cat /proc/meminfo for one of the affected servers: MemTotal: 16179780 kB MemFree: 384992 kB MemAvailable: 9381080 kB Buffers: 3704 kB Cached: 8809540 kB SwapCached: 276 kB Active: 3656528 kB Inactive: 5692040 kB Active(anon): 83920 kB Inactive(anon): 611336 kB Active(file): 3572608 kB Inactive(file): 5080704 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2064380 kB SwapFree: 1387004 kB Dirty: 92 kB Writeback: 0 kB AnonPages: 531136 kB Mapped: 257248 kB Shmem: 189552 kB KReclaimable: 686400 kB Slab: 953032 kB SReclaimable: 686400 kB SUnreclaim: 266632 kB KernelStack: 8384 kB PageTables: 19500 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 11076044 kB Committed_AS: 2940032 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB Percpu: 101888 kB HardwareCorrupted: 0 kB AnonHugePages: 10240 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 2400 HugePages_Free: 287 HugePages_Rsvd: 9 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 4915200 kB DirectMap4k: 1275712 kB DirectMap2M: 12355584 kB DirectMap1G: 5242880 kB

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
925	[Cloud] General	minor	always	2022-11-18 14:34	2022-11-22 12:32

Reporter:	Steven Hagting	Platform:
Assigned To:	Louis Abel	OS:
Priority:	low	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Checksum missing generic cloud latest
Description:	Forgive me if I used the wrong format, this is my first report for any distro ever. When checking the CHECKSUM file at https://dl.rockylinux.org/pub/rocky/8/images/x86_64/CHECKSUM I noticed that it is missing a reference to Rocky-8-GenericCloud.latest.x86_64.qcow2 Also, the actual CHECKSUM for that file https://dl.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-GenericCloud.latest.x86_64.qcow2.CHECKSUM points to Rocky-8-GenericCloud.Base.latest.x86_64.qcow2 I also checked https://dl.rockylinux.org/pub/rocky/8.7/images/x86_64/CHECKSUM which has the same issue.
Tags:
Steps To Reproduce:	Open the files mentioned above.
Additional Information:
Attached Files:

Notes
(0001090) Louis Abel 2022-11-18 16:34	Thank you for the report! We will get this addressed soon. We actually are planning to generate a new generic cloud image as it's missing BIOS boot (UEFI is fine though), so the checksums will change either way. You are correct that the checksum for latest points to the "Base latest". Anything that has "latest" in the name is actually a symlink to what it refers to. For the regular "GenericCloud.latest" name, that's a hold over for when we didn't have "base" or "lvm" images. Now that we do, "GenericCloud.latest" points to "base" to have it match the previous release. I hope this helps until we get the checksums corrected!

(0001189) Steven Hagting 2022-11-22 12:32	Thanks Louis :) Perfectly logical explanation about the "latest" bit of the image name. I just noticed the BIOS boot missing as well. I'll keep an eye on the new cloud image before we update the image we offer our customers.

(0001190) Steven Hagting 2022-11-22 12:32	Thanks Louis :) Perfectly logical explanation about the "latest" bit of the image name. I just noticed the BIOS boot missing as well. I'll keep an eye on the new cloud image before we update the image we offer our customers.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
826	[Rocky-Linux-8] Installer	minor	always	2022-11-15 16:46	2022-11-15 16:47

Reporter:	David Roth	Platform:	el8
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	8.6
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	modprobe: ERROR: could not insert 'sha256_mb' : No such device
Description:	When booting from USB Flash Drive (Rocky-8.6-x86_64-dvd1.iso) after selecting Install, a message flashes by I managed to video record: "dracut-pre-udev[850]: modprobe: ERROR: could not insert 'sha256_mb' : No such device The next line is the green "OK" where "Started Show Plymouth Boot Screen". Hardware is: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Tags:	Install, Modprobe
Steps To Reproduce:	Install USB Flash drive in USB port with Rocky-8.6-x86_64-dvd1.iso. Hold F12 to select to boot from USB key in BIOS option and the error message will appear shortly flashing by as described each time.
Additional Information:	This also occurs in the Rocky Linux 8.7 beta which I have reported to the Testing Channel.
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
760	[Rocky-Linux-9] Installer	block	always	2022-11-10 09:59	2022-11-10 09:59

Reporter:	Rob Scheepens	Platform:	Nutanix AHV
Assigned To:		OS:	CentOS
Priority:	normal	OS Version:	7.9
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Ethernet adapter unavailable during Installer
Description:	Downloaded https://download.rockylinux.org/pub/rocky/9/isos/x86_64/Rocky-9.0-20220808.0-x86_64-dvd.iso and https://download.rockylinux.org/pub/rocky/9/isos/x86_64/Rocky-9.0-20220805.0-x86_64-minimal.iso: both do not enable my virtio ethernet adapter (see screenshots).
Tags:	ethernet, installation, networking
Steps To Reproduce:	- download Rocky 9 Minimal or DVD iso - start Installer - look under network configuration
Additional Information:
Attached Files:	Rocky9-DVD.png (599,876 bytes) 2022-11-10 09:59 https://bugs.rockylinux.org/file_download.php?file_id=364&type=bug Rocky9-Minimal.png (554,835 bytes) 2022-11-10 09:59 https://bugs.rockylinux.org/file_download.php?file_id=365&type=bug

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
662	[Rocky-Linux-8] NetworkManager	major	always	2022-11-01 16:01	2022-11-07 22:12

Reporter:	Carl Gromatzky	Platform:	ESXi 7.0.3, open-vm-tools 11.3.5
Assigned To:	Louis Abel	OS:	Rocky 8.6
Priority:	normal	OS Version:	4.18.0-372.9.1.e
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	MAC Addr Corruption VMWare open-vm-tools 11.3.5-1.el8
Description:	Subject: Rock 8.6 VMXNET3 Device Enumeration Corruption Message: Running ESXi 7.0.3 build 20328353 (or build 20395099) on a UCS-C220-M5SX with firmware 4.2(2a) and a Intel Xeon Platinum 8168 2.7GHz processor VM is Rocky 8.6 (4.18.0-372.9.1.el8.x86_64), using VMXNET3 network devices Network devices mac addresses enumerate in the VM OS (Rocky 8.6) just fine, up to 3 network devices. i.e.: eth0 MAC addr = Network Adapter 1 MAC addr eth1 MAC addr = Network Adapter 2 MAC addr eth2 MAC addr = Network Adapter 3 MAC addr Adding a fourth network device causes nmcli to show corrupted MAC address to device mappings. Rebooting causes dmesg errors and network loss (the driver appears to enumerate all vmxnet3 network devices incorrectly upon adding the 4th vmxnet3 device, mapping connection profiles to incorrect devices and causing kernel errors and network connectivity loss) MAC addresses enumerate differently in the OS than the network adapters listed in vCenter after the fourth adapter is added to the vm, i.e.: eth0 MAC addr = Network Adapter 4 MAC addr eth1 MAC addr = Network Adapter 1 MAC addr eth2 MAC addr = Network Adapter 2 MAC addr eth3 MAC addr = Network Adapter 3 MAC addr open-vm-tools version experiencing this issue is 11.3.5-1.el8_6.1 from @AppStream repo I also downloaded open-vm-tools versions 12.0.0, 12.0.5, 12.1.0 from the vmware github and rpm'd them into the build. All provide the same behavior on this vm. 12.1.0 actually started experiencing the MAC enumeration corruption when adding the third Network Adapter. I opened a case with VMWare. They closed my case provided that I must open a case with Rocky Linux directly.
Tags:
Steps To Reproduce:	The VM is given 1 vmxnet3 adapter to start. The network is configured and connectivity good. The VM is given 1 additional adapter. The network connectivity is good. The VM is given 1 additional adapter. The network connectivity is good. The VM is given 1 additional adapter. The network connectivity fails, with mac address to nmcli connection mappings corrupted. Generally, the error will not present until the VM is rebooted. OR The VM is given 4 vmxnet3 adapters to start. The network is configured and connectivity good. The VM is rebooted, connectivity fails, with mac address to nmcli connection mappings corrupted.
Additional Information:	The OS is hardened, running in mult-user.target mode. Running generic Rocky 8.6 build provides the following behavior in the same VMWare environment: Add 4 vmxnet3 devices, the nmcli device list shows mac addr enumeration is fine, though the default network device nomenclature is ens[n]. I notice that the first 2 network devices enumerate as ens2[nn] and that the 3rd and 4th devices enumerate as ens1[nn]. In the production, hardened build, the network device nomenclature is eth[n].
Attached Files:	netid_badrock.txt (1,771 bytes) 2022-11-04 21:29 https://bugs.rockylinux.org/file_download.php?file_id=331&type=bug udevtest_badrock_afterreboot.txt (1,091 bytes) 2022-11-04 21:29 https://bugs.rockylinux.org/file_download.php?file_id=332&type=bug udevtest_badrock.txt (1,096 bytes) 2022-11-04 21:29 https://bugs.rockylinux.org/file_download.php?file_id=333&type=bug udevtest_r8default.txt (1,090 bytes) 2022-11-04 21:29 https://bugs.rockylinux.org/file_download.php?file_id=334&type=bug

Notes
(0000802) Louis Abel 2022-11-01 16:08	Unfortunately we simply rebuild the open-vm-tools package as provided by Red Hat, which contains the sources that VMWare tools builds. So there's not much of a way for us to investigate. I disagree with them that you must come to us to resolve this issue when it's their tools and platform. Please reopen a ticket and reference this bug ticket as well as https://bugs.rockylinux.org/view.php?id=200 to open a discussion with their engineering teams to find a solution.

(0000803) Carl Gromatzky 2022-11-01 16:15	I've update the VMWare ticket and am awaiting response from that support team, regarding the support-ability dispute. Thank you, Louis.

(0000826) Carl Gromatzky 2022-11-02 23:44	I uninstalled open-vm-tools 11.3.5 and confirmed in vcenter. Installed VMWare Tools 10.3.25, confirmed in vcenter, and experienced the same mac address corruption issue. VMWare engineer updated. Perhaps, they will support VMWare Tools official. VMWare engineer also escalating as an open-vm-tools issue to VMWare global engineers (seeing if they will pickup at all). The /sys/class/net/eth[0,1]/address sysfs files show the incorrectly mapped mac addresses. This seems to be a driver issue. Hoping to get feedback. Will update here.

(0000827) Louis Abel 2022-11-02 23:49	Thank you for the update. It's starting to sound like a platform issue (esx level). Perhaps ESX is providing the wrong information to the firmware, and the kernel/driver/udev is just following what it sees. Hoping to hear what they find. One of our testers is currently moving their infra, so if vmware doesn't come back right away, he can probably try to see if the issue is reproducible in his environment with both Rocky Linux and RHEL. It would be interesting to see if it's also a problem in RHEL.

(0000862) Carl Gromatzky 2022-11-04 18:48	That's an interesting note. I researched and tested further, finding the VWMare Firmware/BIOS is indeed the culprit, in that it enumerates Network Adapters on the PCIe bus out of logical sequence. Red Hat referred to this as "giving the kernel information that doesn't make any sense," since 2016, so it's a long-ongoing issue. Below is text from the updated email (with additional research references that led to better understanding) that I sent to the VMWare engineer. --------------------------------- To re-iterate the change in scope: I replicated the MAC Address to Interface corruption in the official VMWare Tools package. This is no longer only an open-vm-tools issue. This is a VMWare-specific problem, as noted by several vendors, and it has to due with PCI/PCIe bus enumeration problems of VMWare. I believe that this VMWare article, which pulls information from Red Hat KBs, may prove the next path for testing: https://docs.vmware.com/en/VMware-Adapter-for-SAP-Landscape-Management/services/Administration-Guide-for-LaMa-Administrators/GUID-0603A3F3-CCB1-42AF-A1E2-6B61979C00CB.html I need to know more about how the PCIe Bus enumeration and Ethernet Port enumeration in VMWare function in order to create a reasonable udev rule to address VMWare's hardware handling. Questions: Is BDF bus assignment consistent and predictable when adding n number of Network Adapters to a VMWare VM? What is the order of operations and resulting output of Bus ID assignment for n number of Network Adapters? Are Ethernet port IDs user-definable in the Advanced Configuration Parameters of VM Settings? I see that I can adjust advanced configuration port numbers for interfaces, but not sure if port number assignments would change bus ID behavior? How are port numbers derived/calculated? Would changing a port number persist a reboot, or would VMWare simply automatically reassign a port number? Root cause of the issue: Root cause of the MAC Addr corruption that takes Ethernet interfaces down appears to be that VMWare Tools passes bus IDs to the Rocky Linux kernel out of numerical order (this is a VMWare-specific issue, as noted by several OS vendors). This behavior causes the naming sequence discrepancy for naming convention of Interface, ethX, to Ethernet Device Connection name, ensY. The ethX old naming style is needed for many environments in order to comply with needs of devops and secops Result: Interface eth0 may map to Connection ens192 when Network Adapter 1 is first presented to the OS, then eth0 may map to ens161 on the next boot. This is due to ID_NET_NAME_PATH nomenclature assigned by udev, as enpMsN, enumerating out of logical sequence, as based on BUS ID enumeration from the VMWare Firmware/BIOS passing through to kernel udev/rules.d naming rules during POST. i.e. Interface eth0 will be enumerated first by the kernel and mapped to the first-presented virtual PCIe connection, which enumerates based on bus ID Generall,y Network Adapter 1 maps to enp11s0 reliably With 4 network adapters, the BUS ID doesn't matter at first presentation of the Network Adapter (hot-plugging gives Network Adapters 1-4 the appropriate eth0-3 names because they're being hot-plugged in order to the OS by VMWare) On the next boot, Network Adapter 4 gets presented to the kernel on enp4s0, connection ens161, so udev then assignes eth0 to ens161 because the lowest numbers in the database get paired together The MAC Address corruption grows in complexity with the number of VMWare Network Adapters added. If I give the VM 8 Network Adapters, the BUS IDs get injected in no predictable order, which goes back to the questions above. If I can understand how VMWare enumerates the PCIe bus and Ethernet ports, I believe I can create the udev rule to handle ethX naming at scale in el7+ (and other OS kernel) builds and satisfy dev and sec requirements. Further links leading to above VMWare KB in research of this problem: https://github.com/Azure/WALinuxAgent/issues/1750 https://github.com/coreos/bugs/issues/2437 https://github.com/systemd/systemd/pull/8458 https://unix.stackexchange.com/questions/611762/how-to-fix-the-conflict-in-the-naming-scheme-for-network-interfaces-use-by-predi https://www.linuxsysadmins.com/systemd-network-interface-name-ensx-to-eth0/ https://www.redhat.com/en/blog/red-hat-enterprise-linux-73-achieving-persistent-and-consistent-network-interface-naming-vmware-environments https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-consistent_network_device_naming#sec-Naming_Schemes_Hierarchy https://communities.vmware.com/t5/vSphere-vNetwork-Discussions/how-to-fix-a-virtual-Network-Adapter-to-be-the-first-one-from/m-p/916181 https://kb.vmware.com/s/article/2047927 https://unix.stackexchange.com/questions/134483/why-is-my-ethernet-interface-called-enp0s10-instead-of-eth0 https://wiki.xenproject.org/wiki/Bus:Device.Function_(BDF)_Notation https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-understanding_the_predictable_network_interface_device_names https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/consistent-network-interface-device-naming_configuring-and-managing-networking https://access.redhat.com/solutions/2592561

(0000863) Carl Gromatzky 2022-11-04 21:29	I meant to attach some files for reference (see attached)

(0000864) Carl Gromatzky 2022-11-05 19:30	Keeping this string updated with research as discovered: Based on the VMWare article and the Kemp article below, the community has understood the VMWare PCIe bus enumeration and configured a .vmx file that attaches max Ethernet devices and hard-codes their sequence to a logical order for the OS in user-space. This seems like a logical way to scale a template-able fix (which is my primary concern, as addressing this issue at scale any time someone wants more the 3 adapters would be inefficient). Any thoughts? (I've ported this comment over to the VMWare engineer assigned. Want to make sure this passes VMWare's eyes and get the ok, regarding any pitfalls or obvious errors.) Kemp article: https://support.kemptechnologies.com/hc/en-us/articles/201978745-When-adding-4-or-more-VMXNET3-NICs-to-a-VLM-in-VMware-the-order-is-incorrect VMWare article: https://kb.vmware.com/s/article/2047927

(0000866) Carl Gromatzky 2022-11-07 22:12	I deployed this config in a .vmx for a test vm, worked great # 001.00101.00000 # PCI Slot=4 # Parent slot 21: # Bus:Dev.Func = 00h:15h.01h # Guest OS Order eth0 ethernet0.pciSlotNumber = "1184" # 010.00101.00000 # PCI Slot=4 # Parent slot 21: # Bus:Dev.Func = 00h:15h.02h # Guest OS Order eth1 ethernet1.pciSlotNumber = "2208" # 011.00101.00000 # PCI Slot=4 # Parent slot 21: # Bus:Dev.Func = 00h:15h.03h # Guest OS Order eth2 ethernet2.pciSlotNumber = "3232" # 001.00110.00000 # PCI Slot=5 # Parent slot 22: # Bus:Dev.Func = 00h:16h.01h # Guest OS Order eth3 ethernet3.pciSlotNumber = "1216" # 010.00110.00000 # PCI Slot=5 # Parent slot 22: # Bus:Dev.Func = 00h:16h.02h # Guest OS Order eth4 ethernet4.pciSlotNumber = "2240" # 011.00110.00000 # PCI Slot=5 # Parent slot 22: # Bus:Dev.Func = 00h:16h.03h # Guest OS Order eth5 ethernet5.pciSlotNumber = "3264" # 001.00111.00000 # PCI Slot=6 # Parent slot 23: # Bus:Dev.Func = 00h:17h.01h # Guest OS Order eth6 ethernet6.pciSlotNumber = "1248" # 010.00111.00000 # PCI Slot=6 # Parent slot 23: # Bus:Dev.Func = 00h:17h.02h # Guest OS Order eth7 ethernet7.pciSlotNumber = "2272" # 001.01000.00000 # PCI Slot=7 # Parent slot 24: # Bus:Dev.Func = 00h:18h.01h # Guest OS Order eth8 ethernet8.pciSlotNumber = "1280" # 010.01000.00000 # PCI Slot=7 # Parent slot 24: # Bus:Dev.Func = 00h:18h.02h # Guest OS Order eth9 ethernet9.pciSlotNumber = "2304" I also found that these .vmx lines need to be removed (they'll be automatically repopulated at next power state change of the vm) ethernetN.dvs.portId = ... ethernetN.generatedAddress = ... ethernetN.addressType = ... ethernetN.generateAddressOffset = ... ------------------------------------------------------------------------------------------- If configuring a VM with the GUI, Need to Edit Settings > VM Optios (tab at the top) > Advanced > Edit Configuration > Add Configuration Params (particularly useful for new VM configuration) Then, add ethernetN.pciSlotNumber and the slot ID noted from the lines above for the n-th interface (where N is the n-th interface in ethernetN) ------------------------------------------------------------------------------------------- VMWare Engineer is also looking into opening a PR for VMWare-Tools and Rocky 8.6. (I would want to guess that this is a way to channel this issue into the right VMWare support workflow vs. VMWare assuming this an OS problem....the long years of history of this issue at the global level leaves interpretation up in the air, but I'm brave enough to feel hopeful lol)

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
698	[Rocky-Linux-9] krb5	minor	always	2022-11-07 17:21	2022-11-07 17:21

Reporter:	Stephen Berg	Platform:
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9.0
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	krb5-pkinit package prevents smartcard authentication
Description:	If the krb5-pkinit package is installed on 9.0 using a smartcard to authenticate at the console or gdm fails. Once that package is removed smartcard auth functions as expected.
Tags:
Steps To Reproduce:	- Install 9.0 - install and configure sssd to bind to a freeipa domain - krb5-pkinit is installed as a dependency of krb5-workstation - attempt to authenticate using smartcard (in my case a DOD Common Access Card)
Additional Information:	Smartcard authentication fails at every attempt using the console or gdm. If I login with password the smartcard does work for authenticating to websites and other services so I'm confident that using the smartcard itself is not the problem. Running "rpm --erase --nodeps krb5-pkinit" seems to fix this problem. Authenticating starts working immediately. Under 8.6 I was able to remove krb5-pkinit without any other packages being removed. But under 9.0 it wants to remove: ipa-client krb5-workstation ipa-client-common ipa-common ipa-selinux oddjob-mkhomedir python3-augeas python3-decorator python3-dns python3-gssapi python3-ipaclient python3-ipalib python3-jwcrypto python3-ldap python3-libipa_hbac python3-netifaces python3-pyasn1 python3-pyasn1-modules python3-pyusb python3-qrcode-core python3-sss python3-sss-murmur python3-sssdconfig python3-systemd python3-yubico sssd-dbus sssd-tools So I choose to just remove the one package using rpm since the ipa-client is definitely needed. I'm not sure if this is an actual bug or misconfiguration. I could be missing some setting that would allow krb5-pkinit to be installed but not interfere with smartcard authentication.
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
695	[Rocky-Linux-9] [Repo] Extras	minor	always	2022-11-04 14:44	2022-11-04 14:44

Reporter:	Stephen Rondeau	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Cannot find or install amanda package
Description:	dnf search amanda dnf whatprovides */amanda Neither return a package that would allow amanda (or amanda-client) to be installed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
595	[Alternative Architectures] General	text	always	2022-10-21 13:54	2022-10-28 19:42

Reporter:	Justin Burdine	Platform:	aarch64 (raspberry pi)
Assigned To:	Louis Abel	OS:	Rocky LInux
Priority:	normal	OS Version:	9.0
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	when creating a new user on Rocky 9 (for raspberry pi) the README says Rocky 8
Description:	default README in rocky user home dir references Rocky 9 as expected. But when I create a new user (adduser) the README that is generated in the new user's home dir references Rocky 8.
Tags:
Steps To Reproduce:	login as rocky user sudo su adduser bob logout / login as bob cat ./README displays Rocky 8
Additional Information:
Attached Files:

Notes
(0000800) Skip Grube 2022-10-28 16:21	Thank you! The file in question is from the rocky-rpi-release RPM, I will update it soon!

(0000801) Louis Abel 2022-10-28 19:42	This is resolved in rocky-release-rpi-9.0-5.el9.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
661	[Rocky-Linux-8] thunderbird	minor	always	2022-10-27 16:42	2022-10-27 16:42

Reporter:	Chris Schanzle	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	unexpanded macro in /usr/bin/thunderbird: line 143: fg: no job control
Description:	/usr/bin/thunderbird has a syntax error at line 143
Tags:
Steps To Reproduce:	starting thunderbird from the terminal emits a harmless error message (it still starts): /usr/bin/thunderbird: line 143: fg: no job control
Additional Information:	/usr/bin/thunderbird line 142, 143 contains: # Linux version specific environment variables %RHEL_ENV_VARS% The % is being interpreted by bash for job control function, but is syntactically incorrect, hence the error message. Clearly this was a placeholder string to expand to something. The thunderbird.spec modifies the script near the comment "# set up the thunderbird start script". Nowhere does the spec do anything with %RHEL_ENV_VARS%, so this might be an upstream bug too (I have no RHEL systems to test).
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
563	[Rocky-Linux-8] thunderbird	feature	always	2022-10-19 15:25	2022-10-22 06:55

Reporter:	Niki Kovacs	Platform:	x86_64
Assigned To:	Louis Abel	OS:	Rocky Linux
Priority:	normal	OS Version:	8.6
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Missing context menu
Description:	Mozilla Thunderbird is missing at least one important context menu. Normally, when you highlight an e-mail, a right mouse click on the sender will display a context menu with various items like adding the sender to the contact list, modifying the contact or creating a filter. This menu is missing. A right click in the latest version does nothing, which is not normal.
Tags:
Steps To Reproduce:	1. Install Rocky Linux 8 desktop or workstation. 2. Install Mozilla Thunderbird: dnf install -y thunderbird 3. Set up an e-mail account. 4. Highlight an e-mail. 5. Right click an e-mail address. 6. See for yourself that the corresponding contextual menu is missing.
Additional Information:
Attached Files:

Notes
(0000728) Louis Abel 2022-10-19 15:41	Thank you for the report. Please attempt to replicate this on RHEL 8.6. If it can be reproduced, you will need to file an upstream bug at bugzilla.redhat.com.

(0000761) Niki Kovacs 2022-10-21 17:21	Apparently this is an upstream bug. I just installed Thunderbird on a virtual installation of Red Hat Enterprise Linux Worksation 8.6, setup a mail account in Thunderbird and tested this. No context menus either. I'll check this out on Red Hat's Bugzilla.

(0000762) Niki Kovacs 2022-10-22 06:55	Right, here goes. I filed a bug on the Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2136970

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
79	[Rocky-Linux-8] kernel	minor	have not tried	2021-11-16 15:25	2022-10-09 20:13

Reporter:	Lukas Magauer	Platform:
Assigned To:	Release Engineering	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	kdump SecureBoot enabled systems on ESXi crashes
Description:	Description of problem: After enabling SecureBoot on an Rocky Linux system on ESXi the kdump service is unable to start. Also after rebuilding the kdump kernel it still doesn't want to start: kdumpctl rebuild kdump: Rebuilding /boot/initramfs-4.18.0-348.el8.0.2.x86_64kdump.img kdumpctl restart kdump: kexec: unloaded kdump kernel kdump: Stopping kdump: [OK] kdump: Secure Boot is enabled. Using kexec file based syscall. kdump: kexec: failed to load kdump kernel kdump: Starting kdump: [FAILED] After some research with Sherif, we noticed that the Rocky Linux SecureBoot CA Certificate is missing inside of the OS: keyctl show %:.platform Keyring 75387545 ---lswrv 0 0 keyring: .platform 12012862 ---lswrv 0 0 \_ asymmetric: VMware, Inc.: 4ad8ba0472073d28127706ddc6ccb9050441bbc7 261459087 ---lswrv 0 0 \_ asymmetric: CentOS Secure Boot CA 2: 70007f99209c126be14774eaec7b6d9631f34dca 833827591 ---lswrv 0 0 \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53 1022550040 ---lswrv 0 0 \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4 587540411 ---lswrv 0 0 \_ asymmetric: VMware, Inc.: VMware Secure Boot Signing: 04597f3e1ffb240bba0ff0f05d5eb05f3e15f6d7 But it is still able to boot with SecureBoot enabled. Furthermore it looks like VMware is using some kind of SecureBoot CA whitelist. Version-Release number of selected component (if applicable): 8.5 Steps to Reproduce: 1. Install SecureBoot enabled system on ESXi 2. Notice that kdump is failing in the system journal Tested on ESXi 7.0.2 and 7.0.3
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	r85-gm-dev_vmware.log (219,724 bytes) 2022-05-01 00:31 https://bugs.rockylinux.org/file_download.php?file_id=3&type=bug screenshot_2022_08_09_02_23_1660051398.png (5,214 bytes) 2022-08-09 13:29 https://bugs.rockylinux.org/file_download.php?file_id=75&type=bug

Notes
(0000089) Lukas Magauer 2021-11-16 15:31	Unfortunately got the output of a CentOS system on how it should look in the keyring in the earlier message, this is how it looks in RL 8.5: keyctl show %:.platform Keyring 874696905 ---lswrv 0 0 keyring: .platform 877754404 ---lswrv 0 0 \_ asymmetric: VMware, Inc.: 4ad8ba0472073d28127706ddc6ccb9050441bbc7 883063272 ---lswrv 0 0 \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53 1049370662 ---lswrv 0 0 \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4 459595990 ---lswrv 0 0 \_ asymmetric: VMware, Inc.: VMware Secure Boot Signing: 04597f3e1ffb240bba0ff0f05d5eb05f3e15f6d7 Furthermore, the CentOS OS type was used in the VM configuration as Rocky Linux is not available there.

(0000090) Sherif Nagy 2021-11-16 15:37	Also could you mention the hardware model underneath the ESXi?

(0000091) Lukas Magauer 2021-11-16 17:30	Off course! My underlying system is a cluster of multiple Lenovo ThinkCentre M910q's with Intel Core i5-6500T, EVC is enabled and uses the Intel Broadwell Generation CPU mode Both DRS and HA are enabled The keyprovider for TPM is also enabled All VMs are using the VM hardware version 19 (ESXi 7U2 and later)

(0000092) Lukas Magauer 2021-11-19 10:39	After more investigation it looks to depend on the specific ESXi version as well, in my case it was 7U3a, but in chats it looks to also affect 7U2d.

(0000093) Sherif Nagy 2021-11-24 11:53	Looks like it is a shim bug: https://github.com/rhboot/shim/pull/387 and hopefully will be fixed when shim 15.5 released Also someone else did test some versions of ESXi 7.0.2 and kdump was working fine with SB enabled, so not all ESXi version are affected by this.

(0000094) Alex Haydock 2021-12-20 14:36	I can reproduce this on VMware Workstation 15.1 too. Looking at the upstream fix in PR #387 to the shim project on GitHub, it seems like the RCs are out in prep for a new release. RC2 was released 10 days ago, so hopefully it'll feed into RHEL too.

(0000271) Lukas Magauer 2022-07-16 12:55	As a small update, this also affects Rocky Linux 8.6, but got fixed for 9.0 Also seeing it for the latest versions of ESXi and Workstation.

(0000310) Lawrence Wright 2022-07-28 15:56	Are there any updates on when the Rocky shim-review for Shim 15.5 (or 15.6 for that matter) will be submitted?

(0000311) Sherif Nagy 2022-07-28 20:37	We did submit 15.5 awhile ago, but due to CVEs in shim 15.5 all reviews has been closed, most likely we will be waiting for the upstream to submit their 15.6 for review and then we will submit ours to make sure we are aligning with the upstream version

(0000330) Lawrence Wright 2022-08-09 10:40	It'd appear that upstream are now using 15.6, is Rocky able to move forward now? Thanks!

(0000331) Sherif Nagy 2022-08-09 13:29	They just pushed the sources to 15.6 but never got 15.6 reviewed or signed by Microsoft, it is basically still the same 15.5 signed shim from Microsoft, you can always check the review submissions here: https://github.com/rhboot/shim-review/issues , so I don't think the upstream got shim15.6 signed yet as per the review issues

(0000332) Lawrence Wright 2022-08-09 13:48	heart sinks yeah we've used your command above checked our upstream 8.6 box and can confirm same grep output as the above for shimx64.efi, this is with the package shim-x64-15.6-1.el8.x86_64. Seems a bit... disappointing... for upstream to have a package versioned 15.6 actually containing a 15.5 shim....

(0000333) Sherif Nagy 2022-08-09 14:41	Not disappointing, we had to do the same, to follow the upstream, that makes it easier so once the shim gets signed by MSFT, it can just be dropped into the shim pkg instead of changing lots of versions like shim-unsigned and such, but I agree, it is confusing :)

(0000468) Sherif Nagy 2022-08-24 10:05	We released shim-15.6 for rocky 8 and rocky 9, please update, test and provide us some feedback, other members in the community and testing team managed to test on their ESXi hardware and everything seems to be working fine.

(0000698) Lukas Magauer 2022-10-09 20:06	From my point of view, this is fixed and can be closed now!

(0000700) Sherif Nagy 2022-10-09 20:13	Perfect! thanks for testing

(0000701) Sherif Nagy 2022-10-09 20:13	Working fine with shim-15.6

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
149	[Rocky-Linux-9] General	minor	always	2022-07-18 16:35	2022-10-09 20:10

Reporter:	Lukas Magauer	Platform:
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9.0
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Characters not showing up correctly in browser, shell and other applications
Description:	It was reported by @darthgelum, that the double parenthesis characters are not showing up correctly in a Workstation install. I was testing with both Graphical Server and Workstation installs and both show the same behavior of missing characters (showing placeholder characters). This was further checked with a fully patched RHEL 9.0 system, which was showing the same behavior. Also further this was tested both on a hardware system with the proprietory NVIDIA driver as well as in a VMware ESXi environment as a VM. For comparison I tested this on a fully patched Fedora Workstation installation, which shows the characters just fine.
Tags:
Steps To Reproduce:	- Install a Graphical Server or Workstation installation - Open the browser and visit the page https://unicode-table.com/en/blocks/supplemental-punctuation - You will see many placeholder characters
Additional Information:	As this is a upstream bug, please handle this more as documentation than a Rocky Linux specific bug. Thank you!
Attached Files:	image.png (161,484 bytes) 2022-07-18 16:35 https://bugs.rockylinux.org/file_download.php?file_id=68&type=bug image-2.png (166,380 bytes) 2022-07-18 16:35 https://bugs.rockylinux.org/file_download.php?file_id=69&type=bug

Notes
(0000272) Lukas Magauer 2022-07-18 16:56	Back tracking, here is the RHEL bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=2108245

(0000280) Philipp Dmitrov 2022-07-19 08:58	It could be fixed by installing font with full utf8 table support. For example, julia mono https://copr.fedorainfracloud.org/coprs/shassard/juliamono-fonts/

(0000699) Lukas Magauer 2022-10-09 20:10	As mentioned in the RHEL bugreport, this issue got fixed in the npm package. Browsers are still affected, but I don't really see any moving forward as the mindset looks to be that the websites should provide their own or 3rd party online available fonts. -> we can close this now @darthgelum I hope you also have this impression!

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
498	[Rocky-Linux-9] selinux-policy	minor	always	2022-10-09 17:29	2022-10-09 19:03

Reporter:	Clinton Bunch	Platform:	x86_64
Assigned To:		OS:	Rocky Linux
Priority:	normal	OS Version:	9
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	SELinux blocks systemd from using LoadCredentials
Description:	Using LoadCrential in systemd service unit fails with a protocol error. audit2why shows selinux blocked the creation of a ramfs that systemd uses to store the credentials.
Tags:	ramfs, selinux, systemd
Steps To Reproduce:	cat /etc/systemd/system/test-cred.service [Unit] Description=Processes IMAP mailbox for DMARC messages, parses them into a database [Service] Type=oneshot LoadCredential=rr:/etc/redhat-release ExecStart=/bin/cat ${CREDENTIALS_DIRECTORY}/rr DynamicUser=true [root@montes ~]# systemctl start test-cred.service Job for test-cred.service failed because the control process exited with error code. See "systemctl status test-cred.service" and "journalctl -xeu test-cred.service" for details.
Additional Information:	journalctl output: Oct 09 12:25:41 montes.int.zentaur.org systemd[1]: Starting Processes IMAP mailbox for DMARC messages, parses them into a database... Oct 09 12:25:41 montes.int.zentaur.org systemd[5323]: test-cred.service: Failed to set up credentials: Protocol error Oct 09 12:25:41 montes.int.zentaur.org systemd[5323]: test-cred.service: Failed at step CREDENTIALS spawning /bin/cat: Protocol error Oct 09 12:25:41 montes.int.zentaur.org systemd[1]: test-cred.service: Main process exited, code=exited, status=243/CREDENTIALS Oct 09 12:25:41 montes.int.zentaur.org systemd[1]: test-cred.service: Failed with result 'exit-code'. Oct 09 12:25:41 montes.int.zentaur.org systemd[1]: Failed to start Processes IMAP mailbox for DMARC messages, parses them into a database. auth2why output: type=AVC msg=audit(1665336341.298:119): avc: denied { create } for pid=5324 comm="(sd-mkdcreds)" name=".#credb116a97193b48e33" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=file permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access.
Attached Files:

Notes
(0000696) Clinton Bunch 2022-10-09 17:35	Fedora seems to have addressed this/a similar issue with this commit: https://github.com/fedora-selinux/selinux-policy/commit/a7697467e082ffd4f68a9e03539db3578b5f34d5

(0000697) Clinton Bunch 2022-10-09 18:46	This SELinux type enforcement file (generated from audit2allow) is a quick and dirty solution to the problem, but someone with far more experience with SELinux should make the determination as to what is the correct solution. module systemd-loadcredentials 1.0; require { type ramfs_t; type init_t; class file { create open read rename setattr write }; } #============= init_t ============== allow init_t ramfs_t:file { create open read rename setattr write };

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
331	[Rocky-Linux-9] Installer	minor	always	2022-09-26 18:40	2022-09-27 09:07

Reporter:	Nikolay Penchev	Platform:	hp proliant dl380g7
Assigned To:		OS:	rocky 9
Priority:	low	OS Version:	9.0
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	rocky 9 installation crashed on hp dl380g7
Description:	rocky linux 9 installation stop with errors on anaconda screen when installing on hp proliant dl380g7. I have tried following images: Rocky-9.0-20220808.0-x86_64-dvd.iso Rocky-9.0-x86_64-minimal.iso Rocky-x86_64-boot.iso all stop with same error. serverver specifications: BIOS P67 (05/21/2018), cpu 2x Intel Xeon x5690, raid controller p410i, ram 96GB
Tags:
Steps To Reproduce:	-attach virtual disk to hp proliant dl380g7 or plug rocky 9.0 usb stick -boot disk and select "Install Rocky9.0" -installation start and crash on screen with green line on bottom (attached screenshot)
Additional Information:	successful scenarios: -on proliant dl380g7 first install rocky linux 8.5 and upgrade to 9.0 with no problems. - install rocky 9.0 on hp proliant dl580g7 with no problems. attached files are from /tmp from /var/log there only 2 files boot.log and wtmp, all others are with length 0
Attached Files:	rocky9onDL380G7.png (179,995 bytes) 2022-09-26 18:40 https://bugs.rockylinux.org/file_download.php?file_id=232&type=bug anaconda.log (11,715 bytes) 2022-09-26 18:40 https://bugs.rockylinux.org/file_download.php?file_id=233&type=bug dbus.log (3,330 bytes) 2022-09-26 18:40 https://bugs.rockylinux.org/file_download.php?file_id=234&type=bug dnf.librepo.log (454 bytes) 2022-09-26 18:40 https://bugs.rockylinux.org/file_download.php?file_id=235&type=bug packaging.log (432 bytes) 2022-09-26 18:40 https://bugs.rockylinux.org/file_download.php?file_id=236&type=bug program.log (1,435 bytes) 2022-09-26 18:40 https://bugs.rockylinux.org/file_download.php?file_id=237&type=bug X.log (21,711 bytes) 2022-09-26 18:46 https://bugs.rockylinux.org/file_download.php?file_id=238&type=bug

Notes
(0000562) Nikolay Penchev 2022-09-26 18:43	not all attached files are uploaded

(0000563) Nikolay Penchev 2022-09-26 18:46

(0000564) Benjamin Webb 2022-09-27 05:37	I saw the exact same error ("gnome-kiosk exited with status 1") on a couple of my Rocky 9 installs too - I believe one machine was an HP DL380G6, the other a DL380G7. If it helps at all, I found that a VNC install worked fine.

(0000565) Nikolay Penchev 2022-09-27 09:07	confirmed, VNC install works. (Benjamin's workaround)

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
299	[Rocky-Linux-8] selinux-policy	minor	N/A	2022-09-15 19:44	2022-09-15 19:44

Reporter:	Elliott Balsley	Platform:
Assigned To:		OS:	Rocky
Priority:	normal	OS Version:	8.6
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	SELinux is preventing mdadm from ioctl access on the blk_file /dev/nvme11n1
Description:	I'm seeing this SELinux message every few minutes. I have 22 identical NVMe drives in this machine, configured as RAID 60 using mdadm. I don't know what's unique about this one, but this is the only one showing this error. I believe mdadm should be allowed this access by default. ``` # sealert -l 917240ff-1abf-4e9f-980e-ae9400e137bb SELinux is preventing /usr/sbin/mdadm from ioctl access on the blk_file /dev/nvme11n1. *** Plugin catchall (100. confidence) suggests ************************ If you believe that mdadm should be allowed ioctl access on the nvme11n1 blk_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'mdadm' --raw \| audit2allow -M my-mdadm # semodule -X 300 -i my-mdadm.pp Additional Information: Source Context system_u:system_r:pcp_pmcd_t:s0 Target Context system_u:object_r:nvme_device_t:s0 Target Objects /dev/nvme11n1 [ blk_file ] Source mdadm Source Path /usr/sbin/mdadm Port <Unknown> Host moonshine Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-3.14.3-95.el8_6.4.noarch Local Policy RPM selinux-policy-targeted-3.14.3-95.el8_6.4.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name moonshine Platform Linux moonshine 4.18.0-372.19.1.el8_6.x86_64 #1 SMP Tue Aug 2 16:19:42 UTC 2022 x86_64 x86_64 Alert Count 944 First Seen 2022-09-07 00:03:11 PDT Last Seen 2022-09-15 12:22:37 PDT Local ID 917240ff-1abf-4e9f-980e-ae9400e137bb Raw Audit Messages type=AVC msg=audit(1663269757.936:7035): avc: denied { ioctl } for pid=339434 comm="mdadm" path="/dev/nvme11n1" dev="devtmpfs" ino=40986 ioctlcmd=0x1268 scontext=system_u:system_r:pcp_pmcd_t:s0 tcontext=system_u:object_r:nvme_device_t:s0 tclass=blk_file permissive=1 Hash: mdadm,pcp_pmcd_t,nvme_device_t,blk_file,ioctl ``` ``` # ls -lZ /dev/nvmen brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 1 Sep 7 09:25 /dev/nvme0n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 7 Sep 7 09:25 /dev/nvme10n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 9 Sep 7 09:25 /dev/nvme11n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 10 Sep 7 09:25 /dev/nvme12n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 12 Sep 7 09:25 /dev/nvme13n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 23 Sep 7 09:25 /dev/nvme14n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 15 Sep 7 09:25 /dev/nvme15n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 21 Sep 7 09:25 /dev/nvme16n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 13 Sep 7 09:25 /dev/nvme17n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 24 Sep 7 09:25 /dev/nvme18n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 20 Sep 7 09:25 /dev/nvme19n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 0 Sep 7 09:25 /dev/nvme1n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 29 Sep 7 09:25 /dev/nvme20n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 28 Sep 7 09:25 /dev/nvme21n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 11 Sep 7 09:25 /dev/nvme22n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 16 Sep 7 09:25 /dev/nvme22n1p1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 17 Sep 7 09:25 /dev/nvme22n1p2 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 19 Sep 7 09:25 /dev/nvme22n1p3 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 22 Sep 7 09:25 /dev/nvme23n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 25 Sep 7 09:25 /dev/nvme23n1p1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 26 Sep 7 09:25 /dev/nvme23n1p2 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 27 Sep 7 09:25 /dev/nvme23n1p3 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 2 Sep 7 09:25 /dev/nvme2n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 3 Sep 7 09:25 /dev/nvme3n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 4 Sep 7 09:25 /dev/nvme4n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 5 Sep 7 09:25 /dev/nvme5n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 6 Sep 7 09:25 /dev/nvme6n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 8 Sep 7 09:25 /dev/nvme7n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 18 Sep 7 09:25 /dev/nvme8n1 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 14 Sep 7 09:25 /dev/nvme9n1 ``` ``` # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 2.1G 0 rom nvme1n1 259:0 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme0n1 259:1 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme2n1 259:2 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme3n1 259:3 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme4n1 259:4 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme5n1 259:5 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme6n1 259:6 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme10n1 259:7 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme7n1 259:8 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme11n1 259:9 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme12n1 259:10 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme22n1 259:11 0 477G 0 disk ├─nvme22n1p1 259:16 0 1M 0 part ├─nvme22n1p2 259:17 0 1.5G 0 part └─nvme22n1p3 259:19 0 475.4G 0 part └─ubuntu--vg-ubuntu--lv 253:3 0 100G 0 lvm nvme13n1 259:12 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme17n1 259:13 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme9n1 259:14 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme15n1 259:15 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme8n1 259:18 0 5.8T 0 disk └─md101 9:101 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme19n1 259:20 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme16n1 259:21 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme23n1 259:22 0 477G 0 disk ├─nvme23n1p1 259:25 0 600M 0 part /boot/efi ├─nvme23n1p2 259:26 0 1G 0 part /boot └─nvme23n1p3 259:27 0 475.4G 0 part ├─rl-root 253:0 0 70G 0 lvm / ├─rl-swap 253:1 0 4G 0 lvm [SWAP] └─rl-home 253:2 0 401.4G 0 lvm /home nvme14n1 259:23 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme18n1 259:24 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme21n1 259:28 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid nvme20n1 259:29 0 5.8T 0 disk └─md102 9:102 0 52.4T 0 raid6 └─md0 9:0 0 104.8T 0 raid0 └─md0p1 259:30 0 104.8T 0 md /mnt/raid ```
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
161	[Rocky Services] Mirror Manager	minor	always	2022-07-21 19:45	2022-08-24 14:41

Reporter:	Louis Abel	Platform:
Assigned To:	Neil Hanlon	OS:	Rocky Linux
Priority:	high	OS Version:	9.0
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[Mirror Manager] boot.iso images refer to BaseOS/AppStream/extras-9.0 which report 404
Description:	Reported in our mattermost by txj, the boot.iso images do not properly find repository information. The boot.iso's cannot properly work without adding a repository as the default behavior is taking "9.0" as the $releasever. As mirror manager does not have aliases for these three primary repositories, it reports a 404 and the boot.iso installer reports that it cannot find repository information. There should be three aliases per release: BaseOS-X.Y -> rocky-BaseOS-X.Y AppStream-X.Y -> rocky-AppStream-X.Y extras-X.Y -> rocky-extras-X.Y This should fix not only 9.0, but eventually the 8.X series when moved to peridot. This only affects the boot.iso images produced and does not affect an installed operating system as it dnf will use just the major version. Optionally, when 8.7/9.1 release, the older 8.6 and 9.0 could potentially stick around but what it refers to (rocky-NAME-X.Y) could point to the vault instead to allow older installation media to continue working.
Tags:
Steps To Reproduce:	Boot up a boot.iso image of Rocky Linux 8.6 and it will succeed finding repository information. Boot up a boot.iso image of Rocky Linux 9.0 and it will fail to find repository information.
Additional Information:	There will also be cases where aliases for the beta and lookahead will be needed, but mostly the former. BaseOS-X.Y-beta -> rocky-BaseOS-X.Y-beta AppStream-X.Y-beta -> rocky-AppStream-X.Y-beta extras-X.Y-beta -> rocky-extras-X.Y-beta BaseOS-X.Y-lookahead -> rocky-BaseOS-X.Y-lookahead AppStream-X.Y-lookahead -> rocky-AppStream-X.Y-lookahead extras-X.Y-lookahead -> rocky-extras-X.Y-lookahead
Attached Files:

Notes
(0000469) Neil Hanlon 2022-08-24 14:41	Resolved by creating repository redirect for the major versions. Going forward we will add this to the toolkit to keep in check.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
166	[Rocky-Linux-9] NetworkManager	block	always	2022-07-29 05:57	2022-08-24 07:23

Reporter:	Pascal Häussler	Platform:
Assigned To:		OS:
Priority:	high	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	NetworkManager fails to configure IP over InfiniBand (IPoIB) connections
Description:	We setup a HPE ProLiant DL380 system with Rocky 9 minimal install. Based on that, we installed InfiniBand support (`dnf group install "InfiniBand Support"`). The HPE InfiniBand NIC (in fact, a Mellanox ConnectX 5 adapter) is detected and the kernel modules are loaded. Both, a ib verbs capable IB device `mlx5_0`and a IPoIB default device `ips2`are available. When trying to configure an IPoIB connection with NetworkManager `nmcli` along the steps described in the RHEL 9 manual on InfiniBand support, NetworkManager fails to bring the connection up. We see these log entries in `journalctl`: ``` Jul 29 07:46:37 master01.c.hpc.zhaw.ch NetworkManager[1521]: <info> [1659073597.0438] device (ibs2): Activation: starting connection 'mlx5-ipoib' (e60615fc-b9fc-48fd-9797-db1addb6625e) Jul 29 07:46:37 master01.c.hpc.zhaw.ch NetworkManager[1521]: <info> [1659073597.0439] device (ibs2): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Jul 29 07:46:37 master01.c.hpc.zhaw.ch NetworkManager[1521]: <warn> [1659073597.4487] device (ibs2): mtu: failure to set IPv6 MTU Jul 29 07:46:37 master01.c.hpc.zhaw.ch NetworkManager[1521]: <info> [1659073597.4487] device (ibs2): state change: prepare -> failed (reason 'config-failed', sys-iface-state: 'managed') Jul 29 07:46:37 master01.c.hpc.zhaw.ch NetworkManager[1521]: <warn> [1659073597.4489] device (ibs2): Activation: failed for connection 'mlx5-ipoib' Jul 29 07:46:37 master01.c.hpc.zhaw.ch NetworkManager[1521]: <info> [1659073597.4491] device (ibs2): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') Jul 29 07:46:37 master01.c.hpc.zhaw.ch NetworkManager[1521]: <warn> [1659073597.4493] device (ibs2): mtu: failure to set IPv6 MTU Jul 29 07:46:37 master01.c.hpc.zhaw.ch NetworkManager[1521]: <info> [1659073597.4730] device (ibs2): carrier: link connected ``` The connection `mlx5-ipoib`doesn't come online but remains in disconnected state: ``` [root@master01 ~]# nmcli con sh NAME UUID TYPE DEVICE br1 cd93090e-f721-4e7b-87f9-7c1dde6fb994 bridge br1 br0 d7f956d0-f696-43b8-9ba4-86e3541aaa1e bridge br0 bond1 ead7ec11-04d5-4d00-8772-d34412e911d2 bond bond1 bond1-eno5 56affc33-d0bf-4081-b36e-527e6ea02da9 ethernet eno5 bond1-eno6 a4f443b9-35fa-416e-93f6-befe2b07b0d7 ethernet eno6 eno1 787aaf7c-58d7-361c-a85b-48b801a7e4ac ethernet eno1 eno2 2af9052d-6922-4398-bc96-68b7f5f12bef ethernet -- eno3 5af585d0-cd7f-49ba-9e37-f034b5ca0399 ethernet -- eno4 24b4ebd6-c39b-4b5a-a466-1f56bc8df945 ethernet -- eno5 e3d6d805-8919-3131-a47e-cbe9d4341037 ethernet -- eno6 0ad230e1-b47c-389e-bceb-a1722b0fdbee ethernet -- mlx5-ipoib e60615fc-b9fc-48fd-9797-db1addb6625e infiniband -- ``` The device configured for this connection, namely `ibs2`is in a disconnected state: ``` [root@master01 ~]# nmcli device DEVICE TYPE STATE CONNECTION br1 bridge connected br1 br0 bridge connected br0 bond1 bond connected bond1 eno1 ethernet connected eno1 eno5 ethernet connected bond1-eno5 eno6 ethernet connected bond1-eno6 ibs2 infiniband disconnected -- eno2 ethernet unavailable -- eno3 ethernet unavailable -- eno4 ethernet unavailable -- lo loopback unmanaged -- ``` I can reproduce this error on a second system with the exact same hardware. Note: Both of these systems were running on CentOS 7.8 before and uses a peer-to-peer IPoIB connections on these adapters successfully.
Tags:
Steps To Reproduce:	- Install Rocky Linux 9.0 minimal - Install InfiniBand support - Install and start `opensm`subnet manager - Configure IPoIB support as explained in the RHEL 9 manual "Configuring InfiniBand and RDMA support" - Try to gring up the IPoIB connection
Additional Information:	Commands used to configure the connection: ``` nmcli connection add type infiniband con-name mlx5_ib0 ifname ibs2 transport-mode Connected mtu 65520 nmcli connection modify mlx5_ib0 ipv4.addresses 10.20.1.1/24 nmcli connection modify mlx5_ib0 ipv4.method manual nmcli connection modify mlx5_ib0 ipv6.method ignore nmcli connection up mlx5_ib0 ``` Note: As you can see, we set IPv6 support to "ignore". Nevertheless, in the journalctl log excerpt above you can see a warning saying that setting IPv6 MTU fails.
Attached Files:

Notes
(0000467) Pascal Häussler 2022-08-24 07:23	+++ Update +++ This issue might be caused by MELLANOX_OFED v5 inside the RHEL InfiniBand support packages. I found a known issue on this NVIDIA/Mellanox site descritbing exactly this problem on RHEL systems (see issue 1061298 in the table): https://docs.nvidia.com/networking/display/OFEDv501000/Known+Issues I don't know what OFED version is contained in Rocky 9/RHEL 9 but the issue described there is exactly what we observe. The suggested work arround, namely using NO or AUTO as setting for the connection mode works albeit this is not optimal.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
233	[Rocky-Linux-8] NetworkManager	minor	always	2022-08-19 23:08	2022-08-19 23:08

Reporter:	Jonathon Anderson	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky Linux 8 network-scripts package contains "RHEL" in deprecation notification
Description:	WARN : [ifup] You are using 'ifup' script provided by 'network-scripts', which are now deprecated. WARN : [ifup] 'network-scripts' will be removed in one of the next major releases of RHEL. WARN : [ifup] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well.
Tags:
Steps To Reproduce:	Have the network-scripts package installed, not NetworkManager, and ifup/ifdown a network interface.
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
181	[Rocky-Linux-9] dracut	minor	have not tried	2022-08-15 10:38	2022-08-15 10:38

Reporter:	Armughan Bhutta	Platform:	Rocky Linux
Assigned To:		OS:
Priority:	normal	OS Version:	RL9
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	While running "dnf update" I encountered this error.
Description:	I spin up new RL9 box on aws upon running dnf update encountered this.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	Screenshot 2022-08-15 at 2.39.58 PM.png (494,530 bytes) 2022-08-15 10:38 https://bugs.rockylinux.org/file_download.php?file_id=86&type=bug

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
180	[Rocky-Linux-9] Installer	crash	always	2022-08-12 19:31	2022-08-12 22:07

Reporter:	Lech Lobocki	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	needinfo	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Installer fails to read the iso image from a exfat formatted usb pendrive
Description:	Installer fails to read the iso image from an exfat-formatted usb pendrive. It is possible to redirect reading the source ISO by copying it into an ext4 or xfs filesystem available during installation (e.g., a disk partition)
Tags:
Steps To Reproduce:	Copy any of the x86_64 images (minimal, dvd or boot) onto an USB pendrive with an exFAT system (I used Ventoy). Start installer by booting from USB. Upon loading, it reports errors reading the ISO image.
Additional Information:	This problem did not occur with Rocky 8.6 installation. Apparently, fuse-exfat is not available to the installer.
Attached Files:

Notes
(0000342) Louis Abel 2022-08-12 19:54 (Last edited: 2022-08-12 19:55)	https://github.com/ventoy/Ventoy/issues/1636 I would suggest to try booting CentOS Stream 9 and/or RHEL 9 and see if you get the same results as you've reported (and similar to the above upstream github issue). If you cannot fully replicate the issue, then we can do some troubleshooting and investigation to find the possible cause to the problem.

(0000343) Lech Lobocki 2022-08-12 22:07	Yes, exactly the same problem with CentOS Stream 9

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
177	[Rocky-Linux-8] php	tweak	always	2022-08-09 09:41	2022-08-09 09:41

Reporter:	Benedict Rosner	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	php-7.4 - yum updateinfo shows RLSA-2022:5467 even tho patch is merged
Description:	yum updateinfo --list gives me the following list: Last metadata expiration check: 3:09:04 ago on Tue 09 Aug 2022 07:04:44 AM CEST. RLSA-2022:5467 Important/Sec. php-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-cli-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-common-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-fpm-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-gd-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-ldap-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-mbstring-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-opcache-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-pdo-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 RLSA-2022:5467 Important/Sec. php-xml-8.0.13-3.module+el8.6.0+989+3fbff15c.x86_64 You can see that the patch was included in the changelog: yum changelog php Last metadata expiration check: 0:00:05 ago on Tue 09 Aug 2022 11:24:55 AM CEST. Listing all changelogs Changelogs for php-7.4.19-3.module+el8.6.0+990+389ef54a.x86_64 * Wed Jun 22 12:00:00 AM 2022 Remi Collet <rcollet@redhat.com> - 7.4.19-3 - fix password of excessive length triggers buffer overflow leading to RCE CVE-2022-31626 ... https://errata.rockylinux.org/RLSA-2022:5467 shows the installed version to be affected: php-7.4.19-3.module+el8.6.0+990+389ef54a.x86_64.rpm
Tags:
Steps To Reproduce:	install php-7.4 module run yum update check with yum updateinfo --list this will show a couple of critical patches
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
171	[Rocky-Linux-8] Installer	major	have not tried	2022-08-02 21:33	2022-08-05 12:55

Reporter:	Andres Tarallo	Platform:	x86_64
Assigned To:		OS:	Rocky Linux
Priority:	high	OS Version:	8.6
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Network Card Goes Down after a few minutes ... Misconfigured on Install
Description:	Did a fresh install from DVD, Configured network card on the Installer. Filled in the necessary parameters in Network configuration (IP Address, mask, DNS...). After booting I logged into the system via SSH. After a few minutes the session freezes. I logged from the console and noticed the network interface was down. Tried to bring it up from nmtui, without success. After a few times this happend I went to run "journalctl -xe". I've noticed messages from DHCPCD. Then went again to nmtui. I've noticed that the network card was configured in "automatic" but had the parameters of manual configuration.
Tags:
Steps To Reproduce:	Do the install. Configure Network card from the installer. keep the configuration in automatic (DHCP) and fill in the parameters needed for manual configuration.
Additional Information:	Need to check this on RHEL 8.6.
Attached Files:	Screenshot_20220804_130436.png (145,571 bytes) 2022-08-04 16:42 https://bugs.rockylinux.org/file_download.php?file_id=73&type=bug Screenshot_20220804_123128.png (101,526 bytes) 2022-08-04 16:42 https://bugs.rockylinux.org/file_download.php?file_id=74&type=bug

Notes
(0000324) Andres Tarallo 2022-08-04 16:42	I continued investigating. Today I had a freshly installed RockyLinux 8.6, network wasn't configured during install. I've fired nmtui and did manual configuration. On purpose I've keep automatic and provided manual configuration parameters (IP/Mask, default gateway and DNS). Got the same behaviour. Did screenshots that attached to this note. I'm now thinking that this might be a network-manager Issue, not an Installer bug.

(0000326) Louis Abel 2022-08-05 02:35	Thank you for the report. This doesn't appear to be a bug and is normal behavior with network manager (where the configuration stays "automatic" despite filling in static data). If you are configuring a static address, you generally should set the method to manual. On the command line for example, you would use `nmcli con mod <interface> ipv4.method manual` to ensure that this is the case. Otherwise, auto is the default. This is the case whether you're doing it from nmcli, nmtui, or the installer.

(0000327) Andres Tarallo 2022-08-05 12:55	I don't understand this as a bug too, mostly misfeature. I wouldn't realize of this if I did it in a network with an active DHCP server. I think that at least the graphicall installer shouldn't let you fill manual values, when you choose automatic. It took me several minutes to find out what's going on.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
169	[Rocky-Linux-9] shim	block	always	2022-07-31 09:33	2022-07-31 12:31

Reporter:	Arvid Schneider	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	After picking boot loader in bios start_image() error
Description:	This is an upstream bug experienced on a variety of Dell hardware, and sometimes others. This issue is for tracking the upstream issue and as a place to collate similar reports. Here's the launchpad issue: https://github.com/elementary/triage/issues/74 https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1937115 Note: This particular issue only affects booting from the live-media and does not affect the installed system. So if you use one of the workarounds, you only have to apply it once to get the install media to boot, then the installed system will work fine.
Tags:
Steps To Reproduce:
Additional Information:	Same issue on Ubuntu https://github.com/elementary/triage/issues/74
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
168	[Rocky Services] RFE	major	N/A	2022-07-29 20:28	2022-07-29 20:28

Reporter:	Louis Abel	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[RFE] Setup a debuginfod server
Description:	There are several packages and several builds that may or may not have a debuginfod URL set. With upcoming releases of 8.7 and 9.1 in the fall, new RPM macros will be introduced that require a URL (fake or otherwise). However, we should have an actual debuginfod server hosted at https://debuginfod.rockylinux.org
Tags:
Steps To Reproduce:
Additional Information:	Relevant Fedora Wiki: https://fedoraproject.org/wiki/Debuginfod
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
167	[Rocky-Linux-8] dnf	minor	always	2022-07-29 08:50	2022-07-29 08:50

Reporter:	Fabian Lesniak	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	dnf can't install updates if packages already downloaded
Description:	This is a duplicate of RH/Fedora Bug 2024527 https://bugzilla.redhat.com/show_bug.cgi?id=2024527. For some locales, e.g. de_DE.UTF-8, dnf fails to install updates if some of the packages are already downloaded: Fehler: Fehler beim Herunterladen der Pakete: java-1.8.0-openjdk-headless-1:1.8.0.342.b07-2.el8_6.x86_64: Already downloaded A workaround is to clean the package cache and restart the upgrade process. The fix has already been pushed to Fedora 35/36, but is still present in Rocky 8.6. The patch can be found here: https://koji.fedoraproject.org/koji/rpminfo?rpmID=29932072
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
163	[Rocky-Linux-8] NetworkManager	minor	always	2022-07-26 18:32	2022-07-26 18:32

Reporter:	Tim Orbaker	Platform:	x64 (Inspiron 3783)
Assigned To:		OS:	Rocky Linux
Priority:	none	OS Version:	8.5
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Problems with (QC9377) ath10k partially disconnecting with firmware api6
Description:	After an amount of time without establishing a new connection, the wireless network interface (Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31)) refuses to connect to anything until the wifi is disabled and restarted. How it is restarted (gnome interface, restarting NetworkManager or rebooting) does not seem to matter in terms of whether or not function returns or how long the interval is between occurrences. The wired interface is not affected when this happens. Interestingly, the interface does not have to be idle, and existing connections are not terminated (Zoom meetings and SSH sessions), but new connections cannot be created (ping, DNS queries, new SSH sessions). I have continued a Zoom meeting long after my browser stopped being able to do DNS resolution without an issue. No messages were found in any of the logs or with dmesg when this occurs, and the network requests for new connections eventually time out. The interface still shows that it is connected and the system acts as if the Internet is disconnected at the router, although existing connections are not affected. Disabling power management, first for the QC9377 network interface, and then for the entire system did not produce any noticable difference. it happens at roughly the same frequency whether connected to power or not. All available updates were applied. The problem turned out to be the firmware file: /lib/firmware/ath10k/QCA9377/hw1.0/firmware-6.bin If this is removed, then /lib/firmware/ath10k/QCA9377/hw1.0/firmware-5.bin is used and the system functions properly. To verify the fix, use the desg command below and look for "api 5" System information: This is a Dell Inspiron 3783 Diagnosis: see line 5 below ("api 6") $ dmesg \| grep '] ath10k' [ 6.623522] ath10k_pci 0000:03:00.0: enabling device (0000 -> 0002) [ 6.624123] ath10k_pci 0000:03:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 6.830599] ath10k_pci 0000:03:00.0: qca9377 hw1.1 target 0x05020001 chip_id 0x003821ff sub 1028:1810 [ 6.830604] ath10k_pci 0000:03:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 [ 6.831134] ath10k_pci 0000:03:00.0: firmware ver WLAN.TF.1.0-00002-QCATFSWPZ-5 api 6 features ignore-otp crc32 c3e0d04f [ 6.894966] ath10k_pci 0000:03:00.0: board_file api 2 bmi_id N/A crc32 8aedfa4a [ 6.996282] ath10k_pci 0000:03:00.0: htt-ver 3.44 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1 [ 7.070153] ath10k_pci 0000:03:00.0 wlp3s0: renamed from wlan0 Device information $ sudo lspci -vvvvv 03:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31) Subsystem: Dell Device 1810 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 142 Region 0: Memory at b2000000 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit- Address: fee004d8 Data: 0000 Masking: 000000fe Pending: 00000000 Capabilities: [70] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Via message, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCap2: Supported Link Speeds: 2.5GT/s, Crosslink- Retimer- 2Retimers- DRS- LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout+ AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [148 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Capabilities: [168 v1] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [178 v1] Latency Tolerance Reporting Max snoop latency: 3145728ns Max no snoop latency: 3145728ns Capabilities: [180 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=50us PortTPowerOnTime=10us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=81920ns L1SubCtl2: T_PwrOn=10us Kernel driver in use: ath10k_pci Kernel modules: ath10k_pci
Tags:	glitch
Steps To Reproduce:	The amount of time to the appearance of the problem is consistent. The appearance of the problem is consistent. The key feature is going a period of time without establishing a new connection. Allowing the system to sit idle will cause the problem as well. The system may be idle, but this is not a condition of the problem. I have had it happen during a ZOOM meeting, I have had it happen during an SSH session. What is consistent is that the wireless network interface refuses to establish any new connections, even to local addresses.
Additional Information:	I am unsure if this the proper place to report this (it is an upstream product, I can't find a section for wireless drivers or the ath10k driver). It drove me crazy for a week and a half I just want anyone else having the problem to be able to find the solution somewhere.
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
68	[Cloud] General	minor	always	2021-11-01 22:34	2022-07-21 14:30

Reporter:	Michael De La Rue	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky Linux AWS Images should be released as public AMIs
Description:	Currently the official Amazon Machine Images (AMIs) are available only in the AWS market place. That's a fine place but it means that the images aren't available until a user subscribes, so if they search for Rocky by default they get unofficial images which may or may not be updated later. Please publish the AMIs as public ones. See also 0000172 and https://forums.rockylinux.org/t/rocky-linux-official-aws-ami/3049/14 (which also states that this would be useful when creating an instance using Terraform) N.B. This is already under discussion as https://github.com/rocky-linux/rockylinux.org/issues/197 - however now I finally have bug access I want to put it in the right tracker. I'm happy to do this worl but don't think I have the right access now. ===Reproducer=== 1) go to AWS EC2 console https://us-east-2.console.aws.amazon.com/ec2/v2/home?region=us-east-2#Instances: 2) click launch instance 3) type rocky in search and then enter expected result: official rocky linux image shows up actual result no images visible and links to some groups in which there are unoffical images.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000300) Neil Hanlon 2022-07-21 14:30	Closing as all images are now available publically.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
159	[Containers] General	major	always	2022-07-21 09:55	2022-07-21 09:55

Reporter:	CHATRI NGAMBENCHAWONG	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Some Encoding in missing when update base image from rocky8.5 > 8.6
Description:	Some Encoding in missing when update base image from rocky8.5 > 8.6
Tags:	image
Steps To Reproduce:
Additional Information:	1. pull rockylinux:8 2. docker run -it rockylinux:8 3. check os version cat /etc/os-release VERSION_ID = "8.6" .... 4. check some encoding such as TIS iconv -l : grep TIS 5. the result for 4 is Empty Try same step on rockylinux:5 found TIS** Encoding . Your can see more detai in attachment file
Attached Files:	FYGR4zbVEAACtdh.jpg (178,132 bytes) 2022-07-21 09:55 https://bugs.rockylinux.org/file_download.php?file_id=72&type=bug

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
153	[Rocky Linux Build System] RFE	minor	N/A	2022-07-19 18:01	2022-07-19 18:01

Reporter:	Louis Abel	Platform:
Assigned To:	Louis Abel	OS:
Priority:	high	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Store source repositories in vault or another location by default
Description:	Using a combination of empanadas and mirror manager, the source repositories should be synced to a different location away from the normal repositories (similar to how CentOS traditionally sorted the "source" repositories of their composes to the vault by default). This should reduce the storage burden on most mirrors that do not need or wish to sync these packages and should also reduce the time it takes for hardlink to run on our side. Alternatively, mirror scripts or configurations can be tailored for mirrors to selectively sync what they choose to (some mirrors already do this, but we should make it more flexible for everyone else). A quick-fedora-mirror configuration is being designed for mirrors for this purpose.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
142	[Rocky Linux Build System] empanadas	major	N/A	2022-07-14 03:50	2022-07-14 03:50

Reporter:	Louis Abel	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[empanadas] Add side ISO builds for minimal images
Description:	Minimal images are currently manual. Milestone is referenced at git.resf.org: https://git.resf.org/sig_core/toolkit/milestone/1
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
114	[Containers] General	major	always	2022-06-02 08:08	2022-07-07 18:03

Reporter:	Hayden Young	Platform:	Linux
Assigned To:		OS:	*
Priority:	normal	OS Version:	*
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Docker Hub official image hasn't been up to date since 8.5
Description:	The 'official' Docker Hub image (library/rockylinux, https://hub.docker.com/_/rockylinux) has not been updated since 8.5's release ~3mo. ago, where the rockylinux/rockylinux image has been kept up to date just fine. (https://hub.docker.com/r/rockylinux/rockylinux) I can see that rockylinux/rockylinux is updated by @neilresf, where library/rockylinux is updated by @doijanky, not sure who that is but I think we ought to be updating both of the Docker image repos every update. --- Link to original Mattermost thread: https://chat.rockylinux.org/rocky-linux/pl/t8qsyyz3dbfspc65f3g51qh5cr
Tags:
Steps To Reproduce:	- `docker pull docker.io/library/rockylinux` - `podman pull docker.io/library/rockylinux` Either works
Additional Information:
Attached Files:

Notes
(0000251) Neil Hanlon 2022-07-07 18:03	New images are uploaded to docker hub in the rockylinux namespace and are in a PR to push to the official library. Thank you for your patience! we'll automate this going forward

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
135	[Rocky Linux Build System] empanadas	major	N/A	2022-06-28 18:33	2022-07-04 19:05

Reporter:	Louis Abel	Platform:
Assigned To:	Louis Abel	OS:
Priority:	high	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[empanadas] Pull ISO's from empanadas bucket to build and pull ISO's from peridot
Description:	Empanadas should be able to pull ISO's, much like pulling lorax data to build the ISO's in the first place.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000246) Louis Abel 2022-07-04 19:05	Shared functions now contain the reqs and s3 functions to pull down different types of images. Future work will be done to add "filters" as live images will potentially be made in peridot as well.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
129	[Account Services] General	feature	N/A	2022-06-26 19:37	2022-06-26 19:37

Reporter:	Louis Abel	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[SSO] Setup a dex service to replace keycloak/ipsilon
Description:	Currently, account services is a mix of noggin, keycloak, and ipsilon. Keycloak is a java program, ipsilon is a python program ran in the context of httpd. We would like to use dex to replace keycloak and ipsilon where possible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
128	[Rocky Linux Build System] empanadas	feature	N/A	2022-06-26 19:34	2022-06-26 19:35

Reporter:	Louis Abel	Platform:
Assigned To:	Louis Abel	OS:
Priority:	urgent	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[empanadas] Add parallel rsync support to avoid using parallel\|rsync
Description:	Currently, sync-to-staging.sh and sync-to-prod.sh is used to sync to staging or from staging to production. This uses a bash script with a combination of parallel and rsync. This should be brought into empanadas for consistent syncing functionality and to remove the need to use parallel and rsync hacks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
127	[Rocky Linux Build System] empanadas	feature	N/A	2022-06-26 19:33	2022-06-26 19:33

Reporter:	Louis Abel	Platform:
Assigned To:	Louis Abel	OS:
Priority:	urgent	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[empanadas] Add SIG deployment support
Description:	Just like sync-from-peridot can sync from peridot for the base repositories, SIG's should also have the same treatment and ability.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
124	[Cloud] General	major	always	2022-06-09 16:25	2022-06-23 15:51

Reporter:	Ming NI	Platform:	AWS
Assigned To:	Neil Hanlon	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky-8-GenericCloud-8.6-20220515.x86_64.qcow2 import to AWS-CN AMI error
Description:	Hello, Rocky I am in Mainland China and using AWS-CN for cloud service. Since AWS-CN doesn't officially provide the Rocky 8 AMI, so I import it to my own account. with the general AWS import VM process(https://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-image-import.html#upload-image), the IAM role was already promised. with aws-cli import, the AMI import process gets error: deleted ClientError: Unable to find an etc directory with fstab. I think it is the incomplete qcow2 image. I checked the checksum of the current 8.6 qcow2, the file itself is promised the same as current release. 77e79f487c70f6bfa5655d8084e02cb8d31900a2c2a22b2334c3401b40a1231c Rocky-8-GenericCloud-8.6-20220515.x86_64.qcow2
Tags:	cloud, image, qcow2
Steps To Reproduce:	1. # qemu-img info Rocky-8-GenericCloud-8.6-20220515.x86_64.qcow2 provides: file format: qcow2 virtual size: 3.3G (3492806656 bytes) disk size: 818M cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false but similarly, for the Rocky-8.5.qcow2 # qemu-img info Rocky-8-GenericCloud-8.5-20211114.2.x86_64.qcow2 provides: image: Rocky-8-GenericCloud-8.5-20211114.2.x86_64.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 1.4G cluster_size: 65536 Format specific information: compat: 0.10 refcount bits: 16 2. change the qcow2 file to raw file qemu-img convert Rocky-8-GenericCloud-8.6-20220515.x86_64.qcow2 Rocky-8.6.raw 3. cp the raw file to S3 aws s3 cp Rocky-8.6.raw s3://your-bucket 4. write raw image import json file as Rocky-8.6.json. [ { "Description": "Rocky-8.6", "Format": "RAW", "Url": "s3://your-bucket/Rocky-8.6.raw" } ] 5. aws-cli import the raw file as AMI aws ec2 import-image --description "Rocky 8.6" --disk-containers "file://Rocky-8.6.json" you will get a import-ami-XXXXX code 6. check the AMI import status aws ec2 describe-import-image-tasks --import-task-ids import-ami-XXXX get an error deleted ClientError: Unable to find an etc directory with fstab. ---- The same process with the Rocky-8-GenericCloud-8.5-20211114.2.x86_64.qcow2, it passed successfully.
Additional Information:
Attached Files:

Notes
(0000239) Neil Hanlon 2022-06-23 15:50	Hi There! Sorry for the delay in responding. The images are actually different from the GenericCloud images. I can upload them for you, but you should now be able to access them directly in this region, or clone it from another. The GenericCloud images are intended for use with something like an OpenStack cluster, or KVM via libvirt, e.g. Best, Neil

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
123	[Rocky-Linux-8] Installer	major	always	2022-06-07 20:29	2022-06-07 21:27

Reporter:	Joshua Kugler	Platform:	x86_64
Assigned To:		OS:	Linux
Priority:	normal	OS Version:	8.6
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Installation Source defaults are flagged as wrong, and won't allow you to exit
Description:	Entering the "Installation Source" screen in the installer either says the defaults are wrong, or the network is not enabled, and won't allow you exit without changes.
Tags:
Steps To Reproduce:	1. Start installation 2. Select language 3. On the "Installation Summary" screen, click "Installation Source." Without making any changes, get first screen shot, and I cannot exit back to the summary. 4. Reboot 5. Configure network first 6. Click "Installation Source." Without making any changes, get second screen shot, and cannot exit back to the summary.
Additional Information:
Attached Files:	Image Pasted at 2022-6-7 11-40.jpg (99,234 bytes) 2022-06-07 20:29 https://bugs.rockylinux.org/file_download.php?file_id=39&type=bug Image Pasted at 2022-6-7 11-42.jpg (98,425 bytes) 2022-06-07 20:29 https://bugs.rockylinux.org/file_download.php?file_id=40&type=bug

Notes
(0000234) Lukas Magauer 2022-06-07 21:27	Tested and noticed that this behavior only affects the Rocky Linux 8.6 minimal ISO. (not 8.6 boot and dvd1, not 8.5 boot, minimal and dvd1, not RHEL 8.6 boot and dvd) I suspect it searches for AppStream which is not configured and accessible. But there are two workarounds! Either configure network and network repos or click on the "Revert to previous list of repositories" (circle-arrow) button, which lets the errors disappear.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
120	[Rocky Linux Build System] General	minor	have not tried	2022-06-03 17:50	2022-06-03 17:50

Reporter:	Neil Hanlon	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	[secparse] Erratum issues with modular packages
Description:	I think this is the issue we know about w.r.t. erratum... https://community.theforeman.org/t/installable-errata-suddenly-shows-up-in-hosts-content-view-but-not-installable-via-content-view/28787/14
Tags:
Steps To Reproduce:
Additional Information:	>I reproduced the issue and I think I know what’s going on. >Rocky Linux is doing something a little strange and is including modular RPMs in the list of normal RPMs. On top of that, they included this RLSA-2021:3666 erratum that we singled out in both BaseOS and AppStream. Your content view filtered out the c-ares RPMs from BaseOS, so the erratum didn’t make it into there. However, the erratum did make it into AppStream because the c-ares RPMs don’t exist there at all. >Katello marked the erratum as applicable because the c-ares RPM is indeed applicable, and then it marked the erratum as installable because the erratum exists in your content view version. >Essentially it boils down to the relationship between AppStream and BaseOS, plus Rocky Linux seemingly doing something unexpected. >I think there is something here to be improved, regardless of whether or not Rocky Linux is doing something weird (I’m not 100% sure). Either we consider all of a CV’s repositories when deciding if an erratum should be thrown out (katello/yum.rb at KATELLO-4.3 · Katello/katello · GitHub) or we improve the “installable errata” query to not just look at which errata are in the host’s LCE. We’d also need to check if the errata’s RPMs are all available. I’ll make an issue.
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
117	[Rocky-Linux-9] General	minor	sometimes	2022-06-02 20:01	2022-06-02 20:04

Reporter:	Neil Hanlon	Platform:
Assigned To:	Mustafa Gezen	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Some tests in mariadb appear flaky
Description:	Tests sometimes fail with new openssl, as well as other fixes from upstream. +main.innodb_ext_key : MDEV-22119 - fails with NULL values +main.thread_pool_info : MDEV-20372 - thread_pool_info fails randomly in 10.5 +main.tls_version1 : MDEV-21965 - old TLS versions don't work on latest Debian and Ubuntu releases https://github.com/MariaDB/server/commit/6f0b621caf76cf636771cab2e78b6e1846b31c78
Tags:
Steps To Reproduce:	build maria with latest openssl
Additional Information:	https://git.rockylinux.org/staging/patch/mariadb/-/commit/84d4d79bfba903de1024918315812d7c246defbe
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
116	[Rocky-Linux-9] General	minor	sometimes	2022-06-02 19:57	2022-06-02 19:58

Reporter:	Neil Hanlon	Platform:
Assigned To:	Mustafa Gezen	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	NSS Fails to build due to expired cert
Description:	NSS build fails due to expired PayPalEE cert
Tags:
Steps To Reproduce:	Build NSS after expiration of bundled cert
Additional Information:	Fix: replace cert with new cert fetched from paypal.com https://git.rockylinux.org/staging/patch/nss/-/commit/9fe4ba105a102fbfcdd0ac4ae60f032d350e6076 need to remove patch once fixed upstream (issue upstream fix?)
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
109	[Rocky-Linux-8] google-gson	minor	always	2022-05-27 12:40	2022-05-27 12:40

Reporter:	Ross Fenning	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Unable to install google-gson-2.8.6-5.module+el8.6.0+852+cc16a686.noarch
Description:	Cannot install via yum/dnf. Even on a clean base of the official Docker image, I get the following: No available modular metadata for modular package 'google-gson-2.8.6-5.module+el8.6.0+852+cc16a686.noarch', it cannot be installed on the system The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: No available modular metadata for modular package
Tags:
Steps To Reproduce:	yum install google-gson
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
106	[Cloud] General	minor	always	2022-05-20 22:36	2022-05-22 20:07

Reporter:	Neil Hanlon	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	AMI names for 8.6 images differ from previous releases
Description:	From https://gist.github.com/quadespresso/2ee5533270103caf789eaf645a07baee --- For Rocky Linux 8.5, all AMI's in all regions follow the naming convention Rocky-8-ec2-8.5-YYYYMMDD.N.ARCH. Rocky Linux 8.6 doesn't quite follow this. Or rather, it appears to have started out that way in us-east-1, with partial success in us-east-2. That is, us-east-1 has these 8.6 AMI's: Rocky-8-ec2-8.6-20220515.0.aarch64 Rocky-8-ec2-8.6-20220515.0.x86_64 and us-east-2 has this slight variation: Copy of ami-0746c2106d76fa617 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 All of the other regions show these: Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1
Tags:
Steps To Reproduce:	#!/bin/bash for r in $(aws ec2 describe-regions \| jq '.Regions[].RegionName' -r) ; do echo "====================" echo "==== $r ====" # Rocky Linux owner ID 792107900819 aws --region $r ec2 describe-images \ --owners 792107900819 \ \| jq '.Images[].Name' -r \ \| cut -f2 -d/ \ \| sort -u
Additional Information:	==================== ==== eu-north-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== ap-south-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== eu-west-3 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== eu-west-2 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== eu-west-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== ap-northeast-3 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== ap-northeast-2 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== ap-northeast-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== sa-east-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== ca-central-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== ap-southeast-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== ap-southeast-2 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== eu-central-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== us-east-1 ==== Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 Rocky-8-ec2-8.6-20220515.0.aarch64 Rocky-8-ec2-8.6-20220515.0.x86_64 ==================== ==== us-east-2 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 Rocky-8-ec2-8.5-20220515.0.aarch64 ==================== ==== us-west-1 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64 ==================== ==== us-west-2 ==== Copy of ami-0746c2106d76fa617 from us-east-1 Copy of ami-09e5024730b047901 from us-east-1 Rocky-8-ec2-8.5-20211114.1.aarch64 Rocky-8-ec2-8.5-20211114.2.x86_64
Attached Files:

Notes
(0000178) Neil Hanlon 2022-05-22 19:54	x86_64: Making ami-0ebdcb3515daa1b1b in us-east-2 Public.... Still pending Making ami-0afb7029d2868f474 in us-west-1 Public.... Still pending Making ami-0b98dddee00301f7a in us-west-2 Public.... Still pending Making ami-0e6626ba54eb89af2 in ca-central-1 Public.... Still pending Making ami-0d73770c26336c028 in ap-south-1 Public.... Still pending Making ami-01eebb1fe2b7cd12a in sa-east-1 Public.... Still pending Making ami-08547e590b7ff4d5e in eu-north-1 Public.... Still pending Making ami-09d83868d196d9f80 in ap-northeast-1 Public.... Still pending Making ami-006062e95da41a7e0 in ap-northeast-2 Public.... Still pending Making ami-04431d6800b6d6e58 in ap-northeast-3 Public.... Still pending Making ami-053c6780c32bd5d5e in eu-central-1 Public.... Still pending Making ami-08ffb4dd21b37216f in eu-west-2 Public.... Still pending Making ami-06c9fd870b51b1216 in eu-west-3 Public.... Still pending Making ami-0a9761f7c8af71e13 in eu-west-1 Public.... Still pending Making ami-036b685d46ffd83a8 in ap-southeast-2 Public.... Still pending Making ami-0f6054d0561e79461 in ap-southeast-1 Public.... Still pending aarch64: Making ami-0b04b7ca309a8c399 in us-east-2 Public.... Still pending Making ami-0eaa13b719aa6ede6 in us-west-1 Public.... Still pending Making ami-01cf25f337dd859cd in us-west-2 Public.... Still pending Making ami-07c4bb5fdf45af78e in ca-central-1 Public.... Still pending Making ami-01c09e60d533c2a72 in ap-south-1 Public.... Still pending Making ami-0ccce94f818446f58 in sa-east-1 Public.... Still pending Making ami-073d5b5f420781fba in eu-north-1 Public.... Still pending Making ami-0d51a6a96a98db8bc in ap-northeast-1 Public.... Still pending Making ami-0cc0480c977b3b8ae in ap-northeast-2 Public.... Still pending Making ami-086ed01af639ff06c in ap-northeast-3 Public.... Still pending Making ami-0867fae26e716db00 in eu-central-1 Public.... Still pending Making ami-017c0f2b5422880a2 in eu-west-2 Public.... Still pending Making ami-056b84ae09efb7fbe in eu-west-3 Public.... Still pending Making ami-0c1b1f607b05ca3cf in eu-west-1 Public.... Still pending Making ami-0b1ef1431036184bd in ap-southeast-2 Public.... Still pending Making ami-0f1cae0564352e38c in ap-southeast-1 Public.... Still pending

(0000179) Neil Hanlon 2022-05-22 20:07	This should be fixed now. Thank you for the report!

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
105	[Rocky-Linux-8] avahi	minor	have not tried	2022-05-20 11:34	2022-05-20 11:34

Reporter:	Duncan Macleod	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	python3-avahi missing requirement on python3-dbus
Description:	The python3-avahi package is missing a runtime requirement on python3-dbus: <code> $ cat /etc/os-release NAME="Rocky Linux" VERSION="8.5 (Green Obsidian)" ID="rocky" ID_LIKE="rhel centos fedora" VERSION_ID="8.5" PLATFORM_ID="platform:el8" PRETTY_NAME="Rocky Linux 8.5 (Green Obsidian)" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:rocky:rocky:8:GA" HOME_URL="https://rockylinux.org/" BUG_REPORT_URL="https://bugs.rockylinux.org/" ROCKY_SUPPORT_PRODUCT="Rocky Linux" ROCKY_SUPPORT_PRODUCT_VERSION="8" $ yum info python3-avahi Available Packages Name : python3-avahi Version : 0.7 Release : 20.el8 Architecture : x86_64 Size : 13 k Source : avahi-0.7-20.el8.src.rpm Repository : baseos Summary : Python3 Avahi bindings URL : http://avahi.org License : LGPLv2+ Description : Python3 Avahi bindings. $ yum -y install python3 python3-avahi $ python3 -c "import avahi" Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3.6/site-packages/avahi/__init__.py", line 22, in <module> import dbus ModuleNotFoundError: No module named 'dbus' </code>
Tags:
Steps To Reproduce:	<code shell> yum -y install python3 python3-avahi python3 -c "import avahi" </code>
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
78	[Rocky-Linux-8] General	minor	N/A	2021-08-28 01:34	2022-05-16 06:36

Reporter:	randolph	Platform:
Assigned To:	Neil Hanlon	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	8.6
		Target Version:

Summary:	Official AMI contains incorrect SELinux security context for network config scripts
Description:	The Rocky Linux 8 (Official) AMI image contains an issue with the SELinux contexts [ansible@ord1-prod-secparse001 network-scripts]$ ls -laZ total 16 drwxr-xr-x. 2 root root system_u:object_r:net_conf_t:s0 78 Jul 16 23:41 . drwxr-xr-x. 5 root root system_u:object_r:etc_t:s0 4096 Jul 17 01:00 .. -rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 197 Jul 16 23:41 ifcfg-eth0 -rw-r--r--. 1 root root system_u:object_r:net_conf_t:s0 284 Jul 16 22:41 vmimport.ifcfg-ens3 -rw-r--r--. 1 root root system_u:object_r:net_conf_t:s0 126 Jul 16 22:42 vmimport.ifcfg-eth0 [ansible@ord1-prod-secparse001 network-scripts]$ ifcfg-eth0 in this case has the unlabeled_t context, when it should have a net_conf_t context. As a result, NetworkManager cannot modify this file without being blocked by SELinux. Restorecon resolves the situation. the vmimport.ifcfg-* files may also be unecessary to include, but are present in the CentOS8 AMI (Not the RHEL 8 one, however).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000088) Amy Tilghman 2021-11-03 15:01	Adding my reddit post here, confirming what was found by Randolph Meyers I spun up ami-086586d173a744e81 in us-east-2 Immediately after launching I ran ausearch -m avc to see if all was well in SELinux land. Saw this repeating: type=SYSCALL msg=audit(1624236431.107:19): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5564117bcfc0 a2=0 a3=0 items=0 ppid=1 pid=798 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="chrony-helper" exe="/usr/bin/bash" subj=system_u:system_r:chronyd_t:s0 key=(null) type=AVC msg=audit(1624236431.107:19): avc: denied { read } for pid=798 comm="chrony-helper" name="network" dev="xvda1" ino=758181 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 The root cause is a mislabled /etc/sysconfig/network, it is unlabeled_t when it should be etc_t So I went hunting for some more. This is not a full list (it's close) but they are the ones I do not think require much thought or debate. ## In the format of: From: To: ## system_u:object_r:unlabeled_t:s0 394 Jun 21 00:46 /etc/fstab system_u:object_r:etc_t:s0 427 Jun 2 06:05 /etc/fstab system_u:object_r:unlabeled_t:s0 372 Jun 21 00:46 /etc/default/grub system_u:object_r:bootloader_etc_t:s0 357 Jun 2 06:09 /etc/default/grub system_u:object_r:unlabeled_t:s0 197 Jun 21 00:46 /etc/sysconfig/network-scripts/ifcfg-eth0 system_u:object_r:net_conf_t:s0 159 Nov 2 04:11 /etc/sysconfig/network-scripts/ifcfg-eth0 system_u:object_r:unlabeled_t:s0 66 Jun 21 00:46 /etc/sysconfig/network system_u:object_r:etc_t:s0 102 Nov 2 04:11 /etc/sysconfig/network system_u:object_r:unlabeled_t:s0 665 Jun 21 00:46 /etc/rc.d/rc.local.vmimport system_u:object_r:initrc_exec_t:s0 665 Jun 21 00:46 rc.local.vmimport system_u:object_r:unlabeled_t:s0 0 Jun 21 00:46 /etc/cloud/cloud.cfg.d/vmimport.99-disable-network-config.cfg system_u:object_r:etc_t:s0 0 Jun 21 00:46 /etc/cloud/cloud.cfg.d/vmimport.99-disable-network-config.cfg system_u:object_r:unlabeled_t:s0 80 Jun 21 00:46 /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg system_u:object_r:etc_t:s0 80 Jun 21 00:46 /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg system_u:object_r:unlabeled_t:s0 6490 Jun 21 00:46 /boot/grub2/grub.cfg-bkup system_u:object_r:boot_t:s0 6490 Jun 21 00:46 /boot/grub2/grub.cfg-bkup

(0000168) Neil Hanlon 2022-05-16 06:35	Fixed in 8.6

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
100	[Account Services] Account Requests - General	major	have not tried	2022-05-14 23:29	2022-05-14 23:32

Reporter:	John Vandenberg	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Signup set password failed with raw HTML on page
Description:	I tried setting up account "jayvdb" in Rocky Linux Account services, verified my email, was prompted for a new password, and then see this confusing bundle of raw HTML in a light yellow overlay: Your account has been created, but an error occurred while setting your password (<html> <head> <title>200 Success</title> </head> <body> <h1>Password change rejected</h1> The old password or username is not correct. </body> </html>). You may need to change it after logging in. I was able to use the forgot password form to get into my new account.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000166) Louis Abel 2022-05-14 23:32	Thank you for the report. Upon testing, I am also seeing the same behavior. But it seems that either going through forgot password or just logging in to set the password seems to work just fine. We'll take a look to see if we can stamp out this issue. Setting to acknowledged.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
89	[Cloud] General	minor	have not tried	2022-05-06 16:13	2022-05-06 16:19

Reporter:	Mustafa Gezen	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Migration script should be able to install cloud provider specific enhancements
Description:	With SIG/Cloud we're planning to introduce certain enhancements to Core. Automatically installing the enhancements may provide for a better experience. We should look into adding this into the migration script.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000122) Neil Hanlon 2022-05-06 16:19	If we do this we should make sure it's behind a feature flag to make sure the user consents to the changes from default and understands the consequences. I also was thinking we could suggest the changes to the user if we detect they're running in a cloud environment, e.g.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
34	[Rocky-Linux-8] General	minor	have not tried	2022-01-03 20:34	2022-05-05 19:08

Reporter:	Louis Abel	Platform:
Assigned To:	Louis Abel	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	test
Description:	test
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000034) Louis Abel 2022-01-03 20:35	test

(0000118) Louis Abel 2022-05-05 19:00	testing mattermost notification

(0000119) Louis Abel 2022-05-05 19:03	testing mattermost notification

(0000120) Louis Abel 2022-05-05 19:05	testing mattermost notification

(0000121) Louis Abel 2022-05-05 19:08	final test for notification

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
84	[Rocky-Linux-8] anaconda	minor	have not tried	2021-07-08 03:10	2022-05-03 14:56

Reporter:	Peter Ajamian	Platform:
Assigned To:	Release Engineering	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Repository Does Not Match Selected Protocol Error
Description:	When in the Repository selection of the Anaconda installer: 1. Add the baseos repository (if not already done) as the main repo. 2. Add an additional repo (we'll say EPEL). The protocol drop-down is initially blank, and should be changed to HTTPS. This works fine. 3. Add a second additional repo (well say rpmfusion this time). The protocol selection is initially set to HTTPS, and when you type or paste in the URL you will see an error appear on the bottom of the screen, "Repository foo does not match selected protocol". You are then unable to proceed until you fix the error. Workaround: 4. Change the drop down to http. 5. Change the drop down back to https. The error message dissapears and you are able to proceed. This continues to happen for subsequent repositories. Note: The screenshots I am attaching are from the RHEL 8.4 boot.iso installer. The same issue occurs with the RockyLinux boot.iso installer.
Tags:
Steps To Reproduce:
Additional Information:	Screenshot showing error message in THEL 8.4 Anaconda Screenshot showing error has disappeared after dropdown has been changed to HTTP and then back to HTTPS
Attached Files:	Screenshot from 2021-07-08 14-42-51.png (55,628 bytes) 2022-05-03 02:15 https://bugs.rockylinux.org/file_download.php?file_id=4&type=bug Screenshot from 2021-07-08 14-49-54.png (52,543 bytes) 2022-05-03 02:15 https://bugs.rockylinux.org/file_download.php?file_id=5&type=bug

Notes
(0000101) Peter Ajamian 2021-07-08 03:11	Screenshot showing error message in THEL 8.4 Anaconda Screenshot showing error has disappeared after dropdown has been changed to HTTP and then back to HTTPS

(0000102) Peter Ajamian 2021-07-08 03:14	This bug has previously been filed with RedHat: https://mirror.ghettoforge.org/distributions/gf/el/8/gf/x86_64/ RedHat has closed the bug as "WONTFIX" without much explanation as to why they won't address it. If we can fix the bug in RockyLinux then it may put some amount of pressure onto RedHat to fix it upstream.

(0000103) Peter Ajamian 2021-07-18 04:27	I only just realized that I pasted the wrong URL in above, it should be: https://bugzilla.redhat.com/show_bug.cgi?id=1656702

(0000112) Peter Ajamian 2022-05-03 08:38	Red Hat has closed this bug as WONTFIX. Should we consider this for a fix in Rocky Linux? The bug is a minor annoyance at best and there is something to be said to maintain bug-for-bug compatibility with RHEL, but fixing this is not very likely to cause issues for anyone and it will put some amount of pressure on Red Hat to get their act together and fix it upstream.

(0000114) Neil Hanlon 2022-05-03 14:56	I'd be happy to see it fixed, especially as it's likely a few lines of python at best inside anaconda. I do wonder if perhaps it was closed wontfix because of the changes to anaconda coming down the pipe from fedora eventually? In any case, it's an annoyance and UX issue that would be great to fix. For anyone interested: we have a repository here[1] that can be used to run the anaconda locally (and even install to a mounted disk, if you want) for testing purposes. It was originally for design and branding work, but has been expanded to be used in testing SCAP content, too. [1]https://github.com/rocky-linux/vagrant-anaconda

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
73	[Cloud] General	minor	always	2022-04-08 17:55	2022-04-08 20:06

Reporter:	Liam Hopkins	Platform:
Assigned To:	Mustafa Gezen	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Rocky 8 images on Google Cloud Platform should disable 64k page size
Description:	Enterprise Linux version 8 distributions experimentally moved to 64k pages, which was reverted in Enterprise Linux version 9 due to incompatibilities. Please modify the Rocky Linux 8 for GCP kernel build to disable 64k pages to match.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000070) Liam Hopkins 2022-04-08 18:36	thanks for quick reply. everything you said makes sense as a general EL derivative. i may have misfiled the bug, this is a request for a change to the google-specific rocky image being built by CIQ, which does have a custom kernel build.

(0000071) Louis Abel 2022-04-08 18:41	Acknowledged. I would recommend that you reach out to CIQ directly as it is their kernel and thus their modifications. We do not have hands nor knowledge in what the company does or modifies away from the Rocky Linux base.

(0000072) Neil Hanlon 2022-04-08 18:43	Hi all - I can clear up a bit here. This is going to be a contribution via the Cloud SIG - my apologies for the miscommunication as I asked Liam to file the ticket here. Taking this one for myself.

(0000073) Mustafa Gezen 2022-04-08 20:06	Thanks Neil, and sorry for the confusion Louis. This is indeed about the SIG/Cloud kernel to improve Rocky on cloud platforms even if it diverges from upstream. After talking to Neil, I'll be re-assigning this to myself and take the lead regarding SIG/Cloud kernel improvements until the initial release. Also thanks for filing a bug Liam, this shouldn't require too much work hopefully. I'll keep in touch!

(0000069) Louis Abel 2022-04-20 08:28	Unfortunately we do not modify our kernels nor do we roll our own kernels. From a Release Engineering standpoint, our kernels are to match what is upstream (RHEL) with only branding and secure boot changes. Red Hat has stated in their bugzilla (and other mediums) that reducing the page size back to 4K on RHEL 8 would introduce KABI incompatibility and breakage. This implies that backporting said change is not a supported option. My recommendation would be to take the current kernel SRPM and test reducing the page size that way. If it does work, then it could be a potential addition/collaboration with SIG/kernel, but will unfortunately increase the amount of overhead in keeping all kernels in line and up to date as they come upstream. And as a result, can create various KABI incompatibilities with the rest of the distribution. But it will be up to you (and others) to test and confirm this to check if the pros outweigh the cons. As an aside, this 64k page size started with various questions asking about Apple's M1 hardware (which is a limitation on their part). This (among other reasons such as drivers which do not work on non-standard page sizes) is why page sizes are being reduced for non-x86 architectures.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
85	[Rocky-Linux-8] dracut	minor	always	2022-03-16 08:12	2022-03-16 08:13

Reporter:	bmoy	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Can't perform network installation due to ICMP6 socket not created
Description:	This is on what the installation hangs Fresh network installations Loops forever at : IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Additionally, adding ipv6.disable=1 also hangs forever at the same place, with this different error: "dracut-initqueue[1245]: libndp: ndp_sock_open: Failed to create ICMP6 socket" dracut should NOT be trying to use IPv6 when IPv6 is disabled... There is no IPV6 in my network and I'm trying to perform the installation open ipv4. Also, I'm using a KS file if it helps.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	Screen Shot 2022-03-16 at 10.11.38.png (286,950 bytes) 2022-05-03 05:30 https://bugs.rockylinux.org/file_download.php?file_id=7&type=bug

Notes
(0000104) bmoy 2022-03-16 08:13	Sorry for the missing information. The OS version I'm trying to install is RockyLinux 8.5 RockyLinux 8.4 passes the installation successfully without any errors with the same config

(0000105) bmoy 2022-03-16 08:13	This is on what the installation hangs

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
81	[Rocky-Linux-8] kernel	major	always	2022-01-10 16:25	2022-01-10 18:29

Reporter:	cslewis2022	Platform:
Assigned To:	Release Engineering	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	Upgrading rocky to v. 8.5 on a AWS t2 instance does not boot when instance changed to t3
Description:	I created an AWS ami for a version 8.4 of Rocky. This version was then run in a t2 instance and worked fine. It was subsequently updated to version 8.5 via yum update. When the instance was switched to t3 instance type, the instance does not start. No disks are detected. Running the same 8.4 ami in a t3 instance and upgrading to v. 8.5 works fine. Per AWS' documentation, I verified that both the ena and nvme drivers are present in the t2 instance prior to the switch to the t3 instance type.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000095) cslewis2022 2022-01-10 18:29	I was able to resolve this issue by explicitly added the ena and nvme kernel drivers to the dracut configuration, and re-running dracut. echo 'add_drivers+=" ena "' >> /etc/dracut.conf.d/ena.conf echo 'add_drivers+=" nvme "' >> /etc/dracut.conf.d/ena.conf dracut -f -vvvv This was not needed for Rocky v. 8.4.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
80	[Rocky-Linux-8] General	minor	have not tried	2021-12-11 21:57	2021-12-11 21:57

Reporter:	Mohammad Ali Sarbanha	Platform:
Assigned To:	Release Engineering	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	VM 'used' memory is growing? Probably memory leakage
Description:	This image shows the time when the VM has consumed entire memroy and crashes. HDD activity dropped and CPU utilization has become almost 80~90% I use Rocky8.5 Linux and I am experiencing growing the size of used memory when I start transferring gigantic files by SCP! Here is the scenario, I have an ESXi in datacenter A and a VM in datacenter B. In order to access ESXi I had to make IPSec tunnel. The tunnel is made between the VM and the remote network gateway with strongswan. I have a 350GB file that I want to download to the remote VM. The only tool that I have is SCP at the moment. other tools like Rsync or FTP neither available nor fits the current topology. When I start transferring data using SCP, used memory starts increasing: [root@gateway]# free -h total used free shared buff/cache available Mem: 15Gi 1.4Gi 11Gi 16Mi 2.5Gi 13Gi Swap: 4.0Gi 0B 4.0Gi At the same time buff/cache is getting increased which is normal I think. When I run `sync; echo 3 > /proc/sys/vm/drop_caches` buff/cache shrinks: [root@gateway]# free -h total used free shared buff/cache available Mem: 15Gi 1.4Gi 13Gi 16Mi 119Mi 13Gi Swap: 4.0Gi 0B 4.0Gi But the used memory remains at the same size. I am experiencing the VM crash after downloading 60~70GB of the file. I have increased the RAM from 4GB to 16GB to see if it helps, but the result was that it takes longer to crash Initially thought that it was SSH or SCP memory leakage, so I changed my method by setting up NFS on the VM and mount it on remote ESXi machine, then started regular file copy. Still, growing used memory observed. I used 'ps waux' to see if I can find any process overusing the memory. Interestingly, processes barely reach 0.3% MEM In order to see if stopping file copy reduces the allocated memory, I stopped the copy process and left the machine for few hours. Allocated memory wasn't released back to available memory. The hardware on which the VM is hosted is Dell PowerEdge™ R6515, The hypervisor used is VMWare vSphere ESXi 7.x When the VM crashes, it doesn't allow to send reboot signal through keyboard. Only cold boot works.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
74	[Rocky-Linux-8] kmod-kvdo	major	always	2021-11-15 23:22	2021-11-15 23:22

Reporter:	Louis Abel	Platform:
Assigned To:	Release Engineering	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	kmod-kvdo not signed by driver certificate (Secure Boot)
Description:	The kernel is signed for secure boot, but packages like kmod-kvdo are not signed and cannot be ran on secure boot enabled machines. This ticket is to track the progress on getting kmods signed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
76	[Rocky-Linux-8] General	minor	have not tried	2021-07-19 17:14	2021-07-19 17:14

Reporter:	kalyanaraman subramanian	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:

Summary:	selinux user restrictions not working
Description:	hi, my name is raman and I am a fan of past Centos, recently i downloaded rocky Linux 8.4 minimal iso and installed on my vmware. whenever I create a selinux user(user_u, guest_u, xguest_u) and tried to use the following commands it is working with out any restrictions su, networking commands and i can able to create and run scripts in tmp if i run id -Z it returns unconfined_u:unconfined_r:unconfined_t (for both selinux guest, xguest and user accounts)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000081) scott shinn 2022-04-22 06:21	Could you give us the steps you're using so I can recreate your configuration here? Another note here, the SELinux policy isnt going to take effect on a running account until you log back in.