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: |
2576 | [Rocky-Linux-9] kernel | minor | always | 2023-03-07 14:59 | 2023-03-07 14:59 |
Reporter: | Tadas Sutkaitis | 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: | Haproxy pod keeps OOM crashing | ||||
Description: |
Running Kubernetes on Rocky Linux 9 with kernel 5.14, haproxy pod keeps OOM crashing while works fine on Rocky Linux 8 or Ubuntu 20.04.22.04 All the pods are running on four bare metal worker nodes inside a Kubernetes clusters. Two worker nodes have Rocky Linux 8 installed, one Ubuntu 22.04 while one worker nodes has Rocky Linux 9 installed with kernel 5.14. Three of the haproxy pods running on Rocky Linux 8 and Ubuntu 22.04 nodes using memory less than 100MB but that one running on Rocky Linux 9 could use all the memory on the node without limits and easily reaches its memory limits like the one above with 2GB memory limits configured. I also tried to bump its haproxy version to latest stable version 2.7.2 which didn't help and the pod still keeps being OOMKilled. I also tried using kernel 6.2.x from elrepo.org |
||||
Tags: | |||||
Steps To Reproduce: |
Use kubelet/kubeadm 1.22.x-1.25.x Use any version of runc and containerd Use stock kernel 5.14 or even 6.2.x from elrepo.org |
||||
Additional Information: |
log from kernel 5.14(stock): [ 152.697004] sshd invoked oom-killer: gfp_mask=0x1140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0 [ 152.697396] CPU: 1 PID: 700 Comm: sshd Tainted: G ---------h--- 5.14.0-162.18.1.el9_1.x86_64 #1 [ 152.697774] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.20904234.B64.2212051115 12/05/2022 [ 152.698539] Call Trace: [ 152.698918] dump_stack_lvl+0x34/0x48 [ 152.699299] dump_header+0x4a/0x201 [ 152.699676] oom_kill_process.cold+0xb/0x10 [ 152.700054] out_of_memory+0xed/0x2d0 [ 152.700432] __alloc_pages_slowpath.constprop.0+0x7cc/0x8a0 [ 152.700814] __alloc_pages+0x1fe/0x230 [ 152.701191] folio_alloc+0x17/0x50 [ 152.701569] __filemap_get_folio+0x1b6/0x330 [ 152.701947] ? do_sync_mmap_readahead+0x14b/0x270 [ 152.702327] filemap_fault+0x454/0x7a0 [ 152.702706] ? next_uptodate_page+0x160/0x1f0 [ 152.703085] ? filemap_map_pages+0x307/0x4a0 [ 152.703465] __xfs_filemap_fault+0x66/0x280 [xfs] [ 152.703909] __do_fault+0x33/0x110 [ 152.704289] do_read_fault+0xea/0x190 [ 152.704667] do_fault+0x8c/0x2c0 [ 152.705044] __handle_mm_fault+0x3cb/0x750 [ 152.705424] handle_mm_fault+0xc5/0x2a0 [ 152.705799] do_user_addr_fault+0x1bb/0x690 [ 152.706178] ? do_syscall_64+0x69/0x90 [ 152.706557] exc_page_fault+0x62/0x150 [ 152.706959] asm_exc_page_fault+0x22/0x30 [ 152.707348] RIP: 0033:0x5633f1eadae0 [ 152.707732] Code: Unable to access opcode bytes at RIP 0x5633f1eadab6. [ 152.708132] RSP: 002b:00007ffc2fae4de8 EFLAGS: 00010206 [ 152.708530] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000008 [ 152.708937] RDX: 0000000000000004 RSI: 00005633f2c1a120 RDI: 00005633f2bf1b60 [ 152.709348] RBP: 00005633f2c1a120 R08: 00005633f2c1a120 R09: 0000000000000000 [ 152.709756] R10: 00007ffc2fbb0080 R11: 0000000000000246 R12: 0000000000000002 [ 152.710164] R13: 00005633f2bf3230 R14: 00005633f2c1a120 R15: 00005633f2bf1b60 [ 152.710603] Mem-Info: [ 152.711029] active_anon:837 inactive_anon:1940583 isolated_anon:0 active_file:19 inactive_file:29 isolated_file:0 unevictable:0 dirty:0 writeback:0 slab_reclaimable:6301 slab_unreclaimable:15610 mapped:682 shmem:2491 pagetables:4647 bounce:0 kernel_misc_reclaimable:0 free:25244 free_pcp:380 free_cma:0 [ 152.713899] Node 0 active_anon:3348kB inactive_anon:7762332kB active_file:76kB inactive_file:116kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:2728kB dirty:0kB writeback:0kB shmem:9964kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 7049216kB writeback_tmp:0kB kernel_stack:6832kB pagetables:18588kB all_unreclaimable? no [ 152.715107] Node 0 DMA free:14336kB min:128kB low:160kB high:192kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 152.716328] lowmem_reserve[]: 0 2959 7854 7854 7854 [ 152.716718] Node 0 DMA32 free:44784kB min:25412kB low:31764kB high:38116kB reserved_highatomic:0KB active_anon:0kB inactive_anon:3016548kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:3128720kB managed:3063120kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 152.717967] lowmem_reserve[]: 0 0 4895 4895 4895 [ 152.718386] Node 0 Normal free:41856kB min:42040kB low:52548kB high:63056kB reserved_highatomic:0KB active_anon:3348kB inactive_anon:4745784kB active_file:428kB inactive_file:220kB unevictable:0kB writepending:0kB present:5242880kB managed:5020764kB mlocked:0kB bounce:0kB free_pcp:1520kB local_pcp:556kB free_cma:0kB [ 152.719752] lowmem_reserve[]: 0 0 0 0 0 [ 152.720225] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 3*4096kB (M) = 14336kB [ 152.720709] Node 0 DMA32: 6*4kB (UM) 4*8kB (UM) 11*16kB (UM) 6*32kB (UM) 5*64kB (UM) 2*128kB (UM) 1*256kB (U) 0*512kB 1*1024kB (M) 1*2048kB (U) 10*4096kB (UM) = 45288kB [ 152.721706] Node 0 Normal: 455*4kB (UME) 260*8kB (UME) 140*16kB (UME) 61*32kB (UE) 56*64kB (UME) 29*128kB (UME) 23*256kB (UME) 25*512kB (UME) 8*1024kB (UME) 0*2048kB 0*4096kB = 42268kB [ 152.722762] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ 152.723309] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 152.723834] 2549 total pagecache pages [ 152.724373] 0 pages in swap cache [ 152.724895] Swap cache stats: add 0, delete 0, find 0/0 [ 152.725440] Free swap = 0kB [ 152.725983] Total swap = 0kB [ 152.726506] 2096898 pages RAM [ 152.727049] 0 pages HighMem/MovableOnly [ 152.727572] 72087 pages reserved [ 152.728111] 0 pages cma reserved [ 152.728631] 0 pages hwpoisoned [ 152.729168] Tasks state (memory values in pages): [ 152.729687] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [ 152.730243] [ 542] 0 542 6490 942 86016 0 -250 systemd-journal [ 152.730778] [ 558] 0 558 8489 1001 86016 0 -1000 systemd-udevd [ 152.731330] [ 586] 0 586 4535 192 57344 0 -1000 auditd [ 152.731861] [ 610] 0 610 19813 70 53248 0 0 irqbalance [ 152.732413] [ 612] 0 612 41041 1291 90112 0 0 rsyslogd [ 152.732960] [ 615] 0 615 4572 281 73728 0 0 systemd-logind [ 152.733486] [ 617] 192 617 1730 118 53248 0 0 systemd-network [ 152.734026] [ 621] 996 621 21106 166 65536 0 0 chronyd [ 152.734547] [ 622] 81 622 2705 164 61440 0 -900 dbus-broker-lau [ 152.735086] [ 624] 81 624 1248 104 45056 0 -900 dbus-broker [ 152.735606] [ 627] 0 627 4038 395 77824 0 -1000 sshd [ 152.736172] [ 630] 0 630 1519 215 45056 0 0 crond [ 152.736694] [ 631] 0 631 761 21 45056 0 0 agetty [ 152.737241] [ 632] 0 632 485312 10947 421888 0 -999 containerd [ 152.737749] [ 689] 0 689 4810 561 77824 0 0 sshd [ 152.738263] [ 692] 0 692 4929 413 81920 0 100 systemd [ 152.738743] [ 693] 0 693 5543 731 81920 0 100 (sd-pam) [ 152.739229] [ 700] 0 700 4843 611 77824 0 0 sshd [ 152.739683] [ 701] 0 701 3495 2413 65536 0 0 bash [ 152.740141] [ 736] 0 736 485268 9143 499712 0 -999 kubelet [ 152.740579] [ 829] 0 829 178113 1063 106496 0 -998 containerd-shim [ 152.741027] [ 855] 0 855 178113 1025 110592 0 -998 containerd-shim [ 152.741441] [ 893] 0 893 178113 1017 106496 0 -998 containerd-shim [ 152.741840] [ 899] 0 899 178113 1088 106496 0 -998 containerd-shim [ 152.742252] [ 928] 0 928 178113 1144 102400 0 -998 containerd-shim [ 152.742633] [ 932] 65535 932 243 1 28672 0 -998 pause [ 152.743017] [ 959] 65535 959 243 1 28672 0 -998 pause [ 152.743370] [ 999] 65535 999 243 1 28672 0 -998 pause [ 152.743713] [ 1002] 65535 1002 243 1 28672 0 -998 pause [ 152.744060] [ 1022] 65535 1022 243 1 28672 0 -998 pause [ 152.744376] [ 1115] 0 1115 241739 45023 671744 0 -997 kube-apiserver [ 152.744683] [ 1196] 0 1196 2803664 7283 192512 0 -997 etcd [ 152.744995] [ 1203] 0 1203 188393 3900 204800 0 -997 kube-scheduler [ 152.745280] [ 1231] 0 1231 205461 9729 364544 0 -997 kube-controller [ 152.745556] [ 1239] 0 1239 6296 227 81920 0 1000 keepalived [ 152.745841] [ 1290] 0 1290 6316 242 77824 0 1000 keepalived [ 152.746131] [ 1548] 0 1548 178113 1198 110592 0 -998 containerd-shim [ 152.746406] [ 1569] 65535 1569 243 1 28672 0 -998 pause [ 152.746679] [ 1658] 99 1658 41965078 1835879 14815232 0 1000 haproxy [ 152.746971] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/containerd.service/kubepods-besteffort-pod4bff3fd65add1f5f664ebc8e39174145.slice:cri-containerd:d0e7d35e48d1d2c1c4c7398b61375e7fec8dffabb84c972d3be2e08dac600439,task=haproxy,pid=1658,uid=99 [ 152.747889] Out of memory: Killed process 1658 (haproxy) total-vm:167860312kB, anon-rss:7343516kB, file-rss:0kB, shmem-rss:0kB, UID:99 pgtables:14468kB oom_score_adj:1000 ##################### log from kernel 6.2: [ 821.389534] systemd-rc-local-generator[4503]: /etc/rc.d/rc.local is not marked executable, skipping. [ 821.608848] systemd[1]: systemd 250-12.el9_1.3 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) [ 821.610556] systemd[1]: Detected virtualization vmware. [ 821.611494] systemd[1]: Detected architecture x86-64. [ 821.659963] systemd-rc-local-generator[4523]: /etc/rc.d/rc.local is not marked executable, skipping. [ 833.885781] systemd-rc-local-generator[5227]: /etc/rc.d/rc.local is not marked executable, skipping. [ 847.648883] kworker/1:0 invoked oom-killer: gfp_mask=0xdc0(GFP_KERNEL|__GFP_ZERO), order=0, oom_score_adj=0 [ 847.649165] CPU: 1 PID: 1596 Comm: kworker/1:0 Tainted: G E 6.2.2-1.el9.elrepo.x86_64 #1 [ 847.649439] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.20904234.B64.2212051115 12/05/2022 [ 847.649700] Workqueue: events drm_fb_helper_damage_work [drm_kms_helper] [ 847.649978] Call Trace: [ 847.650237] <TASK> [ 847.650493] dump_stack_lvl+0x45/0x5e [ 847.650758] dump_header+0x4a/0x213 [ 847.651034] oom_kill_process.cold+0xb/0x10 [ 847.651349] out_of_memory+0xed/0x2e0 [ 847.651618] __alloc_pages_slowpath.constprop.0+0x78b/0xb00 [ 847.651880] __alloc_pages+0x21d/0x250 [ 847.652135] vmw_validation_mem_alloc+0x78/0x120 [vmwgfx] [ 847.652408] vmw_validation_add_resource+0xd6/0x290 [vmwgfx] [ 847.652677] ? drm_plane_get_damage_clips+0x23/0x60 [drm] [ 847.652968] vmw_du_helper_plane_update+0x102/0x350 [vmwgfx] [ 847.653239] vmw_stdu_plane_update_surface+0xc4/0xf0 [vmwgfx] [ 847.653510] ? __pfx_vmw_stdu_surface_fifo_size_same_display+0x10/0x10 [vmwgfx] [ 847.653783] ? __pfx_vmw_stdu_surface_update_proxy+0x10/0x10 [vmwgfx] [ 847.654055] ? __pfx_vmw_stdu_surface_populate_update+0x10/0x10 [vmwgfx] [ 847.654329] vmw_stdu_primary_plane_atomic_update+0xbb/0x1c0 [vmwgfx] [ 847.654606] drm_atomic_helper_commit_planes+0xb4/0x220 [drm_kms_helper] [ 847.654901] drm_atomic_helper_commit_tail+0x45/0x80 [drm_kms_helper] [ 847.655183] commit_tail+0xd2/0x130 [drm_kms_helper] [ 847.655462] drm_atomic_helper_commit+0x11b/0x140 [drm_kms_helper] [ 847.655742] drm_atomic_commit+0x93/0xc0 [drm] [ 847.656039] ? __pfx___drm_printfn_info+0x10/0x10 [drm] [ 847.656336] drm_atomic_helper_dirtyfb+0x192/0x270 [drm_kms_helper] [ 847.656627] drm_fbdev_fb_dirty+0x146/0x1e0 [drm_kms_helper] [ 847.656918] drm_fb_helper_damage_work+0x87/0x160 [drm_kms_helper] [ 847.657211] process_one_work+0x1e2/0x3b0 [ 847.657494] ? __pfx_worker_thread+0x10/0x10 [ 847.657775] worker_thread+0x50/0x3a0 [ 847.658054] ? __pfx_worker_thread+0x10/0x10 [ 847.658332] kthread+0xe5/0x110 [ 847.658610] ? __pfx_kthread+0x10/0x10 [ 847.658886] ret_from_fork+0x29/0x50 [ 847.659162] </TASK> [ 847.659464] Mem-Info: [ 847.659724] active_anon:978 inactive_anon:1946881 isolated_anon:0 active_file:0 inactive_file:22 isolated_file:0 unevictable:0 dirty:0 writeback:0 slab_reclaimable:6083 slab_unreclaimable:13964 mapped:1894 shmem:4514 pagetables:4753 sec_pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:25293 free_pcp:0 free_cma:0 [ 847.661565] Node 0 active_anon:3912kB inactive_anon:7787524kB active_file:0kB inactive_file:88kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:7576kB dirty:0kB writeback:0kB shmem:18056kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 6526976kB writeback_tmp:0kB kernel_stack:6704kB pagetables:19012kB sec_pagetables:0kB all_unreclaimable? yes [ 847.662252] Node 0 DMA free:14336kB boost:0kB min:128kB low:160kB high:192kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 847.662756] lowmem_reserve[]: 0 2959 7858 7858 7858 [ 847.662996] Node 0 DMA32 free:44964kB boost:0kB min:25400kB low:31748kB high:38096kB reserved_highatomic:0KB active_anon:0kB inactive_anon:3010376kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:3128596kB managed:3063000kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 847.663522] lowmem_reserve[]: 0 0 4899 4899 4899 [ 847.663784] Node 0 Normal free:41872kB boost:0kB min:42052kB low:52564kB high:63076kB reserved_highatomic:0KB active_anon:3912kB inactive_anon:4777148kB active_file:16kB inactive_file:216kB unevictable:0kB writepending:0kB present:5242880kB managed:5024212kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 847.664639] lowmem_reserve[]: 0 0 0 0 0 [ 847.664925] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 3*4096kB (M) = 14336kB [ 847.665228] Node 0 DMA32: 5*4kB (UM) 7*8kB (UM) 8*16kB (UM) 11*32kB (UM) 6*64kB (UM) 4*128kB (UM) 2*256kB (M) 5*512kB (UM) 4*1024kB (M) 0*2048kB 9*4096kB (M) = 45484kB [ 847.665871] Node 0 Normal: 1117*4kB (UME) 462*8kB (UME) 216*16kB (UME) 57*32kB (UME) 68*64kB (UME) 25*128kB (UE) 8*256kB (UME) 6*512kB (UME) 16*1024kB (UME) 0*2048kB 0*4096kB = 42500kB [ 847.666547] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ 847.666878] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 847.667203] 4526 total pagecache pages [ 847.667546] 0 pages in swap cache [ 847.667869] Free swap = 0kB [ 847.668188] Total swap = 0kB [ 847.668522] 2096867 pages RAM [ 847.668837] 0 pages HighMem/MovableOnly [ 847.669150] 71224 pages reserved [ 847.669479] 0 pages cma reserved [ 847.669789] 0 pages hwpoisoned [ 847.670095] Tasks state (memory values in pages): [ 847.670422] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [ 847.670749] [ 536] 0 536 8650 2368 102400 0 -250 systemd-journal [ 847.671068] [ 551] 0 551 8153 480 86016 0 -1000 systemd-udevd [ 847.671410] [ 578] 0 578 4535 706 57344 0 -1000 auditd [ 847.671729] [ 603] 0 603 19813 580 61440 0 0 irqbalance [ 847.672046] [ 605] 0 605 59473 2208 98304 0 0 rsyslogd [ 847.672364] [ 606] 0 606 4572 288 69632 0 0 systemd-logind [ 847.672705] [ 611] 192 611 1730 96 49152 0 0 systemd-network [ 847.673028] [ 613] 996 613 21106 131 65536 0 0 chronyd [ 847.673367] [ 616] 81 616 2705 192 61440 0 -900 dbus-broker-lau [ 847.673692] [ 617] 81 617 1248 128 40960 0 -900 dbus-broker [ 847.674016] [ 620] 0 620 4038 384 65536 0 -1000 sshd [ 847.674338] [ 623] 0 623 1520 192 49152 0 0 crond [ 847.674679] [ 624] 0 624 761 0 40960 0 0 agetty [ 847.675002] [ 625] 0 625 483312 11430 413696 0 -999 containerd [ 847.675325] [ 675] 0 675 4810 544 73728 0 0 sshd [ 847.675669] [ 678] 0 678 4918 384 77824 0 100 systemd [ 847.675993] [ 679] 0 679 5541 730 69632 0 100 (sd-pam) [ 847.676337] [ 686] 0 686 4810 537 73728 0 0 sshd [ 847.676663] [ 687] 0 687 1512 480 49152 0 0 bash [ 847.676980] [ 2026] 0 2026 4810 576 73728 0 0 sshd [ 847.677289] [ 2028] 0 2028 4842 604 69632 0 0 sshd [ 847.677608] [ 4462] 0 4462 4374 224 73728 0 0 systemd-hostnam [ 847.677902] [ 5142] 0 5142 1149 64 45056 0 0 sh [ 847.678186] [ 5154] 0 5154 6179 2967 81920 0 0 python3 [ 847.678483] [ 5155] 0 5155 187580 3342 204800 0 0 kubeadm [ 847.678758] [ 5237] 0 5237 427856 7811 466944 0 -999 kubelet [ 847.679023] [ 5304] 0 5304 180044 1246 106496 0 -998 containerd-shim [ 847.679282] [ 5328] 0 5328 180044 1226 106496 0 -998 containerd-shim [ 847.679552] [ 5339] 0 5339 180044 1237 110592 0 -998 containerd-shim [ 847.679793] [ 5345] 0 5345 180044 1254 114688 0 -998 containerd-shim [ 847.680024] [ 5359] 0 5359 180044 1255 102400 0 -998 containerd-shim [ 847.680253] [ 5369] 65535 5369 243 0 28672 0 -998 pause [ 847.680497] [ 5361] 0 5361 180044 1755 110592 0 -998 containerd-shim [ 847.680718] [ 5416] 65535 5416 243 0 28672 0 -998 pause [ 847.680927] [ 5466] 65535 5466 243 0 28672 0 -998 pause [ 847.681125] [ 5467] 65535 5467 243 0 28672 0 -998 pause [ 847.681317] [ 5492] 65535 5492 243 32 28672 0 -998 pause [ 847.681518] [ 5500] 65535 5500 243 0 28672 0 -998 pause [ 847.681701] [ 5564] 0 5564 188393 3323 208896 0 -997 kube-scheduler [ 847.681882] [ 5615] 0 5615 241579 40190 630784 0 -997 kube-apiserver [ 847.682063] [ 5618] 0 5618 6296 192 81920 0 1000 keepalived [ 847.682246] [ 5648] 0 5648 205333 5527 339968 0 -997 kube-controller [ 847.682454] [ 5655] 0 5655 2803664 6184 180224 0 -997 etcd [ 847.682643] [ 5696] 0 5696 6316 219 81920 0 1000 keepalived [ 847.682832] [ 5739] 99 5739 41965116 1845247 14876672 0 1000 haproxy [ 847.683021] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/k8s.io/e53c4abf72ff20acdbd7a50818b95ef02dfc5401f0c4515368104c487be65d7d,task=haproxy,pid=5739,uid=99 |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
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: |
2477 | [Rocky-Linux-9] appstream | tweak | always | 2023-03-03 08:31 | 2023-03-03 09:03 |
Reporter: | Christian Kirchner | 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: | not solved dependency python-unversioned-command-3.9.14-1.el9_1.1 and python3 3.9.14-1.el9_1.2 | ||||
Description: |
On a fresh Rocky Linux 9 Installation in Azure (official rocky linux 9 images was choosed) I get the following issue: <code> [root@test-vm-1 ~]# yum update Rocky Linux 9 - BaseOS 10 kB/s | 4.1 kB 00:00 Rocky Linux 9 - AppStream 21 kB/s | 4.1 kB 00:00 Rocky Linux 9 - AppStream 19 MB/s | 6.4 MB 00:00 Rocky Linux 9 - Extras 6.2 kB/s | 2.9 kB 00:00 Error: Problem 1: cannot install both python3-3.9.14-1.el9_1.2.x86_64 and python3-3.9.14-1.el9_1.1.x86_64 - package python-unversioned-command-3.9.14-1.el9_1.1.noarch requires python3 = 3.9.14-1.el9_1.1, but none of the providers can be installed - cannot install the best update candidate for package python3-3.9.14-1.el9_1.1.x86_64 - cannot install the best update candidate for package python-unversioned-command-3.9.14-1.el9_1.1.noarch Problem 2: problem with installed package python-unversioned-command-3.9.14-1.el9_1.1.noarch - package python-unversioned-command-3.9.14-1.el9_1.1.noarch requires python3 = 3.9.14-1.el9_1.1, but none of the providers can be installed - package python3-3.9.14-1.el9_1.1.x86_64 requires python3-libs(x86-64) = 3.9.14-1.el9_1.1, but none of the providers can be installed - cannot install both python3-libs-3.9.14-1.el9_1.2.x86_64 and python3-libs-3.9.14-1.el9_1.1.x86_64 - cannot install the best update candidate for package python3-libs-3.9.14-1.el9_1.1.x86_64 (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) [root@test-vm-1 ~]# </code> |
||||
Tags: | dependency, python, update, yum | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0002674)
Louis Abel 2023-03-03 08:38 |
Hello. We cannot reproduce your issue. Please run dnf clean all and try again. Failing this, you may want to verify the mirrors/repositories you're connecting to, as these updates were released Wednesday. [root@xmpp01 ~]# dnf update python3 python-unversioned-command Last metadata expiration check: 2:02:41 ago on Thu 02 Mar 2023 11:32:43 PM MST. Dependencies resolved. ================================================================================================================================================================ Package Architecture Version Repository Size ================================================================================================================================================================ Upgrading: python-unversioned-command noarch 3.9.14-1.el9_1.2 appstream 11 k python3 x86_64 3.9.14-1.el9_1.2 baseos 27 k python3-libs x86_64 3.9.14-1.el9_1.2 baseos 7.3 M Transaction Summary ================================================================================================================================================================ Upgrade 3 Packages Total download size: 7.3 M Is this ok [y/N]: |
(0002675)
Christian Kirchner 2023-03-03 08:50 |
Hi Louis, thanks for very fast feedback. The clean all have solved that issue. [root@test-vm-1 ~]# dnf clean all 24 files removed [root@test-vm-1 ~]# yum install python-unversioned-command Rocky Linux 9 - BaseOS 3.4 MB/s | 1.7 MB 00:00 Rocky Linux 9 - AppStream 9.5 MB/s | 6.6 MB 00:00 Rocky Linux 9 - Extras 11 kB/s | 8.5 kB 00:00 Dependencies resolved. ===================================================================================================================== Package Architecture Version Repository Size ===================================================================================================================== Installing: python-unversioned-command noarch 3.9.14-1.el9_1.2 appstream 11 k Transaction Summary ===================================================================================================================== Install 1 Package Total download size: 11 k Installed size: 23 Is this ok [y/N]: y Downloading Packages: [MIRROR] python-unversioned-command-3.9.14-1.el9_1.2.noarch.rpm: Status code: 404 for http://mirror.pulsant.com/sites/rocky/9.1/AppStream/x86_64/os/Packages/p/python-unversioned-command-3.9.14-1.el9_1.2.noarch.rpm (IP: 89.151.64.194) python-unversioned-command-3.9.14-1.el9_1.2.noarch.rpm 75 kB/s | 11 kB 00:00 --------------------------------------------------------------------------------------------------------------------- Total 21 kB/s | 11 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : python-unversioned-command-3.9.14-1.el9_1.2.noarch 1/1 Running scriptlet: python-unversioned-command-3.9.14-1.el9_1.2.noarch 1/1 Verifying : python-unversioned-command-3.9.14-1.el9_1.2.noarch 1/1 Installed: python-unversioned-command-3.9.14-1.el9_1.2.noarch Complete! [root@test-vm-1 ~]# Ticket could be closed. |
(0002676)
Christian Kirchner 2023-03-03 09:03 |
The image I used: erockyenterprisesoftwarefoundationinc1653071250513 rockylinux-9 |
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
2443 | [Rocky-Linux-9] cockpit | major | always | 2023-03-01 11:29 | 2023-03-01 16:17 |
Reporter: | Julien BOZZOLO | 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: | Browser too old message with firefox 110.0 64bits | ||||
Description: |
When connecting to cockpit (x.x.x.x:9090), it shown a message that a modern browser is required, and it show links to download firefox, chrome ... |
||||
Tags: | |||||
Steps To Reproduce: | open firefox 110.0 64bits on cockpit url (x.x.x.x:9090), agree the certificate. | ||||
Additional Information: | |||||
Attached Files: |
screen.png (233,756 bytes) 2023-03-01 11:29 https://bugs.rockylinux.org/file_download.php?file_id=628&type=bug |
||||
Notes | |
(0002642)
Louis Abel 2023-03-01 16:17 |
Thank you for the report. I am unable to reproduce your issue on both Rocky Linux 8 and 9, which both share the same cockpit versions, using the latest firefox version as of this writing (110). I would ensure that you do not have firefox extensions or otherwise that could cause this behavior to occur for you. Setting to needinfo. |
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: |
2377 | [Rocky-Linux-9] anaconda | crash | always | 2023-02-27 23:46 | 2023-02-27 23:50 |
Reporter: | john dyer | 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: | booting 9.0 Minimal (from Admin Magazine) and downloaded image stops | ||||
Description: |
I've tried the DVDs on virtual machines, with no issues. I have the most recent logs, and a screenshot as will. Information begins with This is anaconda 34.25.0.29-1-e19_0rocky0.3 for Rocky Linux 9.0 started. There are 8 'File "..." lines. Ending is UnicodeDecodeErroor: 'utf-8' codec can't decode byte 0xdb in position 1L unexpected end of data. Loges were graabbed from boot installation's /tmp directory for uploade |
||||
Tags: | |||||
Steps To Reproduce: | Insert DVD and (re)boot. | ||||
Additional Information: | |||||
Attached Files: |
anaconda.log (11,831 bytes) 2023-02-27 23:46 https://bugs.rockylinux.org/file_download.php?file_id=595&type=bug dbus.log (3,330 bytes) 2023-02-27 23:46 https://bugs.rockylinux.org/file_download.php?file_id=596&type=bug dnf.librepo.log (454 bytes) 2023-02-27 23:46 https://bugs.rockylinux.org/file_download.php?file_id=597&type=bug packaging.log (432 bytes) 2023-02-27 23:46 https://bugs.rockylinux.org/file_download.php?file_id=598&type=bug program.log (1,121 bytes) 2023-02-27 23:46 https://bugs.rockylinux.org/file_download.php?file_id=599&type=bug storage.log (24,279 bytes) 2023-02-27 23:49 https://bugs.rockylinux.org/file_download.php?file_id=600&type=bug X.log (62,360 bytes) 2023-02-27 23:49 https://bugs.rockylinux.org/file_download.php?file_id=601&type=bug |
||||
Notes | |
(0002575)
john dyer 2023-02-27 23:49 |
two logs that didn't get updated the first time, and from the failed boot console will be in 'Note' |
(0002576)
john dyer 2023-02-27 23:50 |
anaconda 34.25.0.29-1.e219_8eocky.0.3 for Rocky Linux 9.0 started. ! Installation log files are in /tmp during the installation * when repoort a bug add logs /tmp as separate text/plain attachments Traceback (most recent call last): File "/sbin/anaconda", line 509, in <module> ignore_oemdrv_disks() File "usr/lib64/python3.9/site-packages/pyanaconda/ui/lib/storage.py" line 304, in ignore_oemdrv_dismatched = device_matches("LABEL=OEMDRV", disks_only=True) File "usr/lib64python3.,9/site-packages/pyanaconda/core/storage.py", line 100,, in device_matches single_spe_matchs - udev.resolve_glob(full_spec) File "usr/lib/pythin3.9/site-packages/glivet/udev.py", line 163, in resolve_glob for dev in get_devices(): File "usr/lib/pythod3.9/site-packages/blivet/udev.py", line 81, in get_devices dev= device_to_dict(device) File "usr/lib/pythod3.9/site-packages/blivet/udev.py", line 53, in get_devices dev= device_to_dict result=dictr(device.properties) File "usr/lib/python3.9/site-packagages/pyudev/device/_device.py", line 1060 in _getitem_ return ensure_unicode_string(value) File "usr/lib/python3.9/site-packages/pyudev_utill.py", line 64, in ensure_unicode_string value =value.decode(sys.getfilesystemencodeing()) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xdb in position 1: unexpected end of data |
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: |
2278 | [Rocky-Linux-9] fwupd | tweak | always | 2023-02-17 07:55 | 2023-02-17 11:18 |
Reporter: | Danie de Jager | 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: | uninstall fwupd prevent system to boot due to shum-x64 removal | ||||
Description: |
I cleaned up a host running Rocky 9.1. I removed fwupd as I did not need it as I'm running the host in the cloud which won't have any firmware updates. I did not fully appreciate the consequences of what will happen when removing shim-x64 will have on my life. Due to the current dependencies fwupd effectively becomes a required package, even if I don't have a host that would be supported by it. Can the dependency be revaluated not to remove shim-x64? I can see that shim-x64 would be required and should already be installed on the host but can it stay behind when uninstalling something like fwupd and not cause other users to break their systems? |
||||
Tags: | |||||
Steps To Reproduce: |
yum remove fwupd -y Removing: fwupd x86_64 1.7.9-1.el9 @baseos 7.1 M Removing dependent packages: shim-x64 x86_64 15.6-1.el9.rocky.0.1 @baseos 4.5 M Removing unused dependencies: bubblewrap x86_64 0.4.1-6.el9 @baseos 102 k flashrom x86_64 1.2-10.el9 @appstream 1.8 M fwupd-plugin-flashrom x86_64 1.7.9-1.el9 @appstream 2.1 M libgcab1 x86_64 1.4-6.el9 @baseos 207 k libjcat x86_64 0.1.6-3.el9 @baseos 181 k libsmbios x86_64 2.4.3-4.el9 @baseos 388 k libxmlb x86_64 0.3.3-1.el9 @baseos 279 k mokutil x86_64 2:0.4.0-9.el9 @baseos 90 k |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0002511)
Danie de Jager 2023-02-17 07:58 |
I made a typo on the summary. The package is shim-x64 |
(0002512)
Louis Abel 2023-02-17 08:58 |
Thank you for the report. We understand the need to "debloat" or remove "unnecessary" packages. This is a case where there are package dependencies outside of our control. In majority of cases, package dependencies are determined at build time. In this report, shim-x64 requires dbxtool and fwupd provides dbxtool. [root@xmpp01 ~]# rpm -q shim-x64 --requires dbxtool >= 0.6-3 efi-filesystem mokutil >= 1:0.3.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 [root@xmpp01 ~]# dnf repoquery -q --whatprovides dbxtool fwupd-0:1.7.9-1.el9.x86_64 There's unfortunately no (recommended) way around this, other than to run the cloud images in BIOS mode and remove the packages then. We will likely not make adjustments to the packages as it would make us deviate from upstream (RHEL) behavior. RHEL and CentOS stream has this behavior and thus we inherit it. Ultimately, it may be better to report this upstream to bugzilla.redhat.com. They may be able to provide clarification on why it is the way it is and/or if they would be open to adjusting the behavior, which could potentially come down to us in 8.8 and 9.2. Setting to acknowledge for the time being. |
(0002513)
Danie de Jager 2023-02-17 11:18 |
I logged a ticket on Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2170840 |
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: |
859 | [Rocky-Linux-8] General | minor | always | 2022-11-16 15:18 | 2023-02-17 03:56 |
Reporter: | lnx 1991 | 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: | Move 8.6 to the Vault | ||||
Description: |
Hi friends, we need to move 8.6 over to the Vault now that 8.7 is out, such that we can leverage it downstream to pull the older kernels for 3rd party proprietary modules (DellEMC PowerPath). http://dl.rockylinux.org/vault/rocky/ Thank you! ref: https://bugs.rockylinux.org/view.php?id=107 |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0001191)
lnx 1991 2022-11-22 14:17 |
I confirm we now see it on the master server and have mirrored it downstream, thank you. https://dl.rockylinux.org/vault/rocky/8.6/ |
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: |
2080 | [Cloud] General | major | always | 2023-02-03 16:25 | 2023-02-03 16:44 |
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: | 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: | |||||
There are no notes attached to this issue. |
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: |
1190 | [Rocky-Linux-8] rocky-release | feature | N/A | 2022-11-29 19:31 | 2022-12-22 15:04 |
Reporter: | Pat Riehecky | Platform: | |||
Assigned To: | Louis Abel | OS: | |||
Priority: | none | OS Version: | |||
Status: | needinfo | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
Summary: | [RFE] start using os-release SUPPORT_END=YYYY-MM-DD | ||||
Description: |
Following https://bugzilla.redhat.com/show_bug.cgi?id=2105402 . Currently RHEL systemd doesn't recognize this metadata, but it is still handy to have a unified way to check for EOL date from the OS itself. Description of problem: Systemd has added a field to os-release called SUPPORT_END which can be useful for folks to generate automated reminders of systems nearing their end of support. Starting with systemd 252 the system can use this metadata directly. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: |
Additional info: https://github.com/systemd/systemd/pull/23924/files A sample script to begin notifying folks about pending end of life is provided in: https://github.com/systemd/systemd/issues/21764 |
||||
Attached Files: | |||||
Notes | |
(0001354)
Pat Riehecky 2022-11-29 19:31 |
A similar fix would be welcome in Rocky Linux 9 as well. |
(0001355)
Louis Abel 2022-11-29 21:14 |
Thank you for the RFE. Unfortunately, Rocky Linux 8 uses systemd 239 and Rocky Linux 9 uses 250. They do not have the patches necessary to support the SUPPORT_END feature, and it's unlikely that Red Hat would backport it. While I do like the idea of supporting such a feature, I'm not sure of the implications of backporting it just for Rocky Linux (as at that point it would make us begin to deviate). While this is the case though, this wouldn't stop us from adding SUPPORT_END to our /etc/os-release file (keeping in mind there would be no direct system utility that would use it). |
(0001882)
Pat Riehecky 2022-12-22 15:04 |
With https://gitlab.com/redhat/centos-stream/rpms/systemd/-/merge_requests/59 merged into CentOS Stream, I'd love to have this ready for 9.2 |
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: |
1453 | [Cloud] General | minor | always | 2022-12-14 08:46 | 2022-12-14 20:41 |
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! |
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: |
1388 | [Rocky-Linux-9] iptables | minor | always | 2022-12-11 21:05 | 2022-12-12 06:07 |
Reporter: | Wayne Johnson | Platform: | x86_64 | ||
Assigned To: | Louis Abel | OS: | Rocky Linux | ||
Priority: | normal | OS Version: | 9.1 | ||
Status: | needinfo | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
Summary: | iptables no longer accepts --source=network/mask | ||||
Description: |
iptables in CentOS 7.x, Rocky 8.* and Rocky 9.0 accept long options using --name=value syntax, for example: iptables -A INPUT --source=10.224.0.0/27 -j ACCEPT However the same on Rocky 9.1 produces error: iptables-restore v1.8.8 (nf_tables): host/network `--source=10.224.0.0' not found Replacing the '=' with a whitespace works. Is it really the intention to no longer allow --name=value syntax, or is this a regression? We have an automated process which produces iptables rules using the '=' syntax. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0001750)
Louis Abel 2022-12-12 06:07 |
`man 8 iptables` on CentOS 7, Rocky Linux 8, Rocky Linux 9 state: [!] -s, --source address[/mask][,...] Source specification. Address can be either a network name, a hostname, a network IP address (with /mask), or a plain IP address. Hostnames will be resolved once only, before the rule is submitted to the kernel. Please note that specifying any name to be resolved with a remote query such as DNS is a really bad idea. The mask can be either an ipv4 network mask (for iptables) or a plain number, specifying the number of 1's at the left side of the network mask. Thus, an iptables mask of 24 is equivalent to 255.255.255.0. A "!" argument before the address specification inverts the sense of the address. The flag --src is an alias for this option. Multiple addresses can be specified, but this will expand to multiple rules (when adding with -A), or will cause multiple rules to be deleted (with -D). This shows that "=" is likely not expected. Can you present examples or official documentation that shows that `--source=x.x.x.x` should work? If you can, then this may be a bug to report upstream. Note that even if this is an upstream regression, iptables is considered legacy; all iptables commands use the nf_tables backend instead of the legacy backend. As such, it may be unlikely it will be fixed. |
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: |
1354 | [Rocky-Linux-9] rocky-release | minor | N/A | 2022-12-09 00:24 | 2022-12-09 00:24 |
Reporter: | Akemi Yagi | 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-devel.repo does not include [devel-debug] and [devel-source] | ||||
Description: |
The content of rocky-devel.repo includes: [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 However it's missing [devel-debug] and [devel-source]. |
||||
Tags: | |||||
Steps To Reproduce: | It's nice to see the WARNING in big letters. :) | ||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
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: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB (U) 2*2048kB (UM) 2*4096kB (M) = 13312kB Nov 24 05:43:37 hostname kernel: Node 0 DMA32: 24038*4kB (UME) 22093*8kB (UME) 9551*16kB (UME) 293*32kB (UME) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 435088kB Nov 24 05:43:37 hostname kernel: Node 0 Normal: 8267*4kB (UMEH) 1192*8kB (UMEH) 2403*16kB (UMEH) 391*32kB (UH) 10*64kB (H) 3*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 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: |
1024 | [Rocky-Linux-8] General | major | always | 2022-11-21 18:54 | 2022-11-21 20:08 |
Reporter: | sylvain guyot | 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: | openldap rpm is not compiled with sha2 module as it is done in centos7 rpm | ||||
Description: |
openldap rpm r8 (version 2.4.46) on rocky linux 8 is not compiled with sha2 module (as it is done in centos7 rpm) https://git.rockylinux.org/staging/rpms/openldap/-/blob/r8/SPECS/openldap.spec We are not able to hash password with SSHA512 The following command fails : slappasswd -h {SSHA512} -o module-path=/usr/lib64/openldap -o module-load=pw-sha2 -s password Could you modify the rpm build of the version 2.4 (r8) to include the module pw-sha2 ? |
||||
Tags: | |||||
Steps To Reproduce: |
Launch the command : slappasswd -h {SSHA512} -o module-path=/usr/lib64/openldap -o module-load=pw-sha2 -s password |
||||
Additional Information: |
In centos spec (https://git.centos.org/rpms/openldap/blob/c7/f/SPECS/openldap.spec) we have the following lines to compile the sha2 module : # build sha2 with other overlays ln -s ../../../contrib/slapd-modules/passwd/sha2/{sha2.{c,h},slapd-sha2.c} \ servers/slapd/overlays ls servers/slapd/overlays mv contrib/slapd-modules/passwd/sha2/README{,.sha2} |
||||
Attached Files: | |||||
Notes | |
(0001156)
Louis Abel 2022-11-21 20:08 |
Thank you for the report. Unfortunately we avoid making changes like this to the packages that Red Hat releases to maintain compatibility with their product and packages. CentOS 7 was the same way. In your example, you can see pw-sha2 being patched in (and a reference to a private bug in the change log), so this was done by Red Hat (not by CentOS). In 8, this isn't the case. It also seems the Fedora OpenLDAP package doesn't have it patched in either. It's likely this is because Red Hat does not directly support nor maintain the openldap-servers package. You may or may not get a response from red hat if you file a bug at bugzilla.redhat.com. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
991 | [Rocky-Linux-8] Installer | minor | always | 2022-11-20 17:10 | 2022-11-20 17:10 |
Reporter: | David Roth | Platform: | el9 | ||
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: | Module cramfs, floppy and sha256 are not found during installation | ||||
Description: | During a bare metal installation from USB flash drive of Rocky Linux 9.0 messages are displayed that module cramfs, floppy and sha256 are not found. Please see screen photo. The complete syslog file as a ZIP file from installation is also included. | ||||
Tags: | installation, Modprobe | ||||
Steps To Reproduce: |
1) Boot from USB Flash Drive of 9.0 ISO on bare metal. 2) Select Install 3) These messages (Module cramfs, floppy and sha256 are not found) flash by on the screen. 4) Examine the syslog located in /tmp during installation and the following messages can be found, that Module cramfs, floppy and sha256 are not found. 11:30:10,263 INFO dracut-pre-udev:anaconda-modprobe: Module cramfs not found 11:30:10,288 INFO dracut-pre-udev:anaconda-modprobe: Module floppy not found 11:30:10,536 INFO dracut-pre-udev:anaconda-modprobe: Module sha256 not found |
||||
Additional Information: | This is also present on Rocky Linux 9.1 beta and I reported it in the Rocky Linux Testing Channel on 11/20/2022. | ||||
Attached Files: |
Rocky_Linux_9.0_stable_modules_not_found_11_20_2022.png (304,422 bytes) 2022-11-20 17:10 https://bugs.rockylinux.org/file_download.php?file_id=397&type=bug |
||||
There are no notes attached to this issue. |
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: |
696 | [Rocky-Linux-9] General | minor | always | 2022-11-04 18:02 | 2022-11-04 18:02 |
Reporter: | William Yoga | Platform: | aarch64 | ||
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: | Rocky Linux 9.0 aarch minimal image has wrong checksum | ||||
Description: |
In this directory: https://download.rockylinux.org/pub/rocky/9/isos/aarch64/ The files Rocky-9.0-20220805.0-aarch64-minimal.iso and Rocky-aarch64-minimal.iso are both 1268580352 bytes, and has the checksum of 93e0aa19988ca49cf7fa6ae39790c24cb9f21136fbc5c490eb298c8762a6ffaf. As described in the README, Rocky-aarch64-minimal.iso is a link to the latest minimal iso. So this is expected. The file Rocky-aarch64-minimal.iso.CHECKSUM contains the correct file size and checksum. However, the file Rocky-9.0-20220805.0-aarch64-minimal.iso.CHECKSUM has a wrong file size and checksum. The file CHECKSUM also contains the wrong file size and checksum for Rocky-9.0-20220805.0-aarch64-minimal.iso. |
||||
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: |
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: |
298 | [Rocky-Linux-9] Installer | crash | always | 2022-09-14 07:29 | 2022-10-06 06:09 |
Reporter: | MING-LI JIANG | Platform: | Virtual Environment | ||
Assigned To: | Louis Abel | OS: | Proxmox VE | ||
Priority: | high | OS Version: | 7.2-7 | ||
Status: | needinfo | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
Summary: | Fatal glibc error: CPU does not support x86-64-v2 when installing Rocky Linux 9 on pve7 | ||||
Description: | Fatal glibc error: CPU does not support x86-64-v2 | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: |
螢幕擷取畫面 2022-09-14 003405.png (157,355 bytes) 2022-09-14 07:29 https://bugs.rockylinux.org/file_download.php?file_id=203&type=bug 螢幕擷取畫面 2022-09-14 153754.png (58,810 bytes) 2022-09-14 07:41 https://bugs.rockylinux.org/file_download.php?file_id=204&type=bug 螢幕擷取畫面 2022-09-14 155939.png (27,839 bytes) 2022-09-14 08:01 https://bugs.rockylinux.org/file_download.php?file_id=205&type=bug |
||||
Notes | |
(0000529)
Louis Abel 2022-09-14 07:32 |
Thank you for the report. What CPU is in your system? I would verify your CPU supports x86-64-v2. If your CPU supports x86-64-v2, it is recommended to pass your CPU to the virtual machine. You can do this by choosing "host" for your virtual machine CPU. Setting to needinfo. |
(0000530)
MING-LI JIANG 2022-09-14 07:41 |
Linux icmnlab 5.15.53-1-pve #1 SMP PVE 5.15.53-1 (Fri, 26 Aug 2022 16:53:52 +0200) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Sep 14 15:34:49 CST 2022 on pts/0 root@icmnlab:~# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 46 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) W-2123 CPU @ 3.60GHz Stepping: 4 CPU MHz: 3600.000 CPU max MHz: 3900.0000 CPU min MHz: 1200.0000 BogoMIPS: 7200.00 Virtualization: VT-x L1d cache: 128 KiB L1i cache: 128 KiB L2 cache: 4 MiB L3 cache: 8.3 MiB NUMA node0 CPU(s): 0-7 Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages Vulnerability L1tf: Mitigation; PTE Inversion; VMX EPT disabled Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Retbleed: Mitigation; IBRS Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; IBRS, IBPB conditional, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Mitigation; Clear CPU buffers; SMT vulnerable Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1g b rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_c pl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriori ty ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida ara t pln pts hwp hwp_act_window hwp_epp hwp_pkg_req md_clear flush_l1d |
(0000531)
Louis Abel 2022-09-14 07:51 |
Please run: /lib64/ld-linux-x86-64.so.2 --help | grep x86-64-v2 "x86-64-v2 (supported, searched)" must return when you run this. In the event that it does, you will need to ensure your VM's are being passed "host" for the CPU. |
(0000532)
MING-LI JIANG 2022-09-14 08:01 |
|
(0000535)
Louis Abel 2022-09-15 02:42 |
Please read through the following link to help determine if your system supports x86-64-v2. https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-supports-x86-64-v2/631226 |
(0000665)
Joris Lambrecht 2022-10-06 06:00 |
Same problem. CPU supports x86-64-v2 CPU supports x86-64-v3 What is the point of Rocky Linux refusing to work on kvm64 ? Using host is wasteful in terms of resource usage. Are there any boot flags which can be used to avoid this behavior ? |
(0000667)
Joris Lambrecht 2022-10-06 06:09 |
FYI/ https://bugzilla.redhat.com/show_bug.cgi?id=2060839 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
432 | [Rocky-Linux-9] lorax | tweak | always | 2022-10-04 16:58 | 2022-10-06 02:34 |
Reporter: | Jeff Domogala | Platform: | x86_64 | ||
Assigned To: | Louis Abel | OS: | Rocky Linux | ||
Priority: | normal | OS Version: | 9.0 | ||
Status: | acknowledged | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
Summary: | Network config should not be required for url install type for file:/// | ||||
Description: |
The lorax package I have installed is lorax-34.9.14-1.el9.x86_64. The livemedia-creator install is to a disk image. In CentOS 7 I was able to mount the install ISO in /mnt/install/repo and use the following kickstart url install method: url --url="file:///mnt/install/repo" With the same install method used in Rocky 9, livemedia-creator now throws the following message and exits: The kickstart must activate networking if the url or nfs install method is used. |
||||
Tags: | |||||
Steps To Reproduce: |
1 - Create the file test.ks with just one line: url --url="file:///mnt/install/repo" 2 - Run the following command: livemedia-creator --no-virt --make-disk --ks=test.ks --image-only --dracut-arg=--no-hostonly --image-name image.tmp 3 - The command will fail with output similar to the following: [root@rocky9 i95code]# livemedia-creator --no-virt --make-disk --ks=test.ks --image-only --dracut-arg=--no-hostonly --image-name image.tmp 2022-10-04 12:52:13,684: livemedia-creator v34.9.14-1 2022-10-04 12:52:13,684: selinux is Disabled 2022-10-04 12:52:13,737: The kickstart must activate networking if the url or nfs install method is used. 2022-10-04 12:52:13,737: The kickstart must activate networking if the url or nfs install method is used. |
||||
Additional Information: |
The source of this message is in /usr/lib/python3.9/site-packages/pylorax/creator.py A workaround patch I am using is: [root@rocky9 pylorax]# diff /usr/lib/python3.9/site-packages/pylorax/creator.py.orig /usr/lib/python3.9/site-packages/pylorax/creator.py 609,611c609,611 < if ks.handler.method.method in ("url", "nfs") and not ks.handler.network.seen: < errors.append("The kickstart must activate networking if " < "the url or nfs install method is used.") --- > # if ks.handler.method.method in ("url", "nfs") and not ks.handler.network.seen: > # errors.append("The kickstart must activate networking if " > # "the url or nfs install method is used.") |
||||
Attached Files: | |||||
Notes | |
(0000661)
Louis Abel 2022-10-04 17:26 |
The change they made here is likely deliberate. See this: https://github.com/weldr/lorax/issues/164 I think it would be better to post the question to the lorax folks and get clarification on how to work with local file repositories. As far as I understand it, you can't use "repo" by itself, you need both url and repo, and url in lorax (since about 4 years ago) expects networking to be enabled. |
(0000663)
Jeff Domogala 2022-10-06 02:12 |
Lorax issue opened: https://github.com/weldr/lorax/issues/1272 Resulting PR: https://github.com/weldr/lorax/pull/1273 Bug opened against RHEL 9: https://bugzilla.redhat.com/show_bug.cgi?id=2132511 |
(0000664)
Louis Abel 2022-10-06 02:34 |
Thank you for the info! I'm always glad to see how quick they are to respond. I'll keep this ticket open. |
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/nvme*n* 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: |
278 | [Rocky-Linux-9] basesystem | minor | always | 2022-09-08 18:19 | 2022-09-08 19:56 |
Reporter: | donovan ellis | Platform: | rocky 9 | ||
Assigned To: | Louis Abel | OS: | rocky patched | ||
Priority: | normal | OS Version: | 9 | ||
Status: | needinfo | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
Summary: | unable to installed chkconfig | ||||
Description: |
Unable to install chkconfig, tried many times. See below I did see a ticket on this and it said you could not replicate the problem. This is a brand new machine that is fully patched yum update -y. I then installed safenet then I need chkconfig and it would not install [root@rocktest centrify]# dnf install chkconfig Last metadata expiration check: 0:18:24 ago on Thu 08 Sep 2022 01:58:06 PM EDT. Dependencies resolved. =========================================================================================================================================================================== Package Architecture Version Repository Size =========================================================================================================================================================================== Installing: chkconfig x86_64 1.20-2.el9 baseos 162 k Transaction Summary =========================================================================================================================================================================== Install 1 Package Total download size: 162 k Installed size: 764 k Is this ok [y/N]: y Downloading Packages: chkconfig-1.20-2.el9.x86_64.rpm 244 kB/s | 162 kB 00:00 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 165 kB/s | 162 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : chkconfig-1.20-2.el9.x86_64 1/1 Error unpacking rpm package chkconfig-1.20-2.el9.x86_64 Verifying : chkconfig-1.20-2.el9.x86_64 1/1 Failed: chkconfig-1.20-2.el9.x86_64 Error: Transaction failed [root@rocktest centrify]# And then [root@rocktest centrify]# yum install chkconfig Last metadata expiration check: 0:19:05 ago on Thu 08 Sep 2022 01:58:06 PM EDT. Dependencies resolved. =========================================================================================================================================================================== Package Architecture Version Repository Size =========================================================================================================================================================================== Installing: chkconfig x86_64 1.20-2.el9 baseos 162 k Transaction Summary =========================================================================================================================================================================== Install 1 Package Total download size: 162 k Installed size: 764 k Is this ok [y/N]: yes Downloading Packages: chkconfig-1.20-2.el9.x86_64.rpm 440 kB/s | 162 kB 00:00 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 239 kB/s | 162 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : chkconfig-1.20-2.el9.x86_64 1/1 Error unpacking rpm package chkconfig-1.20-2.el9.x86_64 Verifying : chkconfig-1.20-2.el9.x86_64 1/1 Failed: chkconfig-1.20-2.el9.x86_64 Error: Transaction failed [root@rocktest centrify]# ^C [root@rocktest centrify]# Same isssue |
||||
Tags: | |||||
Steps To Reproduce: |
Install rocky 9 and try to install chkconfig |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000501)
donovan ellis 2022-09-08 18:29 |
more info. I did try to run chkconfig before installing. It asked if wanted to install it. I said yes. that seems to cause the problem. In my case I restore the snap show and ran dnf install chkconfig and it installed OK |
(0000502)
Louis Abel 2022-09-08 19:56 |
As mentioned in a prior ticket, we cannot reproduce this. [root@idp ~]# dnf install chkconfig Last metadata expiration check: 1:39:01 ago on Thu 08 Sep 2022 11:06:19 AM MST. Dependencies resolved. ================================================================================================================================================================ Package Architecture Version Repository Size ================================================================================================================================================================ Installing: chkconfig x86_64 1.20-2.el9 baseos 162 k Transaction Summary ================================================================================================================================================================ Install 1 Package Total download size: 162 k Installed size: 764 k Is this ok [y/N]: y Downloading Packages: chkconfig-1.20-2.el9.x86_64.rpm 401 kB/s | 162 kB 00:00 ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 212 kB/s | 162 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : chkconfig-1.20-2.el9.x86_64 1/1 Running scriptlet: chkconfig-1.20-2.el9.x86_64 1/1 Verifying : chkconfig-1.20-2.el9.x86_64 1/1 Installed: chkconfig-1.20-2.el9.x86_64 Complete! Please provide the following information: rpm -q initscripts chkconfig systemd rpm -qf /etc/init.d Note: If you have created /etc/init.d as a directory, you will not be able to install the chkconfig nor initscripts packages. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
273 | [Rocky-Linux-9] python3 | minor | always | 2022-09-03 00:16 | 2022-09-06 15:26 |
Reporter: | H Elavia | Platform: | |||
Assigned To: | Louis Abel | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | no change required | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
Summary: | Python3-devel conflict with epel-rpm-macros-9-5.el9.noarch | ||||
Description: |
Hello, I'm trying to create cobbler rpms for Rocky Linux 9 and it requires the both python3-devel and epel-rpm-macros installed. There seems to be a conflict with the two packages regardless of which one is installed first. Please see the following error: dnf install python3-devel Last metadata expiration check: 0:25:45 ago on Fri 02 Sep 2022 04:42:32 PM PDT. Error: Problem: problem with installed package epel-rpm-macros-9-5.el9.noarch - package epel-rpm-macros-9-5.el9.noarch requires (pyproject-rpm-macros if python3-rpm-macros), but none of the providers can be installed - problem with installed package rpm-build-4.16.1.3-12.el9_0.x86_64 - package python3-devel-3.9.10-2.el9.x86_64 requires (python3-rpm-macros if rpm-build), but none of the providers can be installed - cannot install the best candidate for the job (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) |
||||
Tags: | |||||
Steps To Reproduce: |
dnf install epel-release dnf clean all dnf makecache dnf -y update dnf -y install epel-rpm-macros dnf -y install python3-devel |
||||
Additional Information: |
There are additional packages installed but the ones mentioned above are the issue. Please see below: dnf -y install tftp-server openssl python3-cheetah python3-coverage createrepo rpm-build python3-pip-wheel python3-setuptools-wheel python3-pkginfo python3-pip python3-distro python3-netaddr python3-schema pip3 install wheel |
||||
Attached Files: | |||||
Notes | |
(0000495)
Louis Abel 2022-09-03 00:51 |
Hello. I am unable to reproduce your issue. [root@awx ~]# dnf clean all 0 files removed [root@awx ~]# dnf repolist repo id repo name appstream Rocky Linux 9 - AppStream baseos Rocky Linux 9 - BaseOS crb Rocky Linux 9 - CRB epel Extra Packages for Enterprise Linux 9 - x86_64 extras Rocky Linux 9 - Extras [root@awx ~]# rpm -q epel-release epel-release-9-4.el9.noarch [root@awx ~]# dnf makecache Extra Packages for Enterprise Linux 9 - x86_64 3.2 MB/s | 9.4 MB 00:02 Rocky Linux 9 - BaseOS 3.5 MB/s | 1.7 MB 00:00 Rocky Linux 9 - AppStream 11 MB/s | 6.0 MB 00:00 Rocky Linux 9 - CRB 2.8 MB/s | 1.9 MB 00:00 Rocky Linux 9 - Extras 37 kB/s | 6.6 kB 00:00 Metadata cache created. [root@awx ~]# dnf update -y Last metadata expiration check: 0:00:29 ago on Fri 02 Sep 2022 05:23:39 PM MST. Dependencies resolved. Nothing to do. Complete! [root@awx ~]# dnf install epel-rpm-macros -y Last metadata expiration check: 0:00:38 ago on Fri 02 Sep 2022 05:23:39 PM MST. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing: epel-rpm-macros noarch 9-5.el9 epel 16 k Installing dependencies: ansible-srpm-macros noarch 1-7.el9 epel 7.6 k Transaction Summary ================================================================================ Install 2 Packages Total download size: 24 k Installed size: 18 k Downloading Packages: (1/2): ansible-srpm-macros-1-7.el9.noarch.rpm 14 kB/s | 7.6 kB 00:00 (2/2): epel-rpm-macros-9-5.el9.noarch.rpm 30 kB/s | 16 kB 00:00 -------------------------------------------------------------------------------- Total 22 kB/s | 24 kB 00:01 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : ansible-srpm-macros-1-7.el9.noarch 1/2 Installing : epel-rpm-macros-9-5.el9.noarch 2/2 Running scriptlet: epel-rpm-macros-9-5.el9.noarch 2/2 Verifying : ansible-srpm-macros-1-7.el9.noarch 1/2 Verifying : epel-rpm-macros-9-5.el9.noarch 2/2 Installed: ansible-srpm-macros-1-7.el9.noarch epel-rpm-macros-9-5.el9.noarch Complete! [root@awx ~]# dnf install python3-devel Last metadata expiration check: 0:00:43 ago on Fri 02 Sep 2022 05:23:39 PM MST. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing: python3-devel x86_64 3.9.10-2.el9 appstream 208 k Installing weak dependencies: python3-pip noarch 21.2.3-6.el9 appstream 1.7 M Transaction Summary ================================================================================ Install 2 Packages Total download size: 1.9 M Installed size: 9.4 M Is this ok [y/N]: y Downloading Packages: (1/2): python3-devel-3.9.10-2.el9.x86_64.rpm 567 kB/s | 208 kB 00:00 (2/2): python3-pip-21.2.3-6.el9.noarch.rpm 3.4 MB/s | 1.7 MB 00:00 -------------------------------------------------------------------------------- Total 3.7 MB/s | 1.9 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : python3-pip-21.2.3-6.el9.noarch 1/2 Installing : python3-devel-3.9.10-2.el9.x86_64 2/2 Running scriptlet: python3-devel-3.9.10-2.el9.x86_64 2/2 Verifying : python3-pip-21.2.3-6.el9.noarch 1/2 Verifying : python3-devel-3.9.10-2.el9.x86_64 2/2 Installed: python3-devel-3.9.10-2.el9.x86_64 python3-pip-21.2.3-6.el9.noarch Complete! --- Installing all packages you've mentioned works as well. This is another Rocky Linux 9 system. [root@idp ~]# dnf -y install tftp-server openssl python3-cheetah python3-coverage createrepo rpm-build python3-pip-wheel python3-setuptools-wheel python3-pkginfo python3-pip python3-distro python3-netaddr python3-schema epel-rpm-macros python3-devel Last metadata expiration check: 0:02:08 ago on Fri 02 Sep 2022 05:23:39 PM MST. Package openssl-1:3.0.1-41.el9_0.x86_64 is already installed. Package python3-pip-wheel-21.2.3-6.el9.noarch is already installed. Package python3-setuptools-wheel-53.0.0-10.el9.noarch is already installed. Package python3-netaddr-0.8.0-5.el9.noarch is already installed. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: createrepo_c x86_64 0.17.7-4.el9_0 appstream 74 k epel-rpm-macros noarch 9-5.el9 epel 16 k python3-cheetah x86_64 3.2.6.post1-1.el9 epel 311 k python3-coverage x86_64 6.2-1.el9 epel 257 k python3-devel x86_64 3.9.10-2.el9 appstream 208 k python3-distro noarch 1.5.0-7.el9 appstream 36 k python3-pip noarch 21.2.3-6.el9 appstream 1.7 M python3-pkginfo noarch 1.8.2-3.el9 epel 35 k python3-schema noarch 0.7.5-3.el9 epel 35 k rpm-build x86_64 4.16.1.3-12.el9_0 appstream 95 k tftp-server x86_64 5.2-35.el9 appstream 40 k Installing dependencies: ansible-srpm-macros noarch 1-7.el9 epel 7.6 k createrepo_c-libs x86_64 0.17.7-4.el9_0 appstream 98 k dwz x86_64 0.14-3.el9 appstream 127 k efi-srpm-macros noarch 6-2.el9_0 appstream 22 k elfutils x86_64 0.186-1.el9 baseos 521 k fonts-srpm-macros noarch 1:2.0.5-7.el9.1 appstream 27 k gdb-minimal x86_64 10.2-9.el9 appstream 3.5 M ghc-srpm-macros noarch 1.5.0-6.el9 appstream 7.8 k go-srpm-macros noarch 3.0.9-9.el9 appstream 26 k kernel-srpm-macros noarch 1.0-11.el9 appstream 15 k lua-srpm-macros noarch 1-6.el9 appstream 8.5 k ocaml-srpm-macros noarch 6-6.el9 appstream 7.8 k openblas-srpm-macros noarch 2-11.el9 appstream 7.4 k patch x86_64 2.7.6-16.el9 appstream 127 k perl-srpm-macros noarch 1-41.el9 appstream 8.2 k pyproject-rpm-macros noarch 1.0.0~rc1-1.el9 crb 38 k python-rpm-macros noarch 3.9-52.el9 appstream 18 k python-srpm-macros noarch 3.9-52.el9 appstream 22 k python3-packaging noarch 20.9-5.el9 appstream 69 k python3-pyparsing noarch 2.4.7-9.el9 baseos 150 k python3-rpm-generators noarch 12-8.el9 appstream 30 k python3-rpm-macros noarch 3.9-52.el9 appstream 15 k qt5-srpm-macros noarch 5.15.2-9.el9 appstream 8.9 k redhat-rpm-config noarch 194-1.el9 appstream 68 k rust-srpm-macros noarch 17-4.el9 appstream 9.3 k Transaction Summary ================================================================================ Install 36 Packages Total download size: 7.7 M Installed size: 29 M Downloading Packages: (1/36): epel-rpm-macros-9-5.el9.noarch.rpm 20 kB/s | 16 kB 00:00 (2/36): ansible-srpm-macros-1-7.el9.noarch.rpm 8.9 kB/s | 7.6 kB 00:00 (3/36): python3-cheetah-3.2.6.post1-1.el9.x86_6 287 kB/s | 311 kB 00:01 (4/36): python3-pkginfo-1.8.2-3.el9.noarch.rpm 128 kB/s | 35 kB 00:00 (5/36): python3-coverage-6.2-1.el9.x86_64.rpm 732 kB/s | 257 kB 00:00 (6/36): python3-schema-0.7.5-3.el9.noarch.rpm 83 kB/s | 35 kB 00:00 (7/36): python3-rpm-generators-12-8.el9.noarch. 121 kB/s | 30 kB 00:00 (8/36): python3-pyparsing-2.4.7-9.el9.noarch.rp 219 kB/s | 150 kB 00:00 (9/36): elfutils-0.186-1.el9.x86_64.rpm 754 kB/s | 521 kB 00:00 (10/36): ghc-srpm-macros-1.5.0-6.el9.noarch.rpm 50 kB/s | 7.8 kB 00:00 (11/36): python3-packaging-20.9-5.el9.noarch.rp 456 kB/s | 69 kB 00:00 (12/36): python3-rpm-macros-3.9-52.el9.noarch.r 115 kB/s | 15 kB 00:00 (13/36): python-srpm-macros-3.9-52.el9.noarch.r 169 kB/s | 22 kB 00:00 (14/36): rust-srpm-macros-17-4.el9.noarch.rpm 69 kB/s | 9.3 kB 00:00 (15/36): python-rpm-macros-3.9-52.el9.noarch.rp 88 kB/s | 18 kB 00:00 (16/36): python3-distro-1.5.0-7.el9.noarch.rpm 249 kB/s | 36 kB 00:00 (17/36): efi-srpm-macros-6-2.el9_0.noarch.rpm 146 kB/s | 22 kB 00:00 (18/36): fonts-srpm-macros-2.0.5-7.el9.1.noarch 134 kB/s | 27 kB 00:00 (19/36): go-srpm-macros-3.0.9-9.el9.noarch.rpm 152 kB/s | 26 kB 00:00 (20/36): kernel-srpm-macros-1.0-11.el9.noarch.r 110 kB/s | 15 kB 00:00 (21/36): openblas-srpm-macros-2-11.el9.noarch.r 46 kB/s | 7.4 kB 00:00 (22/36): lua-srpm-macros-1-6.el9.noarch.rpm 47 kB/s | 8.5 kB 00:00 (23/36): redhat-rpm-config-194-1.el9.noarch.rpm 435 kB/s | 68 kB 00:00 (24/36): perl-srpm-macros-1-41.el9.noarch.rpm 63 kB/s | 8.2 kB 00:00 (25/36): rpm-build-4.16.1.3-12.el9_0.x86_64.rpm 569 kB/s | 95 kB 00:00 (26/36): patch-2.7.6-16.el9.x86_64.rpm 596 kB/s | 127 kB 00:00 (27/36): tftp-server-5.2-35.el9.x86_64.rpm 262 kB/s | 40 kB 00:00 (28/36): python3-devel-3.9.10-2.el9.x86_64.rpm 2.5 MB/s | 208 kB 00:00 (29/36): python3-pip-21.2.3-6.el9.noarch.rpm 3.7 MB/s | 1.7 MB 00:00 (30/36): ocaml-srpm-macros-6-6.el9.noarch.rpm 54 kB/s | 7.8 kB 00:00 (31/36): createrepo_c-libs-0.17.7-4.el9_0.x86_6 563 kB/s | 98 kB 00:00 (32/36): createrepo_c-0.17.7-4.el9_0.x86_64.rpm 364 kB/s | 74 kB 00:00 (33/36): dwz-0.14-3.el9.x86_64.rpm 570 kB/s | 127 kB 00:00 (34/36): qt5-srpm-macros-5.15.2-9.el9.noarch.rp 57 kB/s | 8.9 kB 00:00 (35/36): pyproject-rpm-macros-1.0.0~rc1-1.el9.n 209 kB/s | 38 kB 00:00 (36/36): gdb-minimal-10.2-9.el9.x86_64.rpm 2.3 MB/s | 3.5 MB 00:01 -------------------------------------------------------------------------------- Total 1.4 MB/s | 7.7 MB 00:05 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : qt5-srpm-macros-5.15.2-9.el9.noarch 1/36 Installing : gdb-minimal-10.2-9.el9.x86_64 2/36 Installing : dwz-0.14-3.el9.x86_64 3/36 Installing : createrepo_c-libs-0.17.7-4.el9_0.x86_64 4/36 Installing : ocaml-srpm-macros-6-6.el9.noarch 5/36 Installing : patch-2.7.6-16.el9.x86_64 6/36 Installing : python3-pip-21.2.3-6.el9.noarch 7/36 Installing : perl-srpm-macros-1-41.el9.noarch 8/36 Installing : openblas-srpm-macros-2-11.el9.noarch 9/36 Installing : lua-srpm-macros-1-6.el9.noarch 10/36 Installing : kernel-srpm-macros-1.0-11.el9.noarch 11/36 Installing : efi-srpm-macros-6-2.el9_0.noarch 12/36 Installing : rust-srpm-macros-17-4.el9.noarch 13/36 Installing : ghc-srpm-macros-1.5.0-6.el9.noarch 14/36 Installing : python-srpm-macros-3.9-52.el9.noarch 15/36 Installing : fonts-srpm-macros-1:2.0.5-7.el9.1.noarch 16/36 Installing : go-srpm-macros-3.0.9-9.el9.noarch 17/36 Installing : redhat-rpm-config-194-1.el9.noarch 18/36 Installing : python-rpm-macros-3.9-52.el9.noarch 19/36 Installing : python3-rpm-macros-3.9-52.el9.noarch 20/36 Installing : pyproject-rpm-macros-1.0.0~rc1-1.el9.noarch 21/36 Installing : elfutils-0.186-1.el9.x86_64 22/36 Installing : python3-pyparsing-2.4.7-9.el9.noarch 23/36 Installing : python3-packaging-20.9-5.el9.noarch 24/36 Installing : python3-rpm-generators-12-8.el9.noarch 25/36 Installing : ansible-srpm-macros-1-7.el9.noarch 26/36 Installing : epel-rpm-macros-9-5.el9.noarch 27/36 Installing : python3-devel-3.9.10-2.el9.x86_64 28/36 Installing : rpm-build-4.16.1.3-12.el9_0.x86_64 29/36 Installing : createrepo_c-0.17.7-4.el9_0.x86_64 30/36 Installing : tftp-server-5.2-35.el9.x86_64 31/36 Running scriptlet: tftp-server-5.2-35.el9.x86_64 31/36 Installing : python3-distro-1.5.0-7.el9.noarch 32/36 Installing : python3-schema-0.7.5-3.el9.noarch 33/36 Installing : python3-pkginfo-1.8.2-3.el9.noarch 34/36 Installing : python3-coverage-6.2-1.el9.x86_64 35/36 Installing : python3-cheetah-3.2.6.post1-1.el9.x86_64 36/36 Running scriptlet: python3-cheetah-3.2.6.post1-1.el9.x86_64 36/36 Verifying : ansible-srpm-macros-1-7.el9.noarch 1/36 Verifying : epel-rpm-macros-9-5.el9.noarch 2/36 Verifying : python3-cheetah-3.2.6.post1-1.el9.x86_64 3/36 Verifying : python3-coverage-6.2-1.el9.x86_64 4/36 Verifying : python3-pkginfo-1.8.2-3.el9.noarch 5/36 Verifying : python3-schema-0.7.5-3.el9.noarch 6/36 Verifying : python3-pyparsing-2.4.7-9.el9.noarch 7/36 Verifying : elfutils-0.186-1.el9.x86_64 8/36 Verifying : python3-rpm-generators-12-8.el9.noarch 9/36 Verifying : ghc-srpm-macros-1.5.0-6.el9.noarch 10/36 Verifying : python3-packaging-20.9-5.el9.noarch 11/36 Verifying : python3-rpm-macros-3.9-52.el9.noarch 12/36 Verifying : python-srpm-macros-3.9-52.el9.noarch 13/36 Verifying : python-rpm-macros-3.9-52.el9.noarch 14/36 Verifying : rust-srpm-macros-17-4.el9.noarch 15/36 Verifying : python3-distro-1.5.0-7.el9.noarch 16/36 Verifying : efi-srpm-macros-6-2.el9_0.noarch 17/36 Verifying : fonts-srpm-macros-1:2.0.5-7.el9.1.noarch 18/36 Verifying : go-srpm-macros-3.0.9-9.el9.noarch 19/36 Verifying : kernel-srpm-macros-1.0-11.el9.noarch 20/36 Verifying : lua-srpm-macros-1-6.el9.noarch 21/36 Verifying : openblas-srpm-macros-2-11.el9.noarch 22/36 Verifying : redhat-rpm-config-194-1.el9.noarch 23/36 Verifying : perl-srpm-macros-1-41.el9.noarch 24/36 Verifying : python3-pip-21.2.3-6.el9.noarch 25/36 Verifying : rpm-build-4.16.1.3-12.el9_0.x86_64 26/36 Verifying : patch-2.7.6-16.el9.x86_64 27/36 Verifying : tftp-server-5.2-35.el9.x86_64 28/36 Verifying : ocaml-srpm-macros-6-6.el9.noarch 29/36 Verifying : python3-devel-3.9.10-2.el9.x86_64 30/36 Verifying : createrepo_c-libs-0.17.7-4.el9_0.x86_64 31/36 Verifying : createrepo_c-0.17.7-4.el9_0.x86_64 32/36 Verifying : dwz-0.14-3.el9.x86_64 33/36 Verifying : gdb-minimal-10.2-9.el9.x86_64 34/36 Verifying : qt5-srpm-macros-5.15.2-9.el9.noarch 35/36 Verifying : pyproject-rpm-macros-1.0.0~rc1-1.el9.noarch 36/36 Installed: ansible-srpm-macros-1-7.el9.noarch createrepo_c-0.17.7-4.el9_0.x86_64 createrepo_c-libs-0.17.7-4.el9_0.x86_64 dwz-0.14-3.el9.x86_64 efi-srpm-macros-6-2.el9_0.noarch elfutils-0.186-1.el9.x86_64 epel-rpm-macros-9-5.el9.noarch fonts-srpm-macros-1:2.0.5-7.el9.1.noarch gdb-minimal-10.2-9.el9.x86_64 ghc-srpm-macros-1.5.0-6.el9.noarch go-srpm-macros-3.0.9-9.el9.noarch kernel-srpm-macros-1.0-11.el9.noarch lua-srpm-macros-1-6.el9.noarch ocaml-srpm-macros-6-6.el9.noarch openblas-srpm-macros-2-11.el9.noarch patch-2.7.6-16.el9.x86_64 perl-srpm-macros-1-41.el9.noarch pyproject-rpm-macros-1.0.0~rc1-1.el9.noarch python-rpm-macros-3.9-52.el9.noarch python-srpm-macros-3.9-52.el9.noarch python3-cheetah-3.2.6.post1-1.el9.x86_64 python3-coverage-6.2-1.el9.x86_64 python3-devel-3.9.10-2.el9.x86_64 python3-distro-1.5.0-7.el9.noarch python3-packaging-20.9-5.el9.noarch python3-pip-21.2.3-6.el9.noarch python3-pkginfo-1.8.2-3.el9.noarch python3-pyparsing-2.4.7-9.el9.noarch python3-rpm-generators-12-8.el9.noarch python3-rpm-macros-3.9-52.el9.noarch python3-schema-0.7.5-3.el9.noarch qt5-srpm-macros-5.15.2-9.el9.noarch redhat-rpm-config-194-1.el9.noarch rpm-build-4.16.1.3-12.el9_0.x86_64 rust-srpm-macros-17-4.el9.noarch tftp-server-5.2-35.el9.x86_64 Complete! --- Could you verify the repositories you have enabled? You will need baseos, appstream, crb, and epel at a minimum. If you do not have crb enabled, run `crb enable`. |
(0000497)
H Elavia 2022-09-06 14:47 |
Hello Louis, Thanks for your feedback. enabling crb seems to have fixed the issue. Regards, Hanoz |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
267 | [Rocky-Linux-9] xorg-x11-apps | minor | always | 2022-08-25 20:06 | 2022-08-25 20:14 |
Reporter: | Roger Sewell | Platform: | x86_64 | ||
Assigned To: | Louis Abel | OS: | rockylinux | ||
Priority: | normal | OS Version: | 9.0 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | not fixable | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
Summary: | Can't find xorg-x11-apps on any of the repos | ||||
Description: |
Running yum --showduplicates --enablerepo=\* list available xorg-x11-apps says No matching packages to list. (It also updates among others the CRB repo, which I had thought was where stuff from rocky8 PowerTools was supposed to be.) What has happened to this package ? (Red Hat staff seemed to think it still exists, but haven't yet responded to my saying I can't find it.) |
||||
Tags: | |||||
Steps To Reproduce: | See above | ||||
Additional Information: | I've actually tried installing xorg-x11-apps-7.7-21.el8.x86_64 on my rocky 9.0 system (probably not a brilliant idea) and it installed fine and (to the limited extent that I've tried it) seems to work. | ||||
Attached Files: | |||||
Notes | |
(0000480)
Louis Abel 2022-08-25 20:14 |
xorg-x11-apps doesn't exist for RHEL 9, and thus Rocky Linux 9. It was built in the beginnings of CentOS Stream 9's development as evidenced here: https://kojihub.stream.centos.org/koji/packageinfo?packageID=3367 -- But in general xorg-x11-apps is a deprecated package. See this page for more information: https://access.redhat.com/solutions/3887371 See this page for more information: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages |
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: |
102 | [Cloud] General | major | always | 2022-05-17 03:46 | 2022-08-02 13:09 |
Reporter: | David Monro | Platform: | |||
Assigned To: | Neil Hanlon | OS: | |||
Priority: | high | OS Version: | |||
Status: | confirmed | Product Version: | |||
Product Build: | Resolution: | open | |||
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: |
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: |
158 | [Rocky-Linux-9] General | major | always | 2022-07-21 06:50 | 2022-07-22 06:41 |
Reporter: | Louis Abel | Platform: | pSeries | ||
Assigned To: | Louis Abel | OS: | Rocky Linux | ||
Priority: | normal | OS Version: | 9.0 | ||
Status: | resolved | Product Version: | 9.0 | ||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | 9.0 | ||
Target Version: | 9.0 | ||||
Summary: | ppc64le DVD and minimal images are not bootable | ||||
Description: | The images built for ppc64le, which are the DVD and minimal images, are not bootable, even under emulation. There is likely missing compliance options not being passed into xorriso. | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000299)
Louis Abel 2022-07-21 09:28 |
Rocky-9.0-20220721.0-ppc64le-dvd.iso should contain the attempted fix. empanadas 0.4.0 development commit 2b0907043e9a84b9a44b771b7b10f9ca18c19de0 addresses this change. |
(0000306)
Louis Abel 2022-07-22 06:41 |
This is resolved in the latest compose. The new ppc64le images should be bootable: Rocky-9.0-20220721.0-ppc64le-dvd.iso Rocky-9.0-20220721.0-ppc64le-minimal.iso |
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: |
156 | [Rocky-Linux-9] rocky-release | minor | always | 2022-07-20 11:32 | 2022-07-21 06:53 |
Reporter: | Roman Zhivotovskiy | 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: | Can't add the name of the current tty before login prompt | ||||
Description: |
Edit /etc/issue to show current tty by adding \l escape code. Test with agetty --show-issue is fine, but before login prompt I see "-" instead of the current tty name. Try to some other escape codes and they all work fine. In Rocky 8.6 and Fedora 36 I have no such problem. |
||||
Tags: | |||||
Steps To Reproduce: |
Add \l in /etc/issue Run agetty --show-issue Exit the shell to show message before login prompt |
||||
Additional Information: | |||||
Attached Files: |
bug.png (21,182 bytes) 2022-07-20 11:32 https://bugs.rockylinux.org/file_download.php?file_id=70&type=bug |
||||
Notes | |
(0000291)
Louis Abel 2022-07-20 17:19 (Last edited: 2022-07-20 18:41) |
Thank you for the report. This behavior appears to have been started by a change in systemd itself upstream, where stdin is used to determine the tty. This works in Fedora as you've seen. This is reproducible in RHEL 9 and CentOS Stream 9, though it is unclear why Fedora does not exhibit this issue. This may be a bug report that can be filed upstream to bugzilla.redhat.com. Context: EL8: [root@router ~]# systemctl status | grep getty │ │ └─3914354 grep --color=auto getty │ ├─system-getty.slice │ │ └─getty@tty1.service │ │ └─2292 /sbin/agetty -o -p -- \u --noclear tty1 linux [root@router ~]# grep 'ExecStart' /usr/lib/systemd/system/getty@.service ExecStart=-/sbin/agetty -o '-p -- \\u' --noclear %I $TERM EL9: [root@awx ~]# systemctl status | grep getty │ ├─system-getty.slice │ │ └─getty@tty1.service │ │ └─5883 /sbin/agetty -o "-p -- \\u" --noclear - linux [root@awx ~]# grep 'ExecStart' /usr/lib/systemd/system/getty@.service ExecStart=-/sbin/agetty -o '-p -- \\u' --noclear - $TERM The change in systemd occurred here: https://github.com/systemd/systemd/commit/b4bf9007cbee7dc0b1356897344ae2a7890df84c If the tty arg is set to "-", agetty uses the stdin fd as the tty. Let's pass the tty this way so that we keep an fd open to the tty at all times. If all fd's to a tty are closed, the kernel might reset the tty which we want to avoid. |
(0000292)
Roman Zhivotovskiy 2022-07-20 18:48 |
Thank You very much for answer! It helped me to understand strange behavior of agetty on my system. |
(0000293)
Louis Abel 2022-07-20 18:51 |
Upstream bug has been filed: https://bugzilla.redhat.com/show_bug.cgi?id=2109252 |
(0000296)
Roman Zhivotovskiy 2022-07-21 06:18 |
I find: Fedora 36 uses agetty from util-linux 2.38 Rocky Linux uses agetty from util-linux 2.37.4 https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.38/v2.38-ReleaseNotes Changes between v2.37 and v2.38 ... agetty: - ... - resolve tty name even if stdin is specified [tamz] So for fix, we must update agetty |
(0000297)
Roman Zhivotovskiy 2022-07-21 06:53 |
https://github.com/util-linux/util-linux/issues/1546 Systemd 250 changed its getty@ unit file in systemd/systemd@b4bf900 to call agetty with stdin ("-") port as apparently the kernel could have pontentially reset ttys otherwise. This means that any distribution running systemd will now not display the tty device name at the login prompt, but a dash symbol instead (systemd/systemd#21919). |
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: |
148 | [Rocky-Linux-9] General | trivial | always | 2022-07-18 09:13 | 2022-07-19 12:09 |
Reporter: | Simon Hensel | 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: | Rocky 9 latest image files missing in CHECKSUM file | ||||
Description: |
The checksums for the 'latest' Rocky 9 images are missing in the checksum file (as opposed to Rocky 8.6). E.g. https://dl.rockylinux.org/pub/rocky/9/images/x86_64/CHECKSUM is missing an entry for the image 'Rocky-9-GenericCloud.latest.x86_64.qcow2'. This applies to both x86_64 and aarch64 images. |
||||
Tags: | image | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000276)
Louis Abel 2022-07-19 06:45 |
Hello. Thank you for the report. The "latest" link is actually a symlink to the latest available image. In this case, it would be the images that are dated for 20220706. Our toolkit currently doesn't account for the symlink'd image. In my mind it didn't make sense to have duplicate sums that could potentially confuse users. But it seems this is also confusing too. I will treat this as an RFE and see about putting in the functionality to address this. I can't imagine it'll be too difficult. We'll have new images soon-ish to address another report to us in our mattermost dev channel. I'll leave this bug report open for now. |
(0000279)
Simon Hensel 2022-07-19 08:32 |
Hello Louis, thanks for the quick response! Maybe it helps if I briefly clarify my use case. We maintain a private OpenStack cloud and thus provide different cloud images for our users (e.g. Debian, Ubuntu, Rocky, etc.). This is done via an automated script that takes an image download URL (the latest link) and the corresponding checksums file. If the upstream checksum changes, the image gets updated. So it would be sufficient to have an additional entry with the latest filename in the checksums file that points to the checksum of the newest image. Rocky 8.6 already offers checksums for the latetst pointer: https://dl.rockylinux.org/pub/rocky/8.6/images/CHECKSUM. A similar functionality can be found with other image providers like Ubuntu or Debian. |
(0000281)
Louis Abel 2022-07-19 09:06 |
That is a good point, it looks like we were doing this for 8. It slipped my mind since I haven't looked at our original bash scripts in a long time and my focus was just getting the toolkit working just right for our 9 release (and to eventually take over for 8 this coming fall). So definitely an oversight on my part. I have it fixed in this commit: https://git.resf.org/sig_core/toolkit/commit/65a4ec93c323353742ab99f9c9a8f76b3a1b2440 I am assuming this should work for you (a very simple and testing example below just to verify my change works) [label@sani x86_64]$ ll total 10485776 -rw-r--r--. 1 label label 326 Jul 19 02:04 CHECKSUM -rw-r--r--. 1 label label 10737418240 Jul 19 01:48 Rocky-9-EC2-9.0-20220706.0.x86_64.raw -rw-r--r--. 1 label label 171 Jul 19 01:58 Rocky-9-EC2-9.0-20220706.0.x86_64.raw.CHECKSUM lrwxrwxrwx. 1 label label 37 Jul 19 01:58 Rocky-9-EC2.latest.x86_64.raw -> Rocky-9-EC2-9.0-20220706.0.x86_64.raw -rw-r--r--. 1 label label 155 Jul 19 01:58 Rocky-9-EC2.latest.x86_64.raw.CHECKSUM [label@sani x86_64]$ cat CHECKSUM Rocky-9-EC2-9.0-20220706.0.x86_64.raw: 10737418240 bytes SHA256 (Rocky-9-EC2-9.0-20220706.0.x86_64.raw) = 1ea30f27c7295b2a86f79783d8f2eef1a18db07acfdb7cd9570272c7db2f4f11 Rocky-9-EC2.latest.x86_64.raw: 10737418240 bytes SHA256 (Rocky-9-EC2.latest.x86_64.raw) = 1ea30f27c7295b2a86f79783d8f2eef1a18db07acfdb7cd9570272c7db2f4f11 |
(0000282)
Simon Hensel 2022-07-19 12:09 |
Yes that works perfectly. Thanks for the quick fix! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
145 | [Rocky-Linux-9] anaconda | minor | sometimes | 2022-07-15 15:11 | 2022-07-15 15:57 |
Reporter: | Philipp Dmitrov | Platform: | x86_64 | ||
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: | Graphical artefact during installation | ||||
Description: | Leftbar background doesn't scales | ||||
Tags: | anacoda, glitch, installation | ||||
Steps To Reproduce: | Start installation | ||||
Additional Information: | Was reproduced on Thinkpad l13 (1920x1080), 4k workstation screen and VMs. | ||||
Attached Files: |
Image Pasted at 2022-7-15 17-20.png (189,811 bytes) 2022-07-15 15:11 https://bugs.rockylinux.org/file_download.php?file_id=67&type=bug |
||||
Notes | |
(0000270)
Louis Abel 2022-07-15 15:57 |
Thank you for the report. I believe this is because we are missing a redhat.css file that seems to be present upstream. While we cannot reissue every installer, this fix will come in 9.1 (and updated live images throughout 9.0's release cycle). Once we have an updated package and live image, we would welcome you to help us test the change on your system. Addressed in commit bd43c46ce4ff51fb03ab8d6f597d04308eff9519 https://github.com/rocky-linux/rocky-logos |
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: |
82 | [Rocky-Linux-8] dnf | minor | always | 2022-02-03 09:43 | 2022-05-05 18:19 |
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 . |
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: |
75 | [Rocky-Linux-8] General | major | always | 2021-06-12 15:52 | 2022-04-22 06:17 |
Reporter: | Rich Ercolani | 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: | virtio_scsi and XFS get quite sad in my Virtualbox VM under load | ||||
Description: |
journalctl -k from a relevant run As an experiment, I was trying the OpenZFS ZFS Test Suite, which involves creating a number of large sparse files in /var/, and creating and destroying zpools on them. Every time I've tried this, very quickly the system has gotten upset in a way that an identically-configured VM on Centos 8 does not (see attached log), until ultimately all access to the rootfs responds EIO. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: |
rocky8.log (90,400 bytes) 2022-04-22 06:17 https://bugs.rockylinux.org/file_download.php?file_id=1&type=bug test.dmesg.log (135,439 bytes) 2022-04-22 06:17 https://bugs.rockylinux.org/file_download.php?file_id=2&type=bug |
||||
Notes | |
(0000074)
Louis Abel 2021-06-12 09:35 |
Hello. According to some of the messages, they are leading to believe that either A) there is a kernel or module bug or more likely B) the backend storage device is having issues (whether disk is failing, cabling, etc). This is based on the following logs (ignoring the call obvious traces): Jun 12 01:01:02 rocky8 kernel: XFS (dm-0): metadata I/O error in xfs_da_read_buf+0xcf/0x120 [xfs] at daddr 0x29b0a48 len 8 error 5 ... Jun 12 01:00:17 rocky8 kernel: virtio_scsi virtio1: request:id 549 is not a head! Jun 12 01:00:17 rocky8 kernel: sd 0:0:0:0: [sda] tag#958 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s Jun 12 01:00:17 rocky8 kernel: sd 0:0:0:0: [sda] tag#958 CDB: Write(10) 2a 00 01 76 38 d0 00 00 18 00 Jun 12 01:00:17 rocky8 kernel: blk_update_request: I/O error, dev sda, sector 24525008 op 0x1:(WRITE) flags 0x800 phys_seg 3 prio class 0 ... Jun 12 01:18:36 rocky8 kernel: dm-0: writeback error on inode 52098861, offset 2265088, sector 45857848 Jun 12 01:18:36 rocky8 kernel: sd 0:0:0:0: [sda] tag#903 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s Jun 12 01:18:36 rocky8 kernel: sd 0:0:0:0: [sda] tag#903 CDB: Write(10) 2a 00 03 42 4c d8 00 00 08 00 Jun 12 01:18:36 rocky8 kernel: blk_update_request: I/O error, dev sda, sector 54676696 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0 ... Jun 12 01:20:04 rocky8 kernel: Read-error on swap-device (253:1:93232) Jun 12 01:27:54 rocky8 kernel: sd 0:0:0:0: [sda] tag#911 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s Jun 12 01:27:54 rocky8 kernel: sd 0:0:0:0: [sda] tag#911 CDB: Read(10) 28 00 00 20 1b a0 00 00 08 00 Jun 12 01:27:54 rocky8 kernel: blk_update_request: I/O error, dev sda, sector 2104224 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Jun 12 01:27:54 rocky8 kernel: Read-error on swap-device (253:1:2976) Also ZFS clearly segfaulted at the beginning. This could be related to the above or it could be an isolated case. Jun 12 00:17:13 rocky8 kernel: ZFS: Loaded module v2.1.99-302_gffdf019cb (DEBUG mode), ZFS pool version 5000, ZFS filesystem version 5 Jun 12 00:17:17 rocky8 kernel: loop: module loaded Jun 12 00:24:48 rocky8 kernel: lt-btree_test[48540]: segfault at 0 ip 00007f47eebb0aa3 sp 00007ffc6bf95990 error 4 in libzpool.so.5.0.0[7f47eeb2e000+38f000] Jun 12 00:24:48 rocky8 kernel: Code: 57 41 56 49 89 f6 41 55 41 54 49 89 d4 53 48 89 fb 48 83 ec 58 48 8b 47 28 0f 29 45 90 48 c7 45 a0 00 00 00 00 48 85 c0 74 61 <48> 39 02 74 5c e8 33 f5 ff ff 4c 8d 65 90 4c 89 f6 48 89 df 4c 89 Please setup a similar CentOS 8 system under the following conditions: * kernel 4.18.0-305.el8.x86_64 (do *not* update to 3.1 for now) * Same system specs * Same KVM settings * Same ZFS module and version * Using the same storage backend as your rocky VM Run your tests on this system and provide the logs from journalctl -k. Also attach the XML configuration of both machines to this bug report. Setting to NEEDINFO for now. |
(0000075)
Rich Ercolani 2021-06-12 09:44 |
This is Virtualbox, not KVM, and neither the host nor other guests have reported any similar issues. I'll try setting up the Centos VM as described and get back to you, but this also happened on 4.18.0-240.22.1.el8.x86_64. (The backend being used, as you might infer from some of the log messages, is virtio-scsi.) (The ZFS test segfault is currently expected.) |
(0000076)
Rich Ercolani 2021-06-12 14:01 |
It took 2 runs on Centos 8 with 4.18.0-305.el8.x86_64, versus reproducing every time I tried on Rocky, but it did the same thing. |
(0000077)
Louis Abel 2021-06-12 21:51 |
I cannot reproduce your issue. I've ran the ZFS tests twice on a virtualbox system with virtio_scsi. I have attached a dmesg log from my own system. I will leave this ticket as NEEDINFO. |
(0000078)
Rich Ercolani 2021-06-13 15:03 |
1) The host VirtualBox system is Windows. Should that make a difference? No, but I'm mentioning it for completeness. 2) You used 0.8.6, while I was using git master. The number of commits between those two is...high. I can try and see if my case reproduces with 0.8.6 or 2.0.4 (which is in the zfs-testing repo in the same zfs repo file, where I assume you got your package), but I had something else I wanted to try first. 3) Most importantly, I too could not reproduce it...with one core given to the VM. With two cores, however, fire ensued. |
(0000079)
Rich Ercolani 2021-07-25 11:01 |
Incidental note, still happens on 4.18.0-305.10.2.el8_4.x86_64 |
(0000080)
Louis Abel 2022-04-22 06:17 |
reuploading attachments |
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: |
86 | [Rocky-Linux-8] subscription-manager | minor | always | 2022-03-26 00:38 | 2022-03-26 00:38 |
Reporter: | Lukas Magauer | 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: | 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: | |||||
There are no notes attached to this issue. |
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: |
87 | [Rocky-Linux-8] anaconda | minor | always | 2021-10-14 18:35 | 2021-10-19 22:20 |
Reporter: | Lukas Magauer | Platform: | |||
Assigned To: | Infrastructure Team | OS: | |||
Priority: | low | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
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! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
77 | [Rocky-Linux-8] pki-core | major | always | 2021-08-12 14:27 | 2021-08-12 14:27 |
Reporter: | jonathan MERCIER | 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: | freeipa can not works due too Selinux prevent access to /run/lock/opencryptoki/LCK..APIlock | ||||
Description: |
Dear, I tried to deploy freeipa on rocky linux but I encounter some issues. Indeed pki-tomcat service fail to works properly due to SElinux ``` systemctl start pki-tomcatd@pki-tomcat.service ... août 12 13:44:55 ipa.foo.com java[22792]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock août 12 13:44:57 ipa.foo.com systemd[1]: Started PKI Tomcat Server pki-tomcat. août 12 13:44:57 ipa.foo.com server[22898]: Java virtual machine used: /usr/lib/jvm/java-1.8.0-openjdk/bin/java août 12 13:44:57 ipa.foo.com server[22898]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr> août 12 13:44:57 ipa.foo.com server[22898]: main class used: org.apache.catalina.startup.Bootstrap août 12 13:44:57 ipa.foo.com server[22898]: flags used: -Dcom.redhat.fips=false août 12 13:44:57 ipa.foo.com server[22898]: options used: -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/> août 12 13:44:57 ipa.foo.com server[22898]: arguments used: start août 12 13:44:58 ipa.foo.com java[22898]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock août 12 13:44:59 ipa.foo.com server[22898]: WARNING: Some of the specified [protocols] are not supported by the SSL engine and have been skipped: [[TLSv1, TLSv1.1]] ``` Maybe it is related to the same bug filled on Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1894132 How to reproduce: To deploy freeipa I tried with the ansible collection: https://github.com/freeipa/ansible-freeipa Firstly add rocky linux support ``` git clone https://github.com/freeipa/ansible-freeipa cd ansible-freeipa git checkout v0.3.8 for i in ansible-freeipa/roles/*/vars; do ln -s RedHat-8.yml Rocky-8.yml; done ./utils/build-galaxy-release.sh ansible-galaxy install freeipa-ansible_freeipa-0.3.8.tar.gz ``` The playbooks is more or less like this: ``` --- - name: 'Install python3' hosts: 'ipaserver' become: true gather_facts: false tasks: - name: 'Check if Python 3 is installed' raw: 'python3 --version' register: is_python_installed ignore_errors: true changed_when: is_python_installed.rc != 0 - name: 'Get OS ID like' raw: 'source /etc/os-release && echo "${ID_LIKE}"' register: id_like when: is_python_installed.rc != 0 - name: 'Install python3 on rhel like os' raw: 'yum install -y python3' when: is_python_installed.rc != 0 and 'rhel' in id_like.stdout - name: 'Install python3 on debian like os' raw: 'apt update && apt install -y python3' when: is_python_installed.rc != 0 and 'debian' in id_like.stdout - names: 'freeipa_initialization' roles: tasks: - name: install firewalld dnf: name: firewalld state: latest - name: 'Remove ipa domain into host line with multiple domain name into /etc/hosts' lineinfile: path: '/etc/hosts' regexp: '^(127\.0\.0\.1.+){{ inventory_hostname }}(\s*.+)$' line: '\1\2' backrefs: true - name: 'Remove line where line describe single association of 127.0.0.1 and ipa domain into /etc/hosts' lineinfile: path: '/etc/hosts' regexp: '^127\.0\.0\.1.+{{ inventory_hostname }}\s*$' state: 'absent' - name: 'Add association between external ip and ipa domain into etc/hosts' lineinfile: path: '/etc/hosts' line: '{{ ipaserver_ip_addresses|first }} {{ inventory_hostname }}' insertbefore: BOF - name: Check hostname is valid command: hostname -i register: hostname_ip failed_when: hostname_ip.stdout != ipaserver_ip_addresses|first - name: 'Allow traffic in default zone for freeipa services' ansible.posix.firewalld: service: '{{ item }}' permanent: true state: 'enabled' with_items: - 'freeipa-ldap' - 'freeipa-ldaps' - 'ntp' - 'dns' - 'freeipa-4' - name: 'Playbook to configure IPA servers' hosts: 'ipaserver' become: true collections: - 'freeipa.ansible_freeipa' #vars_files: # - 'group_vars/ipaserver' # - 'group_vars/ipaserver_vault' vars: ipaserver_domain: 'infra.foo.com' ipaserver_realm: 'INFRA.FOO.COM' ipaserver_setup_dns: true ipaserver_auto_forwarders: true ipaserver_idstart: 2000 ipaserver_install_packages: true ipaserver_ip_addresses: - '{{ ansible_default_ipv4.address|default(ansible_all_ipv4_addresses[0]) }}' ipaadmin_password: ADMPassword1 ipadm_password: DMPassword1 roles: - role: 'ipaserver' state: 'present' ``` with ansible-playbooks run and see the issue Thanks for your help best regards |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000082)
jonathan MERCIER 2021-08-12 15:19 |
I have not try the playbooks below, as I use directory architecture I can introduce some yaml syntax error but the general idea of playbook was rewritten, see below. Too I try to switch to permissive mode but I have the same issue ``` --- - name: 'Install python3' hosts: 'ipaserver' become: true gather_facts: false tasks: - name: 'Check if Python 3 is installed' raw: 'python3 --version' register: is_python_installed ignore_errors: true changed_when: is_python_installed.rc != 0 - name: 'Get OS ID like' raw: 'source /etc/os-release && echo "${ID_LIKE}"' register: id_like when: is_python_installed.rc != 0 - name: 'Install python3 on rhel like os' raw: 'yum install -y python3' when: is_python_installed.rc != 0 and 'rhel' in id_like.stdout - name: 'Install python3 on debian like os' raw: 'apt update && apt install -y python3' when: is_python_installed.rc != 0 and 'debian' in id_like.stdout - names: 'freeipa_initialization' hosts: 'ipaserver' become: true roles: tasks: - name: install firewalld dnf: name: firewalld state: latest - name: 'Remove ipa domain into host line with multiple domain name into /etc/hosts' lineinfile: path: '/etc/hosts' regexp: '^(127\.0\.0\.1.+){{ inventory_hostname }}(\s*.+)$' line: '\1\2' backrefs: true - name: 'Remove line where line describe single association of 127.0.0.1 and ipa domain into /etc/hosts' lineinfile: path: '/etc/hosts' regexp: '^127\.0\.0\.1.+{{ inventory_hostname }}\s*$' state: 'absent' - name: 'Add association between external ip and ipa domain into etc/hosts' lineinfile: path: '/etc/hosts' line: '{{ ipaserver_ip_addresses|first }} {{ inventory_hostname }}' insertbefore: BOF - name: Check hostname is valid command: hostname -i register: hostname_ip failed_when: hostname_ip.stdout != ipaserver_ip_addresses|first - name: 'Allow traffic in default zone for freeipa services' ansible.posix.firewalld: service: '{{ item }}' permanent: true state: 'enabled' with_items: - 'freeipa-ldap' - 'freeipa-ldaps' - 'ntp' - 'dns' - 'freeipa-4' - name: 'Playbook to configure IPA servers' hosts: 'ipaserver' become: true collections: - 'freeipa.ansible_freeipa' #vars_files: # - 'group_vars/ipaserver' # - 'group_vars/ipaserver_vault' vars: ipaserver_domain: 'infra.foo.com' ipaserver_realm: 'INFRA.FOO.COM' ipaserver_setup_dns: true ipaserver_auto_forwarders: true ipaserver_idstart: 2000 ipaserver_install_packages: true ipaserver_ip_addresses: - '{{ ansible_default_ipv4.address|default(ansible_all_ipv4_addresses[0]) }}' ipaadmin_password: ADMPassword1 ipadm_password: DMPassword1 roles: - role: 'ipaserver' state: 'present' ``` |
(0000083)
jonathan MERCIER 2021-08-12 23:19 |
The issue can be reproduce more easily by calling ipa-server-install command. See below maybe it is the same red hat bug: https://pagure.io/freeipa/issue/8907 ``` # ipa-server-install --ds-password='changeme' --admin-password='changeme' --setup-dns --idstart=2000 --domain=infra.foo.com --realm=INFRA.FOO.COM --hostname=identity.foo.com --dirsrv-pin='changeme' --http-pin='changeme' --pkinit-pin='changeme' --mkhomedir --ntp-server=XX.YY.ZZ.II --auto-forwarders ... INFO: Starting server\nDEBUG: Command: systemctl start pki-tomcatd@pki-tomcat.service\nINFO: FIPS mode: False\nINFO: Waiting for CA subsystem to start (1s)\nINFO: Waiting for CA subsystem to start (2s)\nINFO: Waiting for CA subsystem to start (3s)\nINFO: Waiting for CA subsystem to start (5s)\nINFO: Waiting for CA subsystem to start (6s)\nINFO: Waiting for CA subsystem to start (7s)\nINFO: Waiting for CA subsystem to start (8s)\nINFO: Waiting for CA subsystem to start (9s)\nINFO: Waiting for CA subsystem to start (10s)\nINFO: Waiting for CA subsystem to start (11s)\nINFO: Waiting for CA subsystem to start (12s)\nINFO: Waiting for CA subsystem to start (13s)\nINFO: Waiting for CA subsystem to start (14s)\nINFO: Waiting for CA subsystem to start (15s)\nINFO: Waiting for CA subsystem to start (16s)\nINFO: Waiting for CA subsystem to start (17s)\nINFO: Waiting for CA subsystem to start (19s)\nINFO: Waiting for CA subsystem to start (20s)\nINFO: Waiting for CA subsystem to start (21s)\nINFO: Waiting for CA subsystem to start (22s)\nINFO: Waiting for CA subsystem to start (23s)\nINFO: Waiting for CA subsystem to start (24s)\nINFO: Waiting for CA subsystem to start (25s)\nINFO: Waiting for CA subsystem to start (26s)\nINFO: Waiting for CA subsystem to start (27s)\nINFO: Waiting for CA subsystem to start (28s)\nINFO: Waiting for CA subsystem to start (29s)\nINFO: Waiting for CA subsystem to start (30s)\nINFO: Waiting for CA subsystem to start (31s)\nINFO: Waiting for CA subsystem to start (32s)\nINFO: Waiting for CA subsystem to start (33s)\nINFO: Waiting for CA subsystem to start (34s)\nINFO: Waiting for CA subsystem to start (35s)\nINFO: Waiting for CA subsystem to start (36s)\nINFO: Waiting for CA subsystem to start (38s)\nINFO: Waiting for CA subsystem to start (39s)\nINFO: Waiting for CA subsystem to start (40s)\nINFO: Waiting for CA subsystem to start (41s)\nINFO: Waiting for CA subsystem to start (42s)\nINFO: Waiting for CA subsystem to start (43s)\nINFO: Waiting for CA subsystem to start (44s)\nINFO: Waiting for CA subsystem to start (45s)\nINFO: Waiting for CA subsystem to start (46s)\nINFO: Waiting for CA subsystem to start (47s)\nINFO: Waiting for CA subsystem to start (48s)\nINFO: Waiting for CA subsystem to start (49s)\nINFO: Waiting for CA subsystem to start (50s)\nINFO: Waiting for CA subsystem to start (51s)\nINFO: Waiting for CA subsystem to start (52s)\nINFO: Waiting for CA subsystem to start (53s)\nINFO: Waiting for CA subsystem to start (54s)\nINFO: Waiting for CA subsystem to start (55s)\nINFO: Waiting for CA subsystem to start (56s)\nINFO: Waiting for CA subsystem to start (57s)\nINFO: Waiting for CA subsystem to start (58s)\nINFO: Waiting for CA subsystem to start (59s)\nERROR: Exception: CA subsystem did not start after 60s\n File "/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line 575, in main\n scriptlet.spawn(deployer)\n File "/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py", line 965, in spawn\n request_timeout,\n File "/usr/lib/python3.6/site-packages/pki/server/deployment/pkihelper.py", line 891, in wait_for_startup\n (subsystem.type, startup_timeout)) from exc\n\n') See the installation logs and the following files/directories for more information: /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration failed. CA configuration failed. The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ``` |
(0000084)
Louis Abel 2021-08-13 01:10 |
Hello. The pagure link in #2 refers to when CentOS did their build against a newer NSS (stream) instead of the current NSS (in 8.4). We did not have this issue and thus did not need to rebuild. Please install the rpaste package and provide the output of rpaste --sysinfo. Optionally, you can provide us this information manually: CPU RAM Disk + Partition and volume layout cat /etc/os-release |
(0000085)
jonathan MERCIER 2021-08-13 07:13 |
Thanks Louis Abel for your help. Here the requested information: https://rpa.st/DV5A |
(0000086)
jonathan MERCIER 2021-08-13 07:30 |
Some extra contextual information that could help (or not): While the pki-tomcatd service is running we can see somme errors ``` # LANG=C journalctl -xe -u pki-tomcatd@pki-tomcat -- Logs begin at Thu 2021-08-12 23:50:54 CEST, end at Fri 2021-08-13 09:16:20 CEST. -- Aug 13 00:42:59 identity.foo.com systemd[1]: Starting PKI Tomcat Server pki-tomcat... -- Subject: Unit pki-tomcatd@pki-tomcat.service has begun start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit pki-tomcatd@pki-tomcat.service has begun starting up. Aug 13 00:43:02 identity.foo.com java[69998]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock Aug 13 00:43:04 identity.foo.com systemd[1]: Started PKI Tomcat Server pki-tomcat. -- Subject: Unit pki-tomcatd@pki-tomcat.service has finished start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit pki-tomcatd@pki-tomcat.service has finished starting up. -- -- The start-up result is done. Aug 13 00:43:04 identity.foo.com server[70104]: Java virtual machine used: /usr/lib/jvm/java-1.8.0-openjdk/bin/java Aug 13 00:43:04 identity.foo.com server[70104]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/ant.jar:/usr/share/java/ant-launcher.j> Aug 13 00:43:04 identity.foo.com server[70104]: main class used: org.apache.catalina.startup.Bootstrap Aug 13 00:43:04 identity.foo.com server[70104]: flags used: -Dcom.redhat.fips=false Aug 13 00:43:04 identity.foo.com server[70104]: options used: -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-> Aug 13 00:43:04 identity.foo.com server[70104]: arguments used: start Aug 13 00:43:05 identity.foo.com java[70104]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock Aug 13 00:43:06 identity.foo.com server[70104]: WARNING: Some of the specified [protocols] are not supported by the SSL engine and have been skipped: [[TLSv1, TLSv1.1]] # systemctl status pki-tomcatd@pki-tomcat.service ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/usr/lib/systemd/system/pki-tomcatd@.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2021-08-13 00:43:04 CEST; 8h ago Process: 70013 ExecStartPre=/usr/bin/pkidaemon start pki-tomcat (code=exited, status=0/SUCCESS) Process: 69980 ExecStartPre=/usr/sbin/pki-server migrate pki-tomcat (code=exited, status=0/SUCCESS) Process: 69977 ExecStartPre=/usr/sbin/pki-server upgrade pki-tomcat (code=exited, status=0/SUCCESS) Main PID: 70104 (java) Tasks: 115 (limit: 23448) Memory: 465.5M CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-tomcat.service └─70104 /usr/lib/jvm/java-1.8.0-openjdk/bin/java -Dcom.redhat.fips=false -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/ant.jar:/usr/shar> ``` Indeed /run/lock/opencryptoki/LCK..APIlock is not present ``` # ls /run/lock/opencryptoki/LCK..APIlock ls: cannot access '/run/lock/opencryptoki/LCK..APIlock': No such file or directory # ls /run/lock/opencryptoki icsf swtok tpm ``` This file is usualy generated by pkcsslotd service ... and this service is dead ``` # systemctl status pkcsslotd * pkcsslotd.service - Daemon which manages cryptographic hardware tokens for the openCryptoki package Loaded: loaded (/usr/lib/systemd/system/pkcsslotd.service; disabled; vendor preset: disabled) Active: inactive (dead) # systemctl start pkcsslotd # systemctl status pkcsslotd * pkcsslotd.service - Daemon which manages cryptographic hardware tokens for the openCryptoki package Loaded: loaded (/usr/lib/systemd/system/pkcsslotd.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-08-13 09:25:35 CEST; 1s ago Process: 71344 ExecStart=/usr/sbin/pkcsslotd (code=exited, status=0/SUCCESS) Main PID: 71345 (pkcsslotd) Tasks: 1 (limit: 23448) Memory: 5.6M CGroup: /system.slice/pkcsslotd.service `-71345 /usr/sbin/pkcsslotd Aug 13 09:25:34 identity.microbiome.studio systemd[1]: Starting Daemon which manages cryptographic hardware tokens for the openCryptoki package... Aug 13 09:25:35 identity.microbiome.studio systemd[1]: Started Daemon which manages cryptographic hardware tokens for the openCryptoki package. # ls /run/lock/opencryptoki/LCK..APIlock /run/lock/opencryptoki/LCK..APIlock ``` |
(0000087)
jonathan MERCIER 2021-08-13 10:38 |
After read this freeipa user lists: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/XFYVC6MUAKYLRIR6H6WM6SD4USLMIG2E/ I removed from /etc/crypto-policies/back-ends/nss.config these two lines: name=p11-kit-proxy library=p11-kit-proxy.so And I downgraded 389-ds-base: dnf downgrade -y 389-ds-base With this I get rid of error: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock Ass seen here: ``` # systemctl status pki-tomcatd@pki-tomcat ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/usr/lib/systemd/system/pki-tomcatd@.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2021-08-13 12:32:13 CEST; 1min 31s ago Process: 11182 ExecStartPre=/usr/bin/pkidaemon start pki-tomcat (code=exited, status=0/SUCCESS) Process: 11149 ExecStartPre=/usr/sbin/pki-server migrate pki-tomcat (code=exited, status=0/SUCCESS) Process: 11146 ExecStartPre=/usr/sbin/pki-server upgrade pki-tomcat (code=exited, status=0/SUCCESS) Main PID: 11273 (java) Tasks: 115 (limit: 23441) Memory: 475.3M CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-tomcat.service └─11273 /usr/lib/jvm/java-1.8.0-openjdk/bin/java -Dcom.redhat.fips=false -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/ant.jar:/usr/shar> août 13 12:32:08 identity.microbiome.studio systemd[1]: Starting PKI Tomcat Server pki-tomcat... août 13 12:32:13 identity.microbiome.studio systemd[1]: Started PKI Tomcat Server pki-tomcat. août 13 12:32:13 identity.microbiome.studio server[11273]: Java virtual machine used: /usr/lib/jvm/java-1.8.0-openjdk/bin/java août 13 12:32:13 identity.microbiome.studio server[1173]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/ant.jar:/usr/share/java/ant-launcher.> août 13 12:32:13 identity.microbiome.studio server[11273]: main class used: org.apache.catalina.startup.Bootstrap août 13 12:32:13 identity.microbiome.studio server[11273]: flags used: -Dcom.redhat.fips=false août 13 12:32:13 identity.microbiome.studio server[11273]: options used: -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki> août 13 12:32:13 identity.microbiome.studio server[11273]: arguments used: start août 13 12:32:16 identity.microbiome.studio server[11273]: WARNING: Some of the specified [protocols] are not supported by the SSL engine and have been skipped: [[TLSv1, TLSv1.1]] ``` but the process still fail ``` INFO: Starting server\nDEBUG: Command: systemctl start pki-tomcatd@pki-tomcat.service\nINFO: FIPS mode: False\nINFO: Waiting for CA subsystem to start (1s)\nINFO: Waiting for CA subsystem to start (2s)\nINFO: Waiting for CA subsystem to start (3s)\nINFO: Waiting for CA subsystem to start (4s)\nINFO: Waiting for CA subsystem to start (5s)\nINFO: Waiting for CA subsystem to start (6s)\nINFO: Waiting for CA subsystem to start (7s)\nINFO: Waiting for CA subsystem to start (8s)\nINFO: Waiting for CA subsystem to start (9s)\nINFO: Waiting for CA subsystem to start (10s)\nINFO: Waiting for CA subsystem to start (11s)\nINFO: Waiting for CA subsystem to start (12s)\nINFO: Waiting for CA subsystem to start (13s)\nINFO: Waiting for CA subsystem to start (14s)\nINFO: Waiting for CA subsystem to start (15s)\nINFO: Waiting for CA subsystem to start (16s)\nINFO: Waiting for CA subsystem to start (18s)\nINFO: Waiting for CA subsystem to start (19s)\nINFO: Waiting for CA subsystem to start (20s)\nINFO: Waiting for CA subsystem to start (21s)\nINFO: Waiting for CA subsystem to start (22s)\nINFO: Waiting for CA subsystem to start (23s)\nINFO: Waiting for CA subsystem to start (24s)\nINFO: Waiting for CA subsystem to start (25s)\nINFO: Waiting for CA subsystem to start (26s)\nINFO: Waiting for CA subsystem to start (27s)\nINFO: Waiting for CA subsystem to start (28s)\nINFO: Waiting for CA subsystem to start (29s)\nINFO: Waiting for CA subsystem to start (30s)\nINFO: Waiting for CA subsystem to start (31s)\nINFO: Waiting for CA subsystem to start (32s)\nINFO: Waiting for CA subsystem to start (33s)\nINFO: Waiting for CA subsystem to start (34s)\nINFO: Waiting for CA subsystem to start (35s)\nINFO: Waiting for CA subsystem to start (36s)\nINFO: Waiting for CA subsystem to start (37s)\nINFO: Waiting for CA subsystem to start (38s)\nINFO: Waiting for CA subsystem to start (39s)\nINFO: Waiting for CA subsystem to start (40s)\nINFO: Waiting for CA subsystem to start (41s)\nINFO: Waiting for CA subsystem to start (42s)\nINFO: Waiting for CA subsystem to start (43s)\nINFO: Waiting for CA subsystem to start (44s)\nINFO: Waiting for CA subsystem to start (45s)\nINFO: Waiting for CA subsystem to start (46s)\nINFO: Waiting for CA subsystem to start (47s)\nINFO: Waiting for CA subsystem to start (48s)\nINFO: Waiting for CA subsystem to start (49s)\nINFO: Waiting for CA subsystem to start (50s)\nINFO: Waiting for CA subsystem to start (51s)\nINFO: Waiting for CA subsystem to start (52s)\nINFO: Waiting for CA subsystem to start (53s)\nINFO: Waiting for CA subsystem to start (54s)\nINFO: Waiting for CA subsystem to start (55s)\nINFO: Waiting for CA subsystem to start (56s)\nINFO: Waiting for CA subsystem to start (57s)\nINFO: Waiting for CA subsystem to start (58s)\nINFO: Waiting for CA subsystem to start (60s)\nERROR: Exception: CA subsystem did not start after 60s\n File "/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line 575, in main\n scriptlet.spawn(deployer)\n File "/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py", line 965, in spawn\n request_timeout,\n File "/usr/lib/python3.6/site-packages/pki/server/deployment/pkihelper.py", line 891, in wait_for_startup\n (subsystem.type, startup_timeout)) from exc\n\n') See the installation logs and the following files/directories for more information: /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration failed. ``` |
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. |