View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
56 | [AlmaLinux-8] grub2 | minor | have not tried | 2021-04-04 05:32 | 2024-03-27 15:37 |
Reporter: | UnknownVictim | Platform: | x86_64 | ||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | low | OS Version: | 8.3 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | /boot/grub2/grub.cfg not being updated during new kernel installation | ||||
Description: |
Installing newest kernel via "yum update" downloads and installs kernel-4.18.0-240.15.1.el8_3.x86_64 and its dependencies, however, /boot/grub2/grub.cfg is not updated during the process. /boot/grub2/grub.cfg can be manually updated via the command "grub2-mkconfig -o /boot/grub2/grub.cfg". |
||||
Tags: | |||||
Steps To Reproduce: |
Freshly installed minimal server, run "yum update" to download and install the updated kernel and dependencies. Check if /boot/grub2/grub.cfg has been updated with the new kernel. (grep 4.18.0-240.15.1.el8_3.x86_64 /boot/grub2/grub.cfg) |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000119)
alukoshko 2021-04-04 16:10 |
Hello and thanks for report. It shouldn't be updated I believe as boot entries are located here: /boot/loader/entries/ Do you have new kernel available in GRUB? |
(0000120)
UnknownVictim 2021-04-04 16:34 |
/boot/loader/entries/ is being updated during "yum update", [root@alma ~]# ls -l /boot/loader/entries/ total 12 -rw-r--r--. 1 root root 388 Apr 3 23:30 96caaef3565d4035b2459c52e5270b7e-0-rescue.conf -rw-r--r--. 1 root root 368 Apr 3 23:37 96caaef3565d4035b2459c52e5270b7e-4.18.0-240.15.1.el8_3.x86_64.conf -rw-r--r--. 1 root root 316 Apr 3 23:30 96caaef3565d4035b2459c52e5270b7e-4.18.0-240.el8.x86_64.conf [root@alma ~]# however /boot/grub2/grub.cfg is not. On reboot, the system is not loading the new kernel. /boot/grub2/grub.cfg was not reconfigured with the new kernel's details. After running "grub2-mkconfig -o /boot/grub2/grub.cfg", /boot/grub2/grub.cfg is configured with the new kernel's details and the new kernel is loaded on reboots. Hope that clarifies what I am seeing. Thank you. |
(0000188)
UnknownVictim 2021-05-09 05:25 |
FWIW, same issue see when installing kernel 4.18.0-240.22.1.el8_3.x86_64. |
(0000300)
alukoshko 2021-07-07 18:10 |
Is problem still occur in 8.4? |
(0000312)
giulio 2021-07-23 15:28 |
By default, BLS boot config system is used: - kernel-core rpm ships a bls.conf file - /usr/lib/kernel/install.d/20-grub.install copies this file to /boot/loader/entries/<new-name>.conf during kernel install - grub.cfg contains "blscfg" command which will read /boot/loader/entries/*.conf at runtime, and create boot menu on the fly - grub.cfg is never automatically updated during kernel updates, because it does not contain any reference to any kernel/initramfs, so it doesn't need to be updated If you disable BLS by using GRUB_ENABLE_BLSCFG=false in /etc/default/grub then see this: https://bugzilla.redhat.com/show_bug.cgi?id=1899903 I think, going on, disabling BLS will be supported "best effort" by Red Hat / Fedora OTOH, if you have GRUB_ENABLE_BLSCFG=true in /etc/default/grub and boot menu won't update, check whether blscfg is present in grub.cfg: .... ... insmod blscfg blscfg ### END /etc/grub.d/10_linux ### Also, check that /etc/machine-id is always the same and is not somehow updated, otherwise /boot/loader/entries/*.conf files may be out of sync. |
(0000711)
cPanelSrTechAnalysts 2022-10-26 15:26 |
This is still happening as of 10/26/2022 on 4.18.0-372.16.1.el8_6.x86_64. Is this going to be fixed anytime in the near future? |
(0001023)
cPanelSrTechAnalysts 2024-03-27 15:37 |
As of 3/27/2024, this is still happening. I spent over an hour trying to figure out why the new kernel didn't have CVE-2023-6817 in the changelogs. It's clearly addressed at https://errata.almalinux.org/8/ALSA-2024-0897.html dnf update and reboots didn't install the new kernel. Running version was: 4.18.0-513.11.1.el8_9.x86_64 Boot Version was: 4.18.0-513.18.1.el8_9.x86_64 Remembered this case and ran the workaround, and now it updated. After 3+ years, this bug is still present? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
430 | [AlmaLinux-8] -OTHER | minor | have not tried | 2023-10-10 08:28 | 2024-03-14 20:53 |
Reporter: | mlitwora | Platform: | |||
Assigned To: | elkhan | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AWS AMI support for the UEFI | ||||
Description: |
In AWS using the AlmaLinux image I'm not able to boot the instance as an UEFI. If the OS is ready to be booted as an UEFI, the issue can be caused by the fact that the boot method for the AMI instance is not set: [cloudshell-user@ip-10-2-38-115 ~]$ aws ec2 describe-images --region us-east-1 --image-id ami-0662bc457a6bc2bb6 { "Images": [ { "Architecture": "x86_64", "CreationDate": "2023-08-05T21:23:26.000Z", "ImageId": "ami-0662bc457a6bc2bb6", "ImageLocation": "aws-marketplace/AlmaLinux OS 8.8.20230804 x86_64-c076b20a-2305-4771-823f-944909847a05", "ImageType": "machine", "Public": true, "OwnerId": "679593333241", "PlatformDetails": "Linux/UNIX", "UsageOperation": "RunInstances", "ProductCodes": [ { "ProductCodeId": "be714bpjscoj5uvqz0of5mscl", "ProductCodeType": "marketplace" } ], "State": "available", "BlockDeviceMappings": [ { "DeviceName": "/dev/sda1", "Ebs": { "DeleteOnTermination": true, "SnapshotId": "snap-0fac659b1c378abcf", "VolumeSize": 4, "VolumeType": "gp3", "Encrypted": false } } ], "Description": "Official AlmaLinux OS 8.8 x86_64 image", "EnaSupport": true, "Hypervisor": "xen", "ImageOwnerAlias": "aws-marketplace", "Name": "AlmaLinux OS 8.8.20230804 x86_64-c076b20a-2305-4771-823f-944909847a05", "RootDeviceName": "/dev/sda1", "RootDeviceType": "ebs", "SriovNetSupport": "simple", "VirtualizationType": "hvm", "DeprecationTime": "2025-08-05T21:23:26.000Z" } ] } There is missing "BootMode". Can you please add it to make the alma UEFI ready? Set the BootMode to "uefi-preferred". https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launch-instance-boot-mode.html#UEFI-supported-types https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot-mode.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000990)
elkhan 2023-11-07 20:56 |
Hi mlitwora, We are testing 8.9-beta-1 and 9.3-beta-1 AMIs in the "uefi-preferred" boot mode. Which basically means an instance will be created and boot in UEFI if it's supported by the instance type. Would you like to help us with the testing? Here is the AMI IDs on the us-east-1 region. You can also copy them to another region if you want. AlmaLinux OS 8.9-beta-1.20231107 x86_64: ami-0ebb096e453d2fb20 AlmaLinux OS 9.3-beta-1.20231107 x86_64: ami-04036e2559f9d72d9 |
(0001016)
mlitwora 2024-02-26 08:04 |
Hi elkhan, sorry for late reply. We already noticed the added uefi option in AWS for the AlmaLinux images. Thanks for working on this issue! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
258 | [AlmaLinux-8] qemu-kvm | crash | sometimes | 2022-06-03 05:25 | 2024-03-05 20:15 |
Reporter: | jpbennett | Platform: | Amd Server | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | high | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | qemu-kvm process goes to 100%, VM becomes unresponsive, Triggered by Creating a new VM | ||||
Description: |
Multiple times on two separate servers, qemu-kvm processes have suddenly spiked to 100% usage, and the VMs represented by those processes have become unresponsive to the point of needing force-power-cycled. Multiple VMs enter this state at the exact same moment. In two cases, the VM has recovered after multiple minutes, and in both cases, the VM's system clock was set in the future. It seems that the longer the hang goes on, the further in the future, as one machine thought it was the year 2217. Dates were correct before the hangs. These servers were running CentOS 8 before converting to Alma, and didn't exhibit this bug on CentOS. The hanging VMs have also all been running Alma 8, though that's likely coincidence, as that's most of my VMs now. There hasn't been anything notable in the host machine's dmesg or logs that I have seen. |
||||
Tags: | almalinux8, QEMU-KVM | ||||
Steps To Reproduce: |
Run multiple Alma 8 VMs on a server. Migrate an additional VM to that server using a command like virsh migrate --live --persistent --undefinesource --copy-storage-all --verbose Gitlab qemu+ssh://10.10.3.2/system. During the migration process, there is a chance that multiple running VMs will hang in the manner described. Oddly, not every VM hangs, nor does it happen on every migration, but when it occurs, all the affected VMs hang simultaneously. Additionally, this has been reproduced when generating a new VM on a server. One of the other Alma VMs already running on that server entered this odd failure state. |
||||
Additional Information: | Both servers are SuperMicro builds, one a AMD Opteron(TM) Processor 6272, the other a AMD EPYC 7302P 16-Core Processor. I'm using the Opteron_G3 processor type to host, as this allows live migration. | ||||
Attached Files: |
log2.png (85,648 bytes) 2022-06-03 06:29 https://bugs.almalinux.org/file_download.php?file_id=142&type=bug log1.png (80,747 bytes) 2022-06-03 06:29 https://bugs.almalinux.org/file_download.php?file_id=143&type=bug |
||||
Notes | |
(0000585)
jpbennett 2022-06-03 05:40 |
Just reproduced this issue by *rebooting* a running VM, and a sistem VM jumped to 100% CPU and unresponsive. |
(0000586)
jpbennett 2022-06-03 06:29 |
Dmesg from a VM as it hit this bug. |
(0000757)
bgf 2022-12-09 07:37 |
I believe I am seeing the same effect issue. I'm using Rocky but reporting here just because the situation seems very similar to this issue and it could be rare. The environment is a little complex. Nested virtualization is being used on a Mac. The Outer host is a VirtualBox VM with Rocky 8 installed. The Outer VM hosts inner VMs using KVM. The inner VMs are running Rocky 8 as well. The first two inner VMs work. When starting the third of fourth, all cpus allocated to inner VMs go to 100% and the inner VMs become almost unresponsive. One inner VM has been seen to produce the following message into /var/log/messages: chronyd[7233]: Forward time jump detected! Stopping one of the inner VMs returns the system to a relatively normal state. |
(0000883)
mutts 2023-05-08 16:04 |
Are you both still seeing this issue? I'm encountering an issue which I believe is similar, although it may not necessarily be exactly the same. My issue is just an unexplained freeze of the VM. The qemu-kvm process at or near 100% of given CPU. But the VM itself (running top inside the VM) doesn't show a high load or a lot going on. Both nodes (and VMs) are running Almalinux 8. There's not really a rhyme or reason as to why or when this will happen. Nothing in any logs, that I can find, that indicate any problem. It's happened twice within a couple of weeks on one VM. Another VM has had this happen once in the past couple of weeks. A third AlmaLinux node with an AlmaLinux 8 VM has yet to experience this issue. The one that has had this happen twice is an older Intel E3-1270v2. The other one that's had this happen once is an Intel i9-11900K. The one that has yet to have this happen is an AMD Ryzen 9 3900X. When these freezes happen, my only recourse is to destroy the VM and start it back up. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
456 | [AlmaLinux-8] squid | major | random | 2024-02-22 15:47 | 2024-03-01 10:24 |
Reporter: | huckley | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | squid 4.15.7.module_el8.9.0+3708+6acaac63.5 coredumps some time after mirgrate from centos stream 8 | ||||
Description: |
hello, i try to migrate or cent os stream 8 to alma linux 8. I used https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh. Now the squid randomly coredumps. how to debug this? |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: |
Stack trace of thread 2609: #0 0x00007f0410892acf raise (libc.so.6) #1 0x00007f0410865ea5 abort (libc.so.6) 0000002 0x000055e143157a27 xassert.cold.41 (squid) 0000003 0x000055e1432beae0 _ZL21peerDigestHandleReplyPv13StoreIOBuffer (squid) 0000004 0x000055e1432fb310 _ZN12store_client14finishCallbackEv (squid) 0000005 0x000055e1433e7cc1 _ZN9AsyncCall4makeEv (squid) 0000006 0x000055e1433e9268 _ZN14AsyncCallQueue8fireNextEv (squid) 0000007 0x000055e1433e95bd _ZN14AsyncCallQueue4fireEv (squid) 0000008 0x000055e143238bda _ZN9EventLoop7runOnceEv (squid) 0000009 0x000055e143238cc8 _ZN9EventLoop3runEv (squid) 0000010 0x000055e1432a2b40 _Z9SquidMainiPPc (squid) 0000011 0x000055e143180645 main (squid) 0000012 0x00007f041087ed85 __libc_start_main (libc.so.6) #13 0x000055e14318c52e _start (squid) |
||||
Attached Files: | |||||
Notes | |
(0001013)
huckley 2024-02-23 09:47 |
I try to debug this with gdb, but gdb is missing debug symbols for glibc: # yum debuginfo-install glibc Could not find debuginfo package for the following installed packages: glibc-2.28-236.el8_9.12.x86_64 Could not find debugsource package for the following installed packages: glibc-2.28-236.el8_9.12.x86_64 |
(0001014)
huckley 2024-02-23 09:49 |
the backtrace without debug symbols from glibc is: #0 0x00007f0410892acf in raise () from /lib64/libc.so.6 #1 0x00007f0410865ea5 in abort () from /lib64/libc.so.6 0000002 0x000055e143157a27 in xassert (msg=msg@entry=0x55e1435edb50 "fetch->pd && receivedData.data", file=file@entry=0x55e1435ed257 "peer_digest.cc", line=line@entry=418) at debug.cc:618 0000003 0x000055e1432beae0 in peerDigestHandleReply (data=0x55e1497c6f18, receivedData=...) at peer_digest.cc:473 0000004 0x000055e1432fb310 in store_client::finishCallback (this=0x55e14a2d6518) at store_client.cc:138 0000005 0x000055e1433e7cc1 in AsyncCall::make (this=this@entry=0x55e1489629a0) at AsyncCall.cc:40 0000006 0x000055e1433e9268 in AsyncCallQueue::fireNext (this=<optimized out>) at AsyncCallQueue.cc:56 0000007 0x000055e1433e95bd in AsyncCallQueue::fire (this=0x55e147b7c6e0) at AsyncCallQueue.cc:42 0000008 0x000055e143238bda in EventLoop::dispatchCalls (this=0x7ffc4e998300) at EventLoop.cc:144 0000009 EventLoop::runOnce (this=this@entry=0x7ffc4e998300) at EventLoop.cc:121 0000010 0x000055e143238cc8 in EventLoop::run (this=this@entry=0x7ffc4e998300) at EventLoop.cc:83 0000011 0x000055e1432a2b40 in SquidMain (argc=<optimized out>, argv=<optimized out>) at main.cc:1709 0000012 0x000055e143180645 in SquidMainSafe (argv=0x7ffc4e998758, argc=6) at main.cc:1417 #13 main (argc=6, argv=0x7ffc4e998758) at main.cc:1405 |
(0001015)
huckley 2024-02-23 11:14 |
(gdb) bt full #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 set = {__val = {0, 7233379953697167872, 140735667119320, 7233379953697167872, 140735667119296, 140735667119272, 94697681392768, 140735667119296, 94697603046816, 140735667119272, 94697681392768, 94697596123791, 140735667119376, 0, 94697681392536, 94697681392536}} pid = <optimized out> tid = <optimized out> ret = <optimized out> #1 0x00007f29eb069ea5 in __GI_abort () at abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x562083b8ae10, sa_sigaction = 0x562083b8ae10}, sa_mask = {__val = {140735667119680, 94697648860672, 94697599771223, 418, 0, 94697596434368, 94697595705074, 94697648860800, 139818024317434, 94697625377360, 70, 70, 7233379953697167872, 94697615828072, 7233379953697167872, 94697599773520}}, sa_flags = -2085048816, sa_restorer = 0x562080cbab50} sigs = {__val = {32, 0 <repeats 15 times>}} 0000002 0x0000562080824a27 in xassert (msg=msg@entry=0x562080cbab50 "fetch->pd && receivedData.data", file=file@entry=0x562080cba257 "peer_digest.cc", line=line@entry=418) at debug.cc:618 __FUNCTION__ = <optimized out> 0000003 0x000056208098bae0 in peerDigestHandleReply (data=0x562081c0a468, receivedData=...) at peer_digest.cc:473 fetch = 0x562081c0a468 retsize = -1 prevstate = <optimized out> newsize = <optimized out> tmpLock = <optimized out> 0000004 0x00005620809c8310 in store_client::finishCallback (this=0x562085a8b6b8) at store_client.cc:138 __FUNCTION__ = "finishCallback" result = {flags = {error = <optimized out>}, length = 0, offset = <optimized out>, data = <optimized out>} temphandler = 0x56208098b7c0 <peerDigestHandleReply(void*, StoreIOBuffer)> cbdata = 0x562081c0a468 0000005 0x0000562080ab4cc1 in AsyncCall::make (this=this@entry=0x562083f1f7f0) at AsyncCall.cc:40 __FUNCTION__ = "make" 0000006 0x0000562080ab6268 in AsyncCallQueue::fireNext (this=<optimized out>) at AsyncCallQueue.cc:56 call = {p_ = 0x562083f1f7f0} __FUNCTION__ = "fireNext" 0000007 0x0000562080ab65bd in AsyncCallQueue::fire (this=0x562083b9b8d0) at AsyncCallQueue.cc:42 made = true 0000008 0x0000562080905bda in EventLoop::dispatchCalls (this=0x7fff93722ba0) at EventLoop.cc:144 dispatchedSome = <optimized out> dispatchedSome = <optimized out> 0000009 EventLoop::runOnce (this=this@entry=0x7fff93722ba0) at EventLoop.cc:121 sawActivity = <optimized out> waitingEngine = 0x7fff937229c8 __FUNCTION__ = <optimized out> 0000010 0x0000562080905cc8 in EventLoop::run (this=this@entry=0x7fff93722ba0) at EventLoop.cc:83 No locals. 0000011 0x000056208096fb40 in SquidMain (argc=<optimized out>, argv=<optimized out>) at main.cc:1709 cmdLine = {argv_ = std::vector of length 7, capacity 7 = {0x5620812038b0 "(squid-1)", 0x5620812038d0 "--kid", 0x5620812038f0 "squid-1", 0x562081203910 "--foreground", 0x562081203930 "-f", 0x562081203950 "/etc/squid/squid-zscaler.conf", 0x0}, shortOptions_ = 0x562081203840 "CDFNRSYXa:d:f:hk:m::n:sl:u:vz?", longOptions_ = std::vector of length 5, capacity 8 = {{<option> = { name = 0x562081203a40 "foreground", has_arg = 0, flag = 0x0, val = 2}, <No data fields>}, {<option> = {name = 0x562081203c40 "kid", has_arg = 1, flag = 0x0, val = 3}, <No data fields>}, {<option> = {name = 0x562081203c60 "help", has_arg = 0, flag = 0x0, val = 104}, <No data fields>}, {<option> = {name = 0x562081203c80 "version", has_arg = 0, flag = 0x0, val = 118}, <No data fields>}, {<option> = {name = 0x0, has_arg = 0, flag = 0x0, val = 0}, <No data fields>}}} WIN32_init_err = 0 __FUNCTION__ = "SquidMain" mainLoop = {errcount = 0, static Running = 0x7fff93722ba0, last_loop = false, engines = std::vector of length 4, capacity 4 = {0x7fff937229b8, 0x562081003880 <EventScheduler::_instance>, 0x7fff937229c0, 0x7fff937229c8}, timeService = 0x7fff937229d0, primaryEngine = 0x7fff937229c8, loop_delay = 0, error = false, runOnceResult = false} signalEngine = {<AsyncEngine> = {_vptr.AsyncEngine = 0x562080fd4fd0 <vtable for SignalEngine+16>}, <No data fields>} store_engine = {<AsyncEngine> = {_vptr.AsyncEngine = 0x562080fd4fa8 <vtable for StoreRootEngine+16>}, <No data fields>} comm_engine = {<AsyncEngine> = {_vptr.AsyncEngine = 0x562080fe4ec0 <vtable for CommSelectEngine+16>}, <No data fields>} time_engine = {_vptr.TimeEngine = 0x562080fd5d58 <vtable for TimeEngine+16>} 0000012 0x000056208084d645 in SquidMainSafe (argv=0x7fff93722ff8, argc=6) at main.cc:1417 __FUNCTION__ = <optimized out> _dbg_level = <optimized out> _dbo = <optimized out> #13 main (argc=6, argv=0x7fff93722ff8) at main.cc:1405 No locals. |
(0001019)
eabdullin 2024-03-01 10:24 |
Hello! glibc debug packages are in baseos https://repo.almalinux.org/vault/8.9/BaseOS/debug/x86_64/Packages/glibc-debuginfo-2.28-236.el8_9.12.x86_64.rpm https://repo.almalinux.org/vault/8.9/BaseOS/debug/x86_64/Packages/glibc-debugsource-2.28-236.el8_9.12.x86_64.rpm If yum still doesn't see these packages, please try to follow these steps: dnf config-manager --enable baseos-debuginfo dnf install glibc-debuginfo glibc-debugsource I also tried to reproduce it, but unsuccessfully, squid works fine without any errors |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
449 | [AlmaLinux-8] e2fsprogs | major | always | 2023-12-28 12:18 | 2024-03-01 07:34 |
Reporter: | brianjmurrell | Platform: | |||
Assigned To: | eabdullin | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Enable e2scrub build and packag | ||||
Description: |
e2fsprogs on AlmaLinux-8 disables the build and packaging of e2scrub in the e2fsprogs package. Almalinux-9 does not do this however an upgrade to AL9 is a huge undertaking at this point (particularly when IPA is part of the upgrade). It would be great if AL-8 would remove this e2scrub build disablement (https://git.almalinux.org/rpms/e2fsprogs/src/branch/c8/SOURCES/e2fsprogs-1.45.6-Makefile.in-Disable-e2scrub.patch) and add the necessary packaging in https://git.almalinux.org/rpms/e2fsprogs/src/branch/c8/SPECS/e2fsprogs.spec to have it create a package for it. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0001005)
brianjmurrell 2023-12-28 14:28 |
I have opened an PR to accomplish this: https://git.almalinux.org/rpms/e2fsprogs/pulls/1 |
(0001017)
eabdullin 2024-03-01 07:32 |
Hello! The package was released to the extras repo. Thank you for your PR! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
450 | [AlmaLinux-8] -OTHER | block | random | 2024-01-06 18:50 | 2024-01-06 18:50 |
Reporter: | trossoma | Platform: | x64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | urgent | OS Version: | 8.8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | SATA communication drop-outs cause ZFS I/O errors and can result in pool suspension | ||||
Description: |
Distribution: AlmaLinux 8.8 Kernel Version: 4.18.0-477.13.1 Architecture: x64 OpenZFS Version: 2.1.5-1 Intermittent communication dropouts are occurring with SSD drives that are attached to Marvell 88SE9235 SATA controllers via Marvell 88SM9705 port multipliers. The SSD drives are M.2 form factor and are typically models from WD or SanDisk. When the issue occurs, communication with all SSD drives (5) connected to port multiplier is lost and the driver performs recovery steps in order to re-establish connection with the SSD drives. This results in ZFS I/O errors being reported from zpool status. Multiple events with unsuccessful recovery steps by driver can lead to pool suspension. The issue occurs with both small and large I/O workloads, though usually takes longer to manifest with small I/O workload. The issue DOES NOT occur with older version of CentOS and ZFS running on same hardware. Details: Distribution: CentOS 7.9 Kernel Version: 3.10.0-1160.15.2 Architecture: x64 OpenZFS Version: 0.8.6-1 Typically, the ZFS pools in use on AlmaLinux were created in CentOS. Creating the pools in AlmaLinux did not resolve issue. Have tried the following, in different combinations: Disabling NCQ Lowering SATA speed to 3.0 Upgrading ZFS to 2.1.13 Upgrading to AlmaLinux 8.9 Changing SATA power management from max_performance -> medium_power Changing I/O scheduler from None -> mq-deadline Change max_sectors_kb -> 512 |
||||
Tags: | |||||
Steps To Reproduce: |
The issue can be reproduced as follows: Small I/O workload: Boot-up system w/ apps that generate small sustained I/O load on the ZFS pool and let it run w/o interaction Large I/O workload: Use fio to generate heavy I/O workload on ZFS pool |
||||
Additional Information: | |||||
Attached Files: |
syslog_snippet.txt (32,753 bytes) 2024-01-06 18:50 https://bugs.almalinux.org/file_download.php?file_id=229&type=bug zpool_status.txt (2,538 bytes) 2024-01-06 18:50 https://bugs.almalinux.org/file_download.php?file_id=230&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
447 | [AlmaLinux-8] -OTHER | block | unable to reproduce | 2023-12-18 23:10 | 2023-12-18 23:16 |
Reporter: | scapo93 | Platform: | WHM | ||
Assigned To: | OS: | CentOS7` | |||
Priority: | immediate | OS Version: | 7 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Upgrade from CentOS 7 to AlmaLinux 8 unable to access server | ||||
Description: |
I followed the steps to upgrade from CentOS 7 to AlmaLinux 8. After rebooting into step 4 the SSH connection was lost and after I was unable to reconnect to my host. Currently I am unable to reach the server on any port or ping. Everything was fine with no error message, the pre-check also found no blockers. |
||||
Tags: | almalinux8, ssh | ||||
Steps To Reproduce: | Unable to reproduce | ||||
Additional Information: | Currently trying to get help from hosting provider | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
445 | [AlmaLinux-8] qemu-kvm | crash | always | 2023-11-27 19:21 | 2023-12-04 02:51 |
Reporter: | mutts | Platform: | x86_64 | ||
Assigned To: | alukoshko | OS: | Almalinux | ||
Priority: | high | OS Version: | 8 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Fix max integer mmu_invalidate_seq hanging vCPUs | ||||
Description: |
I'm not sure what specific kernel Almalinux 8's kernel is based on, but the kernels starting with 4.18.0-425.3.1.el8.x86_64 and through the current kernel 4.18.0-513.5.1.el8_9.x86_64 are susceptible to this bug. In mainline kernel 6.1 this was addressed in commit 82d811ff566594de3676f35808e8a9e19c5c864c effectively changing mmu_seq from an int to an unsigned long: https://lore.kernel.org/lkml/2023082606-viper-accuracy-b0fd@gregkh/T/ Meanwhile this was fixed in mainline kernel 6.3 through a complete overhaul of the system in commit ba6e3fe25543: https://lore.kernel.org/lkml/2023082644-vaporizer-stuffy-b8bc@gregkh/T/ At any rate, the kernel for Almalinux 8 needs to be updated to resolve this issue in the is_page_fault_stale() function. Kernel 4.18.0-372.26.1.el8_6.x86_64 (and presumably 4.18.0-372.32.1.el8_6.x86_64) is not affected by this because it does not have the is_page_fault_stale() function. |
||||
Tags: | almalinux8, kernel, QEMU-KVM | ||||
Steps To Reproduce: |
Install Almalinux 8 using any kernel between 4.18.0-425.3.1.el8.x86_64 and 4.18.0-513.5.1.el8_9.x86_64 Spin up a KVM guest on that Almalinux node. Do stuff inside the KVM guest that makes it use a lot of memory over and over again. Eventually mmu_notifier_seq will hit max integer - 2,147,483,647 - at which point the KVM guest will freeze up and become unresponsive. |
||||
Additional Information: |
You can monitor the mmu_notifier_seq count from the host node by running the bpftrace script: --SNIP-- #if defined(CONFIG_FUNCTION_TRACER) #define CC_USING_FENTRY #endif #include <linux/kvm_host.h> kprobe:direct_page_fault { $ctr = ((struct kvm_vcpu*)arg0)->kvm->mmu_notifier_seq; @counts[pid] = $ctr; } interval:s:60 { $ts = nsecs + 300000; printf("%s\n", strftime("%m-%d-%y %H:%M:%S", $ts)); print(@counts); print("---\n"); } --SNIP-- Once this hits 2,147,483,647 (max integer) the guest will become unresponsive. Depending on just how much memory is used on the guest and how often the memory pages are cleared, this may take a while. Some guests that use very little memory may take months or years to hit the 2,147,483,647 max integer number. Running a program on the KVM guest that continuously consumes and dumps memory may allow you to more easily duplicate this issue. Looking at the kernel source packages, it would seem that Almalinux 9 was also susceptible to this up to kernel 5.14.0-284.11.1, but the latest Almalinux 9 kernel 5.14.0-362.8.1 appears to have been refactored based on the mainline kernel 6.3 which fixes this issue. |
||||
Attached Files: | |||||
Notes | |
(0001003)
alukoshko 2023-12-03 23:55 |
Kernel build with patch https://lore.kernel.org/lkml/2023082606-viper-accuracy-b0fd@gregkh/T/ included: https://build.almalinux.org/build/8033 |
(0001004)
alukoshko 2023-12-04 02:51 |
Released https://errata.almalinux.org/8/ALSA-2023-7549.html |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
427 | [AlmaLinux-8] -OTHER | crash | always | 2023-09-23 11:59 | 2023-11-27 21:25 |
Reporter: | neilrieck | Platform: | HP DL380p_gen8 | ||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 9.8 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | During the leapp migration from AlmaLinux-8.8 to 9.2 the installer crashes before the last automated reboot | ||||
Description: | During the leapp migration from AlmaLinux-8.8 to 9.2 the installer crashes before the last automated reboot. After a manual reboot the system appears to work properly (but I did see two Traceback messages from Python; see the attached log) | ||||
Tags: | almalinux8, elevate, leapp | ||||
Steps To Reproduce: | Just run ELevate-leapp | ||||
Additional Information: | Also tried this on a scratch system; installed CentOS-7.9 then migrated to AlamaLinux-8.8; then attempted | ||||
Attached Files: |
leapp-upgrade.zip (843,515 bytes) 2023-09-23 11:59 https://bugs.almalinux.org/file_download.php?file_id=221&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
433 | [AlmaLinux-8] -OTHER | minor | have not tried | 2023-10-13 19:30 | 2023-11-27 21:24 |
Reporter: | holzman2 | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Issues with Scientific Linux 7 to alma8 migration | ||||
Description: |
I'm testing SL7 -> alma8 migration (with the goal of then migrating to alma9). There are a number of issues: Pre-upgrade: The sl-logos package conflicts with almalinux-logos; I had to rpm -e to continue. Post-upgrade: almalinux-release is not installed. (I hacked around it by removing sl-release, manually setting /etc/os-release and /etc/redhat-release to look like Centos 8, running almalinux-deploy.sh, and mv'ing /etc/os-release.rpmnew to /etc/os-release). A number of EL7 packages are still present, some of which will interfere with migration to alma9: btrfs-progs-4.9.1-1.el7.x86_64 elevate-release-1.0-2.el7.noarch kernel-3.10.0-1160.102.1.el7.x86_64 leapp-0.14.0-1.el7.noarch leapp-data-almalinux-0.1-6.el7.noarch leapp-upgrade-el7toel8-0.16.0-6.el7.elevate.17.noarch python2-leapp-0.14.0-1.el7.noarch sl7-upgrade-0.1.1-2.el7.noarch yum-conf-extras-1.0-1.el7.noarch yum-conf-repos-1.0-1.el7.noarch yum-plugin-upgrade-helper-1.1.31-54.el7_8.noarch sl-indexhtml yum-conf-sl7x sl-release-notes sl-indexhtml would not uninstall cleanly, but can be removed with --nodeps and replaced with the almalinux-indexhtml package. The /etc/yum.conf file still has: exclude=python2-leapp,snactor,leapp-upgrade-el7toel8,leapp |
||||
Tags: | alma8, elevate, leapp | ||||
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: |
444 | [AlmaLinux-8] rsyslog | minor | always | 2023-11-23 11:45 | 2023-11-23 11:45 |
Reporter: | OscarCS | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | syslog not logging when computer stops | ||||
Description: |
When a reboot is issued nothing reporting this reboot is logged in /var/log/messages A newly installed computer with rsyslog.service enabled includes the following line in "/usr/lib/systemd/system/rsyslog.service": LimitNOFILE=16384 if it is commented, then all information is logged (see additional information) |
||||
Tags: | |||||
Steps To Reproduce: |
as root exec a reboot look at /var/log/messages no report about daemons stoping comment "LimitNOFILE=16384" line in /usr/lib/systemd/system/rsyslog.service and execute: systemctl daemon-reload reboot look at /var/log/messages Now, logs about daemons shutting down are there. |
||||
Additional Information: |
#reboot issued at 23:59: # /var/log/messages after it: (between 23:55 and the starting moment, the log date says 2:00 but it is actually 00:00) Nov 22 23:55:41 dest NetworkManager[1499]: <info> [1700693741.4818] device (eno1np0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Nov 22 23:55:41 dest NetworkManager[1499]: <info> [1700693741.4887] device (eno1np0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') Nov 22 23:55:41 dest NetworkManager[1499]: <info> [1700693741.4889] dhcp4 (eno1np0): activation: beginning transaction (timeout in 45 seconds) Nov 22 23:56:26 dest NetworkManager[1499]: <info> [1700693786.4710] device (eno1np0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed') Nov 22 23:56:26 dest NetworkManager[1499]: <warn> [1700693786.4714] device (eno1np0): Activation: failed for connection 'eno1np0' Nov 22 23:56:26 dest NetworkManager[1499]: <info> [1700693786.4716] device (eno1np0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') Nov 22 23:56:26 dest NetworkManager[1499]: <info> [1700693786.4806] dhcp4 (eno1np0): canceled DHCP transaction Nov 22 23:56:26 dest NetworkManager[1499]: <info> [1700693786.4806] dhcp4 (eno1np0): activation: beginning transaction (timeout in 45 seconds) Nov 22 23:56:26 dest NetworkManager[1499]: <info> [1700693786.4807] dhcp4 (eno1np0): state changed no lease Nov 23 02:00:57 dest kernel: Command line: BOOT_IMAGE=(hd1,gpt3)/boot/vmlinuz-4.18.0-513.5.1.el8_9.x86_64 root=UUID=fa8415c5-ee11-4b66-8c4c-ba6d05868556 ro crashkernel=auto resume=UUID=67244018-cf15-44cb-90e5-6a82bede853b rhgb quiet Nov 23 02:00:57 dest kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Nov 23 02:00:57 dest kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Nov 23 02:00:57 dest kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Nov 23 02:00:57 dest kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Nov 23 02:00:57 dest kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. Nov 23 02:00:57 dest kernel: signal: max sigframe size: 1776 Nov 23 02:00:57 dest kernel: BIOS-provided physical RAM map: Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000073ffffff] usable Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000000074000000-0x0000000074021fff] ACPI NVS Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000000074022000-0x0000000075daffff] usable Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000000075db0000-0x0000000075ffffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000000076000000-0x00000000a532bfff] usable Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000a532c000-0x00000000a71d0fff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000a71d1000-0x00000000a72bbfff] ACPI data Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000a72bc000-0x00000000a773cfff] ACPI NVS Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000a773d000-0x00000000a89a7fff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000a89a8000-0x00000000abffffff] usable Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000ac000000-0x00000000afffffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000b4000000-0x00000000b5ffffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000f4000000-0x00000000f5ffffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000ffffffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000000100000000-0x000000204f1fffff] usable Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x000000204f200000-0x000000204fffffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000010000000000-0x00000100201fffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000020030000000-0x00000200403fffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000020060000000-0x00000200801fffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x0000038090000000-0x00000380a03fffff] reserved Nov 23 02:00:57 dest kernel: BIOS-e820: [mem 0x000007fc00000000-0x000007fc03ffffff] reserved #after comment "LimitNOFILE=16384" line in /usr/lib/systemd/system/rsyslog.service and execute: systemctl daemon-reload #reboot issued at 11:16 # /var/log/messages from 11:16 til next boot: Nov 23 11:16:44 dest systemd[1]: Stopped target rpc_pipefs.target. Nov 23 11:16:44 dest systemd[1]: Stopped target RPC Port Mapper. Nov 23 11:16:44 dest systemd[1]: Stopped target Timers. Nov 23 11:16:44 dest systemd[1]: unbound-anchor.timer: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped daily update of the root trust anchor for DNSSEC. Nov 23 11:16:44 dest systemd[1]: Stopping Session 3 of user root. Nov 23 11:16:44 dest systemd[1]: sysstat-summary.timer: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Generate summary of yesterday's process accounting. Nov 23 11:16:44 dest systemd[1]: lvm2-lvmpolld.socket: Succeeded. Nov 23 11:16:44 dest systemd[1]: Closed LVM2 poll daemon socket. Nov 23 11:16:44 dest systemd[1]: sysstat-collect.timer: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Run system activity accounting tool every 10 minutes. Nov 23 11:16:44 dest systemd[1]: Removed slice system-systemd\x2dhibernate\x2dresume.slice. Nov 23 11:16:44 dest systemd[1]: Removed slice system-sshd\x2dkeygen.slice. Nov 23 11:16:44 dest systemd[1]: Stopped target Multi-User System. Nov 23 11:16:44 dest systemd[1]: Stopped target Login Prompts. Nov 23 11:16:44 dest systemd[1]: Stopping Getty on tty1... Nov 23 11:16:44 dest systemd[1]: Stopping Self Monitoring and Reporting Technology (SMART) Daemon... Nov 23 11:16:44 dest smartd[1429]: smartd received signal 15: Terminated Nov 23 11:16:44 dest smartd[1429]: smartd is exiting (exit status 0) Nov 23 11:16:44 dest systemd[1]: Stopping VDO volume services... Nov 23 11:16:44 dest systemd[1]: Stopping Docker Application Container Engine... Nov 23 11:16:44 dest systemd[1]: sysstat.service: Succeeded. Nov 23 11:16:44 dest dockerd[2009]: time="2023-11-23T11:16:44.862941135+01:00" level=info msg="Processing signal 'terminated'" Nov 23 11:16:44 dest systemd[1]: Stopped Resets System Activity Logs. Nov 23 11:16:44 dest systemd[1]: Stopping Console Mouse manager... Nov 23 11:16:44 dest systemd[1]: Stopping CUPS Scheduler... Nov 23 11:16:44 dest systemd[1]: Stopping OpenSSH server daemon... Nov 23 11:16:44 dest systemd[1]: Stopping Dynamic System Tuning Daemon... Nov 23 11:16:44 dest avahi-daemon[1439]: Got SIGTERM, quitting. Nov 23 11:16:44 dest systemd[1]: Stopping Avahi mDNS/DNS-SD Stack... Nov 23 11:16:44 dest avahi-daemon[1439]: Leaving mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Nov 23 11:16:44 dest systemd[1]: Stopping Command Scheduler... Nov 23 11:16:44 dest avahi-daemon[1439]: Leaving mDNS multicast group on interface eno2np1.IPv6 with address fe80::3eec:efff:fe74:2281. Nov 23 11:16:44 dest systemd[1]: plymouth-quit.service: Succeeded. Nov 23 11:16:44 dest avahi-daemon[1439]: Leaving mDNS multicast group on interface eno2np1.IPv4 with address 158.109.39.58. Nov 23 11:16:44 dest dockerd[2009]: time="2023-11-23T11:16:44.863932768+01:00" level=info msg="stopping event stream following graceful shutdown" error="<nil>" module=libcontainerd namespace=moby Nov 23 11:16:44 dest systemd[1]: Stopped Terminate Plymouth Boot Screen. Nov 23 11:16:44 dest dockerd[2009]: time="2023-11-23T11:16:44.864132795+01:00" level=info msg="Daemon shutdown complete" Nov 23 11:16:44 dest systemd[1]: Stopping privileged operations for unprivileged applications... Nov 23 11:16:44 dest systemd[1]: systemd-tmpfiles-clean.timer: Succeeded. Nov 23 11:16:44 dest dockerd[2009]: time="2023-11-23T11:16:44.864206393+01:00" level=info msg="stopping event stream following graceful shutdown" error="context canceled" module=libcontainerd namespace=plugins.moby Nov 23 11:16:44 dest systemd[1]: Stopped Daily Cleanup of Temporary Directories. Nov 23 11:16:44 dest systemd[1]: Stopping NTP client/server... Nov 23 11:16:44 dest systemd[1]: Stopping libstoragemgmt plug-in server daemon... Nov 23 11:16:44 dest chronyd[1463]: chronyd exiting Nov 23 11:16:44 dest systemd[1]: Unmounting RPC Pipe File System... Nov 23 11:16:44 dest systemd[1]: mlocate-updatedb.timer: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Updates mlocate database every day. Nov 23 11:16:44 dest systemd[1]: Stopping Sending Alert Emails on System shutdown.... Nov 23 11:16:44 dest systemd[1]: Stopping Hardware Monitoring Sensors... Nov 23 11:16:44 dest systemd[1]: Stopping Job spooling tools... Nov 23 11:16:44 dest systemd[1]: dnf-makecache.timer: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped dnf makecache --timer. Nov 23 11:16:44 dest systemd[1]: Stopping Automounts filesystems on demand... Nov 23 11:16:44 dest systemd[1]: Stopping Restore /run/initramfs on shutdown... Nov 23 11:16:44 dest systemd[1]: Stopping irqbalance daemon... Nov 23 11:16:44 dest lm_sensors-modprobe-r-wrapper[8047]: No sensors with loadable kernel modules configured. Nov 23 11:16:44 dest lm_sensors-modprobe-r-wrapper[8047]: Please, run 'sensors-detect' as root in order to search for available sensors. Nov 23 11:16:44 dest avahi-daemon[1439]: avahi-daemon 0.7 exiting. Nov 23 11:16:44 dest systemd[1]: smartd.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Self Monitoring and Reporting Technology (SMART) Daemon. Nov 23 11:16:44 dest systemd[1]: libstoragemgmt.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped libstoragemgmt plug-in server daemon. Nov 23 11:16:44 dest systemd[1]: avahi-daemon.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Avahi mDNS/DNS-SD Stack. Nov 23 11:16:44 dest systemd[1]: oddjobd.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped privileged operations for unprivileged applications. Nov 23 11:16:44 dest systemd[1]: cups.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped CUPS Scheduler. Nov 23 11:16:44 dest systemd[1]: sshd.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped OpenSSH server daemon. Nov 23 11:16:44 dest systemd[1]: docker.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Docker Application Container Engine. Nov 23 11:16:44 dest systemd[1]: crond.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Command Scheduler. Nov 23 11:16:44 dest systemd[1]: atd.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Job spooling tools. Nov 23 11:16:44 dest systemd[1]: getty@tty1.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Getty on tty1. Nov 23 11:16:44 dest systemd[1]: irqbalance.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped irqbalance daemon. Nov 23 11:16:44 dest systemd[1]: gpm.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Console Mouse manager. Nov 23 11:16:44 dest systemd[1]: var-lib-nfs-rpc_pipefs.mount: Succeeded. Nov 23 11:16:44 dest systemd[1]: Unmounted RPC Pipe File System. Nov 23 11:16:44 dest systemd[1]: lm_sensors.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Hardware Monitoring Sensors. Nov 23 11:16:44 dest systemd[1]: dracut-shutdown.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Restore /run/initramfs on shutdown. Nov 23 11:16:44 dest systemd[1]: session-3.scope: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Session 3 of user root. Nov 23 11:16:44 dest systemd-logind[1448]: Session 3 logged out. Waiting for processes to exit. Nov 23 11:16:44 dest systemd[1]: Stopping User Manager for UID 0... Nov 23 11:16:44 dest systemd[1]: Stopping Login Service... Nov 23 11:16:44 dest systemd[7896]: Stopped target Default. Nov 23 11:16:44 dest systemd[7896]: Stopped target Basic System. Nov 23 11:16:44 dest systemd[7896]: Stopped target Timers. Nov 23 11:16:44 dest systemd[7896]: Stopped target Sockets. Nov 23 11:16:44 dest systemd[7896]: Closed D-Bus User Message Bus Socket. Nov 23 11:16:44 dest systemd[7896]: Stopped target Paths. Nov 23 11:16:44 dest systemd[7896]: Reached target Shutdown. Nov 23 11:16:44 dest systemd[7896]: Started Exit the Session. Nov 23 11:16:44 dest systemd[7896]: Reached target Exit the Session. Nov 23 11:16:44 dest systemd[1]: Starting Show Plymouth Reboot Screen... Nov 23 11:16:44 dest systemd[1]: plymouth-quit-wait.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Hold until boot process finishes up. Nov 23 11:16:44 dest systemd[1]: Removed slice system-getty.slice. Nov 23 11:16:44 dest systemd[1]: Stopping containerd container runtime... Nov 23 11:16:44 dest systemd[1]: Stopped target sshd-keygen.target. Nov 23 11:16:44 dest systemd[1]: Received SIGRTMIN+20 from PID 8070 (plymouthd). Nov 23 11:16:44 dest systemd[1]: containerd.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped containerd container runtime. Nov 23 11:16:44 dest systemd[1]: user@0.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped User Manager for UID 0. Nov 23 11:16:44 dest systemd[1]: Stopping User runtime directory /run/user/0... Nov 23 11:16:44 dest systemd[1]: run-user-0.mount: Succeeded. Nov 23 11:16:44 dest systemd[1]: Unmounted /run/user/0. Nov 23 11:16:44 dest systemd[1]: Started Show Plymouth Reboot Screen. Nov 23 11:16:44 dest systemd[1]: user-runtime-dir@0.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped User runtime directory /run/user/0. Nov 23 11:16:44 dest systemd[1]: Removed slice User Slice of UID 0. Nov 23 11:16:44 dest systemd[1]: Stopping Permit User Sessions... Nov 23 11:16:44 dest systemd[1]: systemd-user-sessions.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Permit User Sessions. Nov 23 11:16:44 dest systemd[1]: systemd-logind.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped Login Service. Nov 23 11:16:44 dest systemd[1]: Stopped target User and Group Name Lookups. Nov 23 11:16:44 dest systemd[1]: chronyd.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped NTP client/server. Nov 23 11:16:44 dest systemd[1]: vdo.service: Succeeded. Nov 23 11:16:44 dest systemd[1]: Stopped VDO volume services. Nov 23 11:16:45 dest systemd[1]: tuned.service: Succeeded. Nov 23 11:16:45 dest systemd[1]: Stopped Dynamic System Tuning Daemon. Nov 23 11:16:45 dest systemd[1]: autofs.service: Succeeded. Nov 23 11:16:45 dest systemd[1]: Stopped Automounts filesystems on demand. Nov 23 11:16:45 dest systemd[1]: Stopping NFS status monitor for NFSv2/3 locking.... Nov 23 11:16:45 dest systemd[1]: Stopped target Remote File Systems. Nov 23 11:16:45 dest systemd[1]: Stopped target Remote File Systems (Pre). Nov 23 11:16:45 dest systemd[1]: Stopped target NFS client services. Nov 23 11:16:45 dest systemd[1]: Stopping GSSAPI Proxy Daemon... Nov 23 11:16:45 dest systemd[1]: Stopping Logout off all iSCSI sessions on shutdown... Nov 23 11:16:45 dest systemd[1]: rpc-statd.service: Succeeded. Nov 23 11:16:45 dest systemd[1]: Stopped NFS status monitor for NFSv2/3 locking.. Nov 23 11:16:45 dest systemd[1]: Stopped target Host and Network Name Lookups. Nov 23 11:16:45 dest systemd[1]: gssproxy.service: Succeeded. Nov 23 11:16:45 dest systemd[1]: Stopped GSSAPI Proxy Daemon. Nov 23 11:16:45 dest iscsiadm[8092]: iscsiadm: No matching sessions found Nov 23 11:16:45 dest systemd[1]: iscsi-shutdown.service: Succeeded. Nov 23 11:16:45 dest systemd[1]: Stopped Logout off all iSCSI sessions on shutdown. Nov 23 11:16:49 dest BootMail.sh[8046]: starting reboot Nov 23 11:16:49 dest BootMail.sh[8046]: starting shutdown Nov 23 11:16:49 dest root[8122]: OCS: SCRIPT_REBOOTING_SHUTINGDOWN dest Nov 23 11:16:49 dest BootMail.sh[8046]: Thu Nov 23 11:16:49 CET 2023 Nov 23 11:16:49 dest BootMail.sh[8046]: shuting down dest Nov 23 11:16:49 dest BootMail.sh[8046]: dest.uab.cat dest Nov 23 11:16:49 dest BootMail.sh[8046]: SCRIPT_REBOOTING_SHUTINGDOWN Nov 23 11:16:49 dest BootMail.sh[8046]: Thu Nov 23 11:16:49 CET 2023 Nov 23 11:17:09 dest systemd[1]: ShutDownMail.service: Succeeded. Nov 23 11:17:09 dest systemd[1]: Stopped Sending Alert Emails on System shutdown.. Nov 23 11:17:09 dest systemd[1]: Stopping System Logging Service... Nov 23 11:17:09 dest systemd[1]: Stopping Postfix Mail Transport Agent... Nov 23 11:17:10 dest systemd[1]: postfix.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Postfix Mail Transport Agent. Nov 23 11:17:10 dest rsyslogd[2002]: [origin software="rsyslogd" swVersion="8.2102.0-15.el8" x-pid="2002" x-info="https://www.rsyslog.com"] exiting on signal 15. Nov 23 11:17:10 dest systemd[1]: rsyslog.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped System Logging Service. Nov 23 11:17:10 dest systemd[1]: Stopped target Network is Online. Nov 23 11:17:10 dest systemd[1]: Stopped target Network. Nov 23 11:17:10 dest systemd[1]: Stopping Network Manager... Nov 23 11:17:10 dest NetworkManager[1485]: <info> [1700734630.3095] caught SIGTERM, shutting down normally. Nov 23 11:17:10 dest NetworkManager[1485]: <info> [1700734630.3105] dhcp4 (eno2np1): canceled DHCP transaction Nov 23 11:17:10 dest NetworkManager[1485]: <info> [1700734630.3106] dhcp4 (eno2np1): activation: beginning transaction (timeout in 90 seconds) Nov 23 11:17:10 dest NetworkManager[1485]: <info> [1700734630.3106] dhcp4 (eno2np1): state changed no lease Nov 23 11:17:10 dest NetworkManager[1485]: <info> [1700734630.3108] manager: NetworkManager state is now CONNECTED_SITE Nov 23 11:17:10 dest dbus-daemon[1428]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.6' (uid=0 pid=1485 comm="/usr/sbin/NetworkManager --no-daemon ") Nov 23 11:17:10 dest dbus-daemon[1428]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Refusing activation, D-Bus is shutting down. Nov 23 11:17:10 dest NetworkManager[1485]: <info> [1700734630.3117] exiting (success) Nov 23 11:17:10 dest systemd[1]: NetworkManager.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Network Manager. Nov 23 11:17:10 dest systemd[1]: Stopped target Network (Pre). Nov 23 11:17:10 dest systemd[1]: Stopping firewalld - dynamic firewall daemon... Nov 23 11:17:10 dest systemd[1]: firewalld.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped firewalld - dynamic firewall daemon. Nov 23 11:17:10 dest systemd[1]: Stopping Authorization Manager... Nov 23 11:17:10 dest systemd[1]: Stopping D-Bus System Message Bus... Nov 23 11:17:10 dest systemd[1]: dbus.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped D-Bus System Message Bus. Nov 23 11:17:10 dest systemd[1]: polkit.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Authorization Manager. Nov 23 11:17:10 dest systemd[1]: Stopped target Basic System. Nov 23 11:17:10 dest systemd[1]: Stopped target Sockets. Nov 23 11:17:10 dest systemd[1]: sssd-kcm.socket: Succeeded. Nov 23 11:17:10 dest systemd[1]: Closed SSSD Kerberos Cache Manager responder socket. Nov 23 11:17:10 dest systemd[1]: pcscd.socket: Succeeded. Nov 23 11:17:10 dest systemd[1]: Closed PC/SC Smart Card Daemon Activation Socket. Nov 23 11:17:10 dest systemd[1]: dbus.socket: Succeeded. Nov 23 11:17:10 dest systemd[1]: Closed D-Bus System Message Bus Socket. Nov 23 11:17:10 dest systemd[1]: cups.socket: Succeeded. Nov 23 11:17:10 dest systemd[1]: Closed CUPS Scheduler. Nov 23 11:17:10 dest systemd[1]: avahi-daemon.socket: Succeeded. Nov 23 11:17:10 dest systemd[1]: Closed Avahi mDNS/DNS-SD Stack Activation Socket. Nov 23 11:17:10 dest systemd[1]: iscsiuio.socket: Succeeded. Nov 23 11:17:10 dest systemd[1]: Closed Open-iSCSI iscsiuio Socket. Nov 23 11:17:10 dest systemd[1]: docker.socket: Succeeded. Nov 23 11:17:10 dest systemd[1]: Closed Docker Socket for the API. Nov 23 11:17:10 dest systemd[1]: iscsid.socket: Succeeded. Nov 23 11:17:10 dest systemd[1]: Closed Open-iSCSI iscsid Socket. Nov 23 11:17:10 dest systemd[1]: Stopped target Slices. Nov 23 11:17:10 dest systemd[1]: Removed slice User and Session Slice. Nov 23 11:17:10 dest systemd[1]: systemd-ask-password-plymouth.path: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Forward Password Requests to Plymouth Directory Watch. Nov 23 11:17:10 dest systemd[1]: Stopped target Paths. Nov 23 11:17:10 dest systemd[1]: cups.path: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped CUPS Scheduler. Nov 23 11:17:10 dest systemd[1]: Stopped target System Initialization. Nov 23 11:17:10 dest systemd[1]: Stopping Load/Save Random Seed... Nov 23 11:17:10 dest systemd[1]: systemd-sysctl.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Apply Kernel Variables. Nov 23 11:17:10 dest systemd[1]: nis-domainname.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Read and set NIS domainname from /etc/sysconfig/network. Nov 23 11:17:10 dest systemd[1]: Stopped target Swap. Nov 23 11:17:10 dest systemd[1]: Deactivating swap /dev/disk/by-id/nvme-INTEL_SSDPELKX010T8_PHLJ017200TG1P0I-part2... Nov 23 11:17:10 dest systemd[1]: Stopped target Local Encrypted Volumes. Nov 23 11:17:10 dest systemd[1]: systemd-ask-password-wall.path: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Forward Password Requests to Wall Directory Watch. Nov 23 11:17:10 dest systemd[1]: systemd-modules-load.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Load Kernel Modules. Nov 23 11:17:10 dest systemd[1]: Stopping Update UTMP about System Boot/Shutdown... Nov 23 11:17:10 dest systemd[1]: systemd-random-seed.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Load/Save Random Seed. Nov 23 11:17:10 dest systemd[1]: systemd-update-utmp.service: Succeeded. Nov 23 11:17:10 dest systemd[1]: Stopped Update UTMP about System Boot/Shutdown. Nov 23 11:17:10 dest systemd[1]: Stopping Security Auditing Service... Nov 23 11:17:11 dest systemd[1]: dev-disk-by\x2dpath-pci\x2d0000:c1:00.0\x2dnvme\x2d1\x2dpart2.swap: Succeeded. Nov 23 11:17:11 dest systemd[1]: Deactivated swap /dev/disk/by-path/pci-0000:c1:00.0-nvme-1-part2. Nov 23 11:17:11 dest systemd[1]: dev-disk-by\x2dpartuuid-57ea09c2\x2d2c1c\x2d47d7\x2d918d\x2d7851e15d82c2.swap: Succeeded. Nov 23 11:17:11 dest systemd[1]: Deactivated swap /dev/disk/by-partuuid/57ea09c2-2c1c-47d7-918d-7851e15d82c2. Nov 23 11:17:11 dest systemd[1]: dev-disk-by\x2did-wwn\x2deui.01000000010000005cd2e44f8d455251\x2dpart2.swap: Succeeded. Nov 23 11:17:11 dest systemd[1]: Deactivated swap /dev/disk/by-id/wwn-eui.01000000010000005cd2e44f8d455251-part2. Nov 23 11:17:11 dest systemd[1]: dev-disk-by\x2did-nvme\x2deui.01000000010000005cd2e44f8d455251\x2dpart2.swap: Succeeded. Nov 23 11:17:11 dest systemd[1]: Deactivated swap /dev/disk/by-id/nvme-eui.01000000010000005cd2e44f8d455251-part2. Nov 23 11:17:11 dest systemd[1]: dev-disk-by\x2did-nvme\x2dINTEL_SSDPELKX010T8_PHLJ017200TG1P0I\x2dpart2.swap: Succeeded. Nov 23 11:17:11 dest systemd[1]: Deactivated swap /dev/disk/by-id/nvme-INTEL_SSDPELKX010T8_PHLJ017200TG1P0I-part2. Nov 23 11:17:11 dest systemd[1]: dev-nvme0n1p2.swap: Succeeded. Nov 23 11:17:11 dest systemd[1]: Deactivated swap /dev/nvme0n1p2. Nov 23 11:17:11 dest systemd[1]: dev-disk-by\x2duuid-67244018\x2dcf15\x2d44cb\x2d90e5\x2d6a82bede853b.swap: Succeeded. Nov 23 11:17:11 dest systemd[1]: Deactivated swap /dev/disk/by-uuid/67244018-cf15-44cb-90e5-6a82bede853b. Nov 23 11:17:11 dest auditd[1402]: The audit daemon is exiting. Nov 23 11:17:11 dest kernel: audit: type=1305 audit(1700734631.017:1122): op=set audit_pid=0 old=1402 auid=4294967295 ses=4294967295 res=1 Nov 23 11:17:11 dest systemd[1]: auditd.service: Succeeded. Nov 23 11:17:11 dest systemd[1]: Stopped Security Auditing Service. Nov 23 11:17:11 dest systemd[1]: systemd-tmpfiles-setup.service: Succeeded. Nov 23 11:17:11 dest kernel: audit: type=1130 audit(1700734631.023:1123): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=auditd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 23 11:17:11 dest kernel: audit: type=1131 audit(1700734631.023:1124): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=auditd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 23 11:17:11 dest systemd[1]: Stopped Create Volatile Files and Directories. Nov 23 11:17:11 dest systemd[1]: import-state.service: Succeeded. Nov 23 11:17:11 dest systemd[1]: Stopped Import network configuration from initramfs. Nov 23 11:17:11 dest kernel: audit: type=1130 audit(1700734631.024:1125): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 23 11:17:11 dest kernel: audit: type=1131 audit(1700734631.024:1126): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 23 11:17:11 dest kernel: audit: type=1130 audit(1700734631.024:1127): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=import-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 23 11:17:11 dest kernel: audit: type=1131 audit(1700734631.024:1128): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=import-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 23 11:17:11 dest systemd[1]: Stopping Flush Journal to Persistent Storage... Nov 23 11:17:11 dest systemd[1]: Stopped target Local File Systems. Nov 23 11:17:11 dest systemd[1]: Unmounting /mnt/DATA01... Nov 23 11:17:11 dest systemd[1]: Unmounting /home... Nov 23 11:17:11 dest systemd[1]: Unmounting /boot/efi... Nov 23 12:18:59 dest kernel: Linux version 4.18.0-513.5.1.el8_9.x86_64 (mockbuild@x64-builder02.almalinux.org) (gcc version 8.5.0 20210514 (Red Hat 8.5.0-20) (GCC)) #1 SMP Mon Nov 20 08:56:15 EST 2023 Nov 23 12:18:59 dest kernel: Command line: BOOT_IMAGE=(hd1,gpt3)/boot/vmlinuz-4.18.0-513.5.1.el8_9.x86_64 root=UUID=fa8415c5-ee11-4b66-8c4c-ba6d05868556 ro crashkernel=auto resume=UUID=67244018-cf15-44cb-90e5-6a82bede853b rhgb quiet Nov 23 12:18:59 dest kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Nov 23 12:18:59 dest kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Nov 23 12:18:59 dest kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Nov 23 12:18:59 dest kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Nov 23 12:18:59 dest kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. Nov 23 12:18:59 dest kernel: signal: max sigframe size: 1776 Nov 23 12:18:59 dest kernel: BIOS-provided physical RAM map: Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000073ffffff] usable Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000000074000000-0x0000000074021fff] ACPI NVS Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000000074022000-0x0000000075daffff] usable Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000000075db0000-0x0000000075ffffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000000076000000-0x00000000a532bfff] usable Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000a532c000-0x00000000a71d0fff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000a71d1000-0x00000000a72bbfff] ACPI data Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000a72bc000-0x00000000a773cfff] ACPI NVS Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000a773d000-0x00000000a89a7fff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000a89a8000-0x00000000abffffff] usable Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000ac000000-0x00000000afffffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000b4000000-0x00000000b5ffffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000f4000000-0x00000000f5ffffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000ffffffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000000100000000-0x000000204f1fffff] usable Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x000000204f200000-0x000000204fffffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000010000000000-0x00000100201fffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000020030000000-0x00000200403fffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000020060000000-0x00000200801fffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x0000038090000000-0x00000380a03fffff] reserved Nov 23 12:18:59 dest kernel: BIOS-e820: [mem 0x000007fc00000000-0x000007fc03ffffff] reserved |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
443 | [AlmaLinux-8] ruby | minor | always | 2023-11-16 07:03 | 2023-11-16 07:03 |
Reporter: | emacalinao | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | `gem install --install-dir` and `--bindir` behavior differs from documentation | ||||
Description: |
Method operating_system_defaults at https://git.almalinux.org/rpms/ruby/src/branch/c8-stream-2.5/SOURCES/operating_system.rb#L98-L110 forces binary files to be written to bin/ in the user's home directory when `gem install` is executed as a non-root user, ignoring the GEM_HOME environment setting. From https://guides.rubygems.org/command-reference/#gem-environment: "RubyGems’ default local repository can be overridden with the GEM_PATH and GEM_HOME environment variables. GEM_HOME sets the default repository to install into. " The expected behavior is for binstubs to be installed in $GEM_HOME/bin by default, which differs from the AlmaLinux 8 implementation. Referring to line https://git.almalinux.org/rpms/ruby/src/branch/c8-stream-2.5/SOURCES/operating_system.rb#L103 : If the user specifies `--no-user-install`, having the operating_system_defaults method inject `--bindir #{File.join [Dir.home, 'bin']}` to put binstubs in the user's home directory (as it does now) doesn't make sense. If the user specifies `--install-dir`, `gem install` will fail with output "ERROR: Use --install-dir or --user-install but not both" because operating_system_defaults adds `--user-install`. This renders the `--install-dir` option unusable on its own. Both issues can be worked around by passing in additional arguments (see Steps to Reproduce section), but the solutions are unintuitive. Suggestion: how about not adding both `--user-install` and `--bindir...` if the user specifies either `--no-user-install` or `--install-dir`? |
||||
Tags: | |||||
Steps To Reproduce: |
As a user other than root: > mkdir gem_home > export GEM_HOME=$PWD/gem_home > gem install bundler -v 1.17.3 > ls ~/bin/bundler # confirm that the bundler executable was written to ~/bin > ls $GEM_HOME/bin # fails, directory doesn't exist Work-around: > gem install bundler -v 1.17.3 --bindir $GEM_HOME/bin Also, > gem install bundler --install-dir $GEM_HOME ERROR: Use --install-dir or --user-install but not both Work-around: > gem install bundler --install-dir $GEM_HOME --no-user-install |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
439 | [AlmaLinux-8] gnome-control-center | minor | always | 2023-11-10 01:31 | 2023-11-10 01:46 |
Reporter: | kclem | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux 9.3 Beta | |||
Priority: | normal | OS Version: | AlmaLinux 9 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Wi-Fi show password checkbox in gnome settings does not reveal the Wi-Fi password. | ||||
Description: |
Gnome Desktop Gnome Settings/Wi-Fi/Security When the show password checkbox is checked the password remains hidden. This Bug also affects previous versions of AlmaLinux such AlmaLinux 9.2. |
||||
Tags: | |||||
Steps To Reproduce: |
1. Open Gnome settings Wi-Fi 2. Then toggle to the security settings 3. Check the show password checkbox 4. The password remains hidden or is not displayed |
||||
Additional Information: |
The bug was filed on Red Hat Bugzilla on 7-27-2023 against CentOS stream 9 x86_64. https://bugzilla.redhat.com/show_bug.cgi?id=2227088 |
||||
Attached Files: |
Screenshot from 2023-11-09 19-14-03.png (48,259 bytes) 2023-11-10 01:31 https://bugs.almalinux.org/file_download.php?file_id=226&type=bug |
||||
Notes | |
(0000991)
kclem 2023-11-10 01:46 |
The project is AlmaLinux 9 not Almalinux 8. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
438 | [AlmaLinux-8] -OTHER | block | N/A | 2023-11-06 14:15 | 2023-11-06 15:36 |
Reporter: | kludge | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Interesting issue with Leapp when upgrading from Centos 7 -- filesystem problem | ||||
Description: |
So, I have a Centos 7 machine, and what was interesting about this system is that if you did a df -T, it listed the /run filesystem as being an xfs filesystem instead of tmpfs. I found this out when I run the leapp preupgrade script, and it failed with: 2023-11-06 08:34:30.873 DEBUG PID: 25972 leapp.workflow.FactsCollection.xfs_info_scanner: External command has started: ['/usr/sbin/xfs_info', '/run'] 2023-11-06 08:34:30.891 DEBUG PID: 25972 leapp.workflow.FactsCollection.xfs_info_scanner: xfs_info: specified file ["/run"] is not on an XFS filesystem 2023-11-06 08:34:30.898 DEBUG PID: 25972 leapp.workflow.FactsCollection.xfs_info_scanner: Command ['/usr/sbin/xfs_info', '/run'] failed with exit code 1. Which of course is a problem. So, I did a mount tmpfs -t tmpfs /run and it now shows up as tmpfs and everything is groovy there BUT... when I run a leapp preupgrade it still fails, as if the information is cached somewhere. So, I removed the database in /var/lib/leapp/ and that didn't fix the problem. So.... how do I get whatever cached data exists to be removed.... or how do I get the preupgrade to just skip over the xfs_info stuff... or how do I alter the cached data to get it to stop looking at /run? |
||||
Tags: | |||||
Steps To Reproduce: | I don't know how to reproduce the problem per se because I don't know how you get a system in the first place with /run listed with the wrong filetype. For the time being I am not too worried about debugging that long-term since I hope to soon have an upgraded system anyway. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000989)
kludge 2023-11-06 15:36 |
Okay, so I wrote a wrapper script to /sbin/xfs_info that ignores /run and that seems to be okay.... except.... new and related problem.... This system had the /etc/redhat-release tampered with it so that the security scanner run on our facility would think it was running a supported red hat version until such time as we could get upgraded to oracle 8.... and when I ran leapp preupgrade, it thought we were running redhat and came up with the error " Actor: target_userspace_creator Message: Cannot set the container mode for the subscription-manager." So, I put the original redhat-release file back, BUT.... leapp still keeps giving the same error because that data seems to be cached somewhere. Removing that database file and rebooting does nothing. Where is this being stored? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
412 | [AlmaLinux-8] linux-firmware | major | always | 2023-07-25 01:48 | 2023-10-17 00:42 |
Reporter: | alukoshko | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | high | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux 8 is affected by CVE-2023-20593 (Zenbleed) | ||||
Description: | AMD CPU microcode update is required in linux-firmware package | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: |
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20593 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amd-ucode?id=0bc3126c9cfa0b8c761483215c25382f831a7c6f |
||||
Attached Files: |
alma9-epyc7402p-success.txt (20,814 bytes) 2023-07-25 15:10 https://bugs.almalinux.org/file_download.php?file_id=212&type=bug 20230725_lscpu.txt (1,740 bytes) 2023-07-25 16:12 https://bugs.almalinux.org/file_download.php?file_id=213&type=bug 20230725_journalctl_microcode.txt (5,906 bytes) 2023-07-25 16:12 https://bugs.almalinux.org/file_download.php?file_id=214&type=bug testing.txt (4,621 bytes) 2023-07-26 13:37 https://bugs.almalinux.org/file_download.php?file_id=215&type=bug |
||||
Notes | |
(0000935)
tuxwielder 2023-07-25 16:12 |
Did it work for you? -> Yes Upgrade went just fine. I have been 'stress --cpu 42'-ing for a while now and no issues so far. Thank you for your great work! |
(0000936)
bennyvasquez 2023-07-26 13:37 |
Yup, it worked for 24 identical servers. |
(0000959)
toracat 2023-08-16 17:11 |
I see in the repo: 20230404-114.git2e92a49f.el8_8.noarch.rpm 20230404-114.git2e92a49f.el8_8.alma.noarch.rpm One potential issue is that the patched version has a lower EVR, so yum/dnf will not update the package automatically. $ rpmdev-vercmp 20230404-114.git2e92a49f.el8_8.noarch 20230404-114.git2e92a49f.el8_8.alma.noarch 20230404-114.git2e92a49f.el8_8.noarch > 20230404-114.git2e92a49f.el8_8.alma.noarch |
(0000961)
alukoshko 2023-08-22 14:53 |
[root@febbe3c16572 /]# dnf install linux-firmware AlmaLinux 8 - BaseOS 3.2 MB/s | 6.1 MB 00:01 AlmaLinux 8 - AppStream 3.8 MB/s | 12 MB 00:03 AlmaLinux 8 - Extras 25 kB/s | 23 kB 00:00 Last metadata expiration check: 0:00:01 ago on Tue Aug 22 14:53:13 2023. Dependencies resolved. ========================================================================================================================== Package Architecture Version Repository Size ========================================================================================================================== Installing: linux-firmware noarch 20230404-114.git2e92a49f.el8_8.alma baseos 264 M Transaction Summary ========================================================================================================================== Install 1 Package Total download size: 264 M Installed size: 723 M Is this ok [y/N]: |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
422 | [AlmaLinux-8] kernel | crash | always | 2023-08-27 09:38 | 2023-10-17 00:42 |
Reporter: | gvde2 | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux 8.8. kernel issue - missing patch | ||||
Description: |
The kernel for 8.8 introduced an issue for VMs running on Xen that makes it impossible to pause or migrate VMs in the xen pool. It’s explained here: https://xcp-ng.org/blog/2023/06/09/troubleshooting-live-migration-crashes-in-rhel-8-8-and-derivatives/ This patch is missing: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/xen/events/events_base.c?id=a0bb51f2638e0810c347024679239fd10a8f7990&ref=xcp-ng.org I have noticed that for rhel8.8 the latest kernel 4.18.0-477.21.1.el8_8.x86_64 does include the patch, while it is still missing in the same version on almalinux 8.8. On almalinux: [root@alma8 ~]# uname -a Linux alma8.dkrz.de 4.18.0-477.21.1.el8_8.x86_64 #1 SMP Thu Aug 10 13:51:50 EDT 2023 x86_64 x86_64 x86_64 GNU/Linux [root@alma8 ~]# grep xen.*vector /proc/kallsyms ffffffff8e9e34f0 T xen_callback_vector ffffffff8e9e3633 t xen_callback_vector.cold.25 ffffffff8f000fb0 T xen_hvm_callback_vector ffffffff8f7fe810 r __ksymtab_xen_have_vector_callback ffffffff8f8096af r __kstrtab_xen_have_vector_callback ffffffff903b1030 D xen_have_vector_callback on rhel8.8 [root@rhel8 ~]# uname -a Linux rhel8.dkrz.de 4.18.0-477.21.1.el8_8.x86_64 #1 SMP Thu Jul 20 08:38:27 EDT 2023 x86_64 x86_64 x86_64 GNU/Linux [root@rhel8 ~]# grep xen.*vector /proc/kallsyms ffffffff9b7e4740 T xen_setup_callback_vector ffffffff9b7e487e t xen_setup_callback_vector.cold.25 ffffffff9be00fb0 T xen_hvm_callback_vector ffffffff9c5fe840 r __ksymtab_xen_have_vector_callback ffffffff9c6096eb r __kstrtab_xen_have_vector_callback ffffffff9d1b10f0 D xen_have_vector_callback |
||||
Tags: | almalinux8 | ||||
Steps To Reproduce: | Run a AlmaLinux 8.8 VM on Xen or Citrix Hypervisor with kernel 4.18.0-477.21.1.el8_8.x86_64 installed and migrate or pause the VM. It will reset and boot. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000962)
toracat 2023-08-27 16:54 |
I can confirm this patch is not in Alma-8's kernel. |
(0000964)
alukoshko 2023-08-28 11:53 |
Unfortunately after Red Hat decision to not share sources we don't have legal way to get updated tarballs of RHEL kernels so we do Oracle Linux way now by providing only security fixes. But this patch doesn't look so complicated and I think we can release it to Testing repo pretty soon. Will you help with testing, gvde2? |
(0000966)
gvde2 2023-08-28 14:32 |
Yes. I can test the kernel in a few of our test AL8 VMs. |
(0000967)
alukoshko 2023-08-28 15:46 |
gvde2, before I release to Testing could you please check package directly from build system? curl https://build.almalinux.org/pulp/content/builds/AlmaLinux-8-x86_64-7247-br/config.repo -o /etc/yum.repos.d/albz422.repo dnf update |
(0000968)
gvde2 2023-08-28 18:42 |
I have created a test vm, installed the 21.2 kernel, rebooted and was able to migrate the VMs between hosts in the xen pool. So it seems to fix this issue. |
(0000969)
alukoshko 2023-08-29 06:55 |
Thanks for update. Releasing to Testing repo. |
(0000971)
toracat 2023-08-30 18:42 |
@alukoshko Is it going to stay in the testing repo or get moved to the main repo eventually? Sorry I don't know how a case like this is handled. |
(0000972)
alukoshko 2023-08-30 19:52 |
@toracat This patch will be definitely included in next kernel update. For this particular build I don't know yet because new kernel version higher than RHEL's one can surprise users. |
(0000982)
alukoshko 2023-09-28 12:12 |
Fixed in latest AlmaLinux 8 kernel update |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
352 | [AlmaLinux-8] anaconda | major | always | 2023-01-03 21:10 | 2023-10-13 19:35 |
Reporter: | abotelho | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Upgrade from anaconda-core 33.16.6.7-1.el8.alma (8.6) to 33.16.7.12-1.el8.alma.x86_64 (8.7) breaks livemedia-creator | ||||
Description: |
SUCCESS: 2023-01-03 15:55:32,289: livemedia-creator v28.14.70-1 2023-01-03 15:55:32,289: selinux is enabled and in Permissive mode 2023-01-03 15:55:32,406: disk_img = /images/el8-base/el8-base-2023.01.03-15.55.29.img 2023-01-03 15:55:32,406: Using disk size of 4002MiB 2023-01-03 15:55:32,853: Running anaconda. 2023-01-03 15:55:39,289: Processing logs from ('127.0.0.1', 36258) 2023-01-03 15:55:39,451: Starting installer, one moment... 2023-01-03 15:55:39,451: terminal size detection failed, using default width 2023-01-03 15:55:39,452: anaconda 33.16.6.7-1.el8.alma for AlmaLinux 8 (pre-release) started. 2023-01-03 15:55:39,452: 15:55:39 Not asking for VNC because of an automated install 2023-01-03 15:55:39,452: 15:55:39 Not asking for VNC because we don't have Xvnc 2023-01-03 15:55:59,315: Starting automated install.............. 2023-01-03 15:55:59,315: ================================================================================ 2023-01-03 15:55:59,315: ================================================================================ 2023-01-03 15:55:59,316: Installation 2023-01-03 15:55:59,316: 2023-01-03 15:55:59,316: 1) [x] Language settings 2) [x] Time settings 2023-01-03 15:55:59,316: (English (United States)) (US/Eastern timezone) 2023-01-03 15:55:59,316: 3) [x] Installation source 4) [x] Software selection 2023-01-03 15:55:59,317: (https://pkgrepo.prd.cbnls.net/p (Custom software selected) 2023-01-03 15:55:59,317: ulp/content/almalinux8-baseos/) 2023-01-03 15:55:59,317: 5) [ ] User creation 2023-01-03 15:55:59,317: (No user will be created) 2023-01-03 15:55:59,317: 2023-01-03 15:55:59,317: ================================================================================ 2023-01-03 15:55:59,318: ================================================================================ 2023-01-03 15:55:59,318: Progress 2023-01-03 15:55:59,318: 2023-01-03 15:55:59,318: Setting up the installation environment 2023-01-03 15:55:59,319: .. 2023-01-03 15:55:59,319: Configuring storage 2023-01-03 15:56:04,355: ... 2023-01-03 15:56:04,355: Running pre-installation scripts 2023-01-03 15:56:04,373: . 2023-01-03 15:56:04,374: Running pre-installation tasks 2023-01-03 15:56:41,294: .. 2023-01-03 15:56:41,295: Installing. 2023-01-03 15:56:41,295: Starting package installation process 2023-01-03 15:56:41,295: Downloading packages 2023-01-03 15:56:41,296: Downloading 404 RPMs, 23.21 MiB / 543.41 MiB (4%) done. 2023-01-03 15:56:41,296: Downloading 404 RPMs, 47.24 MiB / 543.41 MiB (8%) done. 2023-01-03 15:56:41,296: Downloading 404 RPMs, 71.15 MiB / 543.41 MiB (13%) done. 2023-01-03 15:56:41,296: Downloading 404 RPMs, 98.43 MiB / 543.41 MiB (18%) done. 2023-01-03 15:56:41,297: Downloading 404 RPMs, 136.91 MiB / 543.41 MiB (25%) done. 2023-01-03 15:56:41,297: Downloading 404 RPMs, 162.76 MiB / 543.41 MiB (29%) done. 2023-01-03 15:56:41,297: Downloading 404 RPMs, 199.99 MiB / 543.41 MiB (36%) done. 2023-01-03 15:56:41,297: Downloading 404 RPMs, 231.67 MiB / 543.41 MiB (42%) done. 2023-01-03 15:56:41,298: Downloading 404 RPMs, 250.13 MiB / 543.41 MiB (46%) done. 2023-01-03 15:56:41,298: Downloading 404 RPMs, 268.68 MiB / 543.41 MiB (49%) done. 2023-01-03 15:56:41,298: Downloading 404 RPMs, 290.37 MiB / 543.41 MiB (53%) done. 2023-01-03 15:56:41,298: Downloading 404 RPMs, 320.95 MiB / 543.41 MiB (59%) done. 2023-01-03 15:56:41,298: Downloading 404 RPMs, 359.27 MiB / 543.41 MiB (66%) done. 2023-01-03 15:56:41,299: Downloading 404 RPMs, 385.21 MiB / 543.41 MiB (70%) done. 2023-01-03 15:56:41,299: Downloading 404 RPMs, 430.6 MiB / 543.41 MiB (79%) done. 2023-01-03 15:56:41,299: Downloading 404 RPMs, 509.33 MiB / 543.41 MiB (93%) done. 2023-01-03 15:56:41,299: Downloading 404 RPMs, 543.41 MiB / 543.41 MiB (100%) done. 2023-01-03 15:56:41,300: Preparing transaction from installation source 2023-01-03 15:57:56,711: Installing libgcc.x86_64 (1/404) 2023-01-03 15:57:56,711: Installing libreport-filesystem.x86_64 (2/404) 2023-01-03 15:57:56,712: Installing tzdata.noarch (3/404) 2023-01-03 15:57:56,712: Installing python3-setuptools-wheel.noarch (4/404) 2023-01-03 15:57:56,712: Installing python3-pip-wheel.noarch (5/404) 2023-01-03 15:57:56,712: Installing dnf-data.noarch (6/404) 2023-01-03 15:57:56,712: Installing xkeyboard-config.noarch (7/404) 2023-01-03 15:57:56,713: Installing firewalld-filesystem.noarch (8/404) 2023-01-03 15:57:56,713: Installing libssh-config.noarch (9/404) 2023-01-03 15:57:56,713: Installing kbd-legacy.noarch (10/404) 2023-01-03 15:57:56,713: Installing kbd-misc.noarch (11/404) 2023-01-03 15:57:56,713: Installing publicsuffix-list-dafsa.noarch (12/404) 2023-01-03 15:57:56,713: Installing linux-firmware.noarch (13/404) 2023-01-03 15:57:56,714: Installing hwdata.noarch (14/404) 2023-01-03 15:57:56,714: Installing almalinux-release.x86_64 (15/404) 2023-01-03 15:57:56,714: Installing setup.noarch (16/404) 2023-01-03 15:57:56,714: Installing filesystem.x86_64 (17/404) 2023-01-03 15:57:56,714: Installing efi-filesystem.noarch (18/404) 2023-01-03 15:57:56,715: Installing basesystem.noarch (19/404) 2023-01-03 15:57:56,715: Installing ncurses-base.noarch (20/404) 2023-01-03 15:57:56,715: Installing pcre2.x86_64 (21/404) 2023-01-03 15:57:56,715: Installing libselinux.x86_64 (22/404) 2023-01-03 15:57:56,715: Installing ncurses-libs.x86_64 (23/404) 2023-01-03 15:57:56,716: Installing glibc-langpack-en.x86_64 (24/404) 2023-01-03 15:57:56,716: Installing glibc-gconv-extra.x86_64 (25/404) 2023-01-03 15:57:56,716: Installing glibc-common.x86_64 (26/404) 2023-01-03 15:57:56,716: Installing glibc.x86_64 (27/404) 2023-01-03 15:57:56,716: Installing bash.x86_64 (28/404) 2023-01-03 15:57:56,717: Installing libsepol.x86_64 (29/404) 2023-01-03 15:57:56,717: Installing zlib.x86_64 (30/404) 2023-01-03 15:57:56,717: Installing xz-libs.x86_64 (31/404) 2023-01-03 15:57:56,717: Installing popt.x86_64 (32/404) 2023-01-03 15:57:56,717: Installing info.x86_64 (33/404) 2023-01-03 15:57:56,718: Installing libcap.x86_64 (34/404) 2023-01-03 15:57:56,718: Installing bzip2-libs.x86_64 (35/404) 2023-01-03 15:57:56,718: Installing sqlite-libs.x86_64 (36/404) 2023-01-03 15:57:56,718: Installing libgpg-error.x86_64 (37/404) 2023-01-03 15:57:56,718: Installing libuuid.x86_64 (38/404) 2023-01-03 15:57:56,719: Installing libcom_err.x86_64 (39/404) 2023-01-03 15:57:56,719: Installing elfutils-libelf.x86_64 (40/404) 2023-01-03 15:57:56,719: Installing libxcrypt.x86_64 (41/404) 2023-01-03 15:57:56,719: Installing libzstd.x86_64 (42/404) 2023-01-03 15:57:56,719: Installing libstdc++.x86_64 (43/404) 2023-01-03 15:57:56,719: Installing readline.x86_64 (44/404) 2023-01-03 15:57:56,720: Installing libxml2.x86_64 (45/404) 2023-01-03 15:57:56,720: Installing expat.x86_64 (46/404) 2023-01-03 15:57:56,720: Installing libunistring.x86_64 (47/404) 2023-01-03 15:57:56,720: Installing chkconfig.x86_64 (48/404) 2023-01-03 15:57:56,720: Installing gmp.x86_64 (49/404) 2023-01-03 15:57:56,721: Installing libmnl.x86_64 (50/404) 2023-01-03 15:57:56,721: Installing nspr.x86_64 (51/404) 2023-01-03 15:57:56,721: Installing nss-util.x86_64 (52/404) 2023-01-03 15:57:56,721: Installing libidn2.x86_64 (53/404) 2023-01-03 15:57:56,721: Installing findutils.x86_64 (54/404) 2023-01-03 15:57:56,722: Installing grub2-common.noarch (55/404) 2023-01-03 15:57:56,722: Installing libnl3.x86_64 (56/404) 2023-01-03 15:57:56,722: Installing lua-libs.x86_64 (57/404) 2023-01-03 15:57:56,722: Installing libgcrypt.x86_64 (58/404) 2023-01-03 15:57:56,722: Installing libtalloc.x86_64 (59/404) 2023-01-03 15:57:56,722: Installing libcap-ng.x86_64 (60/404) 2023-01-03 15:57:56,723: Installing audit-libs.x86_64 (61/404) 2023-01-03 15:57:56,723: Installing libffi.x86_64 (62/404) 2023-01-03 15:57:56,723: Installing p11-kit.x86_64 (63/404) 2023-01-03 15:57:56,723: Installing libassuan.x86_64 (64/404) 2023-01-03 15:57:56,723: Installing file-libs.x86_64 (65/404) 2023-01-03 15:57:56,724: Installing lz4-libs.x86_64 (66/404) 2023-01-03 15:57:56,724: Installing json-c.x86_64 (67/404) 2023-01-03 15:57:56,724: Installing libattr.x86_64 (68/404) 2023-01-03 15:57:56,724: Installing libacl.x86_64 (69/404) 2023-01-03 15:57:56,725: Installing sed.x86_64 (70/404) 2023-01-03 15:57:56,725: Installing libsmartcols.x86_64 (71/404) 2023-01-03 15:57:56,725: Installing file.x86_64 (72/404) 2023-01-03 15:57:56,725: Installing libsemanage.x86_64 (73/404) 2023-01-03 15:57:56,725: Installing libtevent.x86_64 (74/404) 2023-01-03 15:57:56,726: Installing nettle.x86_64 (75/404) 2023-01-03 15:57:56,726: Installing libtdb.x86_64 (76/404) 2023-01-03 15:57:56,726: Installing efivar-libs.x86_64 (77/404) 2023-01-03 15:57:56,726: Installing jansson.x86_64 (78/404) 2023-01-03 15:57:56,726: Installing libref_array.x86_64 (79/404) 2023-01-03 15:57:56,727: Installing libcollection.x86_64 (80/404) 2023-01-03 15:57:56,727: Installing gdbm-libs.x86_64 (81/404) 2023-01-03 15:57:56,727: Installing keyutils-libs.x86_64 (82/404) 2023-01-03 15:57:56,727: Installing libbasicobjects.x86_64 (83/404) 2023-01-03 15:57:56,727: Installing pcre.x86_64 (84/404) 2023-01-03 15:57:56,728: Installing grep.x86_64 (85/404) 2023-01-03 15:57:56,728: Installing tar.x86_64 (86/404) 2023-01-03 15:57:56,728: Installing libnl3-cli.x86_64 (87/404) 2023-01-03 15:57:56,728: Installing libpsl.x86_64 (88/404) 2023-01-03 15:57:56,728: Installing ethtool.x86_64 (89/404) 2023-01-03 15:57:56,729: Installing libnftnl.x86_64 (90/404) 2023-01-03 15:57:56,729: Installing mpfr.x86_64 (91/404) 2023-01-03 15:57:56,729: Installing gdisk.x86_64 (92/404) 2023-01-03 15:57:56,729: Installing libksba.x86_64 (93/404) 2023-01-03 15:57:56,729: Installing libgomp.x86_64 (94/404) 2023-01-03 15:57:56,730: Installing diffutils.x86_64 (95/404) 2023-01-03 15:57:56,730: Installing libsss_idmap.x86_64 (96/404) 2023-01-03 15:57:56,730: Installing libedit.x86_64 (97/404) 2023-01-03 15:57:56,730: Installing cpio.x86_64 (98/404) 2023-01-03 15:57:56,730: Installing dmidecode.x86_64 (99/404) 2023-01-03 15:57:56,730: Installing pciutils-libs.x86_64 (100/404) 2023-01-03 15:57:56,731: Installing lzo.x86_64 (101/404) 2023-01-03 15:57:56,731: Installing libtasn1.x86_64 (102/404) 2023-01-03 15:57:56,731: Installing p11-kit-trust.x86_64 (103/404) 2023-01-03 15:57:56,731: Installing numactl-libs.x86_64 (104/404) 2023-01-03 15:57:56,731: Installing libseccomp.x86_64 (105/404) 2023-01-03 15:57:56,732: Installing libnfnetlink.x86_64 (106/404) 2023-01-03 15:57:56,732: Installing libdhash.x86_64 (107/404) 2023-01-03 15:57:56,732: Installing libnetfilter_conntrack.x86_64 (108/404) 2023-01-03 15:57:56,732: Installing squashfs-tools.x86_64 (109/404) 2023-01-03 15:57:56,733: Installing libbytesize.x86_64 (110/404) 2023-01-03 15:57:56,733: Installing libteam.x86_64 (111/404) 2023-01-03 15:57:56,733: Installing xz.x86_64 (112/404) 2023-01-03 15:57:56,734: Installing gdbm.x86_64 (113/404) 2023-01-03 15:57:56,734: Installing groff-base.x86_64 (114/404) 2023-01-03 15:57:56,734: Installing vim-minimal.x86_64 (115/404) 2023-01-03 15:57:56,734: Installing acl.x86_64 (116/404) 2023-01-03 15:57:56,734: Installing libibverbs.x86_64 (117/404) 2023-01-03 15:57:56,735: Installing libpcap.x86_64 (118/404) 2023-01-03 15:57:56,735: Installing iptables-libs.x86_64 (119/404) 2023-01-03 15:57:56,735: Installing iptables.x86_64 (120/404) 2023-01-03 15:57:56,735: Installing iptables-ebtables.x86_64 (121/404) 2023-01-03 15:57:56,735: Installing nftables.x86_64 (122/404) 2023-01-03 15:57:56,736: Installing grub2-pc-modules.noarch (123/404) 2023-01-03 15:57:56,736: Installing nss-softokn-freebl.x86_64 (124/404) 2023-01-03 15:57:56,736: Installing nss-softokn.x86_64 (125/404) 2023-01-03 15:57:56,736: Installing ipset-libs.x86_64 (126/404) 2023-01-03 15:57:56,736: Installing ipset.x86_64 (127/404) 2023-01-03 15:57:56,736: Installing libcomps.x86_64 (128/404) 2023-01-03 15:57:56,737: Installing libmetalink.x86_64 (129/404) 2023-01-03 15:57:56,737: Installing mozjs60.x86_64 (130/404) 2023-01-03 15:57:56,737: Installing snappy.x86_64 (131/404) 2023-01-03 15:57:56,737: Installing libbpf.x86_64 (132/404) 2023-01-03 15:57:56,737: Installing e2fsprogs-libs.x86_64 (133/404) 2023-01-03 15:57:56,738: Installing libss.x86_64 (134/404) 2023-01-03 15:57:56,738: Installing bubblewrap.x86_64 (135/404) 2023-01-03 15:57:56,738: Installing coreutils-common.x86_64 (136/404) 2023-01-03 15:57:56,738: Installing mtools.x86_64 (137/404) 2023-01-03 15:57:56,738: Installing syslinux-nonlinux.noarch (138/404) 2023-01-03 15:57:56,739: Installing syslinux.x86_64 (139/404) 2023-01-03 15:57:56,739: Installing libpng.x86_64 (140/404) 2023-01-03 15:57:56,739: Installing freetype.x86_64 (141/404) 2023-01-03 15:57:56,739: Installing pigz.x86_64 (142/404) 2023-01-03 15:57:56,739: Installing libselinux-utils.x86_64 (143/404) 2023-01-03 15:57:56,740: Installing kernel-tools-libs.x86_64 (144/404) 2023-01-03 15:57:56,740: Installing less.x86_64 (145/404) 2023-01-03 15:57:56,740: Installing ncurses.x86_64 (146/404) 2023-01-03 15:57:56,740: Installing fuse-libs.x86_64 (147/404) 2023-01-03 15:57:56,740: Installing libsss_sudo.x86_64 (148/404) 2023-01-03 15:57:56,741: Installing sg3_utils-libs.x86_64 (149/404) 2023-01-03 15:57:56,741: Installing hdparm.x86_64 (150/404) 2023-01-03 15:57:56,741: Installing memstrack.x86_64 (151/404) 2023-01-03 15:57:56,741: Installing libsmbios.x86_64 (152/404) 2023-01-03 15:57:56,741: Installing libpipeline.x86_64 (153/404) 2023-01-03 15:57:56,742: Installing psmisc.x86_64 (154/404) 2023-01-03 15:57:56,742: Installing libpath_utils.x86_64 (155/404) 2023-01-03 15:57:56,742: Installing libini_config.x86_64 (156/404) 2023-01-03 15:57:56,742: Installing libnghttp2.x86_64 (157/404) 2023-01-03 15:57:56,742: Installing libyaml.x86_64 (158/404) 2023-01-03 15:57:56,742: Installing hardlink.x86_64 (159/404) 2023-01-03 15:57:56,743: Installing c-ares.x86_64 (160/404) 2023-01-03 15:57:56,743: Installing libsss_autofs.x86_64 (161/404) 2023-01-03 15:57:56,743: Installing libsigsegv.x86_64 (162/404) 2023-01-03 15:57:56,743: Installing gawk.x86_64 (163/404) 2023-01-03 15:57:56,743: Installing brotli.x86_64 (164/404) 2023-01-03 15:57:56,744: Installing libdaemon.x86_64 (165/404) 2023-01-03 15:57:56,744: Installing libsss_nss_idmap.x86_64 (166/404) 2023-01-03 15:57:56,744: Installing lmdb-libs.x86_64 (167/404) 2023-01-03 15:57:56,744: Installing dosfstools.x86_64 (168/404) 2023-01-03 15:57:56,744: Installing libverto.x86_64 (169/404) 2023-01-03 15:57:56,745: Installing slang.x86_64 (170/404) 2023-01-03 15:57:56,745: Installing newt.x86_64 (171/404) 2023-01-03 15:57:56,745: Installing npth.x86_64 (172/404) 2023-01-03 15:57:56,745: Installing libndp.x86_64 (173/404) 2023-01-03 15:57:56,745: Installing libxkbcommon.x86_64 (174/404) 2023-01-03 15:57:56,745: Installing cyrus-sasl-lib.x86_64 (175/404) 2023-01-03 15:57:56,746: Installing python3-libs.x86_64 (176/404) 2023-01-03 15:57:56,746: Installing platform-python-pip.noarch (177/404) 2023-01-03 15:57:56,746: Installing platform-python-setuptools.noarch (178/404) 2023-01-03 15:57:56,746: Installing grub2-tools-minimal.x86_64 (179/404) 2023-01-03 15:57:56,747: Installing openldap.x86_64 (180/404) 2023-01-03 15:57:56,747: Installing platform-python.x86_64 (181/404) 2023-01-03 15:57:56,747: Installing libssh.x86_64 (182/404) 2023-01-03 15:57:56,747: Installing grubby.x86_64 (183/404) 2023-01-03 15:57:56,747: Installing libdb-utils.x86_64 (184/404) 2023-01-03 15:57:56,748: Installing openssl.x86_64 (185/404) 2023-01-03 15:57:56,748: Installing curl.x86_64 (186/404) 2023-01-03 15:57:56,748: Installing libcurl.x86_64 (187/404) 2023-01-03 15:57:56,748: Installing libkcapi.x86_64 (188/404) 2023-01-03 15:57:56,748: Installing libkcapi-hmaccalc.x86_64 (189/404) 2023-01-03 15:57:56,749: Installing crypto-policies-scripts.noarch (190/404) 2023-01-03 15:57:56,749: Installing crypto-policies.noarch (191/404) 2023-01-03 15:57:56,749: Installing libarchive.x86_64 (192/404) 2023-01-03 15:57:56,749: Installing krb5-libs.x86_64 (193/404) 2023-01-03 15:57:56,749: Installing libtirpc.x86_64 (194/404) 2023-01-03 15:57:56,750: Installing libnsl2.x86_64 (195/404) 2023-01-03 15:57:56,750: Installing openssl-pkcs11.x86_64 (196/404) 2023-01-03 15:57:56,750: Installing gzip.x86_64 (197/404) 2023-01-03 15:57:56,750: Installing cracklib.x86_64 (198/404) 2023-01-03 15:57:56,750: Installing cracklib-dicts.x86_64 (199/404) 2023-01-03 15:57:56,751: Installing procps-ng.x86_64 (200/404) 2023-01-03 15:57:56,751: Installing kpartx.x86_64 (201/404) 2023-01-03 15:57:56,751: Installing device-mapper.x86_64 (202/404) 2023-01-03 15:57:56,751: Installing elfutils-debuginfod-client.x86_64 (203/404) 2023-01-03 15:57:56,751: Installing elfutils-default-yama-scope.noarch (204/404) 2023-01-03 15:57:56,752: Installing elfutils-libs.x86_64 (205/404) 2023-01-03 15:57:56,752: Installing libcroco.x86_64 (206/404) 2023-01-03 15:57:56,752: Installing gettext-libs.x86_64 (207/404) 2023-01-03 15:57:56,752: Installing rpm.x86_64 (208/404) 2023-01-03 15:57:56,752: Installing kmod-libs.x86_64 (209/404) 2023-01-03 15:57:56,753: Installing trousers-lib.x86_64 (210/404) 2023-01-03 15:57:56,753: Installing kmod.x86_64 (211/404) 2023-01-03 15:57:56,753: Installing libdb.x86_64 (212/404) 2023-01-03 15:57:56,753: Installing libfdisk.x86_64 (213/404) 2023-01-03 15:57:56,753: Installing libmount.x86_64 (214/404) 2023-01-03 16:00:40,710: Installing kbd.x86_64 (215/404) 2023-01-03 16:00:40,711: Installing libpwquality.x86_64 (216/404) 2023-01-03 16:00:40,711: Installing which.x86_64 (217/404) 2023-01-03 16:00:40,711: Installing dbus-tools.x86_64 (218/404) 2023-01-03 16:00:40,711: Installing dbus-libs.x86_64 (219/404) 2023-01-03 16:00:40,711: Installing coreutils.x86_64 (220/404) 2023-01-03 16:00:40,711: Installing systemd-libs.x86_64 (221/404) 2023-01-03 16:00:40,711: Installing pam.x86_64 (222/404) 2023-01-03 16:00:40,712: Installing libblkid.x86_64 (223/404) 2023-01-03 16:00:40,712: Installing shadow-utils.x86_64 (224/404) 2023-01-03 16:00:40,712: Installing device-mapper-libs.x86_64 (225/404) 2023-01-03 16:00:40,712: Installing ca-certificates.noarch (226/404) 2023-01-03 16:00:40,712: Installing openssl-libs.x86_64 (227/404) 2023-01-03 16:00:40,712: Installing rpm-libs.x86_64 (228/404) 2023-01-03 16:00:40,712: Installing cryptsetup-libs.x86_64 (229/404) 2023-01-03 16:00:40,712: Installing libutempter.x86_64 (230/404) 2023-01-03 16:00:40,712: Installing util-linux.x86_64 (231/404) 2023-01-03 16:00:40,713: Installing systemd-pam.x86_64 (232/404) 2023-01-03 16:00:40,713: Installing dracut.x86_64 (233/404) 2023-01-03 16:00:40,713: Installing os-prober.x86_64 (234/404) 2023-01-03 16:00:40,713: Installing dbus-common.noarch (235/404) 2023-01-03 16:00:40,713: Installing dbus-daemon.x86_64 (236/404) 2023-01-03 16:00:40,713: Installing gettext.x86_64 (237/404) 2023-01-03 16:00:40,713: Installing grub2-tools.x86_64 (238/404) 2023-01-03 16:00:40,713: Installing glib2.x86_64 (239/404) 2023-01-03 16:00:40,713: Installing shared-mime-info.x86_64 (240/404) 2023-01-03 16:00:40,714: Installing gnutls.x86_64 (241/404) 2023-01-03 16:00:40,714: Installing systemd-udev.x86_64 (242/404) 2023-01-03 16:00:40,714: Installing trousers.x86_64 (243/404) 2023-01-03 16:00:40,714: Installing dbus.x86_64 (244/404) 2023-01-03 16:00:40,714: Installing systemd.x86_64 (245/404) 2023-01-03 16:00:40,714: Installing libmodulemd.x86_64 (246/404) 2023-01-03 16:00:40,714: Installing polkit-libs.x86_64 (247/404) 2023-01-03 16:00:40,714: Installing python3-six.noarch (248/404) 2023-01-03 16:00:40,714: Installing kernel-core.x86_64 (249/404) 2023-01-03 16:00:40,714: Installing libsolv.x86_64 (250/404) 2023-01-03 16:00:40,715: Installing parted.x86_64 (251/404) 2023-01-03 16:00:40,715: Installing libblockdev-utils.x86_64 (252/404) 2023-01-03 16:00:40,715: Installing kernel-modules.x86_64 (253/404) 2023-01-03 16:00:40,715: Installing cronie-anacron.x86_64 (254/404) 2023-01-03 16:00:40,715: Installing cronie.x86_64 (255/404) 2023-01-03 16:00:40,715: Installing crontabs.noarch (256/404) 2023-01-03 16:00:40,715: Installing NetworkManager-libnm.x86_64 (257/404) 2023-01-03 16:00:40,715: Installing NetworkManager.x86_64 (258/404) 2023-01-03 16:00:40,715: Installing libgudev.x86_64 (259/404) 2023-01-03 16:00:40,715: Installing grub2-tools-extra.x86_64 (260/404) 2023-01-03 16:00:40,715: Installing openssh.x86_64 (261/404) 2023-01-03 16:00:40,716: Installing policycoreutils.x86_64 (262/404) 2023-01-03 16:00:40,716: Installing libevent.x86_64 (263/404) 2023-01-03 16:00:40,716: Installing libusbx.x86_64 (264/404) 2023-01-03 16:00:40,716: Installing logrotate.x86_64 (265/404) 2023-01-03 16:00:40,716: Installing iproute.x86_64 (266/404) 2023-01-03 16:00:40,716: Installing python3-decorator.noarch (267/404) 2023-01-03 16:00:40,716: Installing libldb.x86_64 (268/404) 2023-01-03 16:00:40,716: Installing libgusb.x86_64 (269/404) 2023-01-03 16:00:40,716: Installing unbound-libs.x86_64 (270/404) 2023-01-03 16:00:40,716: Installing python3-unbound.x86_64 (271/404) 2023-01-03 16:00:40,717: Installing rpm-plugin-selinux.x86_64 (272/404) 2023-01-03 16:00:40,717: Installing selinux-policy.noarch (273/404) 2023-01-03 16:00:40,717: Installing selinux-policy-targeted.noarch (274/404) 2023-01-03 16:00:40,717: Installing libblockdev-part.x86_64 (275/404) 2023-01-03 16:00:40,717: Installing libblockdev-fs.x86_64 (276/404) 2023-01-03 16:00:40,717: Installing libblockdev-loop.x86_64 (277/404) 2023-01-03 16:00:40,717: Installing libblockdev-swap.x86_64 (278/404) 2023-01-03 16:00:40,717: Installing libblockdev.x86_64 (279/404) 2023-01-03 16:00:40,717: Installing python3-pyudev.noarch (280/404) 2023-01-03 16:00:40,717: Installing python3-dateutil.noarch (281/404) 2023-01-03 16:00:40,717: Installing python3-linux-procfs.noarch (282/404) 2023-01-03 16:00:40,718: Installing polkit.x86_64 (283/404) 2023-01-03 16:00:40,718: Installing polkit-pkla-compat.x86_64 (284/404) 2023-01-03 16:00:40,718: Installing timedatex.x86_64 (285/404) 2023-01-03 16:00:40,718: Installing initscripts.x86_64 (286/404) 2023-01-03 16:00:40,718: Installing mdadm.x86_64 (287/404) 2023-01-03 16:00:40,718: Installing libblockdev-mdraid.x86_64 (288/404) 2023-01-03 16:00:40,718: Installing authselect-libs.x86_64 (289/404) 2023-01-03 16:00:40,718: Installing iputils.x86_64 (290/404) 2023-01-03 16:00:40,718: Installing dracut-network.x86_64 (291/404) 2023-01-03 16:00:40,719: Installing libxmlb.x86_64 (292/404) 2023-01-03 16:00:40,719: Installing gobject-introspection.x86_64 (293/404) 2023-01-03 16:00:40,719: Installing python3-gobject-base.x86_64 (294/404) 2023-01-03 16:00:40,719: Installing libuser.x86_64 (295/404) 2023-01-03 16:00:40,719: Installing libsecret.x86_64 (296/404) 2023-01-03 16:00:40,719: Installing pinentry.x86_64 (297/404) 2023-01-03 16:00:40,719: Installing gnupg2-smime.x86_64 (298/404) 2023-01-03 16:00:40,719: Installing gnupg2.x86_64 (299/404) 2023-01-03 16:00:40,719: Installing gpgme.x86_64 (300/404) 2023-01-03 16:00:40,719: Installing librepo.x86_64 (301/404) 2023-01-03 16:00:40,720: Installing libdnf.x86_64 (302/404) 2023-01-03 16:00:40,720: Installing python3-libdnf.x86_64 (303/404) 2023-01-03 16:00:40,720: Installing python3-hawkey.x86_64 (304/404) 2023-01-03 16:00:40,720: Installing python3-gpg.x86_64 (305/404) 2023-01-03 16:00:40,720: Installing json-glib.x86_64 (306/404) 2023-01-03 16:00:40,720: Installing libgcab1.x86_64 (307/404) 2023-01-03 16:00:40,720: Installing dbus-glib.x86_64 (308/404) 2023-01-03 16:00:40,720: Installing python3-dbus.x86_64 (309/404) 2023-01-03 16:00:40,720: Installing libudisks2.x86_64 (310/404) 2023-01-03 16:00:40,720: Installing dracut-squash.x86_64 (311/404) 2023-01-03 16:00:40,721: Installing virt-what.x86_64 (312/404) 2023-01-03 16:00:40,721: Installing rpm-plugin-systemd-inhibit.x86_64 (313/404) 2023-01-03 16:00:40,721: Installing libsss_certmap.x86_64 (314/404) 2023-01-03 16:00:40,721: Installing tpm2-tss.x86_64 (315/404) 2023-01-03 16:00:40,721: Installing ima-evm-utils.x86_64 (316/404) 2023-01-03 16:00:40,722: Installing rpm-build-libs.x86_64 (317/404) 2023-01-03 16:00:40,722: Installing python3-rpm.x86_64 (318/404) 2023-01-03 16:00:40,722: Installing mokutil.x86_64 (319/404) 2023-01-03 16:00:40,722: Installing xfsprogs.x86_64 (320/404) 2023-01-03 16:00:40,722: Installing e2fsprogs.x86_64 (321/404) 2023-01-03 16:00:40,722: Installing sssd-client.x86_64 (322/404) 2023-01-03 16:00:40,722: Installing libatasmart.x86_64 (323/404) 2023-01-03 16:00:40,722: Installing plymouth-core-libs.x86_64 (324/404) 2023-01-03 16:00:40,723: Installing plymouth-scripts.x86_64 (325/404) 2023-01-03 16:00:40,723: Installing plymouth.x86_64 (326/404) 2023-01-03 16:00:40,723: Installing nss-sysinit.x86_64 (327/404) 2023-01-03 16:00:40,723: Installing nss.x86_64 (328/404) 2023-01-03 16:00:40,723: Installing volume_key-libs.x86_64 (329/404) 2023-01-03 16:00:40,723: Installing libblockdev-crypto.x86_64 (330/404) 2023-01-03 16:00:40,723: Installing udisks2.x86_64 (331/404) 2023-01-03 16:00:40,723: Installing fwupd.x86_64 (332/404) 2023-01-03 16:00:40,723: Installing grub2-efi-x64.x86_64 (333/404) 2023-01-03 16:00:40,723: Installing shim-x64.x86_64 (334/404) 2023-01-03 16:00:40,724: Installing teamd.x86_64 (335/404) 2023-01-03 16:00:40,724: Installing libnfsidmap.x86_64 (336/404) 2023-01-03 16:00:40,731: Installing sssd-nfs-idmap.x86_64 (337/404) 2023-01-03 16:00:40,732: Installing sssd-common.x86_64 (338/404) 2023-01-03 16:00:40,732: Installing python3-perf.x86_64 (339/404) 2023-01-03 16:00:40,732: Installing python3-syspurpose.x86_64 (340/404) 2023-01-03 16:00:40,732: Installing python3-nftables.x86_64 (341/404) 2023-01-03 16:00:40,732: Installing kernel-tools.x86_64 (342/404) 2023-01-03 16:00:40,732: Installing python3-libcomps.x86_64 (343/404) 2023-01-03 16:00:40,732: Installing python3-dnf.noarch (344/404) 2023-01-03 16:00:40,732: Installing dnf.noarch (345/404) 2023-01-03 16:00:40,732: Installing python3-dnf-plugins-core.noarch (346/404) 2023-01-03 16:00:40,732: Installing python3-libselinux.x86_64 (347/404) 2023-01-03 16:00:40,733: Installing python3-slip.noarch (348/404) 2023-01-03 16:00:40,733: Installing python3-slip-dbus.noarch (349/404) 2023-01-03 16:00:40,733: Installing python3-firewall.noarch (350/404) 2023-01-03 16:00:40,733: Installing libfastjson.x86_64 (351/404) 2023-01-03 16:00:40,733: Installing libestr.x86_64 (352/404) 2023-01-03 16:00:40,733: Installing rsyslog.x86_64 (353/404) 2023-01-03 16:00:40,733: Installing firewalld.noarch (354/404) 2023-01-03 16:00:40,733: Installing dnf-plugins-core.noarch (355/404) 2023-01-03 16:00:40,733: Installing yum.noarch (356/404) 2023-01-03 16:00:40,733: Installing tuned.noarch (357/404) 2023-01-03 16:00:40,734: Installing sssd-kcm.x86_64 (358/404) 2023-01-03 16:00:40,734: Installing NetworkManager-team.x86_64 (359/404) 2023-01-03 16:00:40,734: Installing kexec-tools.x86_64 (360/404) 2023-01-03 16:00:40,734: Installing wget.x86_64 (361/404) 2023-01-03 16:00:40,734: Installing passwd.x86_64 (362/404) 2023-01-03 16:00:40,734: Installing dracut-live.x86_64 (363/404) 2023-01-03 16:00:40,734: Installing authselect.x86_64 (364/404) 2023-01-03 16:00:40,734: Installing audit.x86_64 (365/404) 2023-01-03 16:00:40,734: Installing chrony.x86_64 (366/404) 2023-01-03 16:00:40,734: Installing openssh-clients.x86_64 (367/404) 2023-01-03 16:00:40,735: Installing openssh-server.x86_64 (368/404) 2023-01-03 16:00:40,735: Installing grub2-pc.x86_64 (369/404) 2023-01-03 16:00:40,735: Installing NetworkManager-tui.x86_64 (370/404) 2023-01-03 16:00:40,735: Installing kernel-modules-extra.x86_64 (371/404) 2023-01-03 16:00:40,735: Installing kernel.x86_64 (372/404) 2023-01-03 16:00:40,735: Installing microcode_ctl.x86_64 (373/404) 2023-01-03 16:00:40,735: Installing puppet-agent.x86_64 (374/404) 2023-01-03 16:00:40,735: Installing qemu-guest-agent.x86_64 (375/404) 2023-01-03 16:00:40,735: Installing irqbalance.x86_64 (376/404) 2023-01-03 16:00:40,736: Installing memtest86+.x86_64 (377/404) 2023-01-03 16:00:40,736: Installing sudo.x86_64 (378/404) 2023-01-03 16:00:40,736: Installing prefixdevname.x86_64 (379/404) 2023-01-03 16:00:40,736: Installing man-db.x86_64 (380/404) 2023-01-03 16:00:40,736: Installing almalinux-logos.x86_64 (381/404) 2023-01-03 16:00:40,736: Installing sg3_utils.x86_64 (382/404) 2023-01-03 16:00:40,736: Installing biosdevname.x86_64 (383/404) 2023-01-03 16:00:40,736: Installing efibootmgr.x86_64 (384/404) 2023-01-03 16:00:40,736: Installing lshw.x86_64 (385/404) 2023-01-03 16:00:40,736: Installing iprutils.x86_64 (386/404) 2023-01-03 16:00:40,737: Installing hostname.x86_64 (387/404) 2023-01-03 16:00:40,737: Installing lsscsi.x86_64 (388/404) 2023-01-03 16:00:40,737: Installing libsysfs.x86_64 (389/404) 2023-01-03 16:00:40,737: Installing langpacks-en.noarch (390/404) 2023-01-03 16:00:40,737: Installing iwl6050-firmware.noarch (391/404) 2023-01-03 16:00:40,737: Installing iwl5150-firmware.noarch (392/404) 2023-01-03 16:00:40,737: Installing iwl5000-firmware.noarch (393/404) 2023-01-03 16:00:40,737: Installing iwl1000-firmware.noarch (394/404) 2023-01-03 16:00:40,737: Installing rootfiles.noarch (395/404) 2023-01-03 16:00:40,737: Installing iwl6000-firmware.noarch (396/404) 2023-01-03 16:00:40,738: Installing iwl105-firmware.noarch (397/404) 2023-01-03 16:00:40,738: Installing iwl3160-firmware.noarch (398/404) 2023-01-03 16:00:40,738: Installing iwl7260-firmware.noarch (399/404) 2023-01-03 16:00:40,738: Installing iwl2030-firmware.noarch (400/404) 2023-01-03 16:00:40,738: Installing iwl6000g2a-firmware.noarch (401/404) 2023-01-03 16:00:40,738: Installing iwl2000-firmware.noarch (402/404) 2023-01-03 16:00:40,738: Installing iwl135-firmware.noarch (403/404) 2023-01-03 16:00:40,738: Installing iwl100-firmware.noarch (404/404) 2023-01-03 16:00:40,738: Performing post-installation setup tasks 2023-01-03 16:00:40,738: Configuring filesystem.x86_64 2023-01-03 16:00:40,739: Configuring crypto-policies-scripts.noarch 2023-01-03 16:00:40,739: Configuring ca-certificates.noarch 2023-01-03 16:00:40,739: Configuring kernel-core.x86_64 2023-01-03 16:00:40,739: Configuring kernel-modules.x86_64 2023-01-03 16:00:40,739: Configuring authselect-libs.x86_64 2023-01-03 16:00:40,739: Configuring nss.x86_64 2023-01-03 16:00:40,739: Configuring grub2-efi-x64.x86_64 2023-01-03 16:00:40,739: Configuring sssd-common.x86_64 2023-01-03 16:00:40,739: Configuring tuned.noarch 2023-01-03 16:00:40,739: Configuring microcode_ctl.x86_64 2023-01-03 16:00:40,739: Configuring puppet-agent.x86_64 2023-01-03 16:00:40,740: Configuring almalinux-logos.x86_64 2023-01-03 16:00:40,740: Configuring rootfiles.noarch 2023-01-03 16:00:40,740: Configuring glibc-common.x86_64 2023-01-03 16:00:40,740: Configuring info.x86_64 2023-01-03 16:00:52,265: Configuring glib2.x86_64 2023-01-03 16:00:52,266: Configuring glib2.x86_64 2023-01-03 16:00:52,266: Configuring shared-mime-info.x86_64 2023-01-03 16:00:52,266: Configuring systemd-udev.x86_64 2023-01-03 16:00:52,266: Configuring systemd-udev.x86_64 2023-01-03 16:00:52,266: Configuring systemd.x86_64 2023-01-03 16:00:52,266: Configuring systemd.x86_64 2023-01-03 16:00:52,267: Configuring systemd.x86_64 2023-01-03 16:00:52,267: Configuring systemd.x86_64 2023-01-03 16:00:52,267: Configuring systemd.x86_64 2023-01-03 16:00:52,268: Configuring man-db.x86_64 2023-01-03 16:00:52,268: Verifying initscripts.x86_64 (1/404) 2023-01-03 16:00:52,268: Verifying iwl100-firmware.noarch (2/404) 2023-01-03 16:00:52,269: Verifying kernel-tools-libs.x86_64 (3/404) 2023-01-03 16:00:52,269: Verifying libmodulemd.x86_64 (4/404) 2023-01-03 16:00:52,269: Verifying libarchive.x86_64 (5/404) 2023-01-03 16:00:52,269: Verifying dnf-data.noarch (6/404) 2023-01-03 16:00:52,270: Verifying libnsl2.x86_64 (7/404) 2023-01-03 16:00:52,270: Verifying iwl135-firmware.noarch (8/404) 2023-01-03 16:00:52,270: Verifying NetworkManager-tui.x86_64 (9/404) 2023-01-03 16:00:52,270: Verifying cronie-anacron.x86_64 (10/404) 2023-01-03 16:00:52,270: Verifying kmod-libs.x86_64 (11/404) 2023-01-03 16:00:52,271: Verifying tuned.noarch (12/404) 2023-01-03 16:00:52,271: Verifying gnupg2-smime.x86_64 (13/404) 2023-01-03 16:00:52,271: Verifying libgpg-error.x86_64 (14/404) 2023-01-03 16:00:52,271: Verifying dracut-live.x86_64 (15/404) 2023-01-03 16:00:52,272: Verifying libtdb.x86_64 (16/404) 2023-01-03 16:00:52,272: Verifying kernel-modules-extra.x86_64 (17/404) 2023-01-03 16:00:52,272: Verifying libgcrypt.x86_64 (18/404) 2023-01-03 16:00:52,272: Verifying basesystem.noarch (19/404) 2023-01-03 16:00:52,272: Verifying kbd.x86_64 (20/404) 2023-01-03 16:00:52,272: Verifying libldb.x86_64 (21/404) 2023-01-03 16:00:52,273: Verifying mozjs60.x86_64 (22/404) 2023-01-03 16:00:52,273: Verifying gobject-introspection.x86_64 (23/404) 2023-01-03 16:00:52,273: Verifying mpfr.x86_64 (24/404) 2023-01-03 16:00:52,273: Verifying python3-dnf.noarch (25/404) 2023-01-03 16:00:52,273: Verifying p11-kit.x86_64 (26/404) 2023-01-03 16:00:52,273: Verifying ncurses.x86_64 (27/404) 2023-01-03 16:00:52,274: Verifying libsss_certmap.x86_64 (28/404) 2023-01-03 16:00:52,274: Verifying audit-libs.x86_64 (29/404) 2023-01-03 16:00:52,274: Verifying iwl2000-firmware.noarch (30/404) 2023-01-03 16:00:52,274: Verifying krb5-libs.x86_64 (31/404) 2023-01-03 16:00:52,275: Verifying fuse-libs.x86_64 (32/404) 2023-01-03 16:00:52,276: Verifying python3-pip-wheel.noarch (33/404) 2023-01-03 16:00:52,276: Verifying trousers-lib.x86_64 (34/404) 2023-01-03 16:00:52,276: Verifying chrony.x86_64 (35/404) 2023-01-03 16:00:52,276: Verifying readline.x86_64 (36/404) 2023-01-03 16:00:52,276: Verifying libuser.x86_64 (37/404) 2023-01-03 16:00:52,277: Verifying device-mapper.x86_64 (38/404) 2023-01-03 16:00:52,277: Verifying grub2-tools-extra.x86_64 (39/404) 2023-01-03 16:00:52,277: Verifying lz4-libs.x86_64 (40/404) 2023-01-03 16:00:52,277: Verifying iwl6000g2a-firmware.noarch (41/404) 2023-01-03 16:00:52,278: Verifying microcode_ctl.x86_64 (42/404) 2023-01-03 16:00:52,278: Verifying coreutils-common.x86_64 (43/404) 2023-01-03 16:00:52,278: Verifying libsss_idmap.x86_64 (44/404) 2023-01-03 16:00:52,278: Verifying libsolv.x86_64 (45/404) 2023-01-03 16:00:52,278: Verifying NetworkManager.x86_64 (46/404) 2023-01-03 16:00:52,279: Verifying openssl-libs.x86_64 (47/404) 2023-01-03 16:00:52,279: Verifying efivar-libs.x86_64 (48/404) 2023-01-03 16:00:52,279: Verifying hostname.x86_64 (49/404) 2023-01-03 16:00:52,279: Verifying platform-python-pip.noarch (50/404) 2023-01-03 16:00:52,279: Verifying file.x86_64 (51/404) 2023-01-03 16:00:52,280: Verifying libsemanage.x86_64 (52/404) 2023-01-03 16:00:52,280: Verifying firewalld.noarch (53/404) 2023-01-03 16:00:52,280: Verifying rpm.x86_64 (54/404) 2023-01-03 16:00:52,280: Verifying bubblewrap.x86_64 (55/404) 2023-01-03 16:00:52,280: Verifying libselinux-utils.x86_64 (56/404) 2023-01-03 16:00:52,280: Verifying crontabs.noarch (57/404) 2023-01-03 16:00:52,281: Verifying elfutils-default-yama-scope.noarch (58/404) 2023-01-03 16:00:52,281: Verifying grub2-pc-modules.noarch (59/404) 2023-01-03 16:00:52,281: Verifying libteam.x86_64 (60/404) 2023-01-03 16:00:52,281: Verifying libgcc.x86_64 (61/404) 2023-01-03 16:00:52,281: Verifying jansson.x86_64 (62/404) 2023-01-03 16:00:52,281: Verifying libsecret.x86_64 (63/404) 2023-01-03 16:00:52,282: Verifying libsss_sudo.x86_64 (64/404) 2023-01-03 16:00:52,282: Verifying mtools.x86_64 (65/404) 2023-01-03 16:00:52,282: Verifying libfdisk.x86_64 (66/404) 2023-01-03 16:00:52,282: Verifying gettext.x86_64 (67/404) 2023-01-03 16:00:52,282: Verifying librepo.x86_64 (68/404) 2023-01-03 16:00:52,283: Verifying sed.x86_64 (69/404) 2023-01-03 16:00:52,283: Verifying gdbm.x86_64 (70/404) 2023-01-03 16:00:52,284: Verifying sssd-kcm.x86_64 (71/404) 2023-01-03 16:00:52,284: Verifying iptables.x86_64 (72/404) 2023-01-03 16:00:52,284: Verifying libtalloc.x86_64 (73/404) 2023-01-03 16:00:52,284: Verifying sssd-client.x86_64 (74/404) 2023-01-03 16:00:52,284: Verifying iwl2030-firmware.noarch (75/404) 2023-01-03 16:00:52,285: Verifying kernel-core.x86_64 (76/404) 2023-01-03 16:00:52,285: Verifying libnl3-cli.x86_64 (77/404) 2023-01-03 16:00:52,285: Verifying libgusb.x86_64 (78/404) 2023-01-03 16:00:52,285: Verifying popt.x86_64 (79/404) 2023-01-03 16:00:52,285: Verifying libedit.x86_64 (80/404) 2023-01-03 16:00:52,286: Verifying libssh.x86_64 (81/404) 2023-01-03 16:00:52,286: Verifying e2fsprogs.x86_64 (82/404) 2023-01-03 16:00:52,286: Verifying bzip2-libs.x86_64 (83/404) 2023-01-03 16:00:52,287: Verifying openssl-pkcs11.x86_64 (84/404) 2023-01-03 16:00:52,287: Verifying dnf.noarch (85/404) 2023-01-03 16:00:52,287: Verifying libassuan.x86_64 (86/404) 2023-01-03 16:00:52,287: Verifying cryptsetup-libs.x86_64 (87/404) 2023-01-03 16:00:52,287: Verifying glibc-langpack-en.x86_64 (88/404) 2023-01-03 16:00:52,287: Verifying teamd.x86_64 (89/404) 2023-01-03 16:00:52,288: Verifying libunistring.x86_64 (90/404) 2023-01-03 16:00:52,288: Verifying libuuid.x86_64 (91/404) 2023-01-03 16:00:52,288: Verifying cpio.x86_64 (92/404) 2023-01-03 16:00:52,288: Verifying syslinux.x86_64 (93/404) 2023-01-03 16:00:52,288: Verifying sg3_utils-libs.x86_64 (94/404) 2023-01-03 16:00:52,289: Verifying grub2-pc.x86_64 (95/404) 2023-01-03 16:00:52,289: Verifying virt-what.x86_64 (96/404) 2023-01-03 16:00:52,289: Verifying tpm2-tss.x86_64 (97/404) 2023-01-03 16:00:52,289: Verifying libselinux.x86_64 (98/404) 2023-01-03 16:00:52,289: Verifying iwl7260-firmware.noarch (99/404) 2023-01-03 16:00:52,289: Verifying iwl3160-firmware.noarch (100/404) 2023-01-03 16:00:52,290: Verifying e2fsprogs-libs.x86_64 (101/404) 2023-01-03 16:00:52,290: Verifying libutempter.x86_64 (102/404) 2023-01-03 16:00:52,291: Verifying python3-setuptools-wheel.noarch (103/404) 2023-01-03 16:00:52,292: Verifying gpgme.x86_64 (104/404) 2023-01-03 16:00:52,292: Verifying gnutls.x86_64 (105/404) 2023-01-03 16:00:52,292: Verifying filesystem.x86_64 (106/404) 2023-01-03 16:00:52,292: Verifying hdparm.x86_64 (107/404) 2023-01-03 16:00:52,292: Verifying ethtool.x86_64 (108/404) 2023-01-03 16:00:52,293: Verifying python3-slip.noarch (109/404) 2023-01-03 16:00:52,293: Verifying libcroco.x86_64 (110/404) 2023-01-03 16:00:52,293: Verifying parted.x86_64 (111/404) 2023-01-03 16:00:52,293: Verifying memstrack.x86_64 (112/404) 2023-01-03 16:00:52,293: Verifying mokutil.x86_64 (113/404) 2023-01-03 16:00:52,294: Verifying rpm-plugin-systemd-inhibit.x86_64 (114/404) 2023-01-03 16:00:52,294: Verifying shared-mime-info.x86_64 (115/404) 2023-01-03 16:00:52,294: Verifying biosdevname.x86_64 (116/404) 2023-01-03 16:00:52,294: Verifying passwd.x86_64 (117/404) 2023-01-03 16:00:52,295: Verifying libsmbios.x86_64 (118/404) 2023-01-03 16:00:52,295: Verifying libpipeline.x86_64 (119/404) 2023-01-03 16:00:52,295: Verifying xz-libs.x86_64 (120/404) 2023-01-03 16:00:52,295: Verifying less.x86_64 (121/404) 2023-01-03 16:00:52,295: Verifying dracut-squash.x86_64 (122/404) 2023-01-03 16:00:52,295: Verifying json-glib.x86_64 (123/404) 2023-01-03 16:00:52,296: Verifying pam.x86_64 (124/404) 2023-01-03 16:00:52,296: Verifying gnupg2.x86_64 (125/404) 2023-01-03 16:00:52,296: Verifying libcomps.x86_64 (126/404) 2023-01-03 16:00:52,296: Verifying elfutils-debuginfod-client.x86_64 (127/404) 2023-01-03 16:00:52,296: Verifying dmidecode.x86_64 (128/404) 2023-01-03 16:00:52,296: Verifying libpcap.x86_64 (129/404) 2023-01-03 16:00:52,297: Verifying pciutils-libs.x86_64 (130/404) 2023-01-03 16:00:52,297: Verifying ncurses-libs.x86_64 (131/404) 2023-01-03 16:00:52,297: Verifying ncurses-base.noarch (132/404) 2023-01-03 16:00:52,297: Verifying dracut-network.x86_64 (133/404) 2023-01-03 16:00:52,298: Verifying systemd-pam.x86_64 (134/404) 2023-01-03 16:00:52,298: Verifying libibverbs.x86_64 (135/404) 2023-01-03 16:00:52,298: Verifying kernel.x86_64 (136/404) 2023-01-03 16:00:52,298: Verifying python3-gpg.x86_64 (137/404) 2023-01-03 16:00:52,299: Verifying psmisc.x86_64 (138/404) 2023-01-03 16:00:52,299: Verifying almalinux-release.x86_64 (139/404) 2023-01-03 16:00:52,299: Verifying libref_array.x86_64 (140/404) 2023-01-03 16:00:52,299: Verifying elfutils-libelf.x86_64 (141/404) 2023-01-03 16:00:52,299: Verifying iwl105-firmware.noarch (142/404) 2023-01-03 16:00:52,299: Verifying lzo.x86_64 (143/404) 2023-01-03 16:00:52,300: Verifying dracut.x86_64 (144/404) 2023-01-03 16:00:52,300: Verifying setup.noarch (145/404) 2023-01-03 16:00:52,300: Verifying sssd-nfs-idmap.x86_64 (146/404) 2023-01-03 16:00:52,300: Verifying file-libs.x86_64 (147/404) 2023-01-03 16:00:52,300: Verifying curl.x86_64 (148/404) 2023-01-03 16:00:52,301: Verifying hwdata.noarch (149/404) 2023-01-03 16:00:52,301: Verifying freetype.x86_64 (150/404) 2023-01-03 16:00:52,302: Verifying efi-filesystem.noarch (151/404) 2023-01-03 16:00:52,302: Verifying python3-rpm.x86_64 (152/404) 2023-01-03 16:00:52,302: Verifying nftables.x86_64 (153/404) 2023-01-03 16:00:52,302: Verifying authselect.x86_64 (154/404) 2023-01-03 16:00:52,303: Verifying python3-six.noarch (155/404) 2023-01-03 16:00:52,303: Verifying prefixdevname.x86_64 (156/404) 2023-01-03 16:00:52,303: Verifying gmp.x86_64 (157/404) 2023-01-03 16:00:52,303: Verifying cronie.x86_64 (158/404) 2023-01-03 16:00:52,303: Verifying kexec-tools.x86_64 (159/404) 2023-01-03 16:00:52,303: Verifying xz.x86_64 (160/404) 2023-01-03 16:00:52,303: Verifying dbus-daemon.x86_64 (161/404) 2023-01-03 16:00:52,304: Verifying grub2-tools-minimal.x86_64 (162/404) 2023-01-03 16:00:52,304: Verifying libcollection.x86_64 (163/404) 2023-01-03 16:00:52,304: Verifying os-prober.x86_64 (164/404) 2023-01-03 16:00:52,304: Verifying iprutils.x86_64 (165/404) 2023-01-03 16:00:52,304: Verifying libevent.x86_64 (166/404) 2023-01-03 16:00:52,305: Verifying libpath_utils.x86_64 (167/404) 2023-01-03 16:00:52,305: Verifying python3-perf.x86_64 (168/404) 2023-01-03 16:00:52,305: Verifying linux-firmware.noarch (169/404) 2023-01-03 16:00:52,305: Verifying polkit-pkla-compat.x86_64 (170/404) 2023-01-03 16:00:52,305: Verifying libnghttp2.x86_64 (171/404) 2023-01-03 16:00:52,306: Verifying libtasn1.x86_64 (172/404) 2023-01-03 16:00:52,306: Verifying man-db.x86_64 (173/404) 2023-01-03 16:00:52,306: Verifying libkcapi-hmaccalc.x86_64 (174/404) 2023-01-03 16:00:52,306: Verifying crypto-policies-scripts.noarch (175/404) 2023-01-03 16:00:52,306: Verifying python3-libs.x86_64 (176/404) 2023-01-03 16:00:52,306: Verifying xfsprogs.x86_64 (177/404) 2023-01-03 16:00:52,307: Verifying libnl3.x86_64 (178/404) 2023-01-03 16:00:52,307: Verifying openssh.x86_64 (179/404) 2023-01-03 16:00:52,307: Verifying publicsuffix-list-dafsa.noarch (180/404) 2023-01-03 16:00:52,307: Verifying gettext-libs.x86_64 (181/404) 2023-01-03 16:00:52,307: Verifying iwl6000-firmware.noarch (182/404) 2023-01-03 16:00:52,307: Verifying python3-gobject-base.x86_64 (183/404) 2023-01-03 16:00:52,308: Verifying expat.x86_64 (184/404) 2023-01-03 16:00:52,308: Verifying libpwquality.x86_64 (185/404) 2023-01-03 16:00:52,308: Verifying dbus-tools.x86_64 (186/404) 2023-01-03 16:00:52,309: Verifying grub2-common.noarch (187/404) 2023-01-03 16:00:52,309: Verifying libxcrypt.x86_64 (188/404) 2023-01-03 16:00:52,309: Verifying libxml2.x86_64 (189/404) 2023-01-03 16:00:52,309: Verifying gdbm-libs.x86_64 (190/404) 2023-01-03 16:00:52,309: Verifying crypto-policies.noarch (191/404) 2023-01-03 16:00:52,310: Verifying cracklib.x86_64 (192/404) 2023-01-03 16:00:52,310: Verifying rpm-plugin-selinux.x86_64 (193/404) 2023-01-03 16:00:52,310: Verifying efibootmgr.x86_64 (194/404) 2023-01-03 16:00:52,310: Verifying NetworkManager-team.x86_64 (195/404) 2023-01-03 16:00:52,310: Verifying openssh-clients.x86_64 (196/404) 2023-01-03 16:00:52,310: Verifying libkcapi.x86_64 (197/404) 2023-01-03 16:00:52,311: Verifying util-linux.x86_64 (198/404) 2023-01-03 16:00:52,311: Verifying libcurl.x86_64 (199/404) 2023-01-03 16:00:52,311: Verifying libgomp.x86_64 (200/404) 2023-01-03 16:00:52,311: Verifying json-c.x86_64 (201/404) 2023-01-03 16:00:52,311: Verifying logrotate.x86_64 (202/404) 2023-01-03 16:00:52,311: Verifying libmnl.x86_64 (203/404) 2023-01-03 16:00:52,312: Verifying squashfs-tools.x86_64 (204/404) 2023-01-03 16:00:52,312: Verifying diffutils.x86_64 (205/404) 2023-01-03 16:00:52,312: Verifying kpartx.x86_64 (206/404) 2023-01-03 16:00:52,312: Verifying systemd-udev.x86_64 (207/404) 2023-01-03 16:00:52,312: Verifying cyrus-sasl-lib.x86_64 (208/404) 2023-01-03 16:00:54,724: Verifying audit.x86_64 (209/404) 2023-01-03 16:00:54,724: Verifying python3-decorator.noarch (210/404) 2023-01-03 16:00:54,725: Verifying libyaml.x86_64 (211/404) 2023-01-03 16:00:54,725: Verifying sqlite-libs.x86_64 (212/404) 2023-01-03 16:00:54,725: Verifying libtevent.x86_64 (213/404) 2023-01-03 16:00:54,725: Verifying sudo.x86_64 (214/404) 2023-01-03 16:00:54,725: Verifying snappy.x86_64 (215/404) 2023-01-03 16:00:54,726: Verifying hardlink.x86_64 (216/404) 2023-01-03 16:00:54,726: Verifying lsscsi.x86_64 (217/404) 2023-01-03 16:00:54,726: Verifying python3-syspurpose.x86_64 (218/404) 2023-01-03 16:00:54,726: Verifying rootfiles.noarch (219/404) 2023-01-03 16:00:54,726: Verifying kmod.x86_64 (220/404) 2023-01-03 16:00:54,726: Verifying openldap.x86_64 (221/404) 2023-01-03 16:00:54,726: Verifying libidn2.x86_64 (222/404) 2023-01-03 16:00:54,727: Verifying trousers.x86_64 (223/404) 2023-01-03 16:00:54,727: Verifying iptables-libs.x86_64 (224/404) 2023-01-03 16:00:54,727: Verifying c-ares.x86_64 (225/404) 2023-01-03 16:00:54,727: Verifying lshw.x86_64 (226/404) 2023-01-03 16:00:54,727: Verifying libcom_err.x86_64 (227/404) 2023-01-03 16:00:54,727: Verifying python3-dbus.x86_64 (228/404) 2023-01-03 16:00:54,728: Verifying sssd-common.x86_64 (229/404) 2023-01-03 16:00:54,728: Verifying libsss_autofs.x86_64 (230/404) 2023-01-03 16:00:54,728: Verifying ima-evm-utils.x86_64 (231/404) 2023-01-03 16:00:54,728: Verifying libbpf.x86_64 (232/404) 2023-01-03 16:00:54,728: Verifying libksba.x86_64 (233/404) 2023-01-03 16:00:54,728: Verifying libnetfilter_conntrack.x86_64 (234/404) 2023-01-03 16:00:54,729: Verifying libgcab1.x86_64 (235/404) 2023-01-03 16:00:54,729: Verifying rpm-build-libs.x86_64 (236/404) 2023-01-03 16:00:54,729: Verifying dbus-glib.x86_64 (237/404) 2023-01-03 16:00:54,729: Verifying ca-certificates.noarch (238/404) 2023-01-03 16:00:54,729: Verifying timedatex.x86_64 (239/404) 2023-01-03 16:00:54,729: Verifying libdb.x86_64 (240/404) 2023-01-03 16:00:54,730: Verifying python3-pyudev.noarch (241/404) 2023-01-03 16:00:54,730: Verifying libdnf.x86_64 (242/404) 2023-01-03 16:00:54,733: Verifying gdisk.x86_64 (243/404) 2023-01-03 16:00:54,733: Verifying tzdata.noarch (244/404) 2023-01-03 16:00:54,733: Verifying openssl.x86_64 (245/404) 2023-01-03 16:00:54,733: Verifying kbd-misc.noarch (246/404) 2023-01-03 16:00:54,733: Verifying procps-ng.x86_64 (247/404) 2023-01-03 16:00:54,734: Verifying python3-nftables.x86_64 (248/404) 2023-01-03 16:00:54,734: Verifying memtest86+.x86_64 (249/404) 2023-01-03 16:00:54,734: Verifying libattr.x86_64 (250/404) 2023-01-03 16:00:54,734: Verifying libacl.x86_64 (251/404) 2023-01-03 16:00:54,734: Verifying grub2-tools.x86_64 (252/404) 2023-01-03 16:00:54,734: Verifying kernel-tools.x86_64 (253/404) 2023-01-03 16:00:54,735: Verifying libsigsegv.x86_64 (254/404) 2023-01-03 16:00:54,735: Verifying libtirpc.x86_64 (255/404) 2023-01-03 16:00:54,735: Verifying libdb-utils.x86_64 (256/404) 2023-01-03 16:00:54,735: Verifying libblkid.x86_64 (257/404) 2023-01-03 16:00:54,735: Verifying shadow-utils.x86_64 (258/404) 2023-01-03 16:00:54,736: Verifying python3-libdnf.x86_64 (259/404) 2023-01-03 16:00:54,736: Verifying vim-minimal.x86_64 (260/404) 2023-01-03 16:00:54,736: Verifying shim-x64.x86_64 (261/404) 2023-01-03 16:00:54,736: Verifying grubby.x86_64 (262/404) 2023-01-03 16:00:54,736: Verifying lua-libs.x86_64 (263/404) 2023-01-03 16:00:54,736: Verifying grep.x86_64 (264/404) 2023-01-03 16:00:54,737: Verifying syslinux-nonlinux.noarch (265/404) 2023-01-03 16:00:54,737: Verifying newt.x86_64 (266/404) 2023-01-03 16:00:54,737: Verifying libini_config.x86_64 (267/404) 2023-01-03 16:00:54,737: Verifying nettle.x86_64 (268/404) 2023-01-03 16:00:54,737: Verifying brotli.x86_64 (269/404) 2023-01-03 16:00:54,737: Verifying rpm-libs.x86_64 (270/404) 2023-01-03 16:00:54,738: Verifying keyutils-libs.x86_64 (271/404) 2023-01-03 16:00:54,738: Verifying glibc-gconv-extra.x86_64 (272/404) 2023-01-03 16:00:54,738: Verifying libcap-ng.x86_64 (273/404) 2023-01-03 16:00:54,738: Verifying libpng.x86_64 (274/404) 2023-01-03 16:00:54,738: Verifying policycoreutils.x86_64 (275/404) 2023-01-03 16:00:54,738: Verifying libdaemon.x86_64 (276/404) 2023-01-03 16:00:54,739: Verifying yum.noarch (277/404) 2023-01-03 16:00:54,739: Verifying libpsl.x86_64 (278/404) 2023-01-03 16:00:54,739: Verifying python3-libcomps.x86_64 (279/404) 2023-01-03 16:00:54,739: Verifying iproute.x86_64 (280/404) 2023-01-03 16:00:54,739: Verifying elfutils-libs.x86_64 (281/404) 2023-01-03 16:00:54,739: Verifying sg3_utils.x86_64 (282/404) 2023-01-03 16:00:54,740: Verifying findutils.x86_64 (283/404) 2023-01-03 16:00:54,740: Verifying selinux-policy.noarch (284/404) 2023-01-03 16:00:54,740: Verifying zlib.x86_64 (285/404) 2023-01-03 16:00:54,740: Verifying iwl1000-firmware.noarch (286/404) 2023-01-03 16:00:54,740: Verifying numactl-libs.x86_64 (287/404) 2023-01-03 16:00:54,741: Verifying info.x86_64 (288/404) 2023-01-03 16:00:54,741: Verifying python3-slip-dbus.noarch (289/404) 2023-01-03 16:00:54,741: Verifying libnfsidmap.x86_64 (290/404) 2023-01-03 16:00:54,741: Verifying chkconfig.x86_64 (291/404) 2023-01-03 16:00:54,741: Verifying libsss_nss_idmap.x86_64 (292/404) 2023-01-03 16:00:54,741: Verifying polkit-libs.x86_64 (293/404) 2023-01-03 16:00:54,742: Verifying acl.x86_64 (294/404) 2023-01-03 16:00:54,742: Verifying python3-libselinux.x86_64 (295/404) 2023-01-03 16:00:54,742: Verifying glibc.x86_64 (296/404) 2023-01-03 16:00:54,742: Verifying python3-firewall.noarch (297/404) 2023-01-03 16:00:54,742: Verifying lmdb-libs.x86_64 (298/404) 2023-01-03 16:00:54,742: Verifying mdadm.x86_64 (299/404) 2023-01-03 16:00:54,743: Verifying libzstd.x86_64 (300/404) 2023-01-03 16:00:54,743: Verifying python3-dateutil.noarch (301/404) 2023-01-03 16:00:54,743: Verifying libsepol.x86_64 (302/404) 2023-01-03 16:00:54,743: Verifying libmetalink.x86_64 (303/404) 2023-01-03 16:00:54,743: Verifying cracklib-dicts.x86_64 (304/404) 2023-01-03 16:00:54,743: Verifying libseccomp.x86_64 (305/404) 2023-01-03 16:00:54,743: Verifying iwl5000-firmware.noarch (306/404) 2023-01-03 16:00:54,744: Verifying dosfstools.x86_64 (307/404) 2023-01-03 16:00:54,744: Verifying libgudev.x86_64 (308/404) 2023-01-03 16:00:54,744: Verifying libsmartcols.x86_64 (309/404) 2023-01-03 16:00:54,744: Verifying libbasicobjects.x86_64 (310/404) 2023-01-03 16:00:54,744: Verifying libxmlb.x86_64 (311/404) 2023-01-03 16:00:54,745: Verifying libcap.x86_64 (312/404) 2023-01-03 16:00:54,745: Verifying gzip.x86_64 (313/404) 2023-01-03 16:00:54,745: Verifying libverto.x86_64 (314/404) 2023-01-03 16:00:54,745: Verifying groff-base.x86_64 (315/404) 2023-01-03 16:00:54,745: Verifying grub2-efi-x64.x86_64 (316/404) 2023-01-03 16:00:54,745: Verifying slang.x86_64 (317/404) 2023-01-03 16:00:54,746: Verifying openssh-server.x86_64 (318/404) 2023-01-03 16:00:54,746: Verifying tar.x86_64 (319/404) 2023-01-03 16:00:54,746: Verifying selinux-policy-targeted.noarch (320/404) 2023-01-03 16:00:54,746: Verifying libnfnetlink.x86_64 (321/404) 2023-01-03 16:00:54,746: Verifying iwl5150-firmware.noarch (322/404) 2023-01-03 16:00:54,747: Verifying pcre.x86_64 (323/404) 2023-01-03 16:00:54,747: Verifying kbd-legacy.noarch (324/404) 2023-01-03 16:00:54,747: Verifying libdhash.x86_64 (325/404) 2023-01-03 16:00:54,747: Verifying libusbx.x86_64 (326/404) 2023-01-03 16:00:54,747: Verifying python3-linux-procfs.noarch (327/404) 2023-01-03 16:00:54,747: Verifying glibc-common.x86_64 (328/404) 2023-01-03 16:00:54,748: Verifying pigz.x86_64 (329/404) 2023-01-03 16:00:54,748: Verifying iptables-ebtables.x86_64 (330/404) 2023-01-03 16:00:54,748: Verifying libnftnl.x86_64 (331/404) 2023-01-03 16:00:54,748: Verifying polkit.x86_64 (332/404) 2023-01-03 16:00:54,748: Verifying coreutils.x86_64 (333/404) 2023-01-03 16:00:54,749: Verifying npth.x86_64 (334/404) 2023-01-03 16:00:54,749: Verifying ipset.x86_64 (335/404) 2023-01-03 16:00:54,749: Verifying python3-dnf-plugins-core.noarch (336/404) 2023-01-03 16:00:54,749: Verifying python3-hawkey.x86_64 (337/404) 2023-01-03 16:00:54,749: Verifying p11-kit-trust.x86_64 (338/404) 2023-01-03 16:00:54,749: Verifying irqbalance.x86_64 (339/404) 2023-01-03 16:00:54,750: Verifying libmount.x86_64 (340/404) 2023-01-03 16:00:54,750: Verifying dbus.x86_64 (341/404) 2023-01-03 16:00:54,750: Verifying kernel-modules.x86_64 (342/404) 2023-01-03 16:00:54,750: Verifying which.x86_64 (343/404) 2023-01-03 16:00:54,750: Verifying dbus-common.noarch (344/404) 2023-01-03 16:00:54,750: Verifying platform-python-setuptools.noarch (345/404) 2023-01-03 16:00:54,751: Verifying libreport-filesystem.x86_64 (346/404) 2023-01-03 16:00:54,751: Verifying libffi.x86_64 (347/404) 2023-01-03 16:00:54,751: Verifying fwupd.x86_64 (348/404) 2023-01-03 16:00:54,751: Verifying platform-python.x86_64 (349/404) 2023-01-03 16:00:54,751: Verifying libss.x86_64 (350/404) 2023-01-03 16:00:54,751: Verifying NetworkManager-libnm.x86_64 (351/404) 2023-01-03 16:00:54,752: Verifying systemd-libs.x86_64 (352/404) 2023-01-03 16:00:54,752: Verifying device-mapper-libs.x86_64 (353/404) 2023-01-03 16:00:54,752: Verifying libssh-config.noarch (354/404) 2023-01-03 16:00:54,752: Verifying firewalld-filesystem.noarch (355/404) 2023-01-03 16:00:54,753: Verifying iwl6050-firmware.noarch (356/404) 2023-01-03 16:00:54,753: Verifying dnf-plugins-core.noarch (357/404) 2023-01-03 16:00:54,753: Verifying bash.x86_64 (358/404) 2023-01-03 16:00:54,753: Verifying libstdc++.x86_64 (359/404) 2023-01-03 16:00:54,753: Verifying authselect-libs.x86_64 (360/404) 2023-01-03 16:00:54,753: Verifying systemd.x86_64 (361/404) 2023-01-03 16:00:54,754: Verifying pcre2.x86_64 (362/404) 2023-01-03 16:00:54,754: Verifying gawk.x86_64 (363/404) 2023-01-03 16:00:54,754: Verifying glib2.x86_64 (364/404) 2023-01-03 16:00:54,754: Verifying libndp.x86_64 (365/404) 2023-01-03 16:00:54,754: Verifying ipset-libs.x86_64 (366/404) 2023-01-03 16:00:54,755: Verifying libsysfs.x86_64 (367/404) 2023-01-03 16:00:54,755: Verifying iputils.x86_64 (368/404) 2023-01-03 16:00:54,755: Verifying dbus-libs.x86_64 (369/404) 2023-01-03 16:00:54,755: Verifying puppet-agent.x86_64 (370/404) 2023-01-03 16:00:54,755: Verifying rsyslog.x86_64 (371/404) 2023-01-03 16:00:54,755: Verifying libblockdev-part.x86_64 (372/404) 2023-01-03 16:00:54,756: Verifying qemu-guest-agent.x86_64 (373/404) 2023-01-03 16:00:54,756: Verifying nss-sysinit.x86_64 (374/404) 2023-01-03 16:00:54,756: Verifying plymouth.x86_64 (375/404) 2023-01-03 16:00:54,756: Verifying libblockdev-fs.x86_64 (376/404) 2023-01-03 16:00:54,756: Verifying nss-softokn.x86_64 (377/404) 2023-01-03 16:00:54,757: Verifying volume_key-libs.x86_64 (378/404) 2023-01-03 16:00:54,757: Verifying udisks2.x86_64 (379/404) 2023-01-03 16:00:54,757: Verifying libblockdev-loop.x86_64 (380/404) 2023-01-03 16:00:54,757: Verifying langpacks-en.noarch (381/404) 2023-01-03 16:00:54,757: Verifying libatasmart.x86_64 (382/404) 2023-01-03 16:00:54,758: Verifying python3-unbound.x86_64 (383/404) 2023-01-03 16:00:54,758: Verifying libblockdev-mdraid.x86_64 (384/404) 2023-01-03 16:00:54,758: Verifying wget.x86_64 (385/404) 2023-01-03 16:00:54,758: Verifying libxkbcommon.x86_64 (386/404) 2023-01-03 16:00:54,758: Verifying nss.x86_64 (387/404) 2023-01-03 16:00:54,758: Verifying libblockdev-swap.x86_64 (388/404) 2023-01-03 16:00:54,759: Verifying nspr.x86_64 (389/404) 2023-01-03 16:00:54,759: Verifying pinentry.x86_64 (390/404) 2023-01-03 16:00:54,759: Verifying libudisks2.x86_64 (391/404) 2023-01-03 16:00:54,759: Verifying nss-softokn-freebl.x86_64 (392/404) 2023-01-03 16:00:54,759: Verifying unbound-libs.x86_64 (393/404) 2023-01-03 16:00:54,760: Verifying libblockdev-utils.x86_64 (394/404) 2023-01-03 16:00:54,760: Verifying nss-util.x86_64 (395/404) 2023-01-03 16:00:54,760: Verifying libfastjson.x86_64 (396/404) 2023-01-03 16:00:54,760: Verifying plymouth-scripts.x86_64 (397/404) 2023-01-03 16:00:54,760: Verifying plymouth-core-libs.x86_64 (398/404) 2023-01-03 16:00:54,761: Verifying libbytesize.x86_64 (399/404) 2023-01-03 16:00:54,761: Verifying libestr.x86_64 (400/404) 2023-01-03 16:00:54,761: Verifying libblockdev-crypto.x86_64 (401/404) 2023-01-03 16:00:54,761: Verifying libblockdev.x86_64 (402/404) 2023-01-03 16:00:54,761: Verifying almalinux-logos.x86_64 (403/404) 2023-01-03 16:00:54,761: Verifying xkeyboard-config.noarch (404/404) 2023-01-03 16:00:54,943: . 2023-01-03 16:00:54,943: Installing boot loader 2023-01-03 16:00:55,000: .. 2023-01-03 16:00:55,001: Performing post-installation setup tasks 2023-01-03 16:00:56,017: . 2023-01-03 16:00:56,017: Configuring installed system 2023-01-03 16:01:01,296: ................... 2023-01-03 16:01:01,296: Creating users 2023-01-03 16:01:01,297: Configuring addons 2023-01-03 16:01:42,517: .. 2023-01-03 16:01:42,518: Generating initramfs 2023-01-03 16:01:42,652: ... 2023-01-03 16:01:42,653: Storing configuration files and kickstarts 2023-01-03 16:01:46,623: . 2023-01-03 16:01:46,624: Running post-installation scripts 2023-01-03 16:01:46,632: . 2023-01-03 16:01:46,632: Installation complete 2023-01-03 16:01:46,632: 2023-01-03 16:01:46,633: Use of this product is subject to the license agreement found at: 2023-01-03 16:01:46,633: /usr/share/almalinux-release/EULA 2023-01-03 16:01:46,633: 2023-01-03 16:02:04,482: Shutting down log processing 2023-01-03 16:02:07,150: Disk Image install successful 2023-01-03 16:02:07,151: SUMMARY 2023-01-03 16:02:07,151: ------- 2023-01-03 16:02:07,151: Logs are in /images/logs 2023-01-03 16:02:07,151: Disk image is at /images/el8-base/el8-base-2023.01.03-15.55.29.img 2023-01-03 16:02:07,152: Results are in /images/el8-base Image built successsfully! FAILURE: 2023-01-03 16:06:00,557: livemedia-creator v28.14.70-1 2023-01-03 16:06:00,557: selinux is enabled and in Permissive mode 2023-01-03 16:06:00,670: disk_img = /images/el8-base/el8-base-2023.01.03-16.05.56.img 2023-01-03 16:06:00,670: Using disk size of 4002MiB 2023-01-03 16:06:01,149: Running anaconda. 2023-01-03 16:06:07,645: Processing logs from ('127.0.0.1', 50176) 2023-01-03 16:06:07,827: Starting installer, one moment... 2023-01-03 16:06:07,827: terminal size detection failed, using default width 2023-01-03 16:06:07,828: anaconda 33.16.7.12-1.el8.alma for AlmaLinux 8 (pre-release) started. 2023-01-03 16:06:07,828: 16:06:07 Not asking for VNC because of an automated install 2023-01-03 16:06:07,828: 16:06:07 Not asking for VNC because we don't have Xvnc 2023-01-03 16:06:12,233: Starting automated install.. 2023-01-03 16:06:12,234: ================================================================================ 2023-01-03 16:06:12,234: ================================================================================ 2023-01-03 16:06:12,234: Installation 2023-01-03 16:06:12,234: 2023-01-03 16:06:12,234: 1) [x] Language settings 2) [x] Time settings 2023-01-03 16:06:12,235: (English (United States)) (US/Eastern timezone) 2023-01-03 16:06:12,235: 3) [x] Installation source 4) [x] Software selection 2023-01-03 16:06:12,235: (https://pkgrepo.prd.cbnls.net/p (Custom software selected) 2023-01-03 16:06:12,235: ulp/content/almalinux8-baseos/) 2023-01-03 16:06:12,235: 5) [ ] User creation 2023-01-03 16:06:12,236: (No user will be created) 2023-01-03 16:06:12,236: 2023-01-03 16:06:12,236: ================================================================================ 2023-01-03 16:06:12,236: ================================================================================ 2023-01-03 16:06:12,236: Progress 2023-01-03 16:06:12,236: 2023-01-03 16:06:12,237: Setting up the installation environment 2023-01-03 16:06:12,242: .. 2023-01-03 16:06:12,242: Configuring storage 2023-01-03 16:06:17,281: ... 2023-01-03 16:06:17,281: Running pre-installation scripts 2023-01-03 16:06:17,298: . 2023-01-03 16:06:17,298: Running pre-installation tasks 2023-01-03 16:09:19,934: .. 2023-01-03 16:09:19,935: Installing. 2023-01-03 16:09:19,935: Starting package installation process 2023-01-03 16:09:19,935: 2023-01-03 16:09:19,936: The installation was stopped due to an error which occurred while running in non-interactive cmdline mode. Since there cannot be any questions in cmdline mode, edit your kickstart file and retry installation. 2023-01-03 16:09:19,936: The exact error message is: 2023-01-03 16:09:19,936: 2023-01-03 16:09:19,936: Non interactive installation failed: Problems in request: 2023-01-03 16:09:19,937: missing packages: puppet-agent, system-logos, wget. 2023-01-03 16:09:19,937: 2023-01-03 16:09:19,937: The installer will now terminate. 2023-01-03 16:09:20,153: Running anaconda failed: process '['anaconda', '--kickstart', '/tmp/el8-flattened.ks', '--cmdline', '--loglevel', 'debug', '--dirinstall', '--remotelog', '127.0.0.1:56259']' exited with status 1 2023-01-03 16:09:20,155: Shutting down log processing 2023-01-03 16:09:20,178: Install failed: novirt_install failed 2023-01-03 16:09:20,179: Removing bad disk image 2023-01-03 16:09:20,179: ERROR: Image creation failed: novirt_install failed 2023-01-03 16:09:20,180: Image creation failed: novirt_install failed Error! It looks like the base image build has failed. |
||||
Tags: | |||||
Steps To Reproduce: |
Upgrade Anaconda from 8.6's version (33.16.6.7-1.el8.alma) to 8.7's version (33.16.7.12-1.el8.alma.x86_64) The livemedia-creator command called by our build script: livemedia-creator --project="${PROJECT}" --releasever=$RELEASEVER --resultdir=$DEST_DIR --image-name=el${RELEASEVER}-base-${TIMESTAMP}.img --no-virt --make-fsimage --image-only --ks=/tmp/el${RELEASEVER}-flattened.ks --logfile=${IMAGES_DIR}/logs/livemedia.log Flattened Kickstart: #version=DEVEL # Keyboard layouts keyboard --vckeymap=us --xlayouts='us' # Root password rootpw --plaintext t000r # System language lang en_US.UTF-8 # Shutdown after installation shutdown # System timezone timezone US/Eastern # Network information network --bootproto=dhcp --device=link --activate repo --name="epel" --baseurl=https://pkgrepo.prd.cbnls.net/pulp/content/epel-el8/ --noverifyssl --install repo --name="puppet7" --baseurl=https://pkgrepo.prd.cbnls.net/pulp/content/puppet7-el8/ --noverifyssl --install # Use network installation url --url="https://pkgrepo.prd.cbnls.net/pulp/content/almalinux8-baseos/" --noverifyssl # Firewall configuration firewall --disabled # SELinux configuration selinux --permissive # System bootloader configuration bootloader --location=mbr # Partition clearing information clearpart --all --initlabel # Disk partitioning information part / --fstype="ext4" --size=4000 %post # Remove random-seed rm /var/lib/systemd/random-seed # Clear /etc/machine-id rm /etc/machine-id rm /etc/hostname # grub must be perfect! cat <<EOF > /etc/default/grub GRUB_TIMEOUT=5 GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_CMDLINE_LINUX="readonlyroot console=tty1 console=ttyS0,115200n8" GRUB_DISABLE_RECOVERY="true" GRUB_TERMINAL="console serial" GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200" GRUB_DISABLE_OS_PROBER="true" EOF %end %packages @core curl dracut-live dracut-network efibootmgr grub2 grub2-efi grubby kernel kernel-modules kernel-modules-extra memtest86+ openssh-server puppet-agent shim syslinux system-logos tar wget -dracut-config-rescue %end |
||||
Additional Information: | |||||
Attached Files: |
almalinux-oci.tar.gz (879 bytes) 2023-10-13 15:33 https://bugs.almalinux.org/file_download.php?file_id=225&type=bug |
||||
Notes | |
(0000893)
lleonard-cbn 2023-05-15 22:55 |
Some extra information for this issue: using a `%post` script I can add the repos required into the `/etc/yum.repos.d` folder and then download the packages via a dnf install command. I was unable to otherwise get kickstart to install packages not present in the provided BaseOS repo. |
(0000983)
abotelho 2023-10-12 00:17 |
Looks like this is still happening on EL 8.8 |
(0000984)
abotelho 2023-10-13 15:33 |
looks like Stream 9 works fine with Lorax... related to https://bugs.almalinux.org/view.php?id=352 and https://chat.almalinux.org/almalinux/pl/tphq85nfrinxppyhfxa5f45byy i've attached a tar.gz of what's required to reproduce. on a Stream 9 box (you may have to set SELinux for permissive temporarily), make sure ```lorax``` and ```anaconda``` are installed, extract the tar.gz, and inside the almalinux-oci directory, provide a boot.iso and run ```livemedia-creator --make-oci --oci-config config.json --oci-runtime runtime.json --iso=boot.iso --ks=stream9.ks --no-virt --resultdir ./output```. this should work fine (and does for me) but on an AlmaLinux 9 box, ```livemedia-creator --make-oci --oci-config config.json --oci-runtime runtime.json --iso=boot.iso --ks=almalinux9.ks --no-virt --resultdir ./output``` doesn't work. i think this is likely the easiest way to reproduce this lorax/anaconda bug. there's gotta be something that was done that's causing every other repo except for the url repo to be ignored. |
(0000985)
abotelho 2023-10-13 19:35 |
i've found the problem! in our yum.conf, we have explicit enabled=0, so that repo files defined without an enabled=0/1 are disabled by default, not enabled. for security/predictability. it looks like Anaconda either had a bug that ignored this entry in our configuration for 8.6 and lower, or they simply stopped setting it for repos defined in Kickstarts. so we only saw this because we use --no-virt for the Lorax builds, and also have enable=0 in yum.conf |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
432 | [AlmaLinux-8] kernel | major | always | 2023-10-13 17:52 | 2023-10-13 17:52 |
Reporter: | sbhat | Platform: | Linux | ||
Assigned To: | OS: | Almalinux8 and 9 | |||
Priority: | high | OS Version: | 8.8 9.1 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Intermittent I/O block, timeout of disks in ZFS on Almalinux8 | ||||
Description: |
This is a continuation of https://bugs.almalinux.org/view.php?id=142 - We had ordered around 4 https://www.supermicro.com/en/products/accessories/addon/AOM-S3216-L-2.php hardwares and installed Almalinux 8 and 9 to Setup a ZFS pool for our Storage server need. However, the pool was failing with read and write errors exactly like previous bug: ``` [root@zfs-backup5:/backups/blahblah]$ zpool status | awk '$4 > 0' status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. NAME STATE READ WRITE CKSUM sde ONLINE 2 302 0 sdk ONLINE 3 234 0 errors: No known data errors [root@zfs-backup5:/backups/blahblah]$ ``` This is how errors look in dmesg: ``` Oct 4 12:52:55 zfs-backup5 kernel: sd 6:0:10:0: [sdk] tag#4183 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s Oct 4 12:52:55 zfs-backup5 kernel: sd 6:0:10:0: [sdk] tag#4183 CDB: Write(16) 8a 00 00 00 00 00 1d ca 72 d8 00 00 08 00 00 00 Oct 4 12:52:55 zfs-backup5 kernel: blk_update_request: I/O error, dev sdk, sector 499806936 op 0x1:(WRITE) flags 0x700 phys_seg 94 prio class 0 Oct 4 12:52:55 zfs-backup5 kernel: zio pool=backups vdev=/dev/sdk1 error=5 type=2 offset=255900102656 size=1048576 flags=40080c80 Oct 4 12:52:55 zfs-backup5 kernel: sd 6:0:10:0: attempting task abort!scmd(0x00000000000fbe3a), outstanding for 30395 ms & timeout 30000 ms Oct 4 12:52:55 zfs-backup5 kernel: sd 6:0:10:0: [sdk] tag#4120 CDB: Write(16) 8a 00 00 00 00 00 1d ca 82 d8 00 00 08 00 00 00 Oct 4 12:52:55 zfs-backup5 kernel: scsi target6:0:10: handle(0x001b), sas_address(0x5000c500ec42c8dd), phy(5) Oct 4 12:52:55 zfs-backup5 kernel: scsi target6:0:10: enclosure logical id(0x500304802ce92e00), slot(10) Oct 4 12:52:55 zfs-backup5 kernel: scsi target6:0:10: enclosure level(0x0000), connector name( ) Oct 4 12:52:55 zfs-backup5 kernel: sd 6:0:10:0: task abort: SUCCESS scmd(0x00000000000fbe3a) Oct 4 12:52:55 zfs-backup5 kernel: sd 6:0:10:0: [sdk] tag#4120 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s Oct 4 12:52:55 zfs-backup5 kernel: sd 6:0:10:0: [sdk] tag#4120 CDB: Write(16) 8a 00 00 00 00 00 1d ca 82 d8 00 00 08 00 00 00 Oct 4 12:52:55 zfs-backup5 kernel: blk_update_request: I/O error, dev sdk, sector 499811032 op 0x1:(WRITE) flags 0x700 phys_seg 99 prio class 0 Oct 4 12:52:55 zfs-backup5 kernel: zio pool=backups vdev=/dev/sdk1 error=5 type=2 offset=255902199808 size=1048576 flags=40080c80 Oct 4 12:53:25 zfs-backup5 kernel: sd 6:0:10:0: attempting task abort!scmd(0x00000000797d5399), outstanding for 60067 ms & timeout 60000 ms Oct 4 12:53:25 zfs-backup5 kernel: sd 6:0:10:0: [sdk] tag#4454 CDB: Log Sense 4d 00 4d 00 00 00 00 00 04 00 Oct 4 12:53:25 zfs-backup5 kernel: scsi target6:0:10: handle(0x001b), sas_address(0x5000c500ec42c8dd), phy(5) Oct 4 12:53:25 zfs-backup5 kernel: scsi target6:0:10: enclosure logical id(0x500304802ce92e00), slot(10) Oct 4 12:53:25 zfs-backup5 kernel: scsi target6:0:10: enclosure level(0x0000), connector name( ) Oct 4 12:53:25 zfs-backup5 kernel: sd 6:0:10:0: task abort: SUCCESS scmd(0x00000000797d5399) ``` 1. We cleaned up zfs pool, zfs packages and built a mdraid using all the HDDs and started hammering the storage using a cp command that would copy high number of 1Gb files into these storages. Everything completed fine, no errors in the EXT4 filesystem. 2. We cleaned up mdraid array and individually mounted each HDD as mount and started hammering the individual disk mounts using same method as #1. Everything completed fine, no errors in the EXT4 filesystem. 3. We rebuilt zfs pool without arc/log l2 cache setup and started storage test, we started seeing same errors. 4. We cleaned up zpool and rebuilt again and added arc/log l2 cache setup and started storage test, we started seeing the errors. Note: 4.1. While we were testing all 4 of above, we did change IO scheduler to `none` - we noticed only improvements of write speed on storage array but we still noticed errors on zfs pool 4.2 While we were testing, we did try various kernel versions, installed ZFS supported / recommended Kernel versions as well. Upgraded and Downgraded ZFS versions as well. 5. We disabled the pool sync setting (zfs set sync=disabled backups) and tried to test storage and read/write errors still occurred. Same when we disabled this interrupt setting (/sys/firmware/acpi/interrupts/gpe6C) no improvements. 6. We confirmed pool ashift setting (12) is good and is recommended by checking the disk (zdb -e backups /dev/sda) 7. We installed kernel-ml kernel but a suitable ZFS package or a zfs_kmod were not available to add to the kernel - we read its not worth using ZFS on kernel-ml on ML or LT. So we wanted to go for Alma9 testing. 8. ZFS version we tried with Alma9 and 9 are 2.1.12-1 and 2.1.13-1. All 4 HW we got had ` LSI SAS3216 PCI-Express Fusion-MPT SAS-3 (rev 01)` controllers in them. It looks like to me, Almalinux mpt3sas driver is not working correctly with Broadcom Controllers and there seem to be stability issues. |
||||
Tags: | alma8, alma9, cmdblock, controllers, lsi, zfs | ||||
Steps To Reproduce: |
1. Get a Hardware with LSI SAS3216 PCI-Express Fusion-MPT SAS-3 (rev 01) controller. 2. Install Alma8 or 9 and install ZFS, create a zpool. 3. Do as much as copies of data. You will see IO blocked and controller freaking out. |
||||
Additional Information: | We installed Ubuntu 22 and ZFS and everything worked perfectly fine. No errors. We are planning to adopt Ubuntu + ZFS setup for our backup infra. However, as a big RHEL/Almalinux/opensource fan, I wanted to report this so someone would try debug, improve the drivers or work with ZFS may be so AlmaLinux could also be a playground for ZFS lovers and ZFS could be a storage opportunity for AlmaLinux fans. | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
431 | [AlmaLinux-8] grubby | trivial | always | 2023-10-13 10:52 | 2023-10-13 11:33 |
Reporter: | sector-one | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | low | OS Version: | |||
Status: | confirmed | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Manpage of grubby(8) referes to wrong UEFI boot loader configuration file | ||||
Description: | The manpage of grubby(8) names /boot/efi/EFI/redhat/grub.cfg as boot loader configuration file while on AlmaLinux 8 & 9 (both are affected) it is actually /boot/efi/EFI/almalinux/grub.cfg | ||||
Tags: | |||||
Steps To Reproduce: |
On AlmaLinux 8.8 on x76_64 in UEFI mode # rpm -q --qf '%{nevra}\n' grubby grubby-8.40-47.el8.x86_64 # find /boot/efi/EFI/ -type f -name grub.cfg /boot/efi/EFI/almalinux/grub.cfg # man -s 8 grubby | grep -Po '/boot/efi/EFI/\S+' /boot/efi/EFI/redhat/grub.cfg. |
||||
Additional Information: |
Code reference for AlmaLinux 8 https://git.almalinux.org/rpms/grubby/src/commit/280685e9ea4faef5a570b1516ce38d8b0f5acee5/SOURCES/grubby.8#L25 Code reference for AlmaLinux 9 https://git.almalinux.org/rpms/grubby/src/commit/3db459f407cd87b01b945e7760111460751e124b/SOURCES/grubby.8#L25 |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
425 | [AlmaLinux-8] linux-firmware | major | always | 2023-09-12 10:44 | 2023-09-28 13:01 |
Reporter: | oneuponatime | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AMD Genoa won't boot with latest linux-firmware | ||||
Description: |
OS won't boot (blank screen after kernel selection) when using latest linux-firmware version (linux-firmware-20230404-114.git2e92a49f.el8_8.alma.1.noarch) on AMD Genoa CPUs (tested on Lenovo SR635v3). Downgrading to linux-firmware-20230404-114.git2e92a49f.el8_8.alma.noarch fixes an issue. I tried upgrading kernel to latest version and it doesn't help. When running latest linux-firmware, OS will only boot if I select rescue image. I tried booting in debug mode, but there is no info or I'm doing it wrong (I was using https://access.redhat.com/solutions/28921). OS: AlmaLinux 8 (upgraded to latest packages) Hardware: Lenovo SR635v3 with latest stable FW patches |
||||
Tags: | |||||
Steps To Reproduce: |
- modern server with AMD Genoa CPU (tested on Lenovo SR635v3) - upgrade linux-firmware to linux-firmware-20230404-114.git2e92a49f.el8_8.alma.1.noarch - reboot server - after grub, there is only blank screen and system hangs |
||||
Additional Information: |
# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 48 On-line CPU(s) list: 0-47 Thread(s) per core: 2 Core(s) per socket: 24 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD BIOS Vendor ID: Advanced Micro Devices, Inc. CPU family: 25 Model: 17 Model name: AMD EPYC 9254 24-Core Processor BIOS Model name: AMD EPYC 9254 24-Core Processor Stepping: 1 CPU MHz: 2900.000 CPU max MHz: 4151.7568 CPU min MHz: 1500.0000 BogoMIPS: 5790.99 Virtualization: AMD-V L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 32768K NUMA node0 CPU(s): 0-47 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local avx512_bf16 clzero irperf xsaveerptr wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid overflow_recov succor smca fsrm flush_l1d |
||||
Attached Files: | |||||
Notes | |
(0000976)
jonathan 2023-09-12 15:42 |
I have not seen this on EPYC 9354P machines. Will do some more testing on them to see if I can find any relevant logs/messages/etc. |
(0000977)
oneuponatime 2023-09-14 14:32 |
I will be able to do some more debuging tomorrow and on monday. Will report. |
(0000980)
oneuponatime 2023-09-25 20:08 |
I upgraded the server to: UEFI: 2.11 KAE112O (latest version at the moment) XCC: 2.13 KAX318X (latest version at the moment) Kernel: kernel-4.18.0-477.27.1.el8_8.x86_64 Linux firmware: 20230404-114.git2e92a49f.el8_8.alma.1 This is now booting and working as expected. |
(0000981)
alukoshko 2023-09-28 12:10 |
Great news |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
429 | [AlmaLinux-8] kernel | major | always | 2023-09-25 23:55 | 2023-09-25 23:55 |
Reporter: | alufmtl | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Quotas with EXT4 on AlmaLinux do not get enacted on MD-RAID1 | ||||
Description: |
- |
||||
Tags: | |||||
Steps To Reproduce: |
I tested an instance in Vmware(with a vanilla installation of AlmaLinux 8.8), and I can confirm that -- for some unknown reason -- I don't need to enable the feature "quota" in ext4. "dumpe2fs -h /dev/md__" in my Vmware informs me there is no "quota" feature, though "quotacheck -ucm -F vfsv1 /" passes. And I can then proceed to using "edquota -u _user_" successfully. I can replicate the same issue again and again with ext4 on md-raid1. in contrary to redhat's official documentation regarding quotas, the redhat site states that "quota" should be enabled in "ext4". ^ So I suppose this is a bug, because here on AlmaLinux, enabling "quota" as a feature in EXT4(and on MD-RAID1), it is preventing the quotas from working. Tested with these two forms in /etcf/fstab -- using stock kernel 4.18.0-477.27.1.el8_8.x86_64 form 1) UUID=__ / ext4 defaults,usrquota,grpquota 0 1 form 2) UUID=__ / ext4 defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 0 1 and both are successful. (after applying "quotacheck -cmgu -F vfsv1 / , and later testing with edquota -u user) question: why would "edquota" only work after disabling or not enabling at all "quota" feature embedded into the ext4 metadata? ^ this 100% contradicts the redhat documentation. please take a look. thanks |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
428 | [AlmaLinux-8] -OTHER | block | always | 2023-09-23 13:02 | 2023-09-23 13:02 |
Reporter: | neilrieck | Platform: | HP DL385p_gen8 | ||
Assigned To: | OS: | Rocky | |||
Priority: | normal | OS Version: | 8.8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | During the leapp migration from Rocky-8.8 to 9.0 the process fails during the "leap update" | ||||
Description: |
excerpt from: leapp-upgrade.log =============================== Error: Transaction test error: file /usr/share/redhat-logos from install of rocky-logos-90.14-1.el9.x86_64 conflicts with file from package rocky-logos-86.3-1.el 8.x86_64 =============================== but unlike other package conflicts (like make-devel), this package cannot be erased (need plymouth on boot) |
||||
Tags: | elevate, leapp | ||||
Steps To Reproduce: | Just follow the pushed instructions | ||||
Additional Information: | none | ||||
Attached Files: |
leapp-rocky-88.txt (1,994 bytes) 2023-09-23 13:02 https://bugs.almalinux.org/file_download.php?file_id=222&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
423 | [AlmaLinux-8] ceph | major | always | 2023-08-29 11:25 | 2023-08-29 13:42 |
Reporter: | aboschke | Platform: | |||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | high | OS Version: | 8 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Missing CentOS Storage SIG - Ceph 18 reef | ||||
Description: |
When will centos-release-ceph-reef be available? I've noticed it's been available for a bit from CBS: [ https://cbs.centos.org/koji/packageinfo?packageID=11271 ] REF: [ https://wiki.almalinux.org/repos/CentOS.html#storage-sig ] |
||||
Tags: | |||||
Steps To Reproduce: |
# cat /etc/redhat-release AlmaLinux release 8.8 (Sapphire Caracal) # dnf search centos-release-ceph-reef Last metadata expiration check: 0:28:49 ago on Tue 29 Aug 2023 03:55:39 AM PDT. No matches found. |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000970)
alukoshko 2023-08-29 13:42 |
Thanks for pointing this out. Package released and soon will be on mirrors https://repo.almalinux.org/almalinux/8/extras/x86_64/os/Packages/centos-release-ceph-reef-1.0-1.el8.noarch.rpm |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
419 | [AlmaLinux-8] linux-firmware | major | always | 2023-08-10 15:30 | 2023-08-29 06:59 |
Reporter: | alukoshko | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | high | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux 8 is affected by CVE-2023-20569 | ||||
Description: | AMD CPU microcode update is required in linux-firmware package | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20569 | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
420 | [AlmaLinux-8] microcode_ctl | major | always | 2023-08-10 15:31 | 2023-08-29 06:59 |
Reporter: | alukoshko | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | high | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux 8 is affected by CVE-2022-40982 aka Downfall | ||||
Description: | Intel CPU microcode update is required in microcode_ctl package | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40982 | ||||
Attached Files: | |||||
Notes | |
(0000956)
4sokol 2023-08-14 19:32 |
lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 2 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 140 Model name: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Stepping: 1 CPU MHz: 2803.200 BogoMIPS: 5606.40 Virtualization: VT-x Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 4096K L3 cache: 16384K NUMA node0 CPU(s): 0,1 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid movdiri movdir64b fsrm avx512_vp2intersect md_clear arch_capabilities ------------------------------------------------------------------------------------------------------------ journalctl -k --grep=microcode -- Logs begin at Mon 2023-08-14 21:31:40 CEST, end at Mon 2023-08-14 21:32:25 CEST. -- -- No entries -- |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
410 | [AlmaLinux-8] junit | major | always | 2023-07-18 15:03 | 2023-08-28 11:30 |
Reporter: | cloph | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | high | OS Version: | |||
Status: | confirmed | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | impossible to install junit via repo manager, have to manually download and install | ||||
Description: |
the repository definitions likely are corrupt or something, since junit (and hamcrest-core for that matter) don't show up in the repository/are out of view for dnf/yum and cannot be installed using the repositories major severity since broken repositories are about the worst experience you can have when setting up a system and certainly |
||||
Tags: | not-a-bug | ||||
Steps To Reproduce: |
# dnf repoquery --refresh junit AlmaLinux 8 - BaseOS 6.6 kB/s | 3.8 kB 00:00 AlmaLinux 8 - AppStream 7.8 kB/s | 4.1 kB 00:00 AlmaLinux 8 - Extras 7.3 kB/s | 3.8 kB 00:00 AlmaLinux 8 - PowerTools 8.2 kB/s | 4.1 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 # → no result # dnf repoquery --refresh -f /usr/share/java/junit.jar AlmaLinux 8 - BaseOS 7.0 kB/s | 3.8 kB 00:00 AlmaLinux 8 - AppStream 7.3 kB/s | 4.1 kB 00:00 AlmaLinux 8 - Extras 5.6 kB/s | 3.8 kB 00:00 AlmaLinux 8 - PowerTools 8.4 kB/s | 4.1 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 # same, also no result. |
||||
Additional Information: |
wget https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/Packages/junit-4.12-14.module_el8.3.0+2043+807b4491.noarch.rpm https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/Packages/hamcrest-core-1.3-29.module_el8.3.0+2043+807b4491.noarch.rpm and installing the manually downloaded rpms works. |
||||
Attached Files: | |||||
Notes | |
(0000948)
alukoshko 2023-08-03 21:20 |
Hi. Mentioned packages are part of eclipse dnf module which is disabled by default. RHEL has the same modules configuration. Run: dnf module enable eclipse After that packages will be available. |
(0000963)
cloph 2023-08-28 11:29 |
Thanks for the reply - misunderstood the settings apparently – no notification mail despite "E-mail on Note Added [x] With Minimum Severity of any" .... guess you have to explicitly monitor a ticket for that... If it is part of another repo/configuration, why is it part of the AppStream directory tree then? Because I had appstream enabled and the files are what looks like part of AppStream is what had me convinced it is a bug in the repos and not a PEBCAK error... Anyhow, it is as you wrote, after enabling eclipse module/repo the packages show up, so feel free to mark the ticket as resolved (I don't see an obvious way to to so myself, I can "monitor" or "clone" and add tags and new comments/notes, but doesn't seem I can change any of the fields other than that) |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
411 | [AlmaLinux-8] ipa | block | always | 2023-07-19 07:48 | 2023-08-08 08:11 |
Reporter: | adelton | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | ipa-server-install fails with [error] RuntimeError: Failed to initialize kerberos container | ||||
Description: |
When running ipa-server-install in an AlmaLinux 8-based container, the process stops at Configuring Kerberos KDC (krb5kdc) [1/10]: adding kerberos container to the directory [2/10]: configuring KDC [3/10]: initialize kerberos container [error] RuntimeError: Failed to initialize kerberos container Failed to initialize kerberos container The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information The /var/log/ipaserver-install.log then ends with 2023-07-19T07:38:22Z DEBUG args=['kdb5_util', 'create', '-s', '-r', 'EXAMPLE.TEST', '-x', 'ipa-setup-override-restrictions'] 2023-07-19T07:38:22Z DEBUG Process finished, return code=1 2023-07-19T07:38:22Z DEBUG stdout=Loading random data Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.TEST', master key name 'K/M@EXAMPLE.TEST' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify: 2023-07-19T07:38:22Z DEBUG stderr=kdb5_util: Unable to load requested database module 'ipadb.so': plugin symbol 'kdb_function_table' not found while creating database '/var/kerberos/krb5kdc/principal' 2023-07-19T07:38:22Z DEBUG kdb5_util failed with CalledProcessError(Command ['kdb5_util', 'create', '-s', '-r', 'EXAMPLE.TEST', '-x', 'ipa-setup-override-restrictions'] returned non-zero exit status 1: "kdb5_util: Unable to load requested database module 'ipadb.so': plugin symbol 'kdb_function_table' not found while creating database '/var/kerberos/krb5kdc/principal'\n") 2023-07-19T07:38:22Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/ipaserver/install/krbinstance.py", line 358, in __init_ipa_kdb ipautil.run(args, nolog=(self.master_password,), stdin=''.join(dialogue)) File "/usr/lib/python3.6/site-packages/ipapython/ipautil.py", line 600, in run p.returncode, arg_string, output_log, error_log ipapython.ipautil.CalledProcessError: CalledProcessError(Command ['kdb5_util', 'create', '-s', '-r', 'EXAMPLE.TEST', '-x', 'ipa-setup-override-restrictions'] returned non-zero exit status 1: "kdb5_util: Unable to load requested database module 'ipadb.so': plugin symbol 'kdb_function_table' not found while creating database '/var/kerberos/krb5kdc/principal'\n") During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line 635, in start_creation run_step(full_msg, method) File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line 621, in run_step method() File "/usr/lib/python3.6/site-packages/ipaserver/install/krbinstance.py", line 361, in __init_ipa_kdb raise RuntimeError("Failed to initialize kerberos container") RuntimeError: Failed to initialize kerberos container 2023-07-19T07:38:22Z DEBUG [error] RuntimeError: Failed to initialize kerberos container 2023-07-19T07:38:22Z DEBUG File "/usr/lib/python3.6/site-packages/ipapython/admintool.py", line 180, in execute return_value = self.run() File "/usr/lib/python3.6/site-packages/ipapython/install/cli.py", line 344, in run return cfgr.run() File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 360, in run return self.execute() File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 386, in execute for rval in self._executor(): File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, in __runner exc_handler(exc_info) File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 460, in _handle_execute_exception self._handle_exception(exc_info) File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, in __runner step() File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 418, in <lambda> step = lambda: next(self.__gen) File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 655, in _configure next(executor) File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, in __runner exc_handler(exc_info) File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 460, in _handle_execute_exception self._handle_exception(exc_info) File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 518, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 515, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, in __runner step() File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 418, in <lambda> step = lambda: next(self.__gen) File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python3.6/site-packages/ipapython/install/common.py", line 65, in _install for unused in self._installer(self.parent): File "/usr/lib/python3.6/site-packages/ipaserver/install/server/__init__.py", line 566, in main master_install(self) File "/usr/lib/python3.6/site-packages/ipaserver/install/server/install.py", line 278, in decorated func(installer) File "/usr/lib/python3.6/site-packages/ipaserver/install/server/install.py", line 890, in install subject_base=options.subject_base) File "/usr/lib/python3.6/site-packages/ipaserver/install/krbinstance.py", line 215, in create_instance self.start_creation() File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line 635, in start_creation run_step(full_msg, method) File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line 621, in run_step method() File "/usr/lib/python3.6/site-packages/ipaserver/install/krbinstance.py", line 361, in __init_ipa_kdb raise RuntimeError("Failed to initialize kerberos container") 2023-07-19T07:38:22Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Failed to initialize kerberos container 2023-07-19T07:38:22Z ERROR Failed to initialize kerberos container 2023-07-19T07:38:22Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information This is with # rpm -qf /usr/lib64/krb5/plugins/kdb/ipadb.so ipa-server-4.9.11-6.module_el8.8.0+3588+9db6b15f.alma.x86_64 |
||||
Tags: | |||||
Steps To Reproduce: |
I believe that even on non-container installation, merely running ipa-server-install -U -r EXAMPLE.TEST -n example.test -p Secret123 -a Secret123 should trigger the issue. Alternatively, in a checkout directory of https://github.com/freeipa/freeipa-container, run tests/run-partial-tests.sh Dockerfile.almalinux-8 |
||||
Additional Information: |
First reported in https://github.com/freeipa/freeipa-container/actions/runs/5595030145/jobs/10230607540. The previous run https://github.com/freeipa/freeipa-container/actions/runs/5571782333/jobs/10177165151 which used ipa-server-4.9.11-5.module_el8.8.0+3473+3c8c1b4b worked fine. |
||||
Attached Files: | |||||
Notes | |
(0000943)
nbrys 2023-08-03 07:28 |
Hi, Yesterday we have hit the same issue with our production IPA setup. On of our servers updated the package to ipa-server-4.9.11-6.module_el8.8.0+3588+9db6b15f.alma.x86_64 after which IPA failed to start with the following error: [root@ipa4 log]# ipactl status Directory Service: STOPPED Directory Service must be running in order to obtain status of other services without this one starting I cannot do much Aug 02 11:58:37 ipa4.ipa.internal krb5kdc[21747](Error): Unable to load requested database module 'ipadb.so': plugin symbol 'kdb_function_table' not found - while initializing database for realm IPA.internal |
(0000944)
Hitamashi 2023-08-03 07:37 |
I have another issue with an installation on VM. Tried to setup a replica with ipa-replica-install but it says krb5kdc service failed to start [5/5]: configuring KDC to start on boot Done configuring Kerberos KDC (krb5kdc). Configuring kadmin [1/2]: starting kadmin [error] CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'restart', 'kadmin.service'] returned non-zero exit status 1: 'Job for kadmin.service failed because the control process exited with error code.\nSee "systemctl status kadmin.service" and "journalctl -xe" for details.\n') Found an error line: krb5kdc[10690](Error): Unable to load requested database module 'ipadb.so': plugin symbol 'kdb_function_table' not found - while initializing database for realm ABC When go back to 4.9.11-5. It works fine |
(0000946)
alukoshko 2023-08-03 14:10 |
Thanks for pointing this out. I'll check. |
(0000947)
alukoshko 2023-08-03 15:16 |
latest ipa-server relies on latest krb5 packages and it seems like this run happened without them for some reason: https://github.com/freeipa/freeipa-container/actions/runs/5595030145/jobs/10230607540 Latest runs look fine. Please check that you have latest krb5 packages: # rpm -q krb5-libs krb5-libs-1.18.2-25.el8_8.x86_64 I can't reproduce issue with latest krb5-libs but immediately got issues with kadmin.service after downgrading. I'll update ipa package to depend on proper krb5 version so this will not happen with partial updates when ipa is latest and krb5 is not. |
(0000951)
Hitamashi 2023-08-04 03:40 |
On the server we have the issue: # rpm -q krb5-libs krb5-libs-1.18.2-22.el8_7.x86_64 Tested with a fresh installation (on another server) the latest krb5-libs is upgraded to latest Upgrade krb5-libs-1.18.2-25.el8_8.x86_64 @baseos Upgraded krb5-libs-1.18.2-22.el8_7.x86_64 @@System Probably it is as you said, krb5-libs is not upgraded in partial update |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
175 | [AlmaLinux-8] -OTHER | feature | always | 2022-01-22 08:35 | 2023-08-08 08:11 |
Reporter: | gattadoit | Platform: | Raspberry pi | ||
Assigned To: | alukoshko | OS: | Almalinux | ||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Raspberry pi 400 WiFi issue | ||||
Description: | Almalinux and GUI load with no issue. The WiFi shows enabled. I do not see any networks. | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000854)
metalefty 2023-04-13 02:19 |
I think this is because Pi 400 uses different WiFi chip from Pi 4 series. Pi 4 uses brcmfmac43455 but Pi 400 uses brcmfmac43456. Unfortunately, firmware for 43456 is not included in linux-firmware package even now Apr 2023. $ cd /lib/firmware/brcm; ls |grep -i raspberry brcmfmac43430-sdio.raspberrypi,3-model-b.txt.xz brcmfmac43430-sdio.raspberrypi,model-zero-w.txt.xz brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt.xz brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi Compute Module 4.txt.xz brcmfmac43455-sdio.raspberrypi,3-model-a-plus.txt.xz brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt.xz brcmfmac43455-sdio.raspberrypi,4-model-b.txt.xz |
(0000856)
metalefty 2023-04-13 08:08 |
Putting proper firmware in /lib/firmware/brcm will enable Wi-Fi. See this: https://github.com/AlmaLinux/raspberry-pi/issues/23 |
(0000953)
metalefty 2023-08-07 07:50 |
Resolved in 20230615 image. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
406 | [AlmaLinux-8] open-vm-tools | major | always | 2023-06-30 09:03 | 2023-07-14 11:59 |
Reporter: | liberodark | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Fix CVE-2023-20867 | ||||
Description: |
Hi, Actually open-vm-tools on AlmaLinux have vulnerability : 12.1.5.39265 (build-20735119) Also can you update open-vm-tools to fix this CVE ? https://access.redhat.com/security/cve/CVE-2023-20867 https://www.vmware.com/security/advisories/VMSA-2023-0013.html Best Regards |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000922)
liberodark 2023-06-30 09:06 |
Im adding source : https://github.com/vmware/open-vm-tools/releases/tag/stable-12.2.5 |
(0000924)
alukoshko 2023-07-14 11:58 |
Updates released for both 8 and 9 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
259 | [AlmaLinux-8] dnf | minor | sometimes | 2022-06-04 23:47 | 2023-06-29 08:13 |
Reporter: | imtek | Platform: | x86_64 | ||
Assigned To: | alukoshko | OS: | 8 | ||
Priority: | normal | OS Version: | 8.6 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Unable to update listed dnf updates on a lot of servers | ||||
Description: |
DNF lists that there are updates available but they are not able to be installed: ALBA-2020:1673 bugfix perl-IO-Socket-SSL-2.066-4.module_el8.6.0+2851+6d072db5.noarch FEDORA-EPEL-2019-6adf1e0ef3 newpackage python3-psutil-5.6.3-5.el8.x86_64 We tried to solve this with updating all bugfix/security/enhancement package and reboot server(s) but they keep getting listed. This only happens on AlmaLinux not on CloudLinux for instance or related projects. Release: AlmaLinux release 8.6 (Sky Tiger) Kernel: 4.18.0-372.9.1.el8.x86_64 #1 SMP Tue May 10 08:57:35 EDT 2022 x86_64 x86_64 |
||||
Tags: | dnf, updates | ||||
Steps To Reproduce: |
dnf updateinfo list dnf upgrade --security --bugfix --enhancement --newpackage -y |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000625)
imtek 2022-07-02 12:00 |
Are there any updates regarding this issue? |
(0000683)
imtek 2022-08-27 23:09 |
Any update? |
(0000685)
ladislavnovak 2022-08-30 12:02 |
@imtek, when you use 'dnf updateinfo list --updates' view only available security/bugfix/ updates for your OS. Run without '--updates' show all available packages and from AlmaLinux 9. |
(0000686)
imtek 2022-08-30 13:19 |
@ladislavnovak, seems related to EPEL. I guess we have to wait for them to fix this issue. |
(0000779)
spiky 2022-12-22 18:10 |
I have the same problem with perl-IO-Socket-SSL and that one is maintained by Alma Linux, not EPEL. |
(0000921)
alukoshko 2023-06-29 08:13 |
Looks fixed now |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
400 | [AlmaLinux-8] autofs | crash | always | 2023-05-25 16:12 | 2023-06-26 21:48 |
Reporter: | lantzer | Platform: | x86_64 | ||
Assigned To: | OS: | Alma Linux | |||
Priority: | high | OS Version: | 8.8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Crash when restarting autofs when a direct map-ed directory is busy and cannot be unmounted | ||||
Description: | After upgrading to Alma Linux 8.8, the autofs 1:5.1.4-93.el8 package now crashes when the autofs service is restarted while a direct mapped mount is in use. This problem did not happen with Alma Linux 8.7 and autofs 1:5.1.4-83.el8. This problem also does not happen for an indirect mount, as it appears to be directly related to the autofs virtual mount and the target mount using the same directory. | ||||
Tags: | AlmaLinux, almalinux8, segfault | ||||
Steps To Reproduce: |
Create a direct map in autofs to mount an exported directory on an NFS server, change to that directory, then restart the autofs service. At this point the service crashes. /etc/auto.master: /- /etc/auto.home /etc/auto.home: /home nfsserver.local:/export cd /home systemctl restart autofs # autofs crashes |
||||
Additional Information: |
May 25 10:56:51 localhost systemd[1]: Stopping Automounts filesystems on demand... May 25 10:56:53 localhost systemd[1]: autofs.service: Succeeded. May 25 10:56:53 localhost systemd[1]: Stopped Automounts filesystems on demand. May 25 10:56:53 localhost systemd[1]: Starting Automounts filesystems on demand... May 25 10:56:53 localhost systemd[1]: tmp-autozPOEVP.mount: Succeeded. May 25 10:56:53 localhost systemd[1]: tmp-autoYYS6Qj.mount: Succeeded. May 25 10:56:53 localhost kernel: automount[2193290]: segfault at 28 ip 000055a2e7004b39 sp 00007ff7f2968970 error 4 in automount[55a2e6fdb000+4b000] May 25 10:56:53 localhost kernel: Code: 01 00 31 c0 31 ed 48 8d 35 5d 5f 01 00 e8 af 18 00 00 41 83 fe 01 0f 84 d5 01 00 00 41 83 a4 24 90 00 00 00 fd 49 8b 44 24 30 <4c> 8b 40 28 41 80 38 2f 0f 84 99 01 00 00 4c 8d ac 24 00 01 00 00 May 25 10:56:53 localhost systemd[1]: Started Process Core Dump (PID 2193293/UID 0). May 25 10:56:53 localhost systemd-coredump[2193294]: Process 2193284 (automount) of user 0 dumped core. Stack trace of thread 2193290: #0 0x000055a2e7004b39 try_remount (automount) #1 0x000055a2e6feeb0c do_mount_autofs_direct (automount) 0000002 0x000055a2e6feef72 mount_autofs_direct (automount) 0000003 0x000055a2e6feb738 handle_mounts (automount) 0000004 0x00007ff7f6d3d1cf start_thread (libpthread.so.0) 0000005 0x00007ff7f52dce73 __clone (libc.so.6) Stack trace of thread 2193286: #0 0x00007ff7f6d4345c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x000055a2e7007ce4 alarm_handler (automount) 0000002 0x00007ff7f6d3d1cf start_thread (libpthread.so.0) 0000003 0x00007ff7f52dce73 __clone (libc.so.6) Stack trace of thread 2193284: #0 0x00007ff7f6d4345c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x000055a2e6ff57cb master_mount_mounts (automount) 0000002 0x000055a2e6ff5fcd master_read_master (automount) 0000003 0x000055a2e6fe81d4 main (automount) 0000004 0x00007ff7f52ddd85 __libc_start_main (libc.so.6) 0000005 0x000055a2e6fe89ee _start (automount) Stack trace of thread 2193287: #0 0x00007ff7f6d4345c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x000055a2e6ffdd3f st_queue_handler (automount) 0000002 0x00007ff7f6d3d1cf start_thread (libpthread.so.0) 0000003 0x00007ff7f52dce73 __clone (libc.so.6) May 25 10:56:53 localhost systemd[1]: systemd-coredump@2-2193293-0.service: Succeeded. May 25 10:56:53 localhost systemd[1]: autofs.service: Main process exited, code=killed, status=11/SEGV May 25 10:56:53 localhost systemd[1]: autofs.service: Failed with result 'signal'. May 25 10:56:53 localhost systemd[1]: Failed to start Automounts filesystems on demand. |
||||
Attached Files: | |||||
Notes | |
(0000919)
lantzer 2023-06-26 21:48 |
After finding a list of CentOS Stream 8 packages (http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/), I tested several autofs RPMs from CentOS Stream 8, and found that this problem appears to have been introduced in autofs-5.1.4-91.el8, but it appears to be resolved in autofs-5.1.4-103.el8. It seems that one possible workaround is to install this package from CentOS Stream 8: http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/autofs-5.1.4-103.el8.x86_64.rpm |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
343 | [AlmaLinux-8] -OTHER | minor | N/A | 2022-12-12 00:05 | 2023-06-19 09:22 |
Reporter: | toracat | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | The minimal iso image should contain the kernel package. | ||||
Description: |
AlmaLinux-8.7-x86_64-minimal.iso.manifest shows the following packages : /Minimal/Packages/kernel-core-4.18.0-425.3.1.el8.x86_64.rpm /Minimal/Packages/kernel-headers-4.18.0-425.3.1.el8.x86_64.rpm /Minimal/Packages/kernel-modules-4.18.0-425.3.1.el8.x86_64.rpm /Minimal/Packages/kernel-modules-extra-4.18.0-425.3.1.el8.x86_64.rpm /Minimal/Packages/kernel-tools-4.18.0-425.3.1.el8.x86_64.rpm /Minimal/Packages/kernel-tools-libs-4.18.0-425.3.1.el8.x86_64.rpm It is missing kernel-425.3.1.el8.x86_64.rpm. $ rpm -qR kernel-4.18.0-425.3.1.el8 | grep 4.18.0-425.3.1.el8 kernel-core-uname-r = 4.18.0-425.3.1.el8.x86_64 kernel-modules-uname-r = 4.18.0-425.3.1.el8.x86_64 $ rpm -qR kernel-core-4.18.0-425.3.1.el8 | grep 4.18.0-425.3.1.el8 (returns nothing) $ rpm -q --whatrequires kernel-modules-uname-r | grep 4.18.0-425.3.1.el8 kernel-4.18.0-425.3.1.el8.x86_64 $ rpm -q --whatrequires kernel-core-uname-r | grep 4.18.0-425.3.1.el8 kernel-4.18.0-425.3.1.el8.x86_64 As a result, if you install from the minimal iso, kernel-modules will bot be installed. This might lead to missing some drivers as seen in this forum post: https://almalinux.discourse.group/t/almalinux-9-network-problem/1880 |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000763)
toracat 2022-12-12 00:09 |
I see https://bugs.almalinux.org/view.php?id=342 submitted earlier. |
(0000765)
alukoshko 2022-12-14 13:28 |
Updated AlmaLinux-8.7-update-1-$ARCH-minimal.iso images were released to fix this issue. |
(0000767)
alukoshko 2022-12-15 13:48 |
Updated AlmaLinux-9.1-update-1-$ARCH-minimal.iso images were released to fix this issue for x86_64, aarch64, ppc64le. Updated image for s390x will be released soon. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
404 | [AlmaLinux-8] samba | major | always | 2023-06-16 13:27 | 2023-06-16 13:27 |
Reporter: | bigbalu | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Share with directory mode 0700 not accessible | ||||
Description: |
I tested it with "homes" share first, then with normal shares. Both are not working. If the shares do not have read or rx permission on directories, it is not accessible on the client. So if the homedir is "/home/testuser" with permission 0700, an error comes up with "NT_ACCESS_DENIED" in the log. If I switch to 0740, it works. On the RedHat Package Version, it works. It is the same package Version samba-4.17.5-2. |
||||
Tags: | |||||
Steps To Reproduce: | Install samba package, ensure an uncommented "[homes]" section. Add a user with "smbpasswd -a testuser" and ensure, the homedir exists. Try to access the share with "smbclient -hlocalhost -Utestuser" or with a windows client. | ||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
403 | [AlmaLinux-8] -OTHER | text | always | 2023-06-08 03:47 | 2023-06-16 08:54 |
Reporter: | Hitamashi | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | |||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Sync AlmaLinux 8 Appstream Repo "https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/" fails | ||||
Description: |
I'm using katello. When syncing AppStream repo https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/, it will following error "PLP0000: Importer indicated a failed response". |
||||
Tags: | almalinux8, appstream, repo | ||||
Steps To Reproduce: | |||||
Additional Information: |
Current version: pulp-server-2.21.5-1.el7.noarch katello-3.18.4-1.el7.noarch foreman-2.3.5-1.el7.noarch Katello output: {"pulp_tasks"=> [{"exception"=>nil, "task_type"=>"pulp.server.managers.repo.sync.sync", "_href"=>"/pulp/api/v2/tasks/d18166c2-c017-4650-8e2b-613385fa4fc2/", "task_id"=>"d18166c2-c017-4650-8e2b-613385fa4fc2", "tags"=> ["pulp:repository:1d58d5fa-c886-444f-af67-e046f262f20a", "pulp:action:sync"], "finish_time"=>"2023-06-07T10:30:04Z", "_ns"=>"task_status", "start_time"=>"2023-06-07T10:28:23Z", "traceback"=> "Traceback (most recent call last):\n" + " File \"/usr/lib/python2.7/site-packages/celery/app/trace.py\", line 367, in trace_task\n" + " R = retval = fun(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py\", line 688, in __call__\n" + " return super(Task, self).__call__(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py\", line 110, in __call__\n" + " return super(PulpTask, self).__call__(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/celery/app/trace.py\", line 622, in __protected_call__\n" + " return self.run(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py\", line 860, in sync\n" + " raise pulp_exceptions.PulpExecutionException(_('Importer indicated a failed response'))\n" + "PulpExecutionException: Importer indicated a failed response\n", "spawned_tasks"=>[], "progress_report"=> {"yum_importer"=> {"content"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "details"=> {"rpm_total"=>0, "rpm_done"=>0, "drpm_total"=>0, "drpm_done"=>0}, "size_total"=>0, "size_left"=>0, "items_left"=>0}, "comps"=>{"state"=>"NOT_STARTED"}, "purge_duplicates"=>{"state"=>"NOT_STARTED"}, "distribution"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "items_left"=>0}, "modules"=> {"state"=>"FAILED", "error"=> "encoder expected a mapping type but got: '\\x1d\\x00\\x00\\x00\\x041.0\\x00\\x13\\x00\\x00\\x00\\x020\\x00\\x07\\x00\\x00\\x00common\\x00\\x00\\x00'"}, "errata"=>{"state"=>"NOT_STARTED"}, "metadata"=>{"state"=>"FINISHED"}}}, "queue"=>"abcxyz", "state"=>"error", "worker_name"=>"abcxyz", "result"=>nil, "error"=> {"code"=>"PLP0000", "data"=>{}, "description"=>"Importer indicated a failed response", "sub_errors"=>[]}, "_id"=>{"$oid"=>"64805bc72fe340c8f5f4c528"}, "id"=>"64805bc72fe340c8f5f4c528"}], "contents_changed"=>true, "poll_attempts"=>{"total"=>27, "failed"=>1}} |
||||
Attached Files: | |||||
Notes | |
(0000908)
Hitamashi 2023-06-08 08:09 |
Another similar error {"pulp_tasks"=> [{"exception"=>nil, "task_type"=>"pulp.server.managers.repo.sync.sync", "_href"=>"/pulp/api/v2/tasks/59a814b5-6332-428e-89d5-02e4ce7d403f/", "task_id"=>"59a814b5-6332-428e-89d5-02e4ce7d403f", "tags"=> ["pulp:repository:1d58d5fa-c886-444f-af67-e046f262f20a", "pulp:action:sync"], "finish_time"=>"2023-06-07T22:01:55Z", "_ns"=>"task_status", "start_time"=>"2023-06-07T22:00:04Z", "traceback"=> "Traceback (most recent call last):\n" + " File \"/usr/lib/python2.7/site-packages/celery/app/trace.py\", line 367, in trace_task\n" + " R = retval = fun(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py\", line 688, in __call__\n" + " return super(Task, self).__call__(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py\", line 110, in __call__\n" + " return super(PulpTask, self).__call__(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/celery/app/trace.py\", line 622, in __protected_call__\n" + " return self.run(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py\", line 860, in sync\n" + " raise pulp_exceptions.PulpExecutionException(_('Importer indicated a failed response'))\n" + "PulpExecutionException: Importer indicated a failed response\n", "spawned_tasks"=>[], "progress_report"=> {"yum_importer"=> {"content"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "details"=> {"rpm_total"=>0, "rpm_done"=>0, "drpm_total"=>0, "drpm_done"=>0}, "size_total"=>0, "size_left"=>0, "items_left"=>0}, "comps"=>{"state"=>"NOT_STARTED"}, "purge_duplicates"=>{"state"=>"NOT_STARTED"}, "distribution"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "items_left"=>0}, "modules"=> {"state"=>"FAILED", "error"=> "strings in documents must be valid UTF-8: '\\x82\\x00\\x00\\x00\\x041.16\\x00\\x13\\x00\\x00\\x00\\x020\\x00\\x07\\x00\\x00\\x00common\\x00\\x00\\x041.22\\x00\\x13\\x00\\x00\\x00\\x020\\x00\\x07\\x00\\x00\\x00common\\x00\\x00\\x041.14\\x00\\x13\\x00\\x00\\x00\\x020\\x00\\x07\\x00\\x00\\x00common\\x00\\x00\\x041.20\\x00\\x13\\x00\\x00\\x00\\x020\\x00\\x07\\x00\\x00\\x00common\\x00\\x00\\x041.18\\x00\\x13\\x00\\x00\\x00\\x020\\x00\\x07\\x00\\x00\\x00common\\x00\\x00\\x00'"}, "errata"=>{"state"=>"NOT_STARTED"}, "metadata"=>{"state"=>"FINISHED"}}}, "queue"=>"abcxyz", "state"=>"error", "worker_name"=>"abcxyz", "result"=>nil, "error"=> {"code"=>"PLP0000", "data"=>{}, "description"=>"Importer indicated a failed response", "sub_errors"=>[]}, "_id"=>{"$oid"=>"6480fde3d0953052c495338e"}, "id"=>"6480fde3d0953052c495338e"}], "contents_changed"=>true, "poll_attempts"=>{"total"=>28, "failed"=>1}} |
(0000909)
ccto32 2023-06-11 00:23 |
Dear AlmaLinux support, Yes, we encountered the similar problem. Please help. -------- [root@xxxxxx ~]# cat /etc/redhat-release AlmaLinux release 8.7 (Stone Smilodon) [root@xxxxxx ~]# [root@xxxxxx ~]# yum clean all 0 files removed [root@xxxxxx ~]# [root@xxxxxx ~]# yum check-update AlmaLinux 8 - BaseOS 1.9 MB/s | 2.8 MB 00:01 AlmaLinux 8 - AppStream 166 B/s | 744 B 00:04 Errors during downloading metadata for repository 'appstream': - Status code: 404 for http://mirrors.nju.edu.cn/almalinux/8.8/AppStream/x86_64/os/repodata/5e704ef80796fd5fadc41eea302860a38195f8ff5ec1810f9a84e9e222aba28b-comps-AppStream.x86_64.xml (IP: 210.28.130.3) - Status code: 404 for http://mirrors.neusoft.edu.cn/almalinux/8.8/AppStream/x86_64/os/repodata/48fac7b41b32ca8d9a67f4f9ca8496ac973e34275260a96c497738d5c394c122-updateinfo.xml.gz (IP: 219.216.128.25) - Status code: 404 for https://mirror.kku.ac.th/almalinux/8.8/AppStream/x86_64/os/repodata/894203b4259b93c5d07945b3c6dfc0d051f5f8be146126d6b9638a3a8b3f6ee1-primary.xml.gz (IP: 202.28.95.174) - Status code: 404 for http://mirror.01link.hk/almalinux/8.8/AppStream/x86_64/os/repodata/48fac7b41b32ca8d9a67f4f9ca8496ac973e34275260a96c497738d5c394c122-updateinfo.xml.gz (IP: 101.78.134.82) ... - Status code: 404 for http://hkg.mirror.rackspace.com/almalinux/8.8/AppStream/x86_64/os/repodata/faaf5696360c1e09891fbd9790c0afe156ebdbae83e6ae5bf7bc61c2671a0f7b-modules.yaml.gz (IP: 180.150.156.88) Error: Failed to download metadata for repo 'appstream': Yum repo downloading error: Downloading error(s): repodata/894203b4259b93c5d07945b3c6dfc0d051f5f8be146126d6b9638a3a8b3f6ee1-primary.xml.gz - Cannot download, all mirrors were already tried without success; repodata/7c0abdd4c0c956c1999dbfcfbb7a0f9866d5ab2899f51daaa884db4ff4607e4d-filelists.xml.gz - Cannot download, all mirrors were already tried without success; repodata/5e704ef80796fd5fadc41eea302860a38195f8ff5ec1810f9a84e9e222aba28b-comps-AppStream.x86_64.xml - Cannot download, all mirrors were already tried without success; repodata/faaf5696360c1e09891fbd9790c0afe156ebdbae83e6ae5bf7bc61c2671a0f7b-modules.yaml.gz - Cannot download, all mirrors were already tried without success; repodata/48fac7b41b32ca8d9a67f4f9ca8496ac973e34275260a96c497738d5c394c122-updateinfo.xml.gz - Cannot download, all mirrors were already tried without success [root@xxxxxx ~]# |
(0000910)
alukoshko 2023-06-12 13:50 |
Hello. Is it possible that you use some caching proxy and it has outdated repomd.xml? There is no such file: http://mirrors.neusoft.edu.cn/almalinux/8.8/AppStream/x86_64/os/repodata/48fac7b41b32ca8d9a67f4f9ca8496ac973e34275260a96c497738d5c394c122-updateinfo.xml.gz In repomd.xml on the same mirror: http://mirrors.neusoft.edu.cn/almalinux/8.8/AppStream/x86_64/os/repodata/repomd.xml |
(0000911)
alukoshko 2023-06-12 13:50 |
Hitamashi, is this still reproducible? When it happened for the first time? |
(0000912)
Hitamashi 2023-06-14 04:01 |
Hello alukoshko, The issue is still happening on my side. As I last check, it started from 18 or 19 May FYI, we don't use any proxy and we are using the official repo: https://repo.almalinux.org (tried some other mirrors too but it is the same) Katello seems to get the correct metadata files but it cannot parse it. Here are some more logs on my katello server 2023-06-13T22:00:11.638443+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:INFO: [77e20cb0] Downloading metadata from https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/. 2023-06-13T22:00:12.030816+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/repomd.xml. 2023-06-13T22:00:12.644387+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:INFO: [77e20cb0] Downloading metadata from https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/. 2023-06-13T22:00:13.037398+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/repomd.xml. 2023-06-13T22:00:13.650485+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:INFO: [77e20cb0] Downloading metadata from https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/. 2023-06-13T22:00:14.039833+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/repomd.xml. 2023-06-13T22:00:14.659084+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:INFO: [77e20cb0] Downloading metadata from https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/. 2023-06-13T22:00:15.056043+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/repomd.xml. 2023-06-13T22:00:17.217328+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/c506a63e6ec2310bbe4700a2cea294829a84a115bf3b2d27d74d040595619c87-comps.xml. 2023-06-13T22:00:17.240123+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/3abb7e78188af4e9bdb9237a1285e44015f444635fea14a2e4c6269508f92d63-updateinfo.xml.gz. 2023-06-13T22:00:17.328541+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/25e7f52dcf83e5d7de9e6ca2e8f2b346731ea65b9cc9382510e96a75628f401c-modules.yaml. 2023-06-13T22:00:17.715379+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/7e6c2e6eaa89ac622558caec1942f4946c3e28e41c9e6409911be897bcb46619-filelists.xml.gz. 2023-06-13T22:00:17.745900+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/909ab6d80107e46aba7fa94265f63b7a41320e651b2982e1cae3690360182726-primary.xml.gz. 2023-06-13T22:00:18.268155+00:00 katello-server pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/repodata/c8b0b2d955b55f1c74db148ae6e7b9643f9d93e4d178e8dae889f526778f7e20-other.xml.gz. 2023-06-13T22:01:59.257174+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) strings in documents must be valid UTF-8: '\x82\x00\x00\x00\x041.16\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x041.22\x00\x13\x00\x00\ x00\x020\x00\x07\x00\x00\x00common\x00\x00\x041.14\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x041.20\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x041.18\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x00' 2023-06-13T22:01:59.257370+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) Traceback (most recent call last): 2023-06-13T22:01:59.257550+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/importers/yum/sync.py", line 312, in run 2023-06-13T22:01:59.257762+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) repair=self.validate) 2023-06-13T22:01:59.257971+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/importers/yum/modularity.py", line 415, in synchronize 2023-06-13T22:01:59.258153+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) remainder = add_defaults(repository, defaults, repair=repair) 2023-06-13T22:01:59.258312+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/importers/yum/modularity.py", line 340, in add_defaults 2023-06-13T22:01:59.258470+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) add_default(repository, default, model) 2023-06-13T22:01:59.258624+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/importers/yum/modularity.py", line 287, in add_default 2023-06-13T22:01:59.258775+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) model.save_and_import_content(path) 2023-06-13T22:01:59.258945+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib/python2.7/site-packages/pulp/server/db/model/__init__.py", line 936, in save_and_import_content 2023-06-13T22:01:59.259099+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) self.save() 2023-06-13T22:01:59.259252+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib/python2.7/site-packages/mongoengine/document.py", line 324, in save 2023-06-13T22:01:59.259414+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) object_id = collection.save(doc, **write_concern) 2023-06-13T22:01:59.259566+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 2180, in save 2023-06-13T22:01:59.259717+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) check_keys, False, manipulate, write_concern) 2023-06-13T22:01:59.259894+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 709, in _update 2023-06-13T22:01:59.260058+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) codec_options=self.codec_options).copy() 2023-06-13T22:01:59.260213+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib64/python2.7/site-packages/pymongo/pool.py", line 216, in command 2023-06-13T22:01:59.260363+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) self._raise_connection_failure(error) 2023-06-13T22:01:59.260515+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) File "/usr/lib64/python2.7/site-packages/pymongo/pool.py", line 343, in _raise_connection_failure 2023-06-13T22:01:59.260665+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) raise error 2023-06-13T22:01:59.260841+00:00 katello-server pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [77e20cb0] (32148-18944) InvalidStringData: strings in documents must be valid UTF-8: '\x82\x00\x00\x00\x041.16\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x041.22\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x041.14\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x041.20\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x041.18\x00\x13\x00\x00\x00\x020\x00\x07\x00\x00\x00common\x00\x00\x00' |
(0000916)
alukoshko 2023-06-15 16:59 |
> 18 or 19 May May 18 was release of 8.8. So it should be related. |
(0000917)
Hitamashi 2023-06-16 07:43 |
``` > 18 or 19 May May 18 was release of 8.8. So it should be related. ``` Do you have any update on the way to generate the metadata when moving to 8.8? FYI, it works fine with 8.7 AppStream: https://repo.almalinux.org/almalinux/8.7/AppStream/x86_64/os/ |
(0000918)
Hitamashi 2023-06-16 08:54 |
It works now with the following workaround: https://forums.developer.nvidia.com/t/error-syncing-rhel8-cuda-repo/176276/9 Similar bugs on satellite: https://bugzilla.redhat.com/show_bug.cgi?id=1920511 I tried this last week but no result but now it works somehow. I think this is more about katello/pulp issue |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
399 | [AlmaLinux-8] kernel | crash | have not tried | 2023-05-24 20:02 | 2023-06-15 16:57 |
Reporter: | almalinuxjack | Platform: | AlmaLinux | ||
Assigned To: | OS: | 8 | |||
Priority: | high | OS Version: | 8.6 ARM | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | [arm64] verify_fips_enable failing with a stack trace | ||||
Description: |
On Azure: SIG Image: SharedImageGalleryTest/AlmaLinux-8.6/8.6.20220607 VMSize: Standard_B2ps_v2, Standard_B16ps_v2 Below is snippet of the stack trace seen (Full logs attcahed) ----------------------------------------------------------------------- 5.112812] Call trace: [ 5.115144] dump_backtrace+0x0/0x210 [ 5.118460] show_stack+0x20/0x30 [ 5.122099] dump_stack+0xd8/0x130 [ 5.125421] panic+0x15c/0x374 [ 5.128422] alg_test+0x3f8/0x4d8 [ 5.131727] do_test+0x43d8/0x6a80 [tcrypt] [ 5.136754] do_test+0x6a6c/0x6a80 [tcrypt] [ 5.140616] tcrypt_mod_init+0x60/0x10000 [tcrypt] [ 5.144932] do_one_initcall+0x54/0x278 [ 5.148399] do_init_module+0x50/0x230 [ 5.151907] load_module+0x18f0/0x1b38 [ 5.155331] __do_sys_init_module+0x1f0/0x260 [ 5.159321] __arm64_sys_init_module+0x24/0x30 [ 5.163293] do_el0_svc+0xfc/0x238 [ 5.166770] el0_svc+0x20/0x30 [ 5.169716] el0_sync_handler+0x90/0xc8 [ 5.173285] el0_sync+0x160/0x180 [ 5.176375] SMP: stopping secondary CPUs [ 5.180169] Kernel Offset: 0x26eba77c0000 from 0xffff800010000000 [ 5.186913] PHYS_OFFSET: 0xfff0fad3c0000000 [ 5.190762] CPU features: 0x8048002,38a02238 [ 5.194690] Memory Limit: none [ 5.197607] ---[ end Kernel panic - not syncing: alg: self-tests for cfb(aes) (cfb(aes)) failed in fips mode! ]--- |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000915)
alukoshko 2023-06-15 16:57 |
What kernel version you have? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
402 | [AlmaLinux-8] lorax | minor | always | 2023-06-02 19:08 | 2023-06-15 15:55 |
Reporter: | fundies | Platform: | x86_64 | ||
Assigned To: | alukoshko | OS: | Almalinux | ||
Priority: | normal | OS Version: | 8.8 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Missing lorax-templates-almalinux on 8.8 | ||||
Description: | Lorax-templates-rhel require bugzilla packages that are not provided. In alma 9 lorax-templates-almalinux has templates that avoid this issue and is available but it is not available in 8. | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000914)
alukoshko 2023-06-15 15:55 |
Released https://repo.almalinux.org/almalinux/8.8/AppStream/x86_64/os/Packages/lorax-templates-almalinux-8.7-1.el8.noarch.rpm Thanks for pointing this out. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
184 | [AlmaLinux-8] osbuild-composer | crash | always | 2022-02-08 05:53 | 2023-06-15 11:35 |
Reporter: | Naranthiran | Platform: | X86_64 | ||
Assigned To: | alukoshko | OS: | Alma Linux | ||
Priority: | urgent | OS Version: | 8.5 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Failed to start OSBuild Composer | ||||
Description: |
I am not able start the OS build compose. When I try to start osbuild-composer.service its stops immediately. [root@localhost ~]# systemctl status osbuild-composer.service ● osbuild-composer.service - OSBuild Composer Loaded: loaded (/usr/lib/systemd/system/osbuild-composer.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2022-02-08 00:18:43 EST; 32min ago Process: 1657 ExecStart=/usr/libexec/osbuild-composer/osbuild-composer (code=exited, status=1/FAILURE) Main PID: 1657 (code=exited, status=1/FAILURE) Feb 08 00:18:43 localhost.localdomain systemd[1]: osbuild-composer.service: Failed with result 'exit-code'. Feb 08 00:18:43 localhost.localdomain systemd[1]: osbuild-composer.service: Service RestartSec=100ms expired, schedu> Feb 08 00:18:43 localhost.localdomain systemd[1]: osbuild-composer.service: Scheduled restart job, restart counter i> Feb 08 00:18:43 localhost.localdomain systemd[1]: Stopped OSBuild Composer. Feb 08 00:18:43 localhost.localdomain systemd[1]: osbuild-composer.service: Start request repeated too quickly. Feb 08 00:18:43 localhost.localdomain systemd[1]: osbuild-composer.service: Failed with result 'exit-code'. Feb 08 00:18:43 localhost.localdomain systemd[1]: Failed to start OSBuild Composer. Feb 08 00:18:45 localhost.localdomain systemd[1]: osbuild-composer.service: Start request repeated too quickly. Feb 08 00:18:45 localhost.localdomain systemd[1]: osbuild-composer.service: Failed with result 'exit-code'. Feb 08 00:18:45 localhost.localdomain systemd[1]: Failed to start OSBuild Composer. |
||||
Tags: | |||||
Steps To Reproduce: |
1. install almalinux 8.4 and updated to 8.5 2. run sudo dnf install osbuild-composer composer-cli cockpit-composer bash-completion 3. sudo systemctl enable --now osbuild-composer.socket 4. run composer-cli blueprint list or try and start the image builder service in cockpit |
||||
Additional Information: | |||||
Attached Files: |
osbuild composer.JPG (57,974 bytes) 2022-02-08 05:53 https://bugs.almalinux.org/file_download.php?file_id=115&type=bug |
||||
Notes | |
(0000488)
alukoshko 2022-02-08 20:39 |
Hello. Unfortunately it's an upstream issue. More details here: https://github.com/osbuild/osbuild-composer/issues/1411#issuecomment-853712989 |
(0000600)
alukoshko 2022-06-21 14:53 |
Hello. We have a patched version that now looks working (at least "Steps To Reproduce"): https://build.almalinux.org/pulp/content/builds/AlmaLinux-8-x86_64-2913-br/ Could you please test it before we'll release it for all? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
401 | [AlmaLinux-8] kernel | crash | unable to reproduce | 2023-05-31 15:56 | 2023-06-06 01:16 |
Reporter: | gschock | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Upgrade to 8.8 leads to hung_task_timeout | ||||
Description: |
We upgraded hosts to 8.8 and get the following message and very high load. Downgrading to 8.7 fixed the issue. kernel: INFO: task consul:9062 blocked for more than 120 seconds. kernel: Not tainted 4.18.0-477.10.1.el8_8.x86_64 #1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: task:consul state:D stack: 0 pid: 9062 ppid: 9061 flags:0x00000004 kernel: Call Trace: kernel: __schedule+0x2d1/0x870 kernel: ? flush_tlb_func_common.constprop.9+0x129/0x220 kernel: schedule+0x55/0xf0 kernel: io_schedule+0x12/0x40 kernel: migration_entry_wait_on_locked+0x1ea/0x290 kernel: ? filemap_fdatawait_keep_errors+0x50/0x50 kernel: do_swap_page+0x5b0/0x710 kernel: ? pmd_devmap_trans_unstable+0x2e/0x40 kernel: ? handle_pte_fault+0x5d/0x880 kernel: __handle_mm_fault+0x453/0x6c0 kernel: handle_mm_fault+0xca/0x2a0 kernel: __do_page_fault+0x1f0/0x450 kernel: do_page_fault+0x37/0x130 kernel: ? page_fault+0x8/0x30 kernel: page_fault+0x1e/0x30 kernel: RIP: 0033:0x1aaafb7 kernel: Code: Unable to access opcode bytes at RIP 0x1aaaf8d. kernel: RSP: 002b:000000c0008c1da8 EFLAGS: 00010212 kernel: RAX: 0000000004f49b40 RBX: 0000000000000009 RCX: 000000c000000300 kernel: RDX: 0000000004f49b88 RSI: 0000000001aaafa0 RDI: 000000c00024b5e8 kernel: RBP: 000000c0008c1df8 R08: 0000000003440118 R09: 0000000000000000 kernel: R10: 0000000000000008 R11: 000000c00024b500 R12: 0000000000000034 kernel: R13: 000000000000000c R14: 0000000000000030 R15: 000000c000307340 |
||||
Tags: | almalinux8 | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000907)
robmv 2023-06-06 01:16 |
For the record, there is a reference to the error at upstream web site https://access.redhat.com/solutions/7014646 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
394 | [AlmaLinux-8] cockpit | major | always | 2023-05-17 07:44 | 2023-05-17 07:44 |
Reporter: | nunop | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux version is stuck in 276 | ||||
Description: |
Hey! AlmaLinux 8's cockpit version is currently 276. Is this because newer versions don't support AlmaLinux 8, or is it possible to update the version available in the "baseos"/"appstream" repositories? Thank you very much! |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | Current version is 292 | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
387 | [AlmaLinux-8] -OTHER | block | always | 2023-04-27 15:18 | 2023-05-10 20:26 |
Reporter: | ccaudle | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Elevate/leapp upgrade from CentOS 7.9.2009 incorrectly flags filesystem space as blocker | ||||
Description: |
Attempted to update from CentOS 7.9 to AlmaLinux 8 with leapp, and got a message at the end of the upgrade step that "At least 317MB more space needed on the / filesystem." I deleted about 3GB of files from a subdir under / and ran leapp upgrade again, and got the same message that 317MB more space was needed. I thought perhaps the message was specifically about /boot but just did not distinguish where the space was needed, so I remove two old kernels which freed about 120MB in /boot. Ran again and the message still stated 317MB more space needed. This is the actual amount of free space available: $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.8G 0 3.8G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 98M 3.8G 3% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/mapper/centos-root 922G 858G 65G 94% / /dev/sda2 497M 104M 394M 21% /boot /dev/sda1 200M 12M 189M 6% /boot/efi tmpfs 781M 0 781M 0% /run/user/1000 The root filesystem is on a /dev/mapper volume, but I did not find anything in the FAQ or Wiki indicating that would be a problem. Earlier in the output there were these warnings, but nothing to indicate they would be upgrade blockers: STDERR: No matches found for the following disable plugin patterns: subscription-manager Repository extras is listed more than once in the configuration Repository extras-source is listed more than once in the configuration Warning: Package marked by Leapp to install not found in repositories metadata: ldns-utils ivy-local python3-javapackages Warning: Package marked by Leapp to upgrade not found in repositories metadata: gpg-pubkey RPM: warning: Generating 6 missing index(es), please wait... Error: Transaction test error: [...long list of packages...] Error Summary ------------- Disk Requirements: At least 317MB more space needed on the / filesystem. I will attempt to attach the log and report files after submitting this. Every attempt to include files with the issue submission resulted in a Mantis error, so hopefully they can be added after the issue has been submitted. |
||||
Tags: | elevate, leapp | ||||
Steps To Reproduce: |
I followed the steps described at https://linuxiac.com/centos-7-to-almalinux-8-migration-guide/ : sudo dnf update sudo dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm sudo dnf install -y leapp-upgrade leapp-data-almalinux sudo leapp preupgrade [fix answer about pam_pkcs11 in answerfile, stop nfsd] sudo leapp preupgrade [no errors after second preupgrade check] sudo leapp upgrade [error message about 317MB more space needed] |
||||
Additional Information: |
I have a few additional repos active, the preupgrade check flagged them as potentially leaving packages not updated, but did not indicate they would cause any upgrade blocker problems. $ dnf repolist Last metadata expiration check: 1:13:33 ago on Thu 27 Apr 2023 08:59:46 AM CDT. repo id repo name status base CentOS-7 - Base 10,072 elevate ELevate 32 *epel Extra Packages for Enterprise Linux 7 - x86_64 13,777 extras CentOS-7 - Extras 515 nux-dextop Nux.Ro RPMs for general desktop use 2,724 updates CentOS-7 - Updates 4,907 |
||||
Attached Files: | |||||
Notes | |
(0000869)
ccaudle 2023-04-27 15:18 |
|
(0000870)
ccaudle 2023-04-27 15:19 |
|
(0000871)
ccaudle 2023-04-27 15:20 |
I attempted to upload the log and report files from leapp upgrade, but the Mantis server returned this error: APPLICATION ERROR #503 Invalid upload path. Directory either does not exist or not writable to webserver. |
(0000874)
ccaudle 2023-05-03 15:56 |
attempting to upload log files again |
(0000875)
ccaudle 2023-05-03 15:57 |
Still getting the web server error: APPLICATION ERROR #503 Invalid upload path. Directory either does not exist or not writable to webserver. Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section. Is no one else having this error attempting to upload files to the bug server? |
(0000876)
ccaudle 2023-05-04 20:07 |
Checking whether new unified Alma account fixes my problem with uploading log files. |
(0000878)
alukoshko 2023-05-04 20:33 |
Hello. Please try workaround that proposed here: https://github.com/AlmaLinux/leapp-repository/issues/38 |
(0000885)
ccaudle 2023-05-10 17:33 |
Still fails with that workaround. Error Summary ------------- Disk Requirements: At least 317MB more space needed on the / filesystem. ... $ sudo echo $LEAPP_OVL_SIZE 8192 |
(0000886)
ccaudle 2023-05-10 20:26 |
I tried that workaround discussed in github but got the same error. I tried again, but from su rather than sudo (previously I was logged in as a user and used sudo to run leapp preupgrade and leapp upgrade, I ran again after using su to login as root) and was able to finish leapp upgrade with no errors. Perhaps I did something else differently, but that is not clear to me right now. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
388 | [AlmaLinux-8] -OTHER | major | have not tried | 2023-05-02 12:08 | 2023-05-05 06:48 |
Reporter: | Adrien_D | Platform: | |||
Assigned To: | OS: | Alma LInux | |||
Priority: | normal | OS Version: | 8.7 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Leapp upgrade : Unable to install RHEL 9 userspace packages. | ||||
Description: |
Risk Factor: high Title: Unable to install RHEL 9 userspace packages. Summary: {"details": "Command ['systemd-nspawn', '--register=no', '--quiet', '--keep-unit', '--capability=all', '-D', '/var/lib/leapp/scratch/mounts/root_/system_overlay', '--setenv=LEAPP_HOSTNAME=S021103', '--setenv=LEAPP_EXPERIMENTAL=0', '--setenv=LEAPP_UNSUPPORTED=0', '--setenv=LEAPP_NO_RHSM=0', '--setenv=LEAPP_UPGRADE_PATH_TARGET_RELEASE=9.0', '--setenv=LEAPP_UPGRADE_PATH_FLAVOUR=default', '--setenv=LEAPP_IPU_IN_PROGRESS=8to9', '--setenv=LEAPP_EXECUTION_ID=5623eb3d-9c42-4a94-bbd4-3db104653d4d', '--setenv=LEAPP_COMMON_TOOLS=:/etc/leapp/repos.d/system_upgrade/common/tools:/etc/leapp/repos.d/system_upgrade/el8toel9/tools', '--setenv=LEAPP_COMMON_FILES=:/etc/leapp/repos.d/system_upgrade/common/files:/etc/leapp/repos.d/system_upgrade/el8toel9/files', 'dnf', 'install', '-y', '--nogpgcheck', '--setopt=module_platform_id=platform:el9', '--setopt=keepcache=1', '--releasever', '9.0', '--installroot', '/el9target', '--disablerepo', '*', '--enablerepo', 'almalinux9-crb', '--enablerepo', 'almalinux9-highavailability', '--enablerepo', 'almalinux9-extras', '--enablerepo', 'almalinux9-resilientstorage', '--enablerepo', 'almalinux9-baseos', '--enablerepo', 'almalinux9-appstream', 'kpatch-dnf', 'dnf', 'dnf-command(config-manager)', '--disableplugin', 'subscription-manager'] failed with exit code 1.", "stderr": "Host and machine ids are equal (539d35f8fdca449b978a55714e5fc07b): refusing to link journals\nNo matches found for the following disable plugin patterns: subscription-manager\nwarning: Generating 18 missing index(es), please wait...\nFatal glibc error: CPU does not support x86-64-v2\nError in PREIN scriptlet in rpm package libutempter\nError in POSTIN scriptlet in rpm package p11-kit-trust\nError unpacking rpm package coreutils-8.32-32.el9.x86_64\nError in PREIN scriptlet in rpm package ca-certificates\nError in POSTIN scriptlet in rpm package libblkid\nError unpacking rpm package systemd-libs-250-12.el9_1.3.x86_64\nError unpacking rpm package util-linux-core-2.37.4-9.el9.x86_64\nError unpacking rpm package python3-3.9.14-1.el9_1.2.x86_64\nError unpacking rpm package python3-libs-3.9.14-1.el9_1.2.x86_64\nError unpacking rpm package pam-1.5.1-12.el9.x86_64\nError unpacking rpm package util-linux-2.37.4-9.el9.x86_64\nError in PREIN scriptlet in rpm package systemd\nError in POSTIN scriptlet in rpm package dbus-common\nError in PREIN scriptlet in rpm package dbus-broker\nError in POSTIN scriptlet in rpm package elfutils-default-yama-scope\nError unpacking rpm package krb5-libs-1.19.1-24.el9_1.x86_64\nError unpacking rpm package openldap-2.6.2-3.el9.x86_64\nError unpacking rpm package rpm-4.16.1.3-19.el9_1.x86_64\nError in PREIN scriptlet in rpm package tpm2-tss\nError unpacking rpm package glib2-2.68.4-5.el9.x86_64\nError unpacking rpm package gnupg2-2.3.3-2.el9_0.x86_64\nError unpacking rpm package python3-libdnf-0.67.0-3.el9.alma.x86_64\nError in POSTIN scriptlet in rpm package dnf\nError in POSTIN scriptlet in rpm package kpatch-dnf\nError in POSTTRANS scriptlet in rpm package filesystem\nError in <unknown> scriptlet in rpm package glibc-common\nError: Transaction failed\n"} Key: 0e5d8451adfe372b923058fd09028cb5356e733d |
||||
Tags: | |||||
Steps To Reproduce: |
Install Alma Linux default Install Install httpd php-fpm mariadb-server dnf install https://repo.almalinux.org/elevate/elevate-release-latest-el8.noarch.rpm dnf install -y leapp-upgrade leapp-data-almalinux leapp preupgrade sed -i "s/^AllowZoneDrifting=.*/AllowZoneDrifting=no/" /etc/firewalld/firewalld.conf setenforce 0 leapp preupgrade |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000879)
alukoshko 2023-05-04 20:35 (Last edited: 2023-05-04 20:36) |
Fatal glibc error: CPU does not support x86-64-v2 This is the key. If it's bare metal system then it's too old. If it's virtual machine then update CPU model for it. It should be at least Nehalem or just match hypervisor CPU. |
(0000882)
Adrien_D 2023-05-05 06:48 |
Noted, i didn't see the CPU does not support x86-64-v2 error, lot of information. After change the CPU in the hypervisor, it's okay We can close this bug : INVALID |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
380 | [AlmaLinux-8] -OTHER | minor | always | 2023-03-31 14:35 | 2023-05-04 22:45 |
Reporter: | mikeowen | Platform: | |||
Assigned To: | elkhan | OS: | |||
Priority: | normal | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AWS Marketplace Alma8 image does not support EC2 G5.* instance type | ||||
Description: | When trying to launch Alma8 or Alma9 marketplace AMI on G5 instance, I get an error it is not supported. Launching the community AMI from Wiki is fine. Please can you enable the marketplace AMI to support all new/latest EC2 instance types and in particular G5.*? | ||||
Tags: | ami, aws, cloud | ||||
Steps To Reproduce: |
EC2 G5 instance type/sizes are not listed in current AWS Marketplace webpage for Alma 8.6 or Alma 8.7 here: https://aws.amazon.com/marketplace/pp/prodview-mku4y3g4sjrye |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000880)
elkhan 2023-05-04 22:45 |
Hi Mike, Thanks for your reporting, we did the changes below: Please, let us know which instance types should be added. Next time, We will add them at them the same day that you reported. :) Sorry for the delay. Thanks a lot! AlmaLinux OS 8 x86_64: Added new 108 instance types, including C6in, R6a, G4 and G5. AlmaLinux OS 8 AArch64: Added new 31 instance types, including M7g, R7g, Is4gen, Im4gn, G5g and c7g. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
377 | [AlmaLinux-8] systemd | major | always | 2023-03-08 18:57 | 2023-05-01 08:24 |
Reporter: | qupfer | Platform: | x64 | ||
Assigned To: | OS: | almalinux | |||
Priority: | normal | OS Version: | 8.7 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Resizing Terminal finish `journalctl -f` with "Couldn't wait for journal event: Interrupted system call" | ||||
Description: | If you run `journalctl -f` inside an gui terminal and resize the gui-terminal, it ends with "Couldn't wait for journal event: Interrupted system call" | ||||
Tags: | almalinux8, resize, systemd | ||||
Steps To Reproduce: |
1: open a gui terminal 2: run journalctl -f 3: resize the window ------- works in docker too 0: open gui terminal like gnome-terminal 1: docker run --rm -it almalinux:8.7 bash 2: journalctl -f 3: resize window seeh screen capute attached or from here: https://nc.caroschaf.de/s/PtpbQ82aksA5wpE |
||||
Additional Information: | I haven't a gui almalinux, so it happend for me (and my colleague, who found it first) through SSH to an almalinux system (and docker) from a ubuntu 22.04 system. | ||||
Attached Files: | |||||
Notes | |
(0000837)
qupfer 2023-03-08 18:58 |
screencapture |
(0000838)
qupfer 2023-03-08 19:05 |
Can't upload the capture. - Same problem with rockylinux:latest |
(0000873)
steen.schutt 2023-05-01 08:22 |
Possibly related: https://github.com/systemd/systemd/issues/10724 I can reproduce on the following AlmaLinux 8.7: ``` # cat /etc/almalinux-release AlmaLinux release 8.7 (Stone Smilodon) # journalctl --version systemd 239 (239-68.el8_7.4) +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy ``` I can not reproduce on the following AlmaLinux 8.6: ``` # cat /etc/almalinux-release AlmaLinux release 8.6 (Sky Tiger) # journalctl --version systemd 239 (239-58.el8) +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy ``` The bug also doesn't appear to be present in any AlmaLinux 9 release. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
386 | [AlmaLinux-8] -OTHER | block | always | 2023-04-27 15:01 | 2023-04-28 14:38 |
Reporter: | ccaudle | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Elevate/leapp upgrade from CentOS 7.9.2009 incorrectly flags filesystem space as blocker | ||||
Description: |
Attempting to update from CentOS 7.9 to AlmaLinux 8 the leapp upgrade step ends with a message that "At least 317MB more space needed on the / filesystem." I deleted about 3GB of files from a subdir under / and ran upgrade again, and got the same 317MB more space needed message. I thought perhaps it actually needed space on /boot and was just not distinguishing the specific subdir, so I remove to old kernels to free up about 120MB of space on /boot, but the same 317MB more space needed message was displayed again. This is the actual amount of space available: $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.8G 0 3.8G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 98M 3.8G 3% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/mapper/centos-root 922G 858G 65G 94% / /dev/sda2 497M 104M 394M 21% /boot /dev/sda1 200M 12M 189M 6% /boot/efi tmpfs 781M 0 781M 0% /run/user/1000 Earlier in the output there were these warnings, but did not seem to indicate anything as an upgrade blocker:STDERR: No matches found for the following disable plugin patterns: subscription-manager Repository extras is listed more than once in the configuration Repository extras-source is listed more than once in the configuration Warning: Package marked by Leapp to install not found in repositories metadata: ldns-utils ivy-local python3-javapackages Warning: Package marked by Leapp to upgrade not found in repositories metadata: gpg-pubkey RPM: warning: Generating 6 missing index(es), please wait... Error: Transaction test error: [...long list of packages...] I will attach the upgrade log and report files. The root partition is on a /dev/mapper but I did not find any notes in the FAQ or Wiki that mapper volumes are a concern |
||||
Tags: | elevate, leapp | ||||
Steps To Reproduce: |
sudo dnf update sudo dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm sudo dnf install -y leapp-upgrade leapp-data-almalinux sudo leapp preupgrade [fix answer file; disable nfsd] sudo leapp preupgrade sudo leapp upgrade |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000872)
ccaudle 2023-04-28 14:38 |
This can be marked as duplicate of 387, I got an error response when I attempted to enter this, did not realize it actually created an issue entry, then re-entered the information again which created 387. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
222 | [AlmaLinux-8] openldap | feature | always | 2022-04-26 17:46 | 2023-04-04 14:26 |
Reporter: | jeriedel24 | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Request for package openldap-servers to be added to the repository | ||||
Description: |
Our software developers need an installation of OpenLDAP server (in addition to 389-ds server) for their unit tests, because they have to test their LDAP client software against both kinds of LDAP server. Would it be possible that you add the package openldap-servers to the AlmaLinux repository? The version of openldap-servers should match the version of the packages openldap and openldap-clients that are part of AlmaLinux. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | The package openldap-servers is available in RockyLinux 8 (in the "plus" repository) and in CentOS 8.5 and in Centos 8-stream (in the "PowerTools" repository). | ||||
Attached Files: | |||||
Notes | |
(0000840)
gwarf 2023-03-17 10:50 |
As documented in https://bugs.almalinux.org/view.php?id=100, the openldap-servers packages is currently availalbe in https://repo.almalinux.org/almalinux/8/devel/x86_64/os/Packages/, but as indeed in CentOS Stream 8 it's present in the PowerTools repository http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/, it would be nice to have it in AlmaLinux's PowerTools too. |
(0000843)
carlwgeorge 2023-03-27 19:39 |
FYI, openldap-servers was added to the RHEL CRB repo in 8.6. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/changes-to-packages_considerations-in-adopting-rhel-8#new-packages-added-in-RHEL-8-minor-releases_changes-to-packages |
(0000847)
alukoshko 2023-04-04 14:26 |
Fixed in AlmaLinux 8. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
382 | [AlmaLinux-8] kernel | crash | always | 2023-04-03 08:22 | 2023-04-04 09:36 |
Reporter: | jiang | Platform: | x86_64 | ||
Assigned To: | OS: | almalinux | |||
Priority: | urgent | OS Version: | almalinux8.7 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | when create >100 gre tunnel devices and set master to a bridge device, the kernel will crash | ||||
Description: |
we create some gre tunnels and attach them to a bridge device. And this bridge device has an IP which is equal to gre local IP. When we add more than 100 gre tunnels, we can see kernel crash. |
||||
Tags: | almalinux8, Bug, kernel | ||||
Steps To Reproduce: |
there is a few steps: 1. almaLinux8.7 starts 2. run ./add_gre_devices.sh (my primary netwrork interface is ens33, with 192.168.131.191, netmask 255.255.255.0) then the kernel crash the add_gre_device.sh is as follows: ----------------------------------------------------START------------------------------------------------------- #!/bin/bash iptables -F ip link del dev br0 ip link add name br0 type bridge ip link set ens33 master br0 ip route del 192.168.131.0/24 ifconfig br0 192.168.131.191 ip route add 192.168.131.0/24 dev br0 for (( i = 1 ; i < 150; i++ )) do IP=`expr $i` DevName=`expr $i` echo "ip link add name ap$DevName type gretap local 192.168.131.191 remote 192.168.131.$IP && ip link set ap$DevName up && ip link set ap$DevName master br0" ip link add name ap$DevName type gretap local 192.168.131.191 remote 192.168.131.$IP && ip link set ap$DevName up && ip link set ap$DevName master br0 done -----------------------------------------------END-------------------------------------------- |
||||
Additional Information: |
In centos7, centos8, almaLinux8.7, we can see this crash issue(kernel reports double-fault). the vmcore-dmesg.txt is copied here: -----------------------------------------------START------------------------------------------ [ 496.548662] BUG: stack guard page was hit at 00000000622361f6 (stack is 00000000673d50e5..00000000ed53eb7f) [ 496.548669] kernel stack overflow (double-fault): 0000 [#1] SMP PTI [ 496.548671] CPU: 1 PID: 20 Comm: ksoftirqd/1 Kdump: loaded Tainted: G ---------r- - 4.18.0-425.3.1.el8.x86_64 #1 [ 496.548674] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 496.548675] RIP: 0010:__skb_flow_dissect+0x39/0x15d0 [ 496.548677] Code: 89 cf 41 56 41 55 49 89 d5 41 54 49 89 f4 53 44 89 cb 48 83 e4 f0 48 81 ec c0 00 00 00 44 8b 5d 10 65 48 8b 04 25 28 00 00 00 <48> 89 84 24 b8 00 00 00 31 c0 4d 85 c0 0f 84 29 07 00 00 41 0f b7 [ 496.548680] RSP: 0018:ffff9cb240aeff40 EFLAGS: 00010282 [ 496.548684] RAX: f209f5ad326b0900 RBX: 0000000000000000 RCX: ffff9cb240af0060 [ 496.548685] RDX: ffffffff8cbb8e60 RSI: ffff910264172500 RDI: 0000000000000000 [ 496.548687] RBP: ffff9cb240af0030 R08: 0000000000000000 R09: 0000000000000000 [ 496.548688] R10: 0000000000000000 R11: 0000000000000000 R12: ffff910264172500 [ 496.548690] R13: ffffffff8cbb8e60 R14: ffff91026c3df000 R15: ffff9cb240af0060 [ 496.548692] FS: 0000000000000000(0000) GS:ffff910279e40000(0000) knlGS:0000000000000000 [ 496.548693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 496.548695] CR2: ffff9cb240aeff38 CR3: 0000000060810004 CR4: 00000000000706e0 [ 496.548696] Call Trace: [ 496.548697] __skb_get_hash+0x57/0x1f0 [ 496.548699] ? nft_do_chain+0x4d0/0x4e0 [nf_tables] [ 496.548700] ip_tunnel_xmit+0x41e/0x770 [ip_tunnel] [ 496.548701] ? kmalloc_reserve+0x2e/0x80 [ 496.548703] ? __gre_xmit+0x6c/0x1f0 [ip_gre] [ 496.548704] gre_tap_xmit+0x10b/0x180 [ip_gre] [ 496.548705] dev_hard_start_xmit+0xd7/0x240 [ 496.548707] sch_direct_xmit+0x9f/0x370 [ 496.548708] __dev_queue_xmit+0x958/0xb60 [ 496.548709] ? nft_do_chain_bridge+0x70/0x190 [nf_tables] [ 496.548711] br_dev_queue_push_xmit+0xbc/0x190 [bridge] [ 496.548712] br_forward_finish+0xaf/0xc0 [bridge] [ 496.548714] ? br_fdb_offloaded_set+0x60/0x60 [bridge] [ 496.548715] __br_forward+0x156/0x1c0 [bridge] [ 496.548716] ? br_dev_queue_push_xmit+0x190/0x190 [bridge] [ 496.548718] deliver_clone+0x32/0x50 [bridge] [ 496.548719] maybe_deliver+0x91/0xd0 [bridge] [ 496.548720] br_flood+0x93/0x130 [bridge] [ 496.548722] br_dev_xmit+0x2f4/0x430 [bridge] [ 496.548723] dev_hard_start_xmit+0xd7/0x240 [ 496.548724] __dev_queue_xmit+0x80c/0xb60 [ 496.548726] ? __alloc_skb+0xe5/0x1c0 [ 496.548727] arp_xmit+0x9d/0xb0 [ 496.548728] ? arp_send_dst.part.21+0x18/0x90 [ 496.548729] arp_solicit+0xf5/0x2d0 [ 496.548731] ? kmem_cache_alloc+0x13f/0x280 [ 496.548732] neigh_probe+0x4c/0x60 [ 496.548733] __neigh_event_send+0xa3/0x370 [ 496.548734] neigh_resolve_output+0x12f/0x1a0 [ 496.548736] ip_finish_output2+0x192/0x430 [ 496.548737] ? ipv4_confirm+0x3c/0xe0 [nf_conntrack] [ 496.548738] ip_output+0x70/0xf0 [ 496.548739] ? __ip_finish_output+0x1d0/0x1d0 [ 496.548741] iptunnel_xmit+0x185/0x230 [ 496.548742] ip_tunnel_xmit+0x409/0x770 [ip_tunnel] [ 496.548849] gre_tap_xmit+0x10b/0x180 [ip_gre] [ 496.548851] dev_hard_start_xmit+0xd7/0x240 [ 496.548853] sch_direct_xmit+0x9f/0x370 [ 496.548854] __dev_queue_xmit+0x958/0xb60 [ 496.548855] ? nft_do_chain_bridge+0x70/0x190 [nf_tables] [ 496.548857] br_dev_queue_push_xmit+0xbc/0x190 [bridge] ------------------------------------------------END--------------------------------------------- And In almaLinux9.1, kernel will not crash,but print "dead loop on virtual device br0, fix it urgently" |
||||
Attached Files: | |||||
Notes | |
(0000845)
jiang 2023-04-03 08:56 |
sometimes vmcore-dmesg.txt reports: [ 6946.688867] PANIC: double fault, error_code: 0x0 [ 6946.688870] CPU: 0 PID: 83263 Comm: ip Kdump: loaded Tainted: G ---------r- - 4.18.0-425.3.1.el8.x86_64 #1 [ 6946.688871] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 6946.688872] RIP: 0010:nft_do_chain+0x25/0x4e0 [nf_tables] [ 6946.688873] Code: 00 00 00 00 00 0f 1f 44 00 00 55 b9 0a 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 49 89 fc 53 48 83 e4 f0 48 81 ec b0 01 00 00 <48> 89 34 24 4c 8d 7c 24 50 65 48 8b 04 25 28 00 00 00 48 89 84 24 [ 6946.688874] RSP: 0000:ffffb7a0fffffe50 EFLAGS: 00010286 [ 6946.688875] RAX: 0000000000000000 RBX: ffff8debf48f7800 RCX: 000000000000000a [ 6946.688876] RDX: 0000000000000014 RSI: ffff8decdb0f2550 RDI: ffffb7a100000040 [ 6946.688876] RBP: ffffb7a100000030 R08: ffff8decdd790000 R09: eaee172c602dc964 [ 6946.688877] R10: ffff8dece371ec00 R11: f488111c00000000 R12: ffffb7a100000040 [ 6946.688877] R13: ffff8decce460f00 R14: ffff8dece371ec00 R15: 000000000000002f [ 6946.688878] FS: 0000000000000000(0000) GS:ffff8decf9e00000(0000) knlGS:0000000000000000 [ 6946.688879] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6946.688879] CR2: ffffb7a0fffffe48 CR3: 000000003586e006 CR4: 00000000003706f0 [ 6946.688880] Call Trace: [ 6946.688880] <IRQ> [ 6946.688880] ? fnhe_hashfun+0x2f/0xa0 [ 6946.688907] nft_do_chain_ipv4+0x66/0x90 [nf_tables] [ 6946.688907] nf_hook_slow+0x44/0xd0 [ 6946.688907] __ip_local_out+0xd7/0x140 [ 6946.688908] ? ip_forward_options.cold.8+0x18/0x18 [ 6946.688908] ip_local_out+0x17/0x50 [ 6946.688909] iptunnel_xmit+0x185/0x230 [ 6946.688909] ip_tunnel_xmit+0x409/0x770 [ip_tunnel] [ 6946.688909] gre_tap_xmit+0x10b/0x180 [ip_gre] [ 6946.688910] dev_hard_start_xmit+0xd7/0x240 [ 6946.688910] sch_direct_xmit+0x9f/0x370 [ 6946.688911] __dev_queue_xmit+0x958/0xb60 [ 6946.688911] ? nft_do_chain_bridge+0x70/0x190 [nf_tables] [ 6946.688912] br_dev_queue_push_xmit+0xbc/0x190 [bridge] [ 6946.688912] br_forward_finish+0xaf/0xc0 [bridge] [ 6946.688912] ? br_fdb_offloaded_set+0x60/0x60 [bridge] [ 6946.688913] __br_forward+0x156/0x1c0 [bridge] [ 6946.688914] ? br_dev_queue_push_xmit+0x190/0x190 [bridge] [ 6946.688914] deliver_clone+0x32/0x50 [bridge] [ 6946.688914] maybe_deliver+0x91/0xd0 [bridge] [ 6946.688915] br_flood+0x93/0x130 [bridge] [ 6946.688915] br_dev_xmit+0x2f4/0x430 [bridge] [ 6946.688916] dev_hard_start_xmit+0xd7/0x240 [ 6946.688916] __dev_queue_xmit+0x80c/0xb60 [ 6946.688916] ? __alloc_skb+0xe5/0x1c0 [ 6946.688917] arp_xmit+0x9d/0xb0 [ 6946.688917] ? arp_send_dst.part.21+0x18/0x90 [ 6946.688918] arp_solicit+0xf5/0x2d0 [ 6946.688918] ? kmem_cache_alloc+0x13f/0x280 [ 6946.688918] neigh_probe+0x4c/0x60 [ 6946.688919] __neigh_event_send+0xa3/0x370 [ 6946.688919] neigh_resolve_output+0x12f/0x1a0 [ 6946.688920] ip_finish_output2+0x192/0x430 [ 6946.688920] ? ipv4_confirm+0x3c/0xe0 [nf_conntrack] [ 6946.688921] ip_output+0x70/0xf0 [ 6946.688921] ? __ip_finish_output+0x1d0/0x1d0 [ 6946.688921] iptunnel_xmit+0x185/0x230 [ 6946.688922] ip_tunnel_xmit+0x409/0x770 [ip_tunnel] [ 6946.688922] gre_tap_xmit+0x10b/0x180 [ip_gre] [ 6946.688923] dev_hard_start_xmit+0xd7/0x240 |
(0000846)
jiang 2023-04-04 09:36 |
currently we find that this crash is due to "stack overflew", and this is a dev_hard_start_xmit loop Becuase our route is 192.168.131.0/24 dev br0, so arp packet before gre packet will be locally sent out by dev_hard_start_xmit(then br_dev_xmit will be called). But br_dev_xmit will call br_flood to send this packet to gretap device again, then ip_tunnel_xmit will be called again, and then dev_hard_start_xmit(===>br_dev_xmit) will be called again. In this way the stack overflows. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
365 | [AlmaLinux-8] kernel | major | sometimes | 2023-01-25 21:26 | 2023-03-28 11:22 |
Reporter: | pascal76 | Platform: | |||
Assigned To: | OS: | almalinux | |||
Priority: | high | OS Version: | 9 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | warning: %posttrans(kernel-core-5.14.0-162.12.1.el9_1.x86_64) scriptlet failed, exit status 1 | ||||
Description: |
On my server: yum reinstall kernel-core-5.14.0-162.12.1.el9_1.x86_64 (same error for yum install) Running transaction Preparing : 1/1 Reinstalling : kernel-core-5.14.0-162.12.1.el9_1.x86_64 1/2 Running scriptlet: kernel-core-5.14.0-162.12.1.el9_1.x86_64 1/2 Running scriptlet: kernel-core-5.14.0-162.12.1.el9_1.x86_64 2/2 Cleanup : kernel-core-5.14.0-162.12.1.el9_1.x86_64 2/2 Running scriptlet: kernel-core-5.14.0-162.12.1.el9_1.x86_64 2/2 dracut: dracut module 'lvm' cannot be found or installed. warning: %posttrans(kernel-core-5.14.0-162.12.1.el9_1.x86_64) scriptlet failed, exit status 1 Error in POSTTRANS scriptlet in rpm package kernel-core Verifying : kernel-core-5.14.0-162.12.1.el9_1.x86_64 1/2 Verifying : kernel-core-5.14.0-162.12.1.el9_1.x86_64 2/2 Reinstalled: kernel-core-5.14.0-162.12.1.el9_1.x86_64 Then: /boot/initramfs-5.14.0-162.12.1.el9_1.x86_64.img is not added and we can't boot anymore (we can't even choose the kernel !) If you reinstall the package and the file already exists, then the scriptlet delete it ! |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000796)
pascal76 2023-01-25 21:27 |
it happened on one of my server only Not on the second one which is similar Not on the 3rd one which has got other hardware |
(0000797)
pascal76 2023-01-26 09:40 |
it impacts almalinux 9 (sorry it is classified as almalinux 8 and I don't know how to change that) |
(0000798)
toracat 2023-01-27 18:08 |
@pascal76 On the server that has the issue, do you have enough space on /boot ? |
(0000799)
pascal76 2023-01-27 18:09 |
df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur devtmpfs 4,0M 0 4,0M 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 6,2G 840K 6,2G 1% /run /dev/md126 443G 173G 271G 39% / /dev/md125 200M 7,0M 193M 4% /boot/efi tmpfs 3,1G 0 3,1G 0% /run/user/0 |
(0000800)
pascal76 2023-01-27 18:09 |
YES ! |
(0000801)
toracat 2023-01-27 18:20 |
Do the 2 servers without the issue have the same/similar configuration? |
(0000802)
pascal76 2023-01-27 18:27 |
in theory yes Same server: https://www.ovhcloud.com/en-gb/bare-metal/advance/adv-3/ About software, here is the diff: rpm -qa > a && ssh bdd2 rpm -qa >> a && cat a | sort | uniq -c |grep -v " 2 " 1 bubblewrap-0.4.1-6.el9.x86_64 1 cabextract-1.9.1-3.el9.x86_64 1 cloud-utils-growpart-0.31-10.el9.x86_64 1 CUnit-2.1.3-25.el9.x86_64 1 device-mapper-multipath-0.8.7-12.el9_1.1.x86_64 1 device-mapper-multipath-libs-0.8.7-12.el9_1.1.x86_64 1 dracut-config-generic-057-13.git20220816.el9.x86_64 1 dracut-config-rescue-057-13.git20220816.el9.x86_64 1 expat-devel-2.4.9-1.el9_1.1.x86_64 1 fwupd-1.7.9-1.el9.alma.1.x86_64 1 glibc-langpack-en-2.34-40.el9_1.1.x86_64 1 glibc-minimal-langpack-2.34-40.el9_1.1.x86_64 1 grub2-pc-2.06-46.el9.alma.x86_64 1 grub2-pc-modules-2.06-46.el9.alma.noarch 1 grub2-tools-efi-2.06-46.el9.alma.x86_64 1 grub2-tools-extra-2.06-46.el9.alma.x86_64 1 iproute-tc-5.18.0-1.el9.x86_64 1 iwl1000-firmware-39.31.5.1-127.el9.noarch 1 iwl100-firmware-39.31.5.1-127.el9.noarch 1 iwl105-firmware-18.168.6.1-127.el9.noarch 1 iwl135-firmware-18.168.6.1-127.el9.noarch 1 iwl2000-firmware-18.168.6.1-127.el9.noarch 1 iwl2030-firmware-18.168.6.1-127.el9.noarch 1 iwl3160-firmware-25.30.13.0-127.el9.noarch 1 iwl5000-firmware-8.83.5.1_1-127.el9.noarch 1 iwl5150-firmware-8.24.2.2-127.el9.noarch 1 iwl6000g2a-firmware-18.168.6.1-127.el9.noarch 1 iwl6050-firmware-41.28.5.1-127.el9.noarch 1 iwl7260-firmware-25.30.13.0-127.el9.noarch 1 json-glib-1.6.6-1.el9.x86_64 1 kernel-5.14.0-162.12.1.el9_1.x86_64 1 kernel-5.14.0-162.6.1.el9_1.x86_64 1 kernel-core-5.14.0-70.30.1.el9_0.x86_64 1 kernel-modules-5.14.0-162.12.1.el9_1.x86_64 1 kernel-modules-5.14.0-162.6.1.el9_1.x86_64 1 langpacks-core-en-3.0-16.el9.noarch 1 langpacks-en-3.0-16.el9.noarch 1 libcap-ng-python3-0.8.2-7.el9.x86_64 1 libevent-devel-2.1.12-6.el9.x86_64 1 libgcab1-1.4-6.el9.x86_64 1 libgusb-0.3.8-1.el9.x86_64 1 libiscsi-1.19.0-5.el9.x86_64 1 libiscsi-utils-1.19.0-5.el9.x86_64 1 libjcat-0.1.6-3.el9.x86_64 1 librdmacm-41.0-3.el9.x86_64 1 libsmbios-2.4.3-4.el9.x86_64 1 libusbx-1.0.26-1.el9.x86_64 1 libxmlb-0.3.3-1.el9.x86_64 1 linux-firmware-20220708-127.el9.noarch 1 mokutil-0.4.0-9.el9.x86_64 1 NetworkManager-config-server-1.40.0-1.el9.noarch 1 nodejs-16.18.1-3.el9_1.x86_64 1 nodejs-docs-16.18.1-3.el9_1.noarch 1 nodejs-full-i18n-16.18.1-3.el9_1.x86_64 1 nodejs-libs-16.18.1-3.el9_1.x86_64 1 npm-8.19.2-1.16.18.1.3.el9_1.x86_64 1 openssl-devel-3.0.1-43.el9_0.x86_64 1 python-unversioned-command-3.9.14-1.el9_1.1.noarch 1 qemu-guest-agent-7.0.0-13.el9.x86_64 1 shim-x64-15.6-1.el9.alma.x86_64 1 systemd-devel-250-12.el9_1.1.x86_64 1 tcpdump-4.99.0-6.el9.x86_64 It should be the same but I think I installed the first server (not impacted) differently Is it possibile to have the (debug) logs of "scriptlet failed, exit status 1" ? |
(0000803)
toracat 2023-01-27 18:33 |
I'm interested in the size of /boot. You don't seem to have /boot but only /boot/efi. There are some reports that indicate 200M is not enough for /boot/efi. So wondered if the 2 "good" servers have a larger size. |
(0000804)
pascal76 2023-01-27 18:39 |
server 1: Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/md125 201M 7,0M 194M 4% /boot/efi dev server: Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/md125 200M 7,0M 193M 4% /boot/efi du -hsc /boot 240M /boot on dev and server1 107M on the impacted server |
(0000805)
toracat 2023-01-27 19:02 |
> 240M /boot on dev and server1 > 107M on the impacted server It's less on the server that fails? Anyway the links I looked at were (FYI): https://bugzilla.redhat.com/show_bug.cgi?id=1844423 "Bug 1844423 - /boot size 200Mib is not enough " https://ask.fedoraproject.org/t/f36-kernel-wont-install-due-to-running-out-of-space-in-boot-efi/22498 "F36 kernel won’t install due to running out of space in /boot/efi" |
(0000806)
pascal76 2023-01-27 19:13 |
>It's less on the server that fails? Yes, because the server is more recent There are less kernels on it |
(0000807)
pascal76 2023-01-27 19:17 |
sorry the space size of the faulty server was incorrect (I gave the data from the dev server ...) Filesystem Size Used Avail Use% Mounted on devtmpfs 4,0M 0 4,0M 0% /dev tmpfs 63G 0 63G 0% /dev/shm tmpfs 26G 50M 26G 1% /run /dev/md126 863G 53G 810G 7% / /dev/md127 1016M 138M 878M 14% /boot /dev/nvme0n1p1 511M 2,5M 509M 1% /boot/efi |
(0000844)
pascal76 2023-03-28 11:22 |
The bug : it was due to this file from OVH ... /etc/dracut.conf.d/98-ovh.conf logfile=/var/log/dracut.log fileloglvl=6 add_dracutmodules+=" lvm mdraid " add_drivers+=" 8139too e1000 e1000e igb r8169 dm-raid raid0 raid1 raid10 raid456 mlx4_en mptspi mptsas ixgbe nvme " hostonly="yes" |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
27 | [AlmaLinux-8] open-vm-tools | major | always | 2021-02-24 15:17 | 2023-03-06 19:40 |
Reporter: | corporategadfly | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | high | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Guest customization fails in vmware when using AlmaLinux 8.3 RC as source template | ||||
Description: |
In an enterprise setting, it is typical to use a source VM template and then deploy multiple VMs using that template. Unfortunately, guest customizations (e.g., setting of hostname, interface settings, DNS, etc.) fails during VM deploy. See https://github.com/vmware/open-vm-tools/issues/497 for some investigative work. To help adoption of AlmaLinux, deployment using vmware (with templates) is essential. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: |
almalinux-bug-27-almalinux-8.4-failed-toolsDeployPkg.log (29,059 bytes) 2021-05-07 20:23 https://bugs.almalinux.org/file_download.php?file_id=75&type=bug almalinux-bug-27-centos-8-toolsDeployPkg.log (25,435 bytes) 2021-05-07 20:23 https://bugs.almalinux.org/file_download.php?file_id=76&type=bug open-vm-tools-11.1.0-2.el8.alma.x86_64.rpm (732,076 bytes) 2021-05-07 21:13 https://bugs.almalinux.org/file_download.php?file_id=77&type=bug open-vm-tools-sdmp-11.1.0-2.el8.alma.x86_64.rpm (37,804 bytes) 2021-05-07 21:13 https://bugs.almalinux.org/file_download.php?file_id=78&type=bug open-vm-tools-desktop-11.1.0-2.el8.alma.x86_64.rpm (196,964 bytes) 2021-05-07 21:13 https://bugs.almalinux.org/file_download.php?file_id=79&type=bug almalinux-bug-27-almalinux-8.3-with-patched-open-vm-tools-failed-toolsDeployPkg.log (29,622 bytes) 2021-05-13 01:46 https://bugs.almalinux.org/file_download.php?file_id=80&type=bug toolsDeployPkg.log (30,717 bytes) 2021-10-25 09:58 https://bugs.almalinux.org/file_download.php?file_id=99&type=bug toolsDeployPkg-2.log (8,181 bytes) 2021-11-25 20:29 https://bugs.almalinux.org/file_download.php?file_id=107&type=bug |
||||
Notes | |
(0000092)
corporategadfly 2021-03-31 14:17 |
Identical experience with AlmaLinux 8.3. |
(0000093)
alukoshko 2021-03-31 16:10 |
Please provide steps to reproduce. What VMware version are you using? What should be customized? |
(0000094)
corporategadfly 2021-03-31 16:14 |
vSphere Client version 6.7.0.46000 So, we typically customize the following: * hostname * domain * DNS entries * assignment for interfaces (typically two) Works in RHEL8 and CentOS8 (as long as perl and open-vm-tools is installed). |
(0000095)
corporategadfly 2021-03-31 16:15 |
Our VSS folks use a custom CLI for initiating the VM creation so I don't know the internal details but generic details are available at: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-EB5F090E-723C-4470-B640-50B35D1EC016.html |
(0000107)
corporategadfly 2021-04-02 01:29 |
Here is an example of a customization which sets hostname, ip addresses, DNS, etc.: <code> { "hostname": "hostname-1", "dhcp": false, "domain": "x.y.z", "dns": [ "128.x.x.x", "128.y.y.y" ], "interfaces": [ { "dhcp": false, "ip": "10.192.228.58", "mask": "255.255.255.128", "gateway": [ "10.192.228.1" ] }, { "dhcp": false, "ip": "10.192.228.186", "mask": "255.255.255.128", "gateway": [ "10.192.228.129" ] } ] } </code> |
(0000180)
corporategadfly 2021-05-06 23:08 |
Any updates? |
(0000181)
alukoshko 2021-05-07 18:19 |
Hi! I wasn't able to reproduce the problem but I haven't tried via CLI. Could you help a bit with this issue? Please attach open-vm-tools logs from AlmaLinux and from RHEL/CentOS with the same customization if you can. I'll try to find out what goes wrong and what's the difference. Also will you able to help with testing of patched open-vm-tools package if I attach it here? I have an idea how to modify it. |
(0000182)
corporategadfly 2021-05-07 18:40 |
Absolutely willing to help with testing if I get a patched open-vm-tools package. I will gather the logs as soon as I'm able to setup a new AlmaLinux template and a new VM deploy (using that template). |
(0000183)
corporategadfly 2021-05-07 20:23 |
added toolsDeployPkg.log (one from successful Centos 8 and one from failed AlmaLinux). |
(0000184)
alukoshko 2021-05-07 20:47 (Last edited: 2021-05-07 20:49) |
Well I see the difference: CentOS: INFO: Customization instance RHEL7Customization loaded. AlmaLinux: INFO: Customization instance RedHatCustomization loaded. Errors at the end of logs actually the same for both OS. |
(0000185)
alukoshko 2021-05-07 21:13 |
|
(0000186)
alukoshko 2021-05-07 21:13 |
|
(0000187)
alukoshko 2021-05-07 21:16 |
Attached files are for 8.3 stable actually but may work on 8.4 beta too I believe. Please attach log even if customization will fail again as I wanna check the difference. |
(0000191)
corporategadfly 2021-05-13 01:46 |
Here is the procedure to create a new template VM from 8.3 stable. After installing 8.3 AlmaLinux, I executed the following commands: yum remove open-vm-tools --noautoremove rpm -ivh /tmp/open-vm-tools-11.1.0-2.el8.alma.x86_64.rpm Installed perl: yum install perl After that shutdown VM and converted VM to template. Then, I used this template to create a new VM with multiple NICs. Find attached the toolsDeployPkg.log (Same detection of RedHat family as earlier - no difference). |
(0000192)
corporategadfly 2021-05-13 01:47 |
And I apologize for the delay in responding. |
(0000212)
alukoshko 2021-05-25 23:07 |
Hello. Looks like nothing can be done on open-vm-tools side. We have to wait for support from VMware. |
(0000357)
jordane fillatre 2021-10-22 08:58 |
Hi, I've just encountered the issue on the AlmaLinux release 8.4 (Electric Cheetah) and open-vm-tools.x86_64 11.2.0-2.el8 In my mind the issue is resolved by following: https://github.com/vmware/open-vm-tools/blob/master/ReleaseNotes.md#resolved-issues But Im currently unable to build package in 11.3.5 to comfirm. Where is the roadmap for package update, either for AlmaLinux or the upstream? Regards |
(0000358)
alukoshko 2021-10-22 09:13 |
Hi. RHEL 8.5 beta has version 11.2.5 CentOS Stream 8 has 11.3.5 https://koji.mbox.centos.org/koji/buildinfo?buildID=19617 Actually we don't know what version will be included in RHEL 8.5 stable. But you can try CentOS Stream 8 package to confirm. |
(0000360)
jordane fillatre 2021-10-22 12:22 |
Ok, I'm able to use the CentOS Stream 11.3.5 build as you suggested. I had to temporary update the /etc/redhat-release file content to "CentOS Linux release 8.4 (Electric Cheetah)" in order to succeed. Regards |
(0000361)
alukoshko 2021-10-22 12:37 |
What happens if you don't update /etc/redhat-release? |
(0000366)
jordane fillatre 2021-10-25 09:58 |
Hi, In the context of use of vsphere_virtual_machine terraform resource, the customisation still fail without redhat-release. In attachment the toolsDeployPkg.log file Regard |
(0000415)
drazenk 2021-11-22 14:19 |
FWIW, I had the same issue and I've worked around it by installing cloud-init (with a suitable configuration) on the template VM. Without cloud-init VmWare will run some Perl script(s) which will correctly figure out that it's running on something which is RHEL compatible, but won't find the distro name in its list. And then it falls back to the wrong configuration mechanism. It could have tried to use the same configuration mechanism as for the equivalent RHEL release and that would have probably worked fine. But instead it falls back to some other mechanism which doesn't work. I think (but am not 100% sure) it's trying to use the mechanism for the oldest RHEL release it knows about, but that doesn't work on a RHEL 8 clone. Maybe it would with some compatibility packages installed, but I wouldn't go that route. I don't know from where are those Perl scripts coming. I don't see anything Perlish in the open-vm-tools package (or its dependencies). If the Perl code is coming from VmWare hypervisor then there's nothing Alma Linux (or any other) distribution can do. But in any case, cloud-init is the new official way to configure cloned VMs and it does work once you manage to figure out how to configure it. Also doesn't have dependencies on the code which is not in the distribution. |
(0000417)
alukoshko 2021-11-22 14:56 |
Thank you drazenk for this update. I think we should add an article to wiki about that. |
(0000428)
drazenk 2021-11-25 20:29 |
I had to debug something with this, so I have more info to share. VmWare will put the relevant logs into /var/log/vmware-imc directory. I'm attaching my log when cloud-init is in use. But you can see (more or less) that VmWare tools are getting a Perl script out of thin air. :-) |
(0000834)
kunalsing thakur 2023-03-06 18:40 |
https://koji.mbox.centos.org/koji/buildinfo?buildID=23263 Is someone has tried open-vm-tools 12 |
(0000836)
kunalsing thakur 2023-03-06 19:40 |
@drazenk can you provide solution ? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
315 | [AlmaLinux-8] -OTHER | minor | always | 2022-10-27 12:55 | 2023-03-06 13:36 |
Reporter: | kamtec1 | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | growpart not working correctly when VG is set to almalinux in LVM - almalinux 8.6 | ||||
Description: |
Hi , growpart not working correctly when Volume Group is set to almalinux in LVM config If you creating a new Volume Group with different name you are ok (default centos 8 is cl) but when you are using almalinux and you try to grow LVM to partition its fails with error : NOCHANGE: partition 1 is size 205807616. it cannot be grown |
||||
Tags: | lvm | ||||
Steps To Reproduce: |
Installing clean almalinux with LVM extend disk via esxi sudo yum -y install cloud-utils-growpart check with lsblk regarding needed partition to grow growpart /dev/sda 1 |
||||
Additional Information: | cloud-utils-growpart version 0.31-3.el8 from appstream | ||||
Attached Files: |
photo_2022-10-27_15-49-14.jpg (2,590 bytes) 2022-10-27 12:55 https://bugs.almalinux.org/file_download.php?file_id=196&type=bug |
||||
Notes | |
(0000833)
kamtec1 2023-03-06 13:36 |
Same problem with almalinux 9 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
375 | [AlmaLinux-8] python2 | minor | N/A | 2023-03-01 02:10 | 2023-03-01 02:10 |
Reporter: | shenzm | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | 有python2.7版本,但是系统识别不了 | ||||
Description: |
[root@centos8-test src]# python2 -V Python 2.7.18 [root@centos8-test src]# rpm -ivh nmap-7.93-1.x86_64.rpm 错误:依赖检测失败: python >= 2.4 被 nmap-2:7.93-1.x86_64 需要 [root@centos8-test src]# |
||||
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: |
372 | [AlmaLinux-8] sssd | major | always | 2023-02-21 23:31 | 2023-02-28 20:54 |
Reporter: | michael.jamieson@zayo.com | Platform: | x86_64 | ||
Assigned To: | OS: | Almalinux 9 | |||
Priority: | normal | OS Version: | 9.1 (Lime Lynx) | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | SSSD will not start TLS | ||||
Description: |
SSSD will not start TLS encryption, update-crypto-policies is set to legacy. (2023-02-21 18:30:43): [be[default]] [resolv_gethostbyname_step] (0x2000): [RID#6] Querying files (2023-02-21 18:30:43): [be[default]] [resolv_gethostbyname_files_send] (0x0100): [RID#6] Trying to resolve A record of 'wor80ossldaps1' in files (2023-02-21 18:30:43): [be[default]] [set_server_common_status] (0x0100): [RID#6] Marking server 'wor80ossldaps1' as 'resolving name' (2023-02-21 18:30:43): [be[default]] [set_server_common_status] (0x0100): [RID#6] Marking server 'wor80ossldaps1' as 'name resolved' (2023-02-21 18:30:43): [be[default]] [be_resolve_server_process] (0x0200): [RID#6] Found address for server wor80ossldaps1: [10.206.31.37] TTL 7200 (2023-02-21 18:30:43): [be[default]] [sdap_uri_callback] (0x0400): [RID#6] Constructed uri 'ldaps://wor80ossldaps1:636' (2023-02-21 18:30:43): [be[default]] [decide_tls_usage] (0x2000): [RID#6] [ldaps://wor80ossldaps1:636] is a secure channel. No need to run START_TLS (2023-02-21 18:30:43): [be[default]] [sssd_async_socket_init_send] (0x4000): [RID#6] Using file descriptor [23] for the connection. (2023-02-21 18:30:43): [be[default]] [sssd_async_socket_init_send] (0x0400): [RID#6] Setting 6 seconds timeout [ldap_network_timeout] for connecting (2023-02-21 18:30:43): [be[default]] [sss_ldap_init_sys_connect_done] (0x0020): [RID#6] ldap_install_tls failed: [Connect error] [error:0A000102:SSL routin es::unsupported protocol] (2023-02-21 18:30:43): [be[default]] [sss_ldap_init_state_destructor] (0x0400): [RID#6] calling ldap_unbind_ext for ldap:[0x5610fcee7ea0] sd:[23] |
||||
Tags: | |||||
Steps To Reproduce: | Configure LDAP authentication using sssd. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000827)
michael.jamieson@zayo.com 2023-02-28 20:54 |
here are some sssd_default logs with debigging enabled (2023-02-28 15:48:19): [be[default]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (2023-02-28 15:48:19): [be[default]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'mrhmonbdh17-ldps' in files (2023-02-28 15:48:19): [be[default]] [set_server_common_status] (0x0100): Marking server 'mrhmonbdh17-ldps' as 'resolving name' (2023-02-28 15:48:19): [be[default]] [set_server_common_status] (0x0100): Marking server 'mrhmonbdh17-ldps' as 'name resolved' (2023-02-28 15:48:19): [be[default]] [be_resolve_server_process] (0x0200): Found address for server mrhmonbdh17-ldps: [10.207.31.37] TTL 7200 (2023-02-28 15:48:19): [be[default]] [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: [Connect error] [error:0A000102:SSL routines::unsu pported protocol] ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * [be[default]] [become_user] (0x0200): Trying to become user [0][0]. * [be[default]] [become_user] (0x0200): Already user [0]. * [be[default]] [sss_set_sssd_user_eid] (0x0080): Failed to set egid to 990: Operation not permitted * [be[default]] [ldb] (0x0400): server_sort:Unable to register control with rootdse! * (2023-02-28 15:48:19): [be[default]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb * (2023-02-28 15:48:19): [be[default]] [dp_get_options] (0x0400): Option lookup_family_order has value ipv4_first * (2023-02-28 15:48:19): [be[default]] [dp_get_options] (0x0400): Option dns_resolver_timeout has value 6 * (2023-02-28 15:48:19): [be[default]] [dp_get_options] (0x0400): Option dns_resolver_op_timeout has value 3 * (2023-02-28 15:48:19): [be[default]] [dp_get_options] (0x0400): Option dns_resolver_server_timeout has value 1000 * (2023-02-28 15:48:19): [be[default]] [dp_get_options] (0x0400): Option dns_discovery_domain has no value * (2023-02-28 15:48:19): [be[default]] [be_res_get_opts] (0x0100): Lookup order: ipv4_first * (2023-02-28 15:48:19): [be[default]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel * (2023-02-28 15:48:19): [be[default]] [fo_context_init] (0x0400): Created new fail over context, retry timeout is 30 * (2023-02-28 15:48:19): [be[default]] [confdb_init_domain_provider_and_enum] (0x0400): No enumeration for [default]! * (2023-02-28 15:48:19): [be[default]] [confdb_init_domain_provider_and_enum] (0x0400): Please note that when enumeration is disabled `getent passwd` d oes not return all users by design. See sssd.conf man page for more detailed information * (2023-02-28 15:48:19): [be[default]] [confdb_init_domain_pwd_expire] (0x1000): pwd_expiration_warning is -1 * (2023-02-28 15:48:19): [be[default]] [sysdb_domain_init_internal] (0x0200): DB File for default: /var/lib/sss/db/cache_default.ldb * (2023-02-28 15:48:19): [be[default]] [sysdb_domain_init_internal] (0x0200): Timestamp file for default: /var/lib/sss/db/timestamps_default.ldb * (2023-02-28 15:48:19): [be[default]] [sysdb_ldb_connect] (0x4000): No ldb module path set in env * (2023-02-28 15:48:19): [be[default]] [ldb] (0x0400): asq: Unable to register control with rootdse! * (2023-02-28 15:48:19): [be[default]] [sysdb_ldb_connect] (0x4000): No ldb module path set in env * (2023-02-28 15:48:19): [be[default]] [sss_domain_get_state] (0x1000): Domain default is Active * (2023-02-28 15:48:19): [be[default]] [sss_names_init_from_args] (0x0100): Using re [(?P<name>[^@]+)@?(?P<domain>[^@]*$)]. * (2023-02-28 15:48:19): [be[default]] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. @@@ |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
373 | [AlmaLinux-8] systemd | minor | have not tried | 2023-02-24 14:00 | 2023-02-26 18:37 |
Reporter: | tnewton | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Unable to boot AlmaLinux with systemd under WSL | ||||
Description: |
It seems that AlmaLinux 8 will not boot using systemd under WSL. Adding: [boot] systemd=true to /etc/wsl.conf and restarting the WSL service does not appear to work. The problem was not observed in AlmaLinux 9 under WSL. |
||||
Tags: | |||||
Steps To Reproduce: |
1. Install WSL and AlmaLinux 8 from the Microsoft Store 2. Edit /etc/wsl.conf and add: [boot] systemd=true 3. Restart WSL 4. Launch AlmaLinux 8 and attempt to start/stop/restart a service using systemctl 5. Receive error that the system was not booted with systemd. |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000825)
alukoshko 2023-02-26 18:37 |
Hello. Is the same happen in fully updated system? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
374 | [AlmaLinux-8] -OTHER | feature | always | 2023-02-24 20:13 | 2023-02-24 20:20 |
Reporter: | oleman | Platform: | |||
Assigned To: | OS: | 8.7 | |||
Priority: | normal | OS Version: | x86_64(Py3.7.8) | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Prevent hibernate on laptop lid close | ||||
Description: | In prior versions of AlmaLinux could change /etc/systemd/logind.conf and pervent shutdown when closing laptop lid | ||||
Tags: | |||||
Steps To Reproduce: |
Disable system-wide lid actions by editing /etc/systemd/logind.conf to ingore: HandleLidSwitch=ingore HandleLidSwitchExternalPower=ingore HandleLidSwitchDocked=ingore |
||||
Additional Information: |
No longer works in latest version of AlmaLinux 8. Closing lid shuts down system |
||||
Attached Files: | |||||
Notes | |
(0000824)
oleman 2023-02-24 20:20 |
current settings |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
370 | [AlmaLinux-8] dnf | major | always | 2023-02-15 14:25 | 2023-02-21 12:39 |
Reporter: | James_azda.gov | Platform: | Azure VM | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Dnf failing to install HTTPD | ||||
Description: |
dnf -y install httpd --refresh Downloads and starts to install httpd Then gets an error and fails |
||||
Tags: | |||||
Steps To Reproduce: | dnf -y install httpd --refresh | ||||
Additional Information: | See output of dnf -y -vvv install httpd --refresh uploaded | ||||
Attached Files: |
apache-Install.txt (5,348 bytes) 2023-02-15 14:25 https://bugs.almalinux.org/file_download.php?file_id=210&type=bug |
||||
Notes | |
(0000812)
alukoshko 2023-02-18 15:54 (Last edited: 2023-02-18 15:54) |
Looks like you had httpd installed before? Because there are config files already present. I can't reproduce this with clean install. Could you provide steps? |
(0000820)
James_azda.gov 2023-02-21 12:34 |
It was working back in December, and January when I tested it. not sure what removed httpd. We are in the process of migrating from CentOS 7 at a local datacenter on kvm hosts, to AlmnaLinux 8 in azure. I'm going to recheck the dnf history and see what I can find. |
(0000821)
James_azda.gov 2023-02-21 12:38 |
moved the old /etc/httpd to another location and it appears to have installed. Now to copy the configs between them. |
(0000822)
James_azda.gov 2023-02-21 12:39 |
Confused why an existing config file would cause a check sum error though. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
369 | [AlmaLinux-8] file | minor | always | 2023-02-10 08:31 | 2023-02-10 08:31 |
Reporter: | olahaye74 | Platform: | aarch64 | ||
Assigned To: | OS: | AlmaLinux 8 | |||
Priority: | normal | OS Version: | 8.7 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | file does not detect that /boot/vmlinuz-$version.aarch64 is a Linux kernel. | ||||
Description: |
file does not detect that /boot/vmlinuz-$version.aarch64 is a Linux kernel. It only reports: - gzip compressed data, was "Image", last modified .... instead of reporting - Linux kernel aarch64 boot executable bzImage, version ..... If I gzcat the kernel | file - it reports MSDOS executable (even worse even if in fact it is. |
||||
Tags: | file, kernel, version | ||||
Steps To Reproduce: |
try command on x86_64 and on aarch64 architectures and you'll notice the difference: file /boot/vmlinu* |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
251 | [AlmaLinux-8] abrt | crash | always | 2022-05-29 16:15 | 2023-01-23 14:31 |
Reporter: | brianjmurrell | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | high | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | 'report_AlmaLinuxBugTracker' exited with 1 | ||||
Description: |
# abrt-cli report 74eaa4767c18c0d20c76df529377307f46fdcbcc ('report_uReport' completed successfully) Ok to upload core dump? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. (It may download a huge amount of data). [y/N/f/e] n Analyzing coredump 'coredump' Coredump references 62 debuginfo files, 31 of them are not installed Initializing package manager Setting up repositories Looking for needed packages in repositories Can't find packages for 1 debuginfo files Removing /var/tmp/abrt-tmp-debuginfo-2022-05-29-11:50:06.4131526 Missing debuginfo file: /usr/lib/debug/.build-id/f9/c39c0e3b76999296fde2908a6cc04b0b02559c.debug Generating backtrace Backtrace is generated and saved, 51206 bytes AlmaLinux Bug Tracker User name: brianjmurrell AlmaLinux Bug Tracker Password: The report has been updated Checking for duplicates Creating a new issue Can't generate stacktrace description (no crash thread?) Adding External URL to issue ('report_AlmaLinuxBugTracker' exited with 1) |
||||
Tags: | |||||
Steps To Reproduce: | See above. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000792)
brianjmurrell 2023-01-23 14:31 |
Any update here? This makes it impossible to report segfaults and other crashes to your bug system. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
358 | [AlmaLinux-8] postfix | minor | always | 2023-01-18 07:42 | 2023-01-18 07:42 |
Reporter: | h.sattar | Platform: | Linux | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | postfix service doesn't start on boot while opendkim service is integrated with it | ||||
Description: | When postfix is integrated with opendkim service, if you reboot the system, postfix service doesn't restart automatically. | ||||
Tags: | |||||
Steps To Reproduce: |
STEP 1: Install packages Postfix and Opendkim. Then configure them according to send signed emails. STEP 2: Now edit the file, /etc/postfix/main.cf and add the following lines, to integrate Opendkim with postfix. # The following configuration will attach DKIM signature for every outgoing mail and will help to make the email more authentic # so receipent server will not treat as SPAM smtpd_milters = inet:127.0.0.1:8891 non_smtpd_milters = $smtpd_milters milter_default_action = accept milter_protocol = 6 STEP 3: Now reboot the server. |
||||
Additional Information: | Actually postfix relies on opendkim service while postfix is integrated with opendkim for signing the emails. So on system reboot, postfix could not start until opendkim service is on. And opendkim may be taking more time than the postfix service on event. | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
355 | [AlmaLinux-8] -OTHER | major | always | 2023-01-05 15:14 | 2023-01-05 17:59 |
Reporter: | SteveJibson | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.7 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | container-tools dnf module (rhel8) missing latest version of fuse-overlayfs | ||||
Description: |
The "rhel8" module version of the container-tools includes a version of "fuse-overlayfs" that is older than the version included in Red Hat Enterprise 8 (and Rocky Linux 8, Oracle Linux 8). RHEL8: : fuse-overlayfs-0:1.9-1.module+el8.7.0+17064+3b31f55c.src : fuse-overlayfs-0:1.9-1.module+el8.7.0+17064+3b31f55c.x86_64 : fuse-overlayfs-debuginfo-0:1.9-1.module+el8.7.0+17064+3b31f55c.x86_64 : fuse-overlayfs-debugsource-0:1.9-1.module+el8.7.0+17064+3b31f55c.x86_64 AlmaLinux 8.7: : fuse-overlayfs-0:1.9-1.module_el8.6.0+3070+1510fbd1.src : fuse-overlayfs-0:1.9-1.module_el8.6.0+3070+1510fbd1.x86_64 : fuse-overlayfs-debuginfo-0:1.9-1.module_el8.6.0+3070+1510fbd1.x86_64 : fuse-overlayfs-debugsource-0:1.9-1.module_el8.6.0+3070+1510fbd1.x86_64 |
||||
Tags: | almalinux8, dnf | ||||
Steps To Reproduce: |
Execute this command on a RHEL8 system and an AlmaLinux system: "dnf module info container-tools:rhel8 | grep fuse-overlayfs" |
||||
Additional Information: | fuse-overlayfs-debugsource-0:1.9-1.module_el8.6.0 includes a security vulnerability that has been addressed in fuse-overlayfs-debugsource-0:1.9-1.module+el8.7.0. | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
304 | [AlmaLinux-8] -OTHER | major | always | 2022-09-19 15:33 | 2023-01-05 17:25 |
Reporter: | abotelho | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Pulp 3 synchronizations failing because of Advisory issues. ALSA-2022:1762 in particular. | ||||
Description: |
"Incoming and existing advisories have the same id and timestamp but different and intersecting package lists, and neither package list is a proper subset of the other. At least one of the advisories is wrong. To allow this behavior, set ALLOW_AUTOMATIC_UNSAFE_ADVISORY_CONFLICT_RESOLUTION = True (q.v.) in your configuration. Advisory id: ALSA-2022:1762" I receive the above error while trying to synchronize our Pulp repositories. Even enabling ALLOW_AUTOMATIC_UNSAFE_ADVISORY_CONFLICT_RESOLUTION fails, as the backend PostgreSQL database spits out: "2022-09-19 15:21:36.593 UTC [19311] ERROR: duplicate key value violates unique constraint "core_artifact_sha256_key" 2022-09-19 15:21:36.593 UTC [19311] DETAIL: Key (sha256)=(dfe49eec7de8a49933ea921f884fac99ea6cd80cb87cbb5de09f1ca7b6ce606b) already exists." |
||||
Tags: | |||||
Steps To Reproduce: | Synchronize AlmaLinux 8 BaseOS using Pulp 3. | ||||
Additional Information: | This is a major issue as it prevents the deployment of updates to our systems. | ||||
Attached Files: | |||||
Notes | |
(0000710)
abotelho 2022-10-18 15:15 |
Has anyone looked at this? We still receive this failure. cheers |
(0000714)
abotelho 2022-11-09 16:43 |
AlmaLinux8-BaseOS { "traceback": " File \"/usr/local/lib/python3.8/site-packages/pulpcore/tasking/pulpcore_worker.py\", line 445, in _perform_task result = func(*args, **kwargs) File \"/usr/local/lib/python3.8/site-packages/pulp_rpm/app/tasks/synchronizing.py\", line 547, 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/local/lib/python3.8/site-packages/pulpcore/app/models/repository.py\", line 1044, in __exit__ repository.finalize_new_version(self) File \"/usr/local/lib/python3.8/site-packages/pulp_rpm/app/models/repository.py\", line 308, in finalize_new_version resolve_advisories(new_version, previous_version) File \"/usr/local/lib/python3.8/site-packages/pulp_rpm/app/advisory.py\", line 136, in resolve_advisories to_add, to_remove, to_exclude = resolve_advisory_conflict( File \"/usr/local/lib/python3.8/site-packages/pulp_rpm/app/advisory.py\", line 261, in resolve_advisory_conflict raise AdvisoryConflict( ", "description": "Incoming and existing advisories have the same id and timestamp but different and intersecting package lists, and neither package list is a proper subset of the other. At least one of the advisories is wrong. To allow this behavior, set ALLOW_AUTOMATIC_UNSAFE_ADVISORY_CONFLICT_RESOLUTION = True (q.v.) in your configuration. Advisory id: ALSA-2022:1762" } This is from Monday's sync. This appears to still be broken. |
(0000752)
abotelho 2022-11-29 15:28 |
FYI it looks like this was correct when the 8.7 update was pushed out! |
(0000755)
danfimov 2022-12-02 10:39 |
Hi, this issue is still actual? |
(0000786)
abotelho 2023-01-05 17:25 |
This issue has definitely resolved itself when 8.7 was released. I can't say if it's still present if you explicitly point your Pulp server to 8.6. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
354 | [AlmaLinux-8] container-selinux | major | always | 2023-01-05 13:42 | 2023-01-05 14:19 |
Reporter: | marcli | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | updated container-selinux packages are not installed | ||||
Description: |
dnf does now find any updated packages, even though there are several. |
||||
Tags: | |||||
Steps To Reproduce: |
# rpm -q container-selinux container-selinux-2.189.0-1.module_el8.6.0+3336+00d107d5.noarch # dnf clean all 39 files removed # dnf upgrade container-selinux AlmaLinux 8 - BaseOS 3.1 MB/s | 2.9 MB 00:00 AlmaLinux 8 - AppStream 9.7 MB/s | 10 MB 00:01 AlmaLinux 8 - Extras 28 kB/s | 18 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 34 MB/s | 13 MB 00:00 Dependencies resolved. Nothing to do. Complete! But if I look at the repos, I can see there is newer versions available: [ ] container-selinux-2.189.0-1.module_el8.6.0+3336+00d107d5.noarch.rpm 2022-10-25 23:49 58K [ ] container-selinux-2.189.0-1.module_el8.7.0+3297+1eb250cf.noarch.rpm 2022-10-11 14:26 54K [ ] container-selinux-2.189.0-1.module_el8.7.0+3344+5bcd850f.noarch.rpm 2022-11-09 09:47 59K I have tested different mirrors of the repos, and same issue. |
||||
Additional Information: |
# cat /etc/redhat-release AlmaLinux release 8.7 (Stone Smilodon) |
||||
Attached Files: | |||||
Notes | |
(0000783)
marcli 2023-01-05 13:44 |
I noticed this issues as I was trying to patch for https://errata.almalinux.org/8/ALSA-2022-7822.html |
(0000784)
marcli 2023-01-05 13:50 |
Even when trying to do a clean install of the package, it picks the older version: # dnf clean all 28 files removed # dnf install container-selinux AlmaLinux 8 - BaseOS 5.1 MB/s | 2.9 MB 00:00 AlmaLinux 8 - AppStream 14 MB/s | 10 MB 00:00 AlmaLinux 8 - Extras 36 kB/s | 18 kB 00:00 Dependencies resolved. Package Architecture Version Repository Size =========================================================================================================================================================================================================================================================== Installing: container-selinux noarch 2:2.189.0-1.module_el8.6.0+3336+00d107d5 appstream 58 k |
(0000785)
marcli 2023-01-05 14:19 |
Maybe this is not an issue with just this package. # yum updateinfo list sec Last metadata expiration check: 0:19:25 ago on Thu 05 Jan 2023 02:57:41 PM CET. ALSA-2022:7822 Low/Sec. container-selinux-2:2.189.0-1.module_el8.7.0+3344+5bcd850f.noarch ALSA-2022:1762 Important/Sec. criu-3.15-3.module_el8.6.0+2877+8e437bf5.x86_64 ALSA-2022:7822 Low/Sec. criu-3.15-3.module_el8.6.0+2877+8e437bf5.x86_64 ALSA-2022:7822 Low/Sec. fuse-overlayfs-1.9-1.module_el8.7.0+3344+5bcd850f.x86_64 # yum update Last metadata expiration check: 0:20:28 ago on Thu 05 Jan 2023 02:57:41 PM CET. Dependencies resolved. Nothing to do. Complete! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
349 | [AlmaLinux-8] dnf | major | always | 2022-12-21 19:01 | 2022-12-22 16:09 |
Reporter: | cPanelSrTechAnalysts | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux 8 yum/dnf repos provide out of date version of libzip | ||||
Description: |
Currently, both versions of libzip (1.5.1-2 and 1.5.2-1) exist here: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/Packages/ But for some reason, 1.51-2 is still getting grabbed by dnf and cannot be updated. # rpm -q libzip libzip-1.5.1-2.module_el8.3.0+2010+7c76a223.x86_64 # dnf update libzip Last metadata expiration check: 3:14:28 ago on Wed 21 Dec 2022 01:41:45 PM UTC. Dependencies resolved. Nothing to do. Complete! # dnf update Last metadata expiration check: 3:14:32 ago on Wed 21 Dec 2022 01:41:45 PM UTC. Dependencies resolved. Nothing to do. Complete! # rpm -q libzip libzip-1.5.1-2.module_el8.3.0+2010+7c76a223.x86_64 |
||||
Tags: | |||||
Steps To Reproduce: |
# rpm -e --nodeps libzip # dnf install libzip Last metadata expiration check: 0:36:05 ago on Wed 21 Dec 2022 06:01:22 PM UTC. Dependencies resolved. ============================================================================================================================================================= Package Architecture Version Repository Size ============================================================================================================================================================= Installing: libzip x86_64 1.5.1-2.module_el8.3.0+2010+7c76a223 appstream 61 k Transaction Summary ============================================================================================================================================================= Install 1 Package Total download size: 61 k Installed size: 108 k Is this ok [y/N]: |
||||
Additional Information: |
This is causing our AWS Marketplace listing to be removed. Amazon has a security scanner that looks for packages related to known CVEs. Although this version of libzip isn't directly affected, it was mentioned as one of the updated packages in connection with CVE-2019-11043 (SEE: https://errata.almalinux.org/8/ALSA-2019-3735.html ). It appears that Amazon's scanner, not knowing any better, assumes that all listed packages are vulnerable. |
||||
Attached Files: | |||||
Notes | |
(0000778)
cPanelSrTechAnalysts 2022-12-22 16:09 |
Apologies. We found that the issue is not with AlmaLinux, but with Amazon. We found that on AL8, libzip is provided by the 'php' dnf module; switching from php 7.2 to 7.3 (dnf -y module switch-to php:7.3) also causes libzip 1.5.2-1 version to be pulled in. This solution works for us because it doesn't require circumventing the packaging system. It would still be helpful if the AL8 EC2 image were compatible with the AWS security scanner, but that's not a packaging issue. We can close this ticket out. Sorry for any confusion. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
337 | [AlmaLinux-8] almalinux-release | feature | N/A | 2022-11-29 19:28 | 2022-12-22 15:04 |
Reporter: | jcpunk | 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: | |||||
abrt_hash: | |||||
URL: | |||||
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 | |
(0000753)
jcpunk 2022-11-29 19:29 |
A similar fix would be welcome in AlmaLinux 9 as well. |
(0000777)
jcpunk 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: |
290 | [AlmaLinux-8] osbuild-composer | major | always | 2022-07-25 10:38 | 2022-12-20 13:09 |
Reporter: | TulanKansen | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Impossible to create Installation ISO with osbuild-composer | ||||
Description: |
Hello, I have discovered a blocking bug in osbuild-composer, who prevent at least creation of "installation ISO" file. In the upstream source package, the package "libreport-rhel-anaconda-bugzilla" is required during image creation. |
||||
Tags: | |||||
Steps To Reproduce: |
1) Install osbuild-composer 2) create a blueprint with any package or configuration 3) create image with type "RHEL Installer (.iso) 4) creation fail because RPM package "libreport-rhel-anaconda-bugzilla" is not available in AlmaLinux |
||||
Additional Information: |
Proposed patch for the compilation of osbuild-composer RPM packages: ```Diff diff -aruN osbuild-composer-46.3/internal/distro/rhel86/package_sets.go osbuild-composer-46.3_alma/internal/distro/rhel86/package_sets.go --- osbuild-composer-46.3/internal/distro/rhel86/package_sets.go 2022-04-28 17:33:25.000000000 +0000 +++ osbuild-composer-46.3_alma/internal/distro/rhel86/package_sets.go 2022-07-22 16:29:43.048882567 +0000 @@ -748,7 +748,6 @@ "libibverbs", "libreport-plugin-bugzilla", "libreport-plugin-reportuploader", - "libreport-rhel-anaconda-bugzilla", "librsvg2", "linux-firmware", "lklug-fonts", ``` |
||||
Attached Files: | |||||
Notes | |
(0000775)
TulanKansen 2022-12-20 13:09 |
Hello, this bug is still present with Almalinux 8.7 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
346 | [AlmaLinux-8] mysql | minor | always | 2022-12-17 12:51 | 2022-12-20 09:00 |
Reporter: | fsolans | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | El servicio de MySQL no arranca despues de instalar los paquetes | ||||
Description: |
Cuando despliego esta máquina y posteriormente despliego los paquetes de MySQL 8, éste no arranca correctamente. Creo que algunos ficheros de configuración no están finos. Gracias. |
||||
Tags: | |||||
Steps To Reproduce: |
yum install mysql-server mysql |
||||
Additional Information: | Los mensajes de logs indican que hay una etiqueta de los ficheros de configuración que están deprecados y el servicio de MySQL no llega a arrancar. | ||||
Attached Files: | |||||
Notes | |
(0000774)
alukoshko 2022-12-20 08:59 |
Hello. Can't reproduce. Do you have empty /var/lib/mysql/ dir when trying to run mysql for the first time? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
341 | [AlmaLinux-8] ipa | block | N/A | 2022-12-11 15:44 | 2022-12-16 16:26 |
Reporter: | dushyantk.sun@gmail.com | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | FreeIPA migration from Centos 7 to Alma Linux 8.6 | ||||
Description: |
Hello Team, i am looking for steps on migration on freeIPA to AlmaLinux8 Currently i have FreeIPA master with Centos 7.9 (IPA 4.6). I am trying to add freeipa replica Almalinux 8 (ipa4.7). Would like to check if anyone has come across such use case. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000769)
TulanKansen 2022-12-16 16:26 |
Hello, as CentOS 7 and Almalinux 8 are RHEL-clones, I think the official Red Hat guide will be a good start: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
344 | [AlmaLinux-8] dnf | minor | always | 2022-12-14 19:26 | 2022-12-14 19:34 |
Reporter: | titodaly | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | repo mirrorlist composed of IPv4 servers (no IPv6) | ||||
Description: |
This is the content of https://mirrors.almalinux.org/mirrorlist/9.1/baseos http://dfw.mirror.rackspace.com/almalinux/9.1/BaseOS/$basearch/os/ http://westus2.azure.repo.almalinux.org/almalinux/9.1/BaseOS/$basearch/os/ http://nnenix.mm.fcix.net/almalinux/9.1/BaseOS/$basearch/os/ http://uvermont.mm.fcix.net/almalinux/9.1/BaseOS/$basearch/os/ http://mirror.siena.edu/almalinux/9.1/BaseOS/$basearch/os/ http://mirror.interserver.net/almalinux/9.1/BaseOS/$basearch/os/ http://nyc.mirrors.clouvider.net/almalinux/9.1/BaseOS/$basearch/os/ http://mirrors-nyj.hawkhost.com/almalinux/9.1/BaseOS/$basearch/os/ according to https://mirrors.almalinux.org only 4 of those servers are IPv6 capable. Yum keeps on trying the IPv4 servers http://mirrors.rit.edu/almalinux/9.1/BaseOS/$basearch/os/ http://mirrors.cat.pdx.edu/alma/9.1/BaseOS/$basearch/os/ |
||||
Tags: | |||||
Steps To Reproduce: |
1. Install an IPv6 ONLY machine with almalinux 9.1 2. Try to install some packages : a) vim b) dhcp-server c) bind-utils |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000766)
titodaly 2022-12-14 19:34 |
Please delete. The issue that I was reporting was on almalinux 9.1 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
338 | [AlmaLinux-8] almalinux-release | major | always | 2022-11-30 08:41 | 2022-12-09 23:21 |
Reporter: | bencheikh | Platform: | |||
Assigned To: | elkhan | OS: | |||
Priority: | high | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | An error occurred (UnsupportedOperatingSystem) when calling the GetDeployablePatchSnapshotForInstance operation | ||||
Description: |
Hello, Hello, I have a problem when I try to install SSM agent aws on Almalinux I have this message An error occurred (UnsupportedOperatingSystem) when calling the GetDeployablePatchSnapshotForInstance operation I tried to upgrade the SSM agent to 3.2.183 on Almalinux 8 but i have the same problème. thank you. |
||||
Tags: | aws, cloud | ||||
Steps To Reproduce: | |||||
Additional Information: |
https://github.com/aws/amazon-ssm-agent/pull/448/files/b48a27a25f321d94a0e5133cc117c0fd6be2d0b0 |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
326 | [AlmaLinux-8] -OTHER | block | always | 2022-11-11 20:01 | 2022-12-09 19:34 |
Reporter: | bugfood | Platform: | |||
Assigned To: | elkhan | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux 8.5 AMI disappeared? Please document removal schedule. | ||||
Description: |
Hi, We've been using AlmaLinux 8.5 as the base AMI for a cloudformation build. Starting today (or shortly earlier?), our build broke because the AMI is apparently no longer available. The AMI ID is ami-0b4dad3b4322e5151 as was published on: https://wiki.almalinux.org/cloud/AWS.html#community-amis I guess I learned my lesson that we will need to host our own copies of AMIs; I had thought that we could trust the officially published AMIs to remain published. Can you please document the schedule of upcoming removal dates alongside the list of AMI in the wiki? That would be good in order to set expectations. Thanks, Corey |
||||
Tags: | |||||
Steps To Reproduce: |
$ aws ec2 describe-images --region us-east-1 --image-ids=ami-0b4dad3b4322e5151 { "Images": [] } |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000717)
elkhan 2022-11-13 22:34 |
Hi Corey, Unfortunately, we hit a "public AMI per region" limitation when try to publish 8.7 AMIs. Once resolve this limitation, we will build all older versions from the https://repo.almalinux.org/vault/ |
(0000718)
elkhan 2022-11-14 14:31 |
Hi Corey, I asked this question on the AlmaLinux chat: We get a bug report[^1] about the removal of the Amazon Machine Images of older versions which broke the reporter's build system. I can build them from the vault and re-publish again but I need to know: * Use cases of using the older AMIs of AlmaLinux OS (8.3,8.4,8.5 and 8.6) * If we decide to build them again which repos should be configured for the further DNF usage there, default(mirrors.almalinux.org) or https://repo.almalinux.org/vault/8.[3-6]/BaseOS/x86_64/os/ Let us know if someone uses the older AMIs as the reporter. Thanks! https://bugs.almalinux.org/view.php?id=326 |
(0000720)
bugfood 2022-11-14 17:30 |
Thank you for your responses. I filed this ticket mostly out of a desire for documentation of when AMI images are to be removed. The removal came as a surprise for me; I would have wanted to know up-front, when I found the AMI documentation, that older versions would eventually be removed. The important part for anybody who configures their build systems to use AMIs is that each configured AMI ID remain reachable. If the AlmaLinux foundation cannot retain older AMIs in perpetuity for practical reasons, that's understandable, but I think that should be made very clear up-front for anybody who searches and finds the published list of AMI IDs. A warning note on https://wiki.almalinux.org/cloud/AWS.html#community-amis would have been great for this. My own use case for needing access to older AMI images will no longer apply, since we'll move to using copies of the AMIs hosted in our own AWS account, in order to be resilient going forward. Still, I'm happy to state my former use case. In order to limit version sprawl across a large-ish fleet of diverse hosts, we don't use every new point release; rather, we select new releases as-needed and maintain older releases internally. AlmaLinux 8.5 was our most recent release in use (and our first use of AlmaLinux). We use our own locally-hosted yum repos, so the repo configuration built into the AMI doesn't matter for us, at least. I could imagine it would be a concern for other people, though. If having AMI for older releases with repos that work "out of the box" is desirable, then that would be a separate concern from what I am describing. |
(0000721)
bugfood 2022-11-15 18:17 |
I filed a related ticket regarding an error when copying the AlmaLinux 8.7 AMI: https://bugs.almalinux.org/view.php?id=329 |
(0000760)
elkhan 2022-12-09 16:54 |
Dear Corey, I would like to inform you that our public AMI limit requests finished successfully for the all regions excluding the new ones like ap-south-2, eu-south-2, eu-central-2 and me-central-1. Thanks to public snapshot and current limit count, We can build older releases from the https://repo.almalinux.org/vault/ and update the wiki to make sure all versions is publicly available. I hope this updates is enough to resolve this bug. |
(0000761)
bugfood 2022-12-09 17:55 |
Thanks. I personally no longer have a need for the older AMIs, since I scrambled to upgrade to 8.6 and then 8.7. Going forward, we host a local copy of the 8.7 AMI in our own AWS account. I don't know if anybody else needs new builds of the older releases. All I would ask for, at this point, is that _if_ existing AMIs are to be removed in the future, that the removal policy be posted alongside the listing of AMIs. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
234 | [AlmaLinux-8] -OTHER | major | always | 2022-05-12 15:25 | 2022-11-30 09:01 |
Reporter: | Eden | Platform: | AWS | ||
Assigned To: | elkhan | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.5 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AWS Systems Manager integration not complete. | ||||
Description: |
From here you can see that the SSM Agent has been included in AlmaLinux AMIs https://almalinux.org/blog/almalinux-cloud-images-updates-september-2021/ I've tried it , and since it is not officially supported by AWS yet, unlike RockyLinux, there are a few major issues. https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html The OS is not detected. See excerpt of /var/log/amazon/ssm/amazon-ssm-agent.log 2022-05-12 14:46:19 INFO [ssm-agent-worker] [StartupProcessor] Write to serial port: Amazon SSM Agent v3.1.338.0 is running 2022-05-12 14:46:19 INFO [ssm-agent-worker] [StartupProcessor] Write to serial port: OsProductName: NotAvailable 2022-05-12 14:46:19 INFO [ssm-agent-worker] [StartupProcessor] Write to serial port: OsVersion: NotAvailable And because of that, Systems Manager operations that require knowing which Operating System is running, will fail. Failed with run commands: AWS-RunPatchBaseline AWS-UpdateSSMAgent Request to liaise with AWS to make it officially supported. |
||||
Tags: | AlmaLinux, almalinux8, aws, cloud, incomplete | ||||
Steps To Reproduce: |
1 - Launch AlmaLinux instance with appropriate Instance Profile role for Systems Manager. 2 - Wait for it to fully boot. 3 - Use Systems Manager Run Command to run these documents against the instance: AWS-RunPatchBaseline AWS-UpdateSSMAgent |
||||
Additional Information: |
Inventory works but is not able to identify OS. Features that do not require identifying the OS work, like Session Manager and AWS-RunShellScript. |
||||
Attached Files: | |||||
Notes | |
(0000628)
elkhan 2022-07-06 10:34 |
Hi Eden, Thanks for the help in making the cloud integration of AlmaLinux OS better. You can track the status of AlmaLinux OS support from this Pull Request: https://github.com/aws/amazon-ssm-agent/pull/448 |
(0000754)
bencheikh 2022-11-30 09:01 |
hello, i'm having this bug with Alma Linux and the AWS SSM Agent where the OS can't be identified. These changes come in handy. I see that the push was validated, is the pull gonna ever be validated and released? thank you. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
330 | [AlmaLinux-8] kernel | block | always | 2022-11-15 21:27 | 2022-11-18 02:37 |
Reporter: | gunther | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Install of ZFS on Alma 8.7 modprobe causes CPU soft lock (watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [modprobe:62910]) | ||||
Description: |
Update to Alma 8.7(Stone Smilodon) with ZFS or installation of ZFS on Alma 8.7 causes CPU soft lockup during modprobe. Booting to previous kernel (Sky Tiger) alleviates the issue - system can see the zfs volumes. |
||||
Tags: | |||||
Steps To Reproduce: | Upgrade a zfs system to 8.7, or install zfs on an 8.7 system. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000731)
ncted 2022-11-17 20:14 |
I see this on 2 out of 3 hosts. The one which does not exhibit the behavior only has 38 drives, while the ones which exhibit the bug have 80 and 100 drives. Reverting to 4.18.0-372.32.1.el8_6.x86_64 kernel works. |
(0000735)
alukoshko 2022-11-18 02:37 |
Thanks for report! ZFS is 3rd party driver and looks like it needs to be updated for RHEL 8.7 kernel. Keep us updated on this please. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
329 | [AlmaLinux-8] -OTHER | block | always | 2022-11-15 18:16 | 2022-11-18 02:03 |
Reporter: | bugfood | Platform: | |||
Assigned To: | elkhan | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux 8.7 AMI EBS snapshot unreadable -- cannot copy AMI | ||||
Description: |
Hello, I am attempting to make a local copy of the AlmaLinux 8.7 us-east-1 x86_64 AMI into our own AWS account. This issue probably applies to the AMIs for other reasons and architectures, though I have not tested any other AMIs. The motivation to do this is to provide resiliency against future removal of the public AMI (see https://bugs.almalinux.org/view.php?id=326). I am following the process documented by AWS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html I am using the AlmaLinux 8.7 AMI list published here: https://wiki.almalinux.org/cloud/AWS.html#community-amis The observed error from AWS is: Failed to copy ami-0924610ece26e5e7b You do not have permission to access the storage of this ami Thanks, Corey |
||||
Tags: | ami, aws, cloud | ||||
Steps To Reproduce: |
1. Log into AWS using a third party account (probably any account that is _not_ the account which owns the AlmaLinux AMIs). 2. Go to https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#CopyImage:imageId=ami-0924610ece26e5e7b 3. Click "Copy AMI". |
||||
Additional Information: |
I searched the web for the text of the error message; this appears to be because the AMI's underlying EBS snapshot does not have public readability. This appears to be a semi-common issue for other projects in the same situation. This CoreOS ticket has the best information I have seen: https://github.com/coreos/bugs/issues/1090 Some other issues of the same nature from other projects are: https://bugzilla.redhat.com/show_bug.cgi?id=1423753 https://debian-cloud.debian.narkive.com/566akePc/ami-storage-permissions https://www.pagure.io/fedora-infrastructure/issue/7797 https://bugs.centos.org/view.php?id=17995 |
||||
Attached Files: | |||||
Notes | |
(0000722)
bugfood 2022-11-15 20:09 |
Typo in my description above: "AMIs for other reasons" should be "AMIs for other regions". |
(0000724)
elkhan 2022-11-16 15:46 (Last edited: 2022-11-16 15:49) |
Dear Corey, Many thanks for such a wonderful report and contribution. We made public every snapshot of the AMI and will add this feature to our AMI mirror tool for the future releases. Please, check whether you can successfully do the copy operation. |
(0000725)
bugfood 2022-11-16 18:23 |
You're welcome for the report, and thank you for fixing this. I re-tried the operation and the copy succeeded this time. I haven't yet tried to use the copy, but should be able to later today. Feel free to close the ticket, though--it should be good. |
(0000726)
bugfood 2022-11-16 20:05 |
I tested an instance built using our copy of ami-0924610ece26e5e7b, and that worked fine. All seems well. Thanks again. |
(0000732)
elkhan 2022-11-18 02:02 |
Dear Corey, Thanks again for the reporting! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
322 | [AlmaLinux-8] qemu-kvm | minor | always | 2022-11-09 11:04 | 2022-11-09 11:05 |
Reporter: | jevingala | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Dis-connected novnc fails to connect again | ||||
Description: |
qemu-kvm seems to have patched upstream. Is it already included in AlmaLinux repo ? Ref : https://gitlab.com/qemu-project/qemu/-/issues/807 Or is it going to be released anytime soon in AlmaLinux repo ? |
||||
Tags: | QEMU-KVM | ||||
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: |
318 | [AlmaLinux-8] almalinux-release | minor | N/A | 2022-11-01 08:08 | 2022-11-01 08:08 |
Reporter: | Naranthiran | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux 8.5 | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | almalinux-release | ||||
Description: |
Hi Team, I have updated the kernel packages to 8.5. But I am not able to find the packages for almalinux-release 8.5. As a result, the os-release file was not updated and still shows OS version as 8.4 Regards Naranthiran Duraisamy |
||||
Tags: | |||||
Steps To Reproduce: |
1)Install AlmaLinux 8.4 ISO. 2)Run the command yum updated --downloadonly and download all the latest updates. 3)copy the updates to the appstream and baseos folder and created a custom ISO. 4)Install the custom ISO and check the file /etc/os-release |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
233 | [AlmaLinux-8] -OTHER | minor | always | 2022-05-05 14:36 | 2022-10-10 08:25 |
Reporter: | ronan | Platform: | AlmaLinux | ||
Assigned To: | OS: | Linux | |||
Priority: | normal | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Some rpm binaries from RPM group are missing | ||||
Description: |
In group define AlmaLinux, some package are define but are not present in AlmaLinux: *base: rhc *core: rhc *standard: rhc *powertools: Judy-devel ant-junit antlr-C++ antlr-tool apache-commons-beanutils apache-commons-compress apache-commons-net apache-ivy aqute-bnd aqute-bndlib bcel beust-jcommander bsf bsh cglib easymock felix-utils geronimo-jms glassfish-jsp-api glassfish-servlet-api hamcrest hamcrest-core javamail javapackages-local jaxen jsch jsr-305 junit jvnet-parent jzlib maven-archiver maven-artifact maven-artifact-manager maven-artifact-resolver maven-artifact-transfer maven-common-artifact-filters maven-compiler-plugin maven-dependency-tree maven-doxia-core maven-doxia-logging-api maven-doxia-module-apt maven-doxia-module-fml maven-doxia-module-xdoc maven-doxia-module-xhtml maven-doxia-sink-api maven-doxia-sitetools maven-enforcer-api maven-enforcer-plugin maven-enforcer-rules maven-filtering maven-invoker maven-jar-plugin maven-local maven-model maven-monitor maven-plugin-annotations maven-plugin-build-helper maven-plugin-bundle maven-plugin-registry maven-plugin-testing-harness maven-profile maven-project maven-remote-resources-plugin maven-reporting-api maven-reporting-impl maven-resources-plugin maven-settings maven-shared-incremental maven-source-plugin maven-surefire maven-surefire-plugin maven-surefire-provider-junit maven-surefire-provider-testng maven-verifier mockito msv-msv objectweb-asm objenesis osgi-annotation osgi-compendium osgi-core plexus-archiver plexus-build-api plexus-compiler plexus-component-api plexus-containers-container-default plexus-i18n plexus-interactivity-api plexus-io plexus-languages plexus-resources plexus-velocity python2-talloc python3-javapackages qdox xbean xmlunit xmvn-api xmvn-connector-aether xmvn-core xmvn-install xmvn-minimal xmvn-mojo xmvn-resolve xmvn-subst xz-java |
||||
Tags: | |||||
Steps To Reproduce: |
$ sudo dnf -v group info base $ sudo dnf -v group info core $ sudo dnf -v group info standard $ sudo dnf -v group info powertools |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
308 | [AlmaLinux-8] NetworkManager | crash | random | 2022-09-28 11:55 | 2022-09-28 11:55 |
Reporter: | brad0525 | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | enp6s0: Detected Tx Unit Hang | ||||
Description: |
Our server has an onboard NIC and an NIC card...We actively using the NIC card. The onoard NIC is causing our server to crash, below is the log..It is random. We do not know how to prevent this from happening or stop it. [106339.305336] igc 0000:06:00.0 enp6s0: Detected Tx Unit Hang Tx Queue <1> TDH <6a> TDT <6a> next_to_use <6a> next_to_clean <46> buffer_info[next_to_clean] time_stamp <105ffdb45> next_to_watch <00000000069e3b56> jiffies <106521180> desc.status <0> [106341.289858] igc 0000:06:00.0 enp6s0: Detected Tx Unit Hang Tx Queue <1> TDH <6a> TDT <6a> next_to_use <6a> next_to_clean <46> buffer_info[next_to_clean] time_stamp <105ffdb45> next_to_watch <00000000069e3b56> jiffies <106521941> desc.status <0> [106343.273170] igc 0000:06:00.0 enp6s0: Detected Tx Unit Hang |
||||
Tags: | |||||
Steps To Reproduce: | This is random occurs from the server running. | ||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
307 | [AlmaLinux-8] almalinux-release | minor | have not tried | 2022-09-27 08:45 | 2022-09-27 08:45 |
Reporter: | brimioulle | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Errata not applied when upgrade package only differs in 4th digit in version | ||||
Description: |
Errata not applied on AlmaLinux 8 server when upgrade package only differs in 4th digit in version. Example: ------------- yum -y update --advisory=ALBA-2021:3594 Output on server: -------------------------- No security updates needed, but 55 updates available Targeted rpm versions in erratum: libdb-5.3.28-42.el8_4.x86_64 libdb-utils-5.3.28-42.el8_4.x86_64 Package versions on the server: -------------------------------------------- [root@aaaa8 ~]# rpm -qa | grep libdb libdb-utils-5.3.28-40.el8.x86_64 libdb-5.3.28-40.el8.x86_64 |
||||
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: |
252 | [AlmaLinux-8] zstd | minor | always | 2022-05-30 12:42 | 2022-09-26 10:19 |
Reporter: | pawan | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Unable to decompress qcow.zst file | ||||
Description: |
Unable to decompress the filename.qcow2.zst It says unsupported format. |
||||
Tags: | zstd | ||||
Steps To Reproduce: |
Zstd version is *** zstd command line interface 64-bits v1.4.4, by Yann Collet *** compressed a file using following command /usr/bin/zstd -c 'file.qcow2' > 'file.qcow2.zst' decompressed a file using following command /usr/bin/zstd -dc 'file.qcow2.zst' > 'file.qcow2' It gives following error zstd: file.qcow2.zst: unsupported format |
||||
Additional Information: |
This same steps worked on centos 7.9 without any issue |
||||
Attached Files: |
zstd_AlmaLinuxOS8.6.txt (1,869 bytes) 2022-09-26 10:19 https://bugs.almalinux.org/file_download.php?file_id=192&type=bug |
||||
Notes | |
(0000591)
maxihoster 2022-06-07 20:26 |
+1 We can't restore any backup! It's a big issue |
(0000693)
elkhan 2022-09-26 10:19 |
Hi, I'm unable to reproduce the bug. Is it still present? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
293 | [AlmaLinux-8] kernel | crash | sometimes | 2022-08-10 15:46 | 2022-09-16 13:01 |
Reporter: | jmadeira | Platform: | VMware ESXi, 7.0.1 | ||
Assigned To: | OS: | AlmaLinux 8.6 | |||
Priority: | high | OS Version: | 4.18.0-372.19.1 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | receiving /proc/sys/kernel/hung message OS locks up | ||||
Description: |
We recently provisioned a number of AlmaLinux 8.6 servers in our VMware virtual environment and after a number of days the servers start hanging an throw the message: Not tainted 4.18.0-372.16.1.e18_6.x86_64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. INFO: task pool: 22704 blocked for more than 120 seconds. Once the message appears the servers become unresponsive and we have to power cycle to bring them back online. These are servers provisioned in our VMware ESXi, 7.0.1 environment and have not seen this issue with any of our other Linux based servers. We have upgraded the servers to 4.18.0-372.19.1 but the issue is still happening. We can not determine the exact time frame when the issues happens but it appears most lock up within the next few days to weeks. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: |
procsys_kernelhung_message.png (217,407 bytes) 2022-08-10 15:46 https://bugs.almalinux.org/file_download.php?file_id=178&type=bug |
||||
Notes | |
(0000666)
jmadeira 2022-08-12 14:29 |
I found this post https://forums.centos.org/viewtopic.php?t=79275 and the issue we are having is very similar. The issue seems to appear when updates for kernel 4.18.0-32.19 are installed. |
(0000691)
Devi 2022-09-15 19:04 |
We are having the same problem Please find log below, do you have any solution ? Sep 15 19:02:49 kernel: INFO: task php-fpm73:164951 blocked for more than 120 seconds. Sep 15 19:02:49 kernel: Not tainted 4.18.0-372.26.1.el8_6.x86_64 #1 Sep 15 19:02:49 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Sep 15 19:02:49 kernel: task:php-fpm73 state:D stack: 0 pid:164951 ppid:108420 flags:0x000003a0 Sep 15 19:02:49 kernel: Call Trace: Sep 15 19:02:49 kernel: __schedule+0x2d1/0x830 Sep 15 19:02:49 kernel: schedule+0x35/0xa0 Sep 15 19:02:49 kernel: io_schedule+0x12/0x40 Sep 15 19:02:49 kernel: wait_on_page_bit+0x123/0x220 Sep 15 19:02:49 kernel: ? file_fdatawait_range+0x20/0x20 Sep 15 19:02:49 kernel: shmem_swapin_page+0x23b/0x630 Sep 15 19:02:49 kernel: shmem_getpage_gfp+0x1f8/0x8a0 Sep 15 19:02:49 kernel: shmem_fault+0x78/0x210 Sep 15 19:02:49 kernel: ? filemap_map_pages+0x271/0x410 Sep 15 19:02:49 kernel: __do_fault+0x38/0xb0 Sep 15 19:02:49 kernel: do_fault+0x1a0/0x3c0 Sep 15 19:02:49 kernel: __handle_mm_fault+0x4a3/0x7e0 Sep 15 19:02:49 kernel: handle_mm_fault+0xc1/0x1e0 Sep 15 19:02:49 kernel: do_user_addr_fault+0x1b5/0x440 Sep 15 19:02:49 kernel: do_page_fault+0x37/0x130 Sep 15 19:02:49 kernel: ? page_fault+0x8/0x30 Sep 15 19:02:49 kernel: page_fault+0x1e/0x30 Sep 15 19:02:49 kernel: RIP: 0033:0x7faf3eb48e98 Sep 15 19:02:49 kernel: Code: Unable to access opcode bytes at RIP 0x7faf3eb48e6e. Sep 15 19:02:49 kernel: RSP: 002b:00007ffd142932a0 EFLAGS: 00010212 Sep 15 19:02:49 kernel: RAX: 00000000002f29e8 RBX: 00007faf36e2bad0 RCX: 000000000110ec5c Sep 15 19:02:49 kernel: RDX: 0000000000159ee4 RSI: 0000000000000000 RDI: 00007faf32159220 Sep 15 19:02:49 kernel: RBP: 00007faf32159180 R08: d600eeaf2779d000 R09: 00007faf41274800 Sep 15 19:02:49 kernel: R10: 0000000000000000 R11: 00007faf41274880 R12: ccb0f624a0b59ee6 Sep 15 19:02:49 kernel: R13: 00007ffd142932c0 R14: 00007faf32153280 R15: 00007faf32166038 |
(0000692)
Devi 2022-09-16 13:01 |
Solution: There was a EXT4 hard disk mounted to the server with an external /Home2 partition which was rather slow and messing up the DirectAdmin (control panel) quota and Brute force monitor. Or the disk had an hardware failure. Disk and partition removed and server is running as it should |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
291 | [AlmaLinux-8] -OTHER | minor | always | 2022-08-06 12:57 | 2022-09-12 14:10 |
Reporter: | ap8 | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Errata entry missing for httpd | ||||
Description: | Advisory https://access.redhat.com/errata/RHSA-2022:5163 for CVE-2020-13950 is missing from AlmaLinux errata, but it is present in RockyLinux (https://errata.rockylinux.org/RLSA-2022:5163) and Oracle Linux (https://linux.oracle.com/errata/ELSA-2022-5163.html). | ||||
Tags: | |||||
Steps To Reproduce: |
In RockyLinux: <code> [root@rocky8 ~]# dnf updateinfo --info --all --cve CVE-2020-13950 Last metadata expiration check: 1:23:17 ago on Sat 06 Aug 2022 11:23:52 UTC. =============================================================================== Low: httpd:2.4 security update =============================================================================== Update ID: RLSA-2022:5163 Type: security Updated: 2022-07-07 20:12:43 CVEs: CVE-2020-13950 Description: For more information visit https://errata.rockylinux.org/RLSA-2022:5163 Severity: Low Installed: true [root@rocky8 ~]# </code> In AlmaLimux: <code> [root@alma8 ~]# dnf updateinfo --info --all --cve CVE-2020-13950 Last metadata expiration check: 1:25:21 ago on Sat 06 Aug 2022 11:20:58 UTC. [root@alma8 ~]# </code> |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000656)
toracat 2022-08-08 23:15 |
Just an observation. The output on RHEL 8 looks similar to the one on Alma: $ sudo dnf updateinfo --info --all --cve CVE-2020-13950 Updating Subscription Management repositories. Last metadata expiration check: 0:26:50 ago on Mon 08 Aug 2022 03:35:41 PM PDT. |
(0000657)
ap8 2022-08-09 09:30 |
Thanks @toracat. I do not have access to a RHEL8 instance so I could not check before reporting the bug. I tried OracleLinux8 and that also behaves like AlmaLinux8 and RHEL8 (i.e. no output). Nonetheless, I assume there may be something missing in AlmaLinux because if you search for `5163` in https://errata.almalinux.org/ you get nothing, but you get the advisory if you search for the same in RockyLinux (https://errata.rockylinux.org/) and RHEL (https://access.redhat.com/errata-search/#/?q=5163&p=1&sort=portal_publication_date%20desc&rows=10&portal_advisory_type=Security%20Advisory&portal_product=Red%20Hat%20Enterprise%20Linux&portal_product_version=8) errata pages. |
(0000689)
jacp10 2022-09-06 13:13 |
I see the same thing as the original reporter, CVE reported for RHEL updates, not ALMA On RHEL: [root@xxx]# dnf updateinfo --info --all --cve CVE-2020-13950 Updating Subscription Management repositories. Last metadata expiration check: 1:56:39 ago on Tue 06 Sep 2022 12:12:13 BST. =============================================================================== Low: httpd:2.4 security update =============================================================================== Update ID: RHSA-2022:5163 Type: security Updated: 2022-06-22 10:23:56 Bugs: 1966738 - CVE-2020-13950 httpd: mod_proxy NULL pointer dereference CVEs: CVE-2020-13950 Description: The httpd packages provide the Apache HTTP Server, a powerful, efficient, and extensible web server. : : Security Fix(es): : : * httpd: mod_proxy NULL pointer dereference (CVE-2020-13950) : : For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. Severity: Low Installed: true On ALMA: [root@xxx]# dnf updateinfo --info --all --cve CVE-2020-13950 Last metadata expiration check: 2:37:16 ago on Tue 06 Sep 2022 11:32:38 BST. [root@xxx]# |
(0000690)
abotelho 2022-09-12 14:10 |
Error: Task /pulp/api/v3/tasks/7c9a2e55-d3cf-4e25-ac1b-941a40c9628a/ failed: 'duplicate key value violates unique constraint "rpm_updatecollection_name_update_record_id_6ef33bed_uniq" DETAIL: Key (name, update_record_id)=(almalinux-8-for-x86_64-appstream-rpms__8_1_subversion_0, 966da980-5314-419f-872a-3b5a480ba41c) already exists. This also appears to be breaking my Pulp 3 weekly sync. This is when syncing AlmaLinux 8 BaseOS |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
280 | [AlmaLinux-8] dracut | major | always | 2022-07-12 05:02 | 2022-09-05 11:42 |
Reporter: | AstroTJP | Platform: | Opteron Servers running Linux | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5, 8.6, (9.0) | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Cannot install AlmaLinux 8.5 and 8.6 (nor 9.0) onto Opteron based servers | ||||
Description: | Booting from AlmaLinux 8.5, 8.6, and 9.0 Live media (or Minimal install media), consistently fails to run or install operating systems. | ||||
Tags: | |||||
Steps To Reproduce: | Using an Opteron 2216 based server (SunFire X4200) with LSI SAS1064-IR RAID controller, OR an Opteron 880 based server (Tyan S4882) with SiI-3114 SATA RAID controller, booting Live media fails to run or install for either server. | ||||
Additional Information: |
Both versions of AlmaLinux 8.5 and 8.6 will drop the attempted installation into "dracut" environment prompt. From there, I was able to copy (and include) the "rdsosreport.txt" files from each attempt, for each server. The AlmaLinux 9.0 Live install doesn't even get to the dracut environment, it just locks up at a "kernel panic" event. At this point, it would be nice to try and get the AlmaLinux 8.x issues resolved first, it may provide insight into the 9.0 issues. For both server installs of version 8.6, both have a suspicious log message: "localhost kernel: random: 7 urandom warning(s) missed due to ratelimiting" in the respective rdsosreport.txt files. This warning appears just prior to dracut timeout messages. Doing internet searches, there is some mention that these messages occur prior to installing hard drive controller drivers; but, was unable to find a definitive fix for said issue. Attached are rdsosreport_*.txt files for each attempt at installs, along with some POST screen photos. I can install Ubuntu 20.04 onto these servers, but my organization is standardizing on the use of AlmaLinux. Server specs: 1) SunFire X4200 M2, Dual Opteron 2216 2.4Ghz CPU's, 4Gb RAM, LSI SAS1064-IR RAID controller configured with RAID-1E and 4 x 600Gb SAS drives. 2) Tyan S4882 Dual Opteron 880 2.4Ghz CPU's, 16Gb RAM, SiI 3114 SATA RAID controller with 1 x 256Gb SATA SSD. |
||||
Attached Files: |
rdsosreport_Alma86_SunFire_X4200_Opteron2216.txt (97,664 bytes) 2022-07-12 05:05 https://bugs.almalinux.org/file_download.php?file_id=167&type=bug rdsosreport_Alma85_SunFire_X4200_Opteron2216.txt (99,770 bytes) 2022-07-12 05:05 https://bugs.almalinux.org/file_download.php?file_id=168&type=bug SunFire_X4200_Opteron2216_LSI_SAS1064.jpg (82,492 bytes) 2022-07-12 05:05 https://bugs.almalinux.org/file_download.php?file_id=169&type=bug SunFire_X4200_Opteron2216_POST01.jpg (132,472 bytes) 2022-07-12 05:05 https://bugs.almalinux.org/file_download.php?file_id=170&type=bug SunFire_X4200_Opteron2216_POST02.jpg (144,887 bytes) 2022-07-12 05:05 https://bugs.almalinux.org/file_download.php?file_id=171&type=bug rdsosreport_Alma86_Tyan_S4882_Opteron880.txt (90,755 bytes) 2022-07-12 05:07 https://bugs.almalinux.org/file_download.php?file_id=172&type=bug rdsosreport_Alma85_Tyan_S4882_Opteron880.txt (97,727 bytes) 2022-07-12 05:07 https://bugs.almalinux.org/file_download.php?file_id=173&type=bug Tyan_S4882_Opteron880_POST01.jpg (119,375 bytes) 2022-07-12 16:52 https://bugs.almalinux.org/file_download.php?file_id=174&type=bug Tyan_S4882_Opteron880_SiI3114.jpg (84,793 bytes) 2022-07-12 16:52 https://bugs.almalinux.org/file_download.php?file_id=175&type=bug Alma90_Kernel_Panic.jpg (177,687 bytes) 2022-07-12 17:08 https://bugs.almalinux.org/file_download.php?file_id=176&type=bug rdsosreport.txt (94,576 bytes) 2022-08-11 00:02 https://bugs.almalinux.org/file_download.php?file_id=179&type=bug Tyan_Error_Screen01.jpg (821,248 bytes) 2022-08-11 00:02 https://bugs.almalinux.org/file_download.php?file_id=180&type=bug rdsosreportv2.txt (115,865 bytes) 2022-08-11 16:47 https://bugs.almalinux.org/file_download.php?file_id=181&type=bug rdsosreportv3.txt (111,956 bytes) 2022-08-13 14:07 https://bugs.almalinux.org/file_download.php?file_id=182&type=bug Tyan_Error_Screen03.jpg (700,389 bytes) 2022-08-13 14:07 https://bugs.almalinux.org/file_download.php?file_id=183&type=bug Alma8_DVD_ISO_burn.txt (24,068 bytes) 2022-08-17 05:24 https://bugs.almalinux.org/file_download.php?file_id=184&type=bug rdsosreport-2.txt (102,345 bytes) 2022-08-17 05:24 https://bugs.almalinux.org/file_download.php?file_id=185&type=bug IMG_3757.jpg (642,352 bytes) 2022-08-17 05:24 https://bugs.almalinux.org/file_download.php?file_id=186&type=bug rdsosreport_stream8.txt (101,999 bytes) 2022-08-19 21:30 https://bugs.almalinux.org/file_download.php?file_id=188&type=bug rdsosreport_rhel8.txt (108,147 bytes) 2022-08-19 21:30 https://bugs.almalinux.org/file_download.php?file_id=189&type=bug fedora36_dmesg.txt (75,739 bytes) 2022-08-19 21:30 https://bugs.almalinux.org/file_download.php?file_id=190&type=bug |
||||
Notes | |
(0000638)
AstroTJP 2022-07-12 05:05 |
The following rdsosreport_*.txt files are from the attempts to install AlmaLinux 8.5 and 8.6 onto SunFire X4200 server. Screen shots of POST screens are attached as well. |
(0000639)
AstroTJP 2022-07-12 05:07 |
The following rdsosreport_*.txt files are from the attempts to install AlmaLinux 8.5 and 8.6 onto Tyan S4882 (Opteron 880) server. Screen shots of POST screens are attached as well. |
(0000640)
AstroTJP 2022-07-12 16:52 |
Tyan S4882 screen shots that didn't make it into previous note... |
(0000641)
AstroTJP 2022-07-12 17:08 |
Attached screen shot of kernel panic message, at point of lockup, when attempting to install AlmaLinux 9.0 (happens with both of the aforementioned servers)... |
(0000659)
elkhan 2022-08-10 11:29 |
Hello, 1) SunFire X4200 M2, Dual Opteron 2216 2.4Ghz CPU's, 4Gb RAM, LSI SAS1064-IR RAID controller configured with RAID-1E and 4 x 600Gb SAS drives. You need the Driver Update Disks (DUD) of the ELRepo's mptsas-kmod driver to install AlmaLinux OS with this raid controller. Download the latest version of dd-mtpsas.iso with a correct Major and Minor version. example: AlmaLinux OS 8.6 (el8_6)==> dd-mptsas-3.04.20-7.el8_6.elrepo.iso 2) Tyan S4882 Dual Opteron 880 2.4Ghz CPU's, 16Gb RAM, SiI 3114 SATA RAID controller with 1 x 256Gb SATA SSD. You need the Driver Update Disks (DUD) of the ELRepo's sata_sil-kmod driver to install AlmaLinux OS with this raid controller. Download the latest version of dd-sata_sil.iso with a correct Major and Minor version. example: AlmaLinux OS 8.6 (el8_6)==> dd-sata_sil-2.4-6.el8_6.elrepo.iso 3) AlmaLinux OS 9: After installing the latest version of AlmaLinux OS 8, please check if your current systems meet the x86_64-v2 minimum architecture requirement: /usr/lib64/ld-linux-x86-64.so.2 --help Make sure you get an output like this. If your system supports x86_64-v2 you can install AlmaLinux OS 9 with the same approach, with DUD ISOs. Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v2 (supported, searched) Resources: How to use the DUD: https://youtu.be/4fOAuXiynYM http://elrepoproject.blogspot.com/2019/08/rhel-80-and-support-for-removed-adapters.html DUD download links: 8: https://elrepo.org/linux/dud/el8/x86_64/ 9: https://elrepo.org/linux/dud/el9/x86_64/ Package Sources: https://elrepo.org/tiki/Download https://github.com/elrepo/packages/tree/master/mptsas-kmod https://github.com/elrepo/packages/tree/master/sata_sil-kmod |
(0000660)
AstroTJP 2022-08-11 00:02 |
Hi lkhn, Thanks for the detailed instructions. :-) Per your instructions and web link instructions, I downloaded the ELRepo drivers and created a USB stick starting with the SATA driver (dd-sata_sil-2.4-6.el8_6.elrepo.iso) for the Tyan S4882 (this system is a little easier and more accommodating than the SunFire). Per the YouTube instructions, I appended the "inst.dd" command at the end of the "vmlinuz" line from the startup installation menu. The system continued to boot but I got an error message followed by it generating the "rdsosreport.txt", followed by the "dracut:/#" prompt. I copied the rdsosreport.txt file to the USB stick, so I know that it's working, and I've attached the report to this note (along with an image of the screen showing errors). It seems as if the installation is not even getting to the point of loading the disk driver, so something is happening prior to that. Please let me know if I can provide you with any additional information? I didn't attempt this on the SunFire, yet, since it exhibits the same behavior. Many thanks. |
(0000661)
elkhan 2022-08-11 07:59 |
Hi AstroTJP, You're welcome! As I see from the volume label, Are you using the Live ISO? 1. Download the DVD ISO (AlmaLinux-8.6-x86_64-dvd.iso) from the nearest mirror: https://mirrors.almalinux.org/isos.html 2. Format to USB device as FAT32 filesystem, 3. Copy dd-sata_sil-2.4-6.el8_6.elrepo.iso to the root directory of the USB. 4. Append the inst.dd=$location boot option to the command line i.e. inst.dd=/dev/sdb1 It might be /dev/sda1 via your latest rdsosreport.txt output. |
(0000662)
AstroTJP 2022-08-11 13:59 |
Hi lkhn, I'm having challenges booting from USB stick, given the 10Gb size of the DVD ISO, will the Minimal Install version be ok? Thanks! |
(0000663)
AstroTJP 2022-08-11 16:47 |
Hi lkhn, Please disregard my previous note, I actually went ahead and tried the 8.6 minimal install with the inst.dd=/dev/sda1 and it successfully loaded the driver. :-) However, dracut appears to have failed for other reasons. After the disk driver loads, I see the following warning: "dracut-initqueue[1195]: Warning: Can't get kickstart from /dev/sda1:/ks.cfg" (this can be seen in the rdsosreport.txt file). Not sure what ks.cfg is suppose to contain, or if it really matters since it was a warning. Do I need to copy some version of ks.cfg onto the USB stick? Thanks! |
(0000664)
elkhan 2022-08-12 10:07 |
Hi AstroTJP, Great! The "sata_sil" module loaded and worked successfully. Since your DUD USB has the "OEMDRV" volume label, the installer tries to find the "ks.cfg" file in there to perform an unattended installation. Therefore, your USB drive serves two purposes at the same time: 1. Driver installation 2. Unattended installation To perform the unattended installation with the USB driver you need to do these steps. * File System format: FAT32 * Volume Label: OEMDRV * Your kickstart file is present as "ks.cfg" in the root directory of the USB drive After each manual installation, a kickstart version of the installation is generated at /root/anaconda-ks.cfg, So you can use this file to do an Unattended version of the same installation. Since, We want the manual installation, and you're directly pointing your DUD USB with inst.dd=/dev/sda1, Could you do these steps?: 1. Format as FAT32 without the OEMDRV volume label. 2. Copy the DUD ISO file to the root directory of the USB. |
(0000665)
elkhan 2022-08-12 10:20 |
Dear AstroTJP, One thing I'd like to mention: There three ways to load DUD on the installation: Automatic: If you have a CD, DVD, or USB flash drive with the OEMDRV volume label, you don't need to append inst.dd or inst.dd=/dev/sda1. The installer will use it automatically. Assisted: If you have a CD, DVD, or USB flash drive other than the OEMDRV volume label, you need to append only inst.dd and choose your DUD manually. See the video: https://youtu.be/4fOAuXiynYM?t=977 Manual: You're currently using this method with directly pointing your DUD: inst.dd=/dev/sda1 |
(0000668)
AstroTJP 2022-08-13 14:07 |
Dear lkhn, I tried your suggested "manual installation", removing the USB stick volume leaving (i.e. made volume name blank as opposed to OEMDRV). Restarted the installation, system recognized the sata sil driver, but I still got the large quantity of "dracut-initqueue" messages, followed by a "Warning: /dev/root does not exist" message. I then thought I'd seek out the anaconda kickstart file to see if that might help, but when I "cd /root ; ls", the directory was empty (please see attached image and rdsosreport.txt). Any suggestions? Many thanks, AstroTJP |
(0000669)
AstroTJP 2022-08-14 21:30 |
Also to clarify my previous note, your previous instructions making the USB stick volume blank, DID help to get rid of the "Can't get kickstart" file message. :-) Thanks, Tim |
(0000670)
elkhan 2022-08-15 08:41 |
Hi AstroTJP, I hope you're doing well. Yes, It's great to see that we're on the right path and have some improvements. I'm afraid the bootable USB from AlmaLinux OS 8.6 Minimal ISO, haven't created properly. Could you recreate the bootable USB with using these methods: Linux,Mac - CLI # dd if=/image_directory/AlmaLinux-8.6-x86_64-minimal.iso of=/dev/sdX (i.e. /dev/sda, /dev/sdb) Linux, Windows - GUI https://github.com/FedoraQt/MediaWriter/releases |
(0000671)
AstroTJP 2022-08-15 21:39 |
Hi lkhn, I am doing well, not bad as far as Monday's go, hopefully you are too. :-) The Tyan 4886 computer that I use, is unable to boot from USB, thus I have been booting from a DVD-ROM (and then pointing to the USB stick for the SATA drivers). I tried downloading the MediaWriter utility, but it only works with writing to USB, is there another utility you would recommend which would allow me to burn to DVD the minimal install ISO? Many thanks, Tim |
(0000672)
elkhan 2022-08-16 09:25 |
Hi AstroTJP, I'm good too, thanks for asking! I see... Could you create an another one with this method please? Linux - CLI: xorriso -as cdrecord -v dev=/dev/sr0 -eject AlmaLinux-8.6-x86_64-minimal.iso |
(0000675)
AstroTJP 2022-08-17 05:24 |
Greeting lkhn, I went ahead and tried your suggestion of burning the AlmaLinux8.6 minimal install ISO using "xorriso" application. I downloaded the minimal install ISO from this specific mirror site: http://mirror.chpc.utah.edu/pub/almalinux/8.6/isos/x86_64/, which I used to burn via xorriso. Towards the end of the burn session, I got an error message: "xorriso : NOTE : Disc status unsuitable for writing" (see the attached note Alma8_DVD_ISO_burn.txt for full session messages). However, I was able to successfully boot with this freshly burned ISO session, but I still get the multiple "dracut-initqueue" timeout messages, followed by a "Warning: /dev/root does not exist" message, then the dracut prompt (same screen info as seen in prior note 668). At the beginning of the DVD boot, I did see some udev error messages, particularly the following (also seen in rdsosreport.txt): "[15.212580] localhost dracut-pre-udev[729]: modprobe: ERROR: could not insert 'sha256_mb': No such device". Not sure if this may be a clue. I am open to your next words of wisdom. :-) Cheers, AstroTJP |
(0000679)
elkhan 2022-08-19 09:12 |
Hi AstroTJP, The xorriso looks successful to me. Probably, not related the issue but this time I don't see the sata_sil module loaded from the USB pen drive. I tried to inspect and compare the ISO files and looks like nothing interesting there. Could you try these two procedures to make sure weather the issue related to the AlmaLinux OS 8 ISO or not? 1. Download and Burn CentOS Stream 8 ISO (CentOS-Stream-8-x86_64-latest-boot.iso ) from here: http://isoredirect.centos.org/centos/8-stream/isos/x86_64/ 2. If you have a RedHat Developer Account, Download and burn "rhel-8.6-x86_64-boot.iso" from here: https://developers.redhat.com/products/rhel/download The DUD only compatible with the downstreams like (RHEL, AlmaLinux OS). Therefore if everything go well on CentOS 8 Stream you will see the Anaconda installer bur not your HDDs works with sata_sil. Looks like these experiments will cost you additional two DVD disks, sorry for any inconvenience. I hope we'll found the answers at the end and it will worth it. |
(0000681)
AstroTJP 2022-08-19 21:30 |
Hi lkhn, I downloaded both the CentOS8.6 stream and Red Hat 8.6 ISO's per your suggestion. I used xorriso to burn both images. Short answer: still the the same issue for both distro's. :-( Studying the rdsosreport's from both distro installation attempts (as well as previous reports), there is something happening with the dracut "hook" ( for example: "[ 21.064796] localhost systemd[1]: Starting dracut initqueue hook..."), shortly thereafter, we get the slew of "dracut-initque timeout" warnings (see attached rdsosreport files). Based on this "train of thought", I went ahead and downloaded the latest Fedora Core 36 and had no trouble installing it onto this workstation (see the attached dmesg file). It even automatically recognized my sata_sil disk controller. Given this latest troubleshooting, what would you like to try next? Many thanks, AstroTJP |
(0000687)
AstroTJP 2022-08-31 14:04 |
Hi lkhn, Hope all is well. Haven't heard back, was wondering if we've reached an impasse here and need to take a different course of action? Many thanks, AstroTJP |
(0000688)
elkhan 2022-09-05 11:42 |
Hi AstroTJP, I hope you're doing well. Sorry for the late reply, had a busy schedule. Thanks to your ISO tests, we know the issue is the upstream rather than the AlmaLinux OS. It might be good idea to file a bug report to the upstream too: https://wiki.centos.org/ReportBugs One thing, I would like to test: From the first output files, we see the failure happens on the "dracut-initqueue.service" step. As we can see from the dracut boot order flowchart[^1], the dracut-initqueue has some parallel operations. As I suspect due your current HW configurations, the steps, somehow timeouts. Could you increase this timeout to find if something different happens or not? Quote from DRACUT.CMDLINE(7) Manual Page[^2]: rd.retry=<seconds> specify how long dracut should retry the initqueue to configure devices. The default is 180 seconds. After 2/3 of the time, degraded raids are force started. If you have hardware, which takes a very long time to announce its drives, you might want to extend this value. How to increase: Append rd.retry=integer in the grub edit mode. Let's start twice of the default value (180) and higher it as much as your time lets you to wait: rd.retry=360 inst.dd=/dev/sda1 [^1]: https://github.com/dracutdevs/dracut/blob/master/man/dracut.bootup.7.asc [^2]: https://github.com/dracutdevs/dracut/blob/master/man/dracut.cmdline.7.asc |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
299 | [AlmaLinux-8] dnf | minor | always | 2022-08-31 16:47 | 2022-08-31 16:47 |
Reporter: | jacp10 | Platform: | ESX VM | ||
Assigned To: | OS: | ALMA 8 | |||
Priority: | normal | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | yum updateinfo list sec displays an el9 package on el8 | ||||
Description: |
'yum updateinfo list sec' displays shim-x64-15.6-1.el9.alma.x86_64, an el9 package, when run on an ALMA8.4 system. Subsequently running 'yum --security update-minimal' does not install anything, which I think is correct, I think this shim update should not be listed. But I think the first command above should not be reporting a package that is not going to be installed. |
||||
Tags: | |||||
Steps To Reproduce: |
[root@xxx ~]# yum updateinfo list sec Last metadata expiration check: 1:46:41 ago on Wed 31 Aug 2022 15:56:48 BST. ALSA-2022:5095 Important/Sec. shim-x64-15.6-1.el9.alma.x86_64 [root@xxx ~]# more /etc/redhat-release AlmaLinux release 8.4 (Electric Cheetah) [root@xxx ~]# yum --security update-minimal Last metadata expiration check: 1:47:05 ago on Wed 31 Aug 2022 15:56:48 BST. Dependencies resolved. Nothing to do. Complete! |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
286 | [AlmaLinux-8] -OTHER | minor | N/A | 2022-07-20 18:11 | 2022-08-19 15:59 |
Reporter: | toracat | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Add missing "AlmaLinux" to the mailing list subject line | ||||
Description: |
Currently, the subject line is set up as: users@lists.almalinux.org [AlmaLinux Users] devel@lists.almalinux.org [Devel] security@lists.almalinux.org [Security] Please change the latter two to [AlmaLinux Devel] and [AlmaLinux Security], respectively. |
||||
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: |
294 | [AlmaLinux-8] systemd | block | always | 2022-08-17 07:15 | 2022-08-17 07:15 |
Reporter: | iopen-al | Platform: | Raspberry Pi 3B | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | immediate | OS Version: | 9 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Boot process stalls with systemd waiting for more than one service to start | ||||
Description: |
Using : AlmaLinux-9-RaspberryPi-9.0-20220615.aarch64.raw (checksum verified) Booting has succeeded only once in more than 20 attempts (so far). Well into the boot process, progress stalls with systemd reporting waiting for service(s) to start. Services include "firewalld", "User Login Management", "D-Bus System Message Bus". The one time that booting succeeded the poweroff sequence stalled with systemd reporting waiting for a service to stop. |
||||
Tags: | |||||
Steps To Reproduce: | Copy the above image file onto a uSD card and try booting a Raspberry Pi 3B from it. | ||||
Additional Information: | No problem booting AL8 on the same hardware. | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
262 | [AlmaLinux-8] rpm | crash | random | 2022-06-07 09:09 | 2022-08-16 19:41 |
Reporter: | gabor567 | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | recurring issue: base and appstream repositories cannot be synchronized using pulp-rpm | ||||
Description: |
I use pulp-rpm (v3) to synchronize the base and appstream repos from http://repo.almalinux.org/almalinux/8/BaseOS/x86_64/os/ and https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/ respectively. I try to run the sync script once a week. Sometimes it works, sometimes it fails with the following error: "Incoming and existing advisories have the same id and timestamp but different and intersecting package lists, and neither package list is a proper subset of the other. At least one of the advisories is wrong. To allow this behavior, set ALLOW_AUTOMATIC_UNSAFE_ADVISORY_CONFLICT_RESOLUTION = True (q.v.) in your configuration. Advisory id: ALSA-2019:2720" (This advisory ID may not always be the same.) I have learnt that deleting and recreating the pulp repository "solves" the problem but I lose the previous versions - keeping these would be one of the purposes of pulp. |
||||
Tags: | almalinux8, appstream | ||||
Steps To Reproduce: |
- create repository and remote in pulp-rpm (like this: https://docs.pulpproject.org/pulp_rpm/workflows/create_sync_publish.html ) - synchronize the repository with the remote once a week - sometimes it works, sometimes it fails. I failed at least 5 times in the last 12 months. It failed twice in the last month. |
||||
Additional Information: |
I have several other (non-AlmaLinux) repositories in pulp and they do work. I only have seen this type of error with AlmaLinux repos. |
||||
Attached Files: | |||||
Notes | |
(0000627)
dralley 2022-07-06 02:02 |
I work on Pulp and a few other users have complained about this as well, both in the past and recently with this specific advisory (hence why I'm here). This warning gets triggered when the advisory in the remote repo was changed at least once *after* being pushed but without changing the updated date metadata, and doing some weird things with the package list that make it difficult to decide what to make of it. I'm not sure what the specifics are in this case, however. If someone has access to figure out what changed between the first and second revision of that advisory, I can try to provide some guidance on what ought to be done on your side (or if it seems reasonable, try to relax the restriction a bit on our side). |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
292 | [AlmaLinux-8] php | major | always | 2022-08-08 11:44 | 2022-08-08 15:58 |
Reporter: | h.sattar | Platform: | AlmaLinux release 8.6 | ||
Assigned To: | OS: | AlmaLinux release 8.6 (Sky Tiger | |||
Priority: | high | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Missing PHP modules | ||||
Description: |
While we are installing PHP 7.4 after enabling PHP 7.4 using the command dnf module enable php:7.4 . We get the following error for the following command php php-cli php-common php-fpm php-gd php-imap php-json php-ldap php-mysqlnd php-curl php-memcached php-imagick php-geoip php-mcrypt php-intl php-xml php-zip php-bz2 php-ssh2 php-mbstring Error provided by AlamaLinux: Last metadata expiration check: 0:58:12 ago on Monday 08 August 2022 06:25:03 AM EDT. No match for argument: php-imap No match for argument: php-memcached No match for argument: php-imagick No match for argument: php-geoip No match for argument: php-mcrypt No match for argument: php-ssh2 Error: Unable to find a match: php-imap php-memcached php-imagick php-geoip php-mcrypt php-ssh2 |
||||
Tags: | |||||
Steps To Reproduce: |
Try to install following PHP modules: php-imap php-memcached php-imagick php-geoip php-mcrypt php-ssh2 |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
274 | [AlmaLinux-8] kernel | major | always | 2022-07-01 06:37 | 2022-07-19 18:05 |
Reporter: | dufgrinder | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | nvidia Legacy 390 does not compile | ||||
Description: |
I've tried to install nvidia driver for my graphic Card GeForce GT520: Using the standard package: akmod-nvidia-390xx The compilation fails (see attached log) For information, it was working fine on CentOS7. I've also tried with the NVIDIA-Linux-x86_64-390.151.sh (downloaded from the vendor site), it also failed. |
||||
Tags: | |||||
Steps To Reproduce: |
dnf install akmod-nvidia-390xx # See the attached /var/cache/akmods/nvidia-390xx/390.144-3.el8-for-4.18.0-372.9.1.el8.x86_64.failed.log |
||||
Additional Information: | |||||
Attached Files: |
390.144-3.el8-for-4.18.0-372.9.1.el8.x86_64.failed.log (511,249 bytes) 2022-07-01 06:39 https://bugs.almalinux.org/file_download.php?file_id=161&type=bug akmods.log (5,536 bytes) 2022-07-01 06:39 https://bugs.almalinux.org/file_download.php?file_id=162&type=bug |
||||
Notes | |
(0000623)
dufgrinder 2022-07-01 06:39 |
The logs |
(0000624)
toracat 2022-07-01 10:41 |
I recommend you give ELRepo's kmod package a try. To do this, you need to uninstall what you have installed so far and : (1) Set up the ELRepo repository by following the instructions on https://www.elrepo.org/ sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org sudo yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm (2) Then install the nvidia-detect package and run it ( see https://www.elrepo.org/tiki/nvidia-detect for details ) sudo yum install nvidia-detect nvidia-detect -v sudo yum install $(nvidia-detect) |
(0000635)
dufgrinder 2022-07-09 11:49 |
Thanks toracat, But it gives the same result (because nvidia-detect recommands to install the kmod-nvidia driver) Read you soon, Olivier |
(0000636)
toracat 2022-07-09 16:34 |
Are you sure nvidia-detect said "kmod-nvidia"? Not "kmod-nvidia-390xx" ? The latter is expected for the GT 520 card. |
(0000637)
toracat 2022-07-09 16:36 |
Please copy the output of the command 'nvidia-detect -v' here. It should show the device IDs [xxxx:yyyy]. |
(0000642)
dufgrinder 2022-07-13 04:13 |
Hi, nvidia-detect reports the following: Probing for supported NVIDIA devices... [10de:1040] NVIDIA Corporation GF119 [GeForce GT 520] This device requires the legacy 390.xx NVIDIA driver kmod-nvidia-390xx |
(0000643)
toracat 2022-07-13 08:51 |
So far, so good. Now all you have to do is to run the last command: sudo yum install $(nvidia-detect) Or you can run: sudo yum install kmod-nvidia-390xx |
(0000644)
dufgrinder 2022-07-14 02:44 |
Hi, I did last week, that was I said " it gives the same result " The akmods fails, compilation logs are uploaded in this ticket. |
(0000645)
toracat 2022-07-14 17:29 |
Please note that ELRepo's kmod packages do NOT require compilation at all. They provide drivers that have been compiled for your kernel. Also, within a minor release (for example el 8.6), they do not need to be re-installed for each kernel update, thanks to their kABI-tracking nature. |
(0000646)
toracat 2022-07-14 17:32 |
Make sure you run : yum install kmod-nvidia-390xx NOT: yum install akmod-nvidia-390xx (akmod is not an elrepo package) |
(0000649)
dufgrinder 2022-07-19 17:59 |
Hello Toracat, We found the root cause: - On my install, I use RPM-Fusion yum install kmod-nvidia-390xx returns: ============================================================================================================== Paquet Architecture Version Dépôt Taille ============================================================================================================== Installation: kmod-nvidia-390xx x86_64 3:390.144-3.el8 rpmfusion-nonfree-updates 55 k Installation des dépendances: akmod-nvidia-390xx x86_64 3:390.144-3.el8 rpmfusion-nonfree-updates 89 k akmods noarch 0.5.6-24.el8 epel 27 k egl-wayland i686 1.1.9-3.el8 appstream 41 k egl-wayland x86_64 1.1.9-3.el8 appstream 39 k kernel-abi-stablelists noarch 4.18.0-372.16.1.el8_6 baseos 8.1 M kmodtool noarch 1-37.el8 epel 19 k nvidia-settings-390xx x86_64 390.144-2.el8 rpmfusion-nonfree-updates 1.7 M xorg-x11-drv-nvidia-390xx x86_64 3:390.144-2.el8 rpmfusion-nonfree-updates 2.6 M xorg-x11-drv-nvidia-390xx-kmodsrc x86_64 3:390.144-2.el8 rpmfusion-nonfree-updates 9.1 M xorg-x11-drv-nvidia-390xx-libs i686 3:390.144-2.el8 rpmfusion-nonfree-updates 16 M xorg-x11-drv-nvidia-390xx-libs x86_64 3:390.144-2.el8 rpmfusion-nonfree-updates 15 M As you see, it also downloads the akmod. Finally, I used > yum install --disablerepo rpmfusion-nonfree-updates kmod-nvidia-390xx And now it works fine. I think we can close this ticket, many thanks for your help KR, Olivier |
(0000650)
toracat 2022-07-19 18:05 |
Glad to hear things are now working. Right, rpmfusion is a different beast. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
236 | [AlmaLinux-8] kernel | major | always | 2022-05-17 13:30 | 2022-07-17 18:57 |
Reporter: | pmdumuid | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | The Simple Desktop Display Manager (sddm) fails to launch when using the default kernel that comes with Almalinux 8.6 | ||||
Description: |
After upgrading to my AlmaLinux 8.6, I was unable to log in to a graphical environment (sddm). However when selecting an older version of the kernel from the grub screen, I am able to log in via the graphical environment (sddm). I have since installed AlmaLinux 8.6 from scratch in a virtual machine and replicated this problem with a fresh install. My colleages using different hardware are also experiencing this issue. Given that sddm is a default desktop manager for KDE environments, I would presume this is major in severity. My diagnosis so far: Switching to a text terminal (Ctrl-Alt+F5) and logging in, I identified that sddm was freezing. journalctl -b -u sddm.service stops after showing: May 17 20:25:50 linux-disp.kydlocal systemd[1]: Started Simple Desktop Display Manager. when using the failing kernel, however for a working kernel, it shows a lot more: -- Logs begin at Tue 2022-05-17 20:25:15 ACST, end at Tue 2022-05-17 22:49:48 ACST. -- May 17 20:25:50 linux-disp.kydlocal systemd[1]: Started Simple Desktop Display Manager. May 17 20:25:58 linux-disp.kydlocal sddm[1933]: Could not setup default cursor May 17 20:25:59 linux-disp.kydlocal sddm-helper[4193]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0) May 17 20:26:32 linux-disp.kydlocal sddm-helper[11443]: pam_unix(sddm:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=xxxx |
||||
Tags: | |||||
Steps To Reproduce: |
Steps: install a fresh Almalinux 8.6 Install sddm Enable sddm (systemctl enable sddm.service) Start sddm (systemctl start sddm.service) What should occur: A graphical login screen to show up . What actually occurs: A black screen with mouse visible upon movement, (i.e. Xorg started) No text or graphics visible |
||||
Additional Information: |
Working kernel version - 4.18.0-348.23.1.el8_5.x86_64 Failing Kernel Version - 4.18.0-372.9.1.el8.x86_64 |
||||
Attached Files: | |||||
Notes | |
(0000577)
alukoshko 2022-05-24 00:23 |
Hi. Seems like upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2082719 |
(0000595)
dfilonov 2022-06-10 15:56 |
Confirming the new kernel from Centos Stream ( kernel-4.18.0-394.el8.x86_64 ) fixes the issue. |
(0000648)
toracat 2022-07-17 18:57 |
There was an update to the RHBZ quoted above: " Troy Dawson 2022-07-13 14:26:47 UTC There is progress on getting this fixed in RHEL 8.6, instead of just waiting for RHEL 8.7. No expected date yet, but the work has started. " Once it is fixed in RHEL, Alma will inherit it. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
277 | [AlmaLinux-8] kernel | major | always | 2022-07-05 01:14 | 2022-07-16 20:23 |
Reporter: | amcrae42 | Platform: | x86_64 | ||
Assigned To: | OS: | almalinux | |||
Priority: | normal | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | 8.6 kernel breaks program | ||||
Description: |
qbittorrent search hangs and locks up GUI. Almalinux 8.4 kernel 305 works OK Almalinux 8.5 kernel 348 works OK Almalinux 8.6 kernel 372 hangs/locks up GUI Almalinux 9.0 kernel 5.x works OK (recompiled for el9) |
||||
Tags: | |||||
Steps To Reproduce: |
Install virgin 8.6 system on test machine install epel, run yum update install qbittorrent under View, tick the search Engine box click on search tab, search plugins, check for updates, close type anything in search field GUI hangs Manually install kernel vmlinuz-4.18.0-348.el8.x86_64 from Almalinux 8.5 (install kernel, kernel-core, kernel-modules rpms from 8.5 cd) reboot Repeat qbittorrent search test - all works OK |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000647)
amcrae42 2022-07-16 20:23 |
This bug breaks multiple applications and is related to the handling of subprocesses. Breaks seafile client, causes hangs in truecrypt. Is probably the same bug as 000236. I am now running centos stream kernel 4.18.0-394 which fixes all of the above. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
282 | [AlmaLinux-8] -OTHER | minor | have not tried | 2022-07-13 21:35 | 2022-07-13 21:35 |
Reporter: | cPSloaneB | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Publicly document that ELevate is not currently compatible with system container environments | ||||
Description: | ELevate is geared towards bare metal or virtual environments which allow the guest system to change the way the system boots. At least according to the migration room on chat.almalinux.org, system containers (e.g., OpenVZ) are not currently supported because of this, and a different way of accomplishing certain operations would need to be devised. This information should be made available in a more publicly visible location, perhaps such as somewhere in the ELevate section of wiki.almalinux.org. | ||||
Tags: | elevate, leapp | ||||
Steps To Reproduce: | |||||
Additional Information: | See https://chat.almalinux.org/almalinux/channels/migration/er4xdybfa7y5ixe18wqxizk59a, at or around the 18th of March 2022, for the start of the relevant conversation. | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
141 | [AlmaLinux-8] -OTHER | minor | have not tried | 2021-11-03 00:14 | 2022-07-08 14:16 |
Reporter: | mjkelly | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | ELevate install: conflicts in /usr/lib/python3.6/site-packages/__pycache__ | ||||
Description: |
I just did a CentOS 7 to AlmaLinux 8.4 conversion with ELevate (https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html). Following the quickstart guide, I ran `sudo leapp preupgrade` until the report showed no issues that inhibited an upgrade. I only had to make 2 of the 3 modifications listed in the quickstart guide: 1. Updating /etc/ssh/sshd_config (I explicitly disabled root login via ssh rather than enabling it) 2. sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True When running `sudo leapp upgrade`, I got the following error from dnf: ``` 2021-11-01 20:33:54.907 DEBUG PID: 41194 leapp.workflow.Download.dnf_package_download: file /usr/lib/python3.6/site-packages/__pycache__/six.cpython-36.opt-1.pyc from install of python3-six-1.11.0-8.el8.noarch conflicts with file from package python36-six-1.14.0-3.el7.noarch ``` My workaround was to remove python36 from the CentOS 7 system (and any packages that depended on it). The upgrade worked after that. There were no remediation steps after the upgrade, because my resulting Alma 8.4 came with Python 3.6 (as a side effect of the upgrade, perhaps?) My previously-installed packages that depended on python3 were from EPEL, so are unsupported in the new installation. Let me know if there's more info I can collect, or if I should attempt a clean repro on a fresh CentOS 7 VM. Thank you! |
||||
Tags: | |||||
Steps To Reproduce: |
[I haven't tried this myself; this is a synthesis of what I believe happened based on looking at logs files] 1. Install `python36-six-1.14.0-3.el7.noarch` on a CentOS 7 system 2. Run `leapp upgrade` 3. It should fail with with the file conflict error mentioned above |
||||
Additional Information: |
I uploaded full logs (all archive tarballs from /var/log/leapp/archive) here: https://scratch.michaelkelly.org.s3-website-us-east-1.amazonaws.com/leapp-logs.tar.bz2. I collected all the logs in a single tarball. Each run is in a sequentially-numbered directory. logs.5/var/log/leapp/leapp-upgrade.log is probably the best place to start -- that contains the error message mentioned above. |
||||
Attached Files: | |||||
Notes | |
(0000372)
mjkelly 2021-11-03 03:28 |
I was able to repro this with a fresh CentOS 7 install. The key is having python36 modules installed via EPEL. I'm not sure if upgrading a CentOS 7 host with EPEL packages installed is supported, but are the more specific repro steps either way! 1. Start from a fresh CentOS 7.9.2009 release 2. (install python 3.6 package from EPEL): yum update; yum install epel-release; install python36-six 3. yum install leapp-upgrade leapp-data-centos 4. (get CentOS set up for ELevate upgrade, from quickstart guide): rmmod pata_acpi; echo PermitRootLogin no | sudo tee -a /etc/ssh/sshd_config; leapp answer --section remove_pam_pkcs11_module_check.confirm=True 5. leapp preupgrade 6. leapp upgrade Step 5 should show the system is ready for an upgrade, and step 6 should fail with an error like this: Error: Transaction test error: file /usr/lib/python3.6/site-packages/__pycache__/six.cpython-36.opt-1.pyc from install of python3-six-1 .11.0-8.el8.noarch conflicts with file from package python36-six-1.14.0-3.el7.noarch file /usr/lib/python3.6/site-packages/__pycache__/six.cpython-36.pyc from install of python3-six-1.11.0- 8.el8.noarch conflicts with file from package python36-six-1.14.0-3.el7.noarch file /usr/lib/python3.6/site-packages/six.py from install of python3-six-1.11.0-8.el8.noarch conflicts w ith file from package python36-six-1.14.0-3.el7.noarch I hope this helps! Thanks. |
(0000374)
alukoshko 2021-11-08 08:57 |
Hi. EPEL is not supported yet and it's not easy because we have to add many actions for EPEL packages to https://pes.almalinux.org. For example python36-six should be replaced with python3-six during upgrade and we have to add action for this. And the same for every package that have it's name changed in EPEL 8. Please stay tuned. Or even better, join us. |
(0000393)
mjkelly 2021-11-16 17:32 |
Gotcha! That makes sense. Thanks for the info. I can't promise any contributions in the near future, but if I have some time I'll learn about Package Evolution Service. Thanks for all your work, it's incredible that this works under any circumstances. :) |
(0000401)
tjyang 2021-11-17 13:03 |
I want to express my kudos for elevate project members for bringing elevate to centos7. Although it is not as automated as it can be but I have use elevate to migrate a few of my centos 7 VMWare test/non-prod VMs with saltstack formula to get rid of manual commands. I will try to find way to see, from sysadmin perspective, if I can contribute after my RTFM of leapp/elevate. |
(0000634)
ParadoxGuitarist 2022-07-08 14:16 |
I just ran into this and it looked like there was just a form that needed to be filled out for each of the conflicting packages? I can totally help out with that! (if it's more complicated, is there any other documentation that's needed for contribution? ) Thanks! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
80 | [AlmaLinux-8] lorax | crash | always | 2021-05-20 13:45 | 2022-07-08 10:04 |
Reporter: | tiny | Platform: | X86_64 | ||
Assigned To: | alukoshko | OS: | Alma Linux | ||
Priority: | normal | OS Version: | 8.4 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | OSbuild Crashes on startup | ||||
Description: |
I am not able to start the osbuild composer service on alma linux 8.4 or run any composer-cli command without it immediately crashing. I installed composer using redhat's documentation listed below. The issue does not exist inside of centos stream using the same instructions. both running 2cpu 4gb KVM virtual machines inside of proxmox https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/composing_a_customized_rhel_system_image/installing-composer_composing-a-customized-rhel-system-image |
||||
Tags: | |||||
Steps To Reproduce: |
1. install almalinux 8.4 2. run sudo dnf install osbuild-composer composer-cli cockpit-composer bash-completion 3. sudo systemctl enable --now osbuild-composer.socket 4. run composer-cli blueprint list or try and start the image builder service in cockpit |
||||
Additional Information: | |||||
Attached Files: |
composer-bug.txt (6,272 bytes) 2021-05-21 02:20 https://bugs.almalinux.org/file_download.php?file_id=84&type=bug os-build-error.txt (96,803 bytes) 2022-07-07 15:01 https://bugs.almalinux.org/file_download.php?file_id=165&type=bug |
||||
Notes | |
(0000206)
tiny 2021-05-21 02:20 |
Here is the stack trace I am gettng from sudo composer-cli blueprint list |
(0000207)
alukoshko 2021-05-21 18:09 |
Hello and thanks. Yes I can confirm it. At the moment osbuild-composer code is only supports RHEL and CentOS and patch to add another distributions would not be trivial. osbuild-composer developers know about this problem and going to implement support for RHEL based distros later. |
(0000208)
tiny 2021-05-21 23:13 |
Linked below is the os-build issue from their GitHub https://github.com/osbuild/osbuild/issues/644 |
(0000601)
alukoshko 2022-06-21 14:53 |
Hello. We have a patched version that now looks working (at least "Steps To Reproduce"): https://build.almalinux.org/pulp/content/builds/AlmaLinux-8-x86_64-2913-br/ Could you please test it before we'll release it for all? |
(0000619)
tiny 2022-06-29 21:16 |
I have confirmed via following steps 1. create an amlalinux vm in cockpit on fedora 2. download all rpms from https://build.almalinux.org/pulp/content/builds/AlmaLinux-8-x86_64-2913-br/Packages/o/ 3. ran sudo dnf install *.rpm 4. ran sudo systemctl enable --now cockpit.socket 5. ran sudo composer-cli blueprints list and returned an empty out as expected I will test creating an image with cockpit-composer later today |
(0000620)
tiny 2022-06-29 22:35 |
I was able to create blueprint in the cockpit-composer web interface but I was not able to build a qcow2 image and it failed with the following error Pipeline build Stage org.osbuild.rpm Output: bwrap: execvp /run/osbuild/lib/runners/org.osbuild.almalinux86: No such file or directory |
(0000621)
tiny 2022-06-29 22:43 |
the output above is identical to the logs generated from creating the image on the cli and extracting them from the tar ball |
(0000626)
eabdullin 2022-07-05 10:28 |
Hello. We patched osbuild for almalinux. Could you please test it with previuos osbuild-composer build? https://build.almalinux.org/pulp/content/builds/AlmaLinux-8-x86_64-3331-br/ |
(0000629)
tiny 2022-07-07 13:12 |
I downloaded and installed the additional packages you posted using the same process as in comment 619 and rebuilt the image from cockpit and it generated a qcow2 file and I was able to import and run it. |
(0000630)
tiny 2022-07-07 15:01 |
this appears to affect alma9 as well let me know if I need to submit a separate bug report. I have also attached the output of journalctl -u osbuild-composer.service this was created using the same steps to reproduce in the inital bug report. |
(0000631)
eabdullin 2022-07-08 05:30 |
Not necessary to create a separate bug report. Thank you for your help! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
276 | [AlmaLinux-8] kernel | minor | always | 2022-07-01 14:45 | 2022-07-01 14:45 |
Reporter: | solidstate | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Raspberry Pi 4 Bluetooth Radio not functional on pre-built almalinux-8 image. | ||||
Description: | Bluetooth radio is not recognized when using pre-built almalinux-8 image on raspberry pi 4, built 20220618. | ||||
Tags: | |||||
Steps To Reproduce: |
Load relevant kernel modules and attempt any operation involving the Bluetooth radio, the radio is not recognized. [root@pi ~]# modprobe bluetooth [root@pi ~]# modprobe brcmfmac [root@pi ~]# rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no [root@pi ~]# |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
275 | [AlmaLinux-8] kernel | major | always | 2022-07-01 09:31 | 2022-07-01 09:31 |
Reporter: | dufgrinder | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Screen Freeze - Driver Nouveau crahes | ||||
Description: |
When Using AlmaLinux with XFCE Desktop (X11 Server), after a while, the screen freezes. The kernel is not crashed, but journalctl report errors in 'nouveau' module. Data retrieved via ssh Graphic Card: 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520] (rev a1) See journalctl and dmesg dumps |
||||
Tags: | |||||
Steps To Reproduce: | Just work either with firefox, thunderbird, today I provoque it with vlc looping on a short video | ||||
Additional Information: | |||||
Attached Files: |
dmesg.txt (78,679 bytes) 2022-07-01 09:31 https://bugs.almalinux.org/file_download.php?file_id=163&type=bug journalctl.txt (171,982 bytes) 2022-07-01 09:31 https://bugs.almalinux.org/file_download.php?file_id=164&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
163 | [AlmaLinux-8] kernel | block | always | 2021-12-07 11:43 | 2022-06-27 13:16 |
Reporter: | aklymov | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Unable to install 8.5 on Intel motherboards S5500, SC2400, SC2600 - problem initializing video | ||||
Description: |
Hello, We are having problem installing Almalinux 8.5 on Intel motherboards S5500, SC2400, SC2600, right from the start - boot iso does not initialize video. When installing from Almalinux 8.3 iso there is no such problem. After selecting "Install" from GRUB menu screen goes dark. |
||||
Tags: | intel, kernel, setup, video | ||||
Steps To Reproduce: | Boot Almalinux 8.5 installation iso on Intel motherboard S5500, SC2400, SC2600CW, after selecting "Install" from GRUB menu, screen goes blank. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000449)
alukoshko 2021-12-13 14:10 |
Hello. Could you please try CentOS 8.5 on the same system? We have to find out if this is upstream regression or AlmaLinux specific bug. |
(0000452)
aklymov 2021-12-13 17:42 |
We tried RockyLinux 8.5 and RHEL8.5 - same symptoms, problem is most likely in kernel configuration difference between 4.18-240 (which was used in 8.3 release and 4.18-348 (8.5 correspondingly). The paradox is, that to report problem upstream we have to have paid subscription. |
(0000453)
alukoshko 2021-12-13 17:48 |
Then the best option is to check it on CentOS Stream 8 iso: http://mirror.centos.org/centos/8-stream/isos/ If it works then most likely it will work with 8.6. If not then you should report to CentOS Stream bugzilla https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream BTW do you need graphics after install? You can either install in text mode or start with AlmaLinux 8.3 and then upgrade it to 8.5. |
(0000454)
toracat 2021-12-13 19:48 |
@aklymov You can report RHEL-related problems upstream (Red Hat) without paid subscription. Just create an account at bugzilla.redhat.com and file a report. |
(0000455)
aklymov 2021-12-15 18:41 |
Thank you, toracat, I will do that. |
(0000617)
alukoshko 2022-06-27 13:16 |
aklymov could you confirm that video works on 8.6? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
269 | [AlmaLinux-8] systemd | minor | always | 2022-06-22 06:08 | 2022-06-22 19:46 |
Reporter: | bogen85 | Platform: | aarch64 | ||
Assigned To: | OS: | Almalinux | |||
Priority: | normal | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | bootctl (systemd-boot) inconsistency | ||||
Description: |
This could be a RHEL issue? AlmaLinux 8 has bootctl on aarch64, AlmaLinux 9 does not. AlmaLinux 9 might not have it due to this: 2021-10-12 - systemd maintenance team <systemd-maint@redhat.com> - 249-8 - boot: don't build bootctl when -Dgnu-efi=false is set (#2003130) Both have bootctl on x86_64. Anyways, this is twofold: 1) AlmaLinux 9 is missing bootctl on aarch64 2) AlmaLinux 8 bootctl installs an efi loader that crashes parallels on the Apple M1. |
||||
Tags: | |||||
Steps To Reproduce: |
On an Apple M1 macbook with the parallels $ prlctl --version prlctl version 17.1.4 (51567) Create partition at least 64MiB as type EF00 format it as fat32: mkfs.vfat -F32 -n EFI-BOOT /dev/sdXY mount it on /boot: mount /dev/sdXY /boot install systemd-boot efi loader: bootctl install reboot results (on aarch64) on Fedora 34: systemd-boot menu is present, can go into firmware on Fedora 35: systemd-boot menu is present, can go into firmware on Fedora 36: systemd-boot menu is present, can go into firmware AlmaLinux 8: parallels crashes and wants to send a bug report AlmaLinux 9: could not test as bootctl is missing results (on x86_64) on Fedora 35: systemd-boot menu is present, can go into firmware on Fedora 36: systemd-boot menu is present, can go into firmware AlmaLinux 8: systemd-boot menu is present, can go into firmware AlmaLinux 9: systemd-boot menu is present, can go into firmware |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000602)
bogen85 2022-06-22 06:11 |
ArchLinux aarch64 on the Apple M1 macbook in parallels passes the above test. $ bootctl --version systemd 251 (251.2-1-arch) |
(0000603)
bogen85 2022-06-22 06:20 |
on each of the above tests I did sync and unmount /boot before rebooting. |
(0000604)
bogen85 2022-06-22 12:33 |
secure boot is not enabled for this |
(0000605)
bogen85 2022-06-22 13:31 |
fedora 34 bootctl (systemd) version 248 (v248.10-1.fc34) fedora 35 bootctl (systemd) version 249 (v249.12-5.fc35) fedora 36 bootctl (systemd) version 250 (v250.7-1.fc36) almalinux 8 bootctl (systemd) version 239 (v239-58.el8) --------- For Fedora 35-36 I used https://getfedora.org/en/workstation/download/ for each release For AlmaLinux (x86_64 and aarch64) I used arch-chroot from arch-install-scripts on the Fedora 36 livecd and the 8 or 9 AlmaLinux default rootfs from https://us.lxd.images.canonical.com/images/almalinux/ (refreshed and upgraded before proceeding, but those are already up to date when downloaded fresh) |
(0000606)
bogen85 2022-06-22 13:44 |
oh, I see bootctl is on AlmaLinux 9 aarch64 $ dnf provides bootctl Last metadata expiration check: 18:19:30 ago on Tue 21 Jun 2022 02:20:16 PM CDT. systemd-boot-250.3-1.el9.aarch64 : Simple UEFI boot manager to execute configured EFI images Repo : epel Matched from: Filename : /usr/bin/bootctl I will try it. |
(0000607)
bogen85 2022-06-22 13:58 |
On AlmaLinux 9 x86_64 and aarch64: $ dnf provides bootctl systemd-boot-250.3-1.el9.x86_64 : Simple UEFI boot manager to execute configured EFI images Repo : @System Matched from: Filename : /usr/bin/bootctl systemd-boot-250.3-1.el9.x86_64 : Simple UEFI boot manager to execute configured EFI images Repo : epel Matched from: Filename : /usr/bin/bootctl All my AlmaLinux installs (8 and 9) on X86_64 use systemd-boot. They work fine. ----------- bootctl on AlmaLinux9 aarch64 works fine. |
(0000608)
bogen85 2022-06-22 14:03 |
So, the only inconsistency is that the systemd-boot on AlmaLinux 8 is older (239) than the bootctl on all the other releases I tried (248, 249, 250) and while 239 works on x86_64, it does not work on Apple aarch64 M1 in parallels. systemd-boot 248, 249, 250 all work on x86_64 (non parallels, not on an Apple machine) and on Apple aarch64 M1 (parallels) |
(0000609)
bogen85 2022-06-22 14:27 |
My AlmaLinux 8 and 9 installs on x86_64 are all custom and semi-automated via scripts. I guess I missed noting the bootctl coming from EPEL 9 for AlmaLinux 9 as EPEL was already enabled before that, and when bootctl was missing I must have done a "dnf provides boot" and adding systemd-boot to an earlier package list. Oh well. So the only issue here is systemd-boot not working with AlmaLinux 8 on aarch64 Apple M1 in parallels, but working everywhere else in the above scenarios. |
(0000610)
bogen85 2022-06-22 15:14 |
Looks like centos-8-stream bootctl is the same version as that in AlmaLinux 8. I will try with centos-8-stream as well... [root@rootfs-centos-8-stream ~]# bootctl --version systemd 239 (239-58.el8) |
(0000611)
bogen85 2022-06-22 19:46 |
Also crashes with centos-8 stream the same way it does with AlmaLinux 8 bootctl --version systemd 239 (239-58.el8) So this is issue is not specific to AlmaLinux. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
266 | [AlmaLinux-8] anaconda | crash | always | 2022-06-15 03:01 | 2022-06-15 15:54 |
Reporter: | ggiesen | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux 8 | |||
Priority: | high | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Anaconda fails after typing in passphrase for encrypted disk with "TypeError: Argument 1 does not allow None as a value" | ||||
Description: |
Anaconda fails after typing in the passphrase for an encrypted disk, and clicking "Save Passphase". May take happen almost immediately or may take a minute. This happens even before your accept the changes for the disk layout. |
||||
Tags: | |||||
Steps To Reproduce: |
Create a VM in VMware Workstation Pro 16.2.1 with the following attributes: 2 GB RAM 1 vCPU 55 GB Disk 1 Network Adapter Remove Sound Card Remove Printer Boot AlmaLinux 8.6 DVD, Configure Networking, Select Time Zone, Disable KDUMP, Enter Root Password. Select Manual Partitioning, "I want to encrypt my disks" with the following disk layout: /boot - 1 GiB /swap - 2 GiB /root - 20 GiB /home - 10 GiB /tmp - 5 GiB /var - 10 GiB /var/log - 5 GiB Click done, and enter encryption passphrase. Click "Accept Passphrase". Within 5-60 seconds, the crash report will appear. |
||||
Additional Information: | Screenshot and crash report attached | ||||
Attached Files: |
anaconda-2022-06-14-224631.338516-1827.tar.gz (524,095 bytes) 2022-06-15 03:01 https://bugs.almalinux.org/file_download.php?file_id=144&type=bug anaconda_error.png (90,383 bytes) 2022-06-15 03:01 https://bugs.almalinux.org/file_download.php?file_id=145&type=bug CentOS 8 64-bit-2022-06-14-23-17-32.png (69,721 bytes) 2022-06-15 03:20 https://bugs.almalinux.org/file_download.php?file_id=146&type=bug CentOS 8 64-bit-2022-06-14-23-12-27.png (65,909 bytes) 2022-06-15 03:20 https://bugs.almalinux.org/file_download.php?file_id=147&type=bug CentOS 8 64-bit-2022-06-14-23-13-18.png (43,094 bytes) 2022-06-15 03:20 https://bugs.almalinux.org/file_download.php?file_id=148&type=bug CentOS 8 64-bit-2022-06-14-23-13-26.png (35,270 bytes) 2022-06-15 03:20 https://bugs.almalinux.org/file_download.php?file_id=149&type=bug CentOS 8 64-bit-2022-06-14-23-13-39.png (81,221 bytes) 2022-06-15 03:20 https://bugs.almalinux.org/file_download.php?file_id=150&type=bug CentOS 8 64-bit-2022-06-14-23-13-58.png (129,822 bytes) 2022-06-15 03:20 https://bugs.almalinux.org/file_download.php?file_id=151&type=bug CentOS 8 64-bit-2022-06-14-23-14-24.png (20,013 bytes) 2022-06-15 15:54 https://bugs.almalinux.org/file_download.php?file_id=152&type=bug CentOS 8 64-bit-2022-06-14-23-14-36.png (53,423 bytes) 2022-06-15 15:54 https://bugs.almalinux.org/file_download.php?file_id=153&type=bug CentOS 8 64-bit-2022-06-14-23-15-03.png (47,307 bytes) 2022-06-15 15:54 https://bugs.almalinux.org/file_download.php?file_id=154&type=bug CentOS 8 64-bit-2022-06-14-23-16-16.png (73,049 bytes) 2022-06-15 15:54 https://bugs.almalinux.org/file_download.php?file_id=155&type=bug CentOS 8 64-bit-2022-06-14-23-16-41.png (58,301 bytes) 2022-06-15 15:54 https://bugs.almalinux.org/file_download.php?file_id=156&type=bug CentOS 8 64-bit-2022-06-14-23-17-13.png (81,325 bytes) 2022-06-15 15:54 https://bugs.almalinux.org/file_download.php?file_id=157&type=bug VM_settings.png (33,936 bytes) 2022-06-15 15:54 https://bugs.almalinux.org/file_download.php?file_id=158&type=bug |
||||
Notes | |
(0000596)
ggiesen 2022-06-15 03:20 |
More screenshots of all settings |
(0000597)
ggiesen 2022-06-15 15:54 |
More settings screenshots since Mantis thinks I'm spamming, it won't let me attach them all at once. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
263 | [AlmaLinux-8] NetworkManager | minor | always | 2022-06-07 11:47 | 2022-06-09 09:55 |
Reporter: | OscarCS | Platform: | |||
Assigned To: | OS: | ||||
Priority: | normal | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | /etc/resolv.conf not correctly updated after sleep | ||||
Description: | /etc/resolv.conf keeps older dns servers when ethernet is removed after a sleep | ||||
Tags: | NetworkManager;/etc/resolve.conf;Laptop;sleep | ||||
Steps To Reproduce: |
In a laptop, in a place "X" whit a USB-C ethernet adapter "A" close the laptop and put it to sleep Go to place Y open the laptop and recover from sleep connect a USB-C ethernet adapter "B" plug the LAN cable to the adapter "B" now you have a new ethernet connected to internet with a new IP adress your /etc/resolve.conf has NEW "nameserver" lines, but the old ones are still there in the first positions as result, name resolution becomes extremely slow since, until timeouts for the old and unreachable dns servers are completed, the new dns servers are not use. Example of /etc/resolve.conf in place A ; generated by /sbin/dhclient-script search XXXXXX # Not sure about this line, I don't have access to it nameserver 192.168.100.1 Example of /etc/resolve.conf in place B: ; generated by /sbin/dhclient-script search uab.cat nameserver 192.168.100.1 nameserver 158.109.0.1 nameserver 158.109.0.9 |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000594)
OscarCS 2022-06-09 09:55 |
More information in the topic. A workaround is: systemctl restart NetworkManager.service Below I'm paste the "nmcli" output of the laptop before and after "systemctl restart NetworkManager.service" The laptop arrived from "home" to the workplace. The user plugged in the Network Cable It received the IP address from the workplace dhcp (158.109.XX.XXX) It received the DNSs from the workplace (158.109.0.1 158.109.0.9) but the old DNS was not removed (192.168.100.1) so every new connection takes ages. the user restarted NetworkManager.service then the old DNS was removed (192.168.100.1) and everything works fine. I can see that hw address from the wifi changed from E6:92:53:5D:FA:B6 to A0:CE:C8:3B:2F:3E after the restart, but after a bit of googling I found that this is perfectly normal. This was not happening 1 month ago I hope this helps to understand the problem and fixing it ################################################# * BEFORE restart NetworkManager.service : ]$ nmcli enp0s13f0u3u3u1: connected to Wired connection 1 "Realtek RTL8153" ethernet (r8152), A0:CE:C8:3B:2F:3E, hw, mtu 1500 ip4 default inet4 158.109.XX.XXX/23 route4 158.109.XX.0/23 metric 100 route4 default via 158.109.XX.1 metric 100 inet6 fe80::3f70:8c7d:70e8:a48d/64 route6 fe80::/64 metric 1024 virbr0: connected (externally) to virbr0 "virbr0" bridge, 52:54:00:56:BF:32, sw, mtu 1500 inet4 192.168.122.1/24 route4 192.168.122.0/24 metric 0 wlp0s20f3: disconnected "Intel Ice Lake-LP PCH CNVi" 2 connections available wifi (iwlwifi), E6:92:53:5D:FA:B6, hw, mtu 1500 p2p-dev-wlp0s20f3: disconnected "p2p-dev-wlp0s20f3" wifi-p2p, hw lo: unmanaged "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 DNS configuration: servers: 192.168.100.1 servers: 158.109.0.1 158.109.0.9 domains: uab.cat interface: enp0s13f0u3u3u1 * AFTER restart NetworkManager.service : $ nmcli enp0s13f0u3u3u1: connected to Wired connection 1 "Realtek RTL8153" ethernet (r8152), A0:CE:C8:3B:2F:3E, hw, mtu 1500 ip4 default inet4 158.109.XX.XXX/23 route4 default via 158.109.XX.1 metric 100 route4 158.109.XX.0/23 metric 100 inet6 fe80::3f70:8c7d:70e8:a48d/64 route6 fe80::/64 metric 1024 virbr0: connected (externally) to virbr0 "virbr0" bridge, 52:54:00:56:BF:32, sw, mtu 1500 inet4 192.168.122.1/24 route4 192.168.122.0/24 metric 0 wlp0s20f3: disconnected "Intel Ice Lake-LP PCH CNVi" 2 connections available wifi (iwlwifi), 3E:C9:F9:3E:FE:27, hw, mtu 1500 p2p-dev-wlp0s20f3: disconnected "p2p-dev-wlp0s20f3" wifi-p2p, hw lo: unmanaged "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 DNS configuration: servers: 158.109.0.1 158.109.0.9 domains: uab.cat interface: enp0s13f0u3u3u1 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
261 | [AlmaLinux-8] -OTHER | minor | always | 2022-06-06 05:55 | 2022-06-06 06:03 |
Reporter: | beaver6675 | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | RFE: Issue a version of AlmaLinux 8 RPM GPG key with SHA256 hash | ||||
Description: |
RHEL 9 does not import RPM GPG keys with SHA1 in particular the AlmaLinux 8 key will not import on AlmaLinux 9. This means that out-of-the-box you cannot build AlmaLinux 8 RPMs using mock on AlmaLinux 9 (unless gpgcheck is disabled in the mock templates which is not the default). |
||||
Tags: | |||||
Steps To Reproduce: |
On Almalinux 9, RHEL 9, CentOS Stream 9 rpm --import RPM-GPG-KEY-AlmaLinux-8 |
||||
Additional Information: |
1. 8 and 9 keys import on AlmaLinux 8 2 8 and 9 keys import on Fedora 36 |
||||
Attached Files: | |||||
Notes | |
(0000588)
beaver6675 2022-06-06 06:03 |
My bad - it might be due to packages signed with SHA1 and not the key itself. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
257 | [AlmaLinux-8] kernel | minor | always | 2022-06-03 02:36 | 2022-06-03 02:36 |
Reporter: | davemoniz | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | unchecked MSR access error on migration from Centos 8 to AL8.6 | ||||
Description: |
I migrated 2 Centos 8 AWS EC2 servers to AlmaLinux 8.6. One was my production server and one was a fresh Centos 8 install. They both have this error in the log at boot and was not there prior to migration. unchecked MSR access error: WRMSR to 0x199 (tried to write 0x0000000000000800) at rIP: 0xffffffffae66dcf4 (native_write_msr+0x4/0x20) Kernel: Linux 4.18.0-372.9.1.el8.x86_64 on x86_64 |
||||
Tags: | |||||
Steps To Reproduce: |
migrate from centos 8 to AL8.6. Reboot. run dmesg | egrep -i 'error|critical|warn' |
||||
Additional Information: | Thank you. | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
248 | [AlmaLinux-8] sssd | minor | N/A | 2022-05-25 19:31 | 2022-05-26 08:07 |
Reporter: | schlitzered | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | why has alma linux more recent packages then centos stream? | ||||
Description: |
i just noticed that the alma linux 8 repos have more recent packages then centos 8-stream. example: http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/sssd-ipa-2.6.2-3.el8.x86_64.rpm https://mirror.23m.com/almalinux/8.6/BaseOS/x86_64/os/Packages/sssd-ipa-2.6.2-4.el8_6.x86_64.rpm i am sorry, but i have no access to a RHEL repo, so i could take a look there, but i was under the impression that 8-stream should have more recent packages then RHEL, and therefore also then ALMA linux. not sure what is going on here, but this sounds strange, at least from the point what centos/redhat folks where telling about the stream stuff |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000580)
toracat 2022-05-26 08:07 |
RHEL 8 has sssd-ipa-2.6.2-4.el8_6. Alma Linux correctly matches it. You may want to file a report upstream at Red Hat. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
246 | [AlmaLinux-8] abrt | crash | always | 2022-05-24 11:33 | 2022-05-24 11:37 |
Reporter: | brianjmurrell | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Failed to create a new issue: 'Error Type: SYSTEM NOTICE, | ||||
Description: |
Trying to use abrt-cli to report a bug results in: Failed to create a new issue: 'Error Type: SYSTEM NOTICE, Error Description: Object of class SoapFault could not be converted to int' ('report_AlmaLinuxBugTracker' exited with 1) |
||||
Tags: | |||||
Steps To Reproduce: |
# abrt-cli report 0158e1432033188b1a25aed3ef912a396d31033c ('report_uReport' completed successfully) AlmaLinux Bug Tracker User name: [redacted] AlmaLinux Bug Tracker Password: [redacted] The report has been updated Checking for duplicates Creating a new issue Adding External URL to issue Failed to create a new issue: 'Error Type: SYSTEM NOTICE, Error Description: Object of class SoapFault could not be converted to int' ('report_AlmaLinuxBugTracker' exited with 1) |
||||
Additional Information: | Severity and Priority set quite high as this impedes filing of many other bugs. | ||||
Attached Files: | |||||
Notes | |
(0000579)
brianjmurrell 2022-05-24 11:37 |
I guess this is only intermittent as I was able to report a different bug with abrt-cli. I don't see any way to edit the metadata on this ticket though. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
247 | [AlmaLinux-8] ipa | minor | have not tried | 2022-05-24 11:35 | 2022-05-24 11:35 |
Reporter: | brianjmurrell | Platform: | |||
Assigned To: | OS: | ||||
Priority: | normal | OS Version: | |||
Status: | new | Product Version: | 8.4 | ||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | b2136489ecd201d5a11f78a9dcecd5cec0b19390 | ||||
URL: | https://retrace.almalinux.org/faf/reports/bthash/03b7f2b3f746674128b45c64c4af5b916d81cc48 | ||||
Summary: | [abrt] ipa-client: run(): ipautil.py:599:run:ipapython.ipautil.CalledProcessError: CalledProcessError(Command ... | ||||
Description: |
Description of problem: Not sure why this happene. Version-Release number of selected component: ipa-client-4.9.6-10.module_el8.5.0+2603+92118e57 Truncated backtrace: #1 run in /usr/lib/python3.6/site-packages/ipapython/ipautil.py:599 0000002 disable_ldap_automount in /usr/lib/python3.6/site-packages/ipaplatform/redhat/tasks.py:776 0000003 uninstall in /usr/lib/python3.6/site-packages/ipaclient/install/ipa_client_automount.py:323 0000004 configure_automount in /usr/lib/python3.6/site-packages/ipaclient/install/ipa_client_automount.py:474 0000005 main in /usr/lib/python3.6/site-packages/ipaclient/install/ipa_client_automount.py:601 0000006 <module> in /usr/sbin/ipa-client-automount:27 |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: |
cmdline: /usr/libexec/platform-python -I /usr/sbin/ipa-client-automount --uninstall --debug crash_function: run exception_type: ipapython.ipautil.CalledProcessError executable: /usr/sbin/ipa-client-automount interpreter: platform-python-3.6.8-39.el8_4.x86_64 kernel: 4.18.0-305.25.1.el8_4.x86_64 pkg_fingerprint: 51D6 647E C21A D6EA pkg_vendor: AlmaLinux runlevel: N 3 type: Python3 uid: 0 |
||||
Attached Files: |
backtrace (7,408 bytes) 2022-05-24 11:35 https://bugs.almalinux.org/file_download.php?file_id=133&type=bug cgroup (298 bytes) 2022-05-24 11:35 https://bugs.almalinux.org/file_download.php?file_id=134&type=bug cpuinfo (1,352 bytes) 2022-05-24 11:35 https://bugs.almalinux.org/file_download.php?file_id=135&type=bug environ (5,126 bytes) 2022-05-24 11:35 https://bugs.almalinux.org/file_download.php?file_id=136&type=bug mountinfo (5,382 bytes) 2022-05-24 11:35 https://bugs.almalinux.org/file_download.php?file_id=137&type=bug namespaces (129 bytes) 2022-05-24 11:35 https://bugs.almalinux.org/file_download.php?file_id=138&type=bug open_fds (320 bytes) 2022-05-24 11:35 https://bugs.almalinux.org/file_download.php?file_id=139&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
238 | [AlmaLinux-8] -OTHER | text | always | 2022-05-17 15:33 | 2022-05-24 06:06 |
Reporter: | akqroldhaber | Platform: | x68_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.6 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | RH Satellite 6 - Sync AlmaLinux 8 Appstream Repo "https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/" fails | ||||
Description: |
RH Satellite 6 - Sync AlmaLinux 8 Appstream Repo "https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/" fails with "PLP0000: Importer indicated a failed response". Sync Upstream https://repo.almalinux.org/almalinux/8.6/AppStream/ fails with "RPM1004: Error retrieving metadata: Not Found" |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000568)
Hitamashi 2022-05-20 07:57 |
Similar issue found on katello Current version: pulp-server-2.21.5-1.el7.noarch katello-3.18.4-1.el7.noarch foreman-2.3.5-1.el7.noarch --- Output katello task: {"pulp_tasks"=> [{"exception"=>nil, "task_type"=>"pulp.server.managers.repo.sync.sync", "_href"=>"/pulp/api/v2/tasks/de72077f-561c-4ff8-b6cf-ad47b90d6c34/", "task_id"=>"de72077f-561c-4ff8-b6cf-ad47b90d6c34", "tags"=> ["pulp:repository:f2ba1795-07bc-432d-9d87-95c9e5333310", "pulp:action:sync"], "finish_time"=>"2022-05-19T23:22:42Z", "_ns"=>"task_status", "start_time"=>"2022-05-19T23:21:08Z", "traceback"=> "Traceback (most recent call last):\n" + " File \"/usr/lib/python2.7/site-packages/celery/app/trace.py\", line 367, in trace_task\n" + " R = retval = fun(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py\", line 688, in __call__\n" + " return super(Task, self).__call__(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py\", line 110, in __call__\n" + " return super(PulpTask, self).__call__(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/celery/app/trace.py\", line 622, in __protected_call__\n" + " return self.run(*args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py\", line 860, in sync\n" + " raise pulp_exceptions.PulpExecutionException(_('Importer indicated a failed response'))\n" + "PulpExecutionException: Importer indicated a failed response\n", "spawned_tasks"=>[], "progress_report"=> {"yum_importer"=> {"content"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "details"=> {"rpm_total"=>0, "rpm_done"=>0, "drpm_total"=>0, "drpm_done"=>0}, "size_total"=>0, "size_left"=>0, "items_left"=>0}, "comps"=>{"state"=>"NOT_STARTED"}, "purge_duplicates"=>{"state"=>"NOT_STARTED"}, "distribution"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "items_left"=>0}, "modules"=>{"state"=>"FINISHED"}, "errata"=>{"state"=>"FAILED", "error"=>"'arch'"}, "metadata"=>{"state"=>"FINISHED"}}}, "queue"=>"reserved_resource_worker-0@katello.ipa.pay-nxt.com.dq2", "state"=>"error", "worker_name"=>"reserved_resource_worker-0@katello.ipa.pay-nxt.com", "result"=>nil, "error"=> {"code"=>"PLP0000", "data"=>{}, "description"=>"Importer indicated a failed response", "sub_errors"=>[]}, "_id"=>{"$oid"=>"6286cc4234e7113fe908e1d0"}, "id"=>"6286cc4234e7113fe908e1d0"}], "contents_changed"=>true, "poll_attempts"=>{"total"=>100, "failed"=>1}} --- --- Log generated by pulp when katello task failed: 2022-05-20T04:24:55.689073+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:INFO: [fb39f8d5] Generating metadata databases. 2022-05-20T04:25:01.582925+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:INFO: [fb39f8d5] Determining which units need to be downloaded. 2022-05-20T04:25:21.044596+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:INFO: [fb39f8d5] Downloading 0 RPMs. 2022-05-20T04:25:25.041468+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.repomd.alternate:INFO: [fb39f8d5] The content container reported: {'downloads': {}, 'total_sou rces': 0} for base URL: https://repo.almalinux.org/almalinux/8/PowerTools/x86_64/os/ 2022-05-20T04:25:25.044808+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:INFO: [fb39f8d5] Downloading additional units. 2022-05-20T04:25:25.170243+00:00 myserver pulp: py.warnings:WARNING: (2485-60864) /usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:852: InsecureR equestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 2022-05-20T04:25:25.170424+00:00 myserver pulp: py.warnings:WARNING: (2485-60864) InsecureRequestWarning) 2022-05-20T04:25:25.170606+00:00 myserver pulp: py.warnings:WARNING: (2485-60864) 2022-05-20T04:25:25.201472+00:00 myserver pulp: nectar.downloaders.threaded:INFO: Download succeeded: https://repo.almalinux.org/almalinux/8/PowerTools/x86_64/os/.treeinfo. 2022-05-20T04:25:26.194570+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.parse.treeinfo:INFO: [fb39f8d5] upstream distribution unchanged and force_full not set; skippi ng 2022-05-20T04:25:26.921826+00:00 myserver pulp: kombu.transport.qpid:INFO: Connected to qpid with SASL mechanism ANONYMOUS 2022-05-20T04:25:27.253469+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) 'arch' 2022-05-20T04:25:27.253675+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) Traceback (most recent call last): 2022-05-20T04:25:27.253870+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/ importers/yum/sync.py", line 316, in run 2022-05-20T04:25:27.254092+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) self.get_errata(metadata_files) 2022-05-20T04:25:27.254231+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/ importers/yum/sync.py", line 924, in get_errata 2022-05-20T04:25:27.254346+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) updateinfo.process_package_element, additive_type=True ) 2022-05-20T04:25:27.254459+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/ importers/yum/sync.py", line 1006, in save_fileless_units 2022-05-20T04:25:27.254585+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) for model in package_info_generator: 2022-05-20T04:25:27.254752+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/ importers/yum/repomd/packages.py", line 64, in package_list_generator 2022-05-20T04:25:27.254900+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) package_info = process_func(element) 2022-05-20T04:25:27.255022+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/ importers/yum/repomd/updateinfo.py", line 33, in process_package_element 2022-05-20T04:25:27.255196+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) pkglists = map(_parse_pkglist, element.findall('pkglis t') or []) 2022-05-20T04:25:27.255321+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/ importers/yum/repomd/updateinfo.py", line 102, in _parse_pkglist 2022-05-20T04:25:27.255460+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) return map(_parse_collection, element.findall('collect ion') or []) 2022-05-20T04:25:27.255631+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/ importers/yum/repomd/updateinfo.py", line 116, in _parse_collection 2022-05-20T04:25:27.255780+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) ret['module'] = _parse_module(module_elements[0]) 2022-05-20T04:25:27.255947+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/ importers/yum/repomd/updateinfo.py", line 175, in _parse_module 2022-05-20T04:25:27.256096+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) 'arch': element.attrib['arch'], 2022-05-20T04:25:27.256212+00:00 myserver pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [fb39f8d5] (2485-05792) KeyError: 'arch' 2022-05-20T04:25:27.354490+00:00 myserver pulp: pulp.server.event.http:INFO: [fb39f8d5] (2485-05792) {"call_report": {"exception": null, "task_type": "pulp.server.managers.r epo.sync.sync", "_href": "/pulp/api/v2/tasks/fb39f8d5-e4c4-45b1-aa75-b9bc177f2940/", "task_id": "fb39f8d5-e4c4-45b1-aa75-b9bc177f2940", "tags": ["pulp:repository:f2ba1795-07bc-432d-9d87-95c9e5333310", "pulp:action:sync"], "finish_time": null, "_ns": "task_status", "start_time": "2022-05-20T04:24:49Z", "traceback": null, "spawned_tasks": [], "progress_report": {"yum_importer": {"content": {"items_total": 0, "state": "FINISHED", "error_details": [], "details": {"rpm_total": 0, "rpm_done": 0, "drpm_total": 0, "drpm_done": 0}, "size_total": 0, "size_left": 0, "items_left": 0}, "comps": {"state": "NOT_STARTED"}, "purge_duplicates": {"state": "NOT_STARTED"}, "distribution": {"items_total": 0, "state": "FINISHED", "error_details": [], "items_left": 0}, "modules": {"state": "FINISHED"}, "errata": {"state": "FAILED", "error": "'arch'"}, "metadata": {"state": "FINISHED"}}}, "state": "running", "worker_name": "reserved_resource_worker-2@myserver", "result": null, "error": null, "_id": {"$oid": "6287181134e7113fe92e92f6"}, "id": "6287181134e7113fe92e92f6"}, "event_type": "repo.sync.finish", "payload": {"importer_id": "yum_importer", "exception": null, "repo_id": "f2ba1795-07bc-432d-9d87-95c9e5333310", "traceback": null, "started": "2022-05-20T04:24:49Z", "_ns": "repo_sync_results", "completed": "2022-05-20T04:25:27Z", "importer_type_id": "yum_importer", "error_message": null, "summary": {"modules": {"state": "FINISHED"}, "content": {"state": "FINISHED"}, "comps": {"state": "NOT_STARTED"}, "purge_duplicates": {"state": "NOT_STARTED"}, "distribution": {"state": "FINISHED"}, "errata": {"state": "FAILED"}, "metadata": {"state": "FINISHED"}}, "added_count": 0, "result": "failed", "updated_count": 52, "details": {"modules": {"state": "FINISHED"}, "content": {"size_total": 0, "items_left": 0, "items_total": 0, "state": "FINISHED", "size_left": 0, "details": {"rpm_total": 0, "rpm_do 2022-05-20T04:25:27.356141+00:00 myserver pulp: pulp.server.event.http:INFO: [fb39f8d5] (2485-05792) ne": 0, "drpm_total": 0, "drpm_done": 0}, "error_details": []}, "comps": {"state": "NOT_STARTED"}, "purge_duplicates": {"state": "NOT_STARTED"}, "distribution": {"items_total": 0, "state": "FINISHED", "error_details": [], "items_left": 0}, "errata": {"state": "FAILED", "error": "'arch'"}, "metadata": {"state": "FINISHED"}}, "id": "62871837320fa809b570ad68", "removed_count": 0}} 2022-05-20T04:25:27.386817+00:00 myserver pulp: pulp.server.event.http:ERROR: [fb39f8d5] Received HTTP 404 from HTTP notifier to https://myserver/katello/api/v2/repositories/sync_complete?token=mqtAbrNHxFMeUiqXLNk9SB3zWbV3vRQg. 2022-05-20T04:25:27.397559+00:00 myserver pulp: pulp.server.async.tasks:INFO: [fb39f8d5] Task failed : [fb39f8d5-e4c4-45b1-aa75-b9bc177f2940] --- |
(0000573)
alukoshko 2022-05-23 22:36 |
Hi. There was issue in updateinfo.xml metadata that prevented AppStream to be synced. Could you try again? |
(0000578)
akqroldhaber 2022-05-24 06:06 |
Hello alukoshko, the problem is fixed, syncing AlmaLinux 8 Appstream Repo works now without any issues. Thanks for fixing the promlem. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
213 | [AlmaLinux-8] abrt | major | always | 2022-04-10 11:19 | 2022-05-24 00:21 |
Reporter: | brianjmurrell | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | urgent | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | No workflow suitable for this problem was found! | ||||
Description: |
# abrt-cli report 3bac1664261a7e5ea668703a412dcc0afdc34ff9 No workflow suitable for this problem was found! # rpm -q abrt abrt-2.10.9-21.el8.alma.x86_64 |
||||
Tags: | |||||
Steps To Reproduce: | See above | ||||
Additional Information: | Set to major/urgent as this impedes the ability to send any useful crash reports. | ||||
Attached Files: | |||||
Notes | |
(0000536)
brianjmurrell 2022-04-10 12:07 |
I guess technically the problem is in libreport: https://github.com/abrt/libreport/blob/865db9ecd8f85e4ac50c87c63ee2062546ec74e8/src/cli/cli-report.c#L811-L819 And indeed, https://git.almalinux.org/rpms/libreport/src/commit/a3b5337005f0f2e7d8a1ac29471b2303e3808469/SPECS/libreport.spec indicates there is supposed to be a libreport-almalinux package with the workflows defined, but there does not appear to be any such package available: # dnf search libreport Last metadata expiration check: 4:52:40 ago on Sun 10 Apr 2022 02:56:15 AM EDT. ========================================================================= Name Exactly Matched: libreport ========================================================================== libreport.x86_64 : Generic library for reporting various problems libreport.i686 : Generic library for reporting various problems ======================================================================== Name & Summary Matched: libreport ========================================================================= libreport-cli.x86_64 : libreport's command line interface libreport-filesystem.x86_64 : Filesystem layout for libreport libreport-gtk.i686 : GTK front-end for libreport libreport-gtk.x86_64 : GTK front-end for libreport libreport-newt.x86_64 : libreport's newt interface libreport-plugin-bugzilla.x86_64 : libreport's bugzilla plugin libreport-plugin-kerneloops.x86_64 : libreport's kerneloops reporter plugin libreport-plugin-logger.x86_64 : libreport's logger reporter plugin libreport-plugin-mailx.x86_64 : libreport's mailx reporter plugin libreport-plugin-reportuploader.x86_64 : libreport's reportuploader plugin libreport-plugin-ureport.x86_64 : libreport's micro report plugin libreport-web.x86_64 : Library providing network API for libreport libreport-web.i686 : Library providing network API for libreport ============================================================================= Name Matched: libreport ============================================================================== libreport-anaconda.x86_64 : Default configuration for reporting anaconda bugs python3-libreport.x86_64 : Python 3 bindings for report-libs |
(0000576)
alukoshko 2022-05-24 00:21 |
Thanks for report. libreport-almalinux is now available in AppStream repo. |
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
224 | [AlmaLinux-8] almalinux-release | major | always | 2022-04-29 19:19 | 2022-05-20 13:12 |
Reporter: | agompel | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Alma Linux 9.0 Beta does not recognize ISO on a Ventoy USB Drive | ||||
Description: |
Alma Linux 9.0 Beta does not recognize ISO on a Ventoy USB Drive. The cause is obvious: a Ventoy (multiboot) uses the exfat format, and the fuse package (or driver( is missing in this BETA. So I could install from the network, but not from the ISO file on the USB. |
||||
Tags: | ISO, VENTOY | ||||
Steps To Reproduce: | Just tried to select the USB drive for install, and got an unrecoverable error. | ||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
240 | [AlmaLinux-8] almalinux-release | block | always | 2022-05-20 13:04 | 2022-05-20 13:04 |
Reporter: | agompel | Platform: | ALMA LINUX 9 Beta | ||
Assigned To: | OS: | LINUX | |||
Priority: | high | OS Version: | 9 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Procedure "WordPress with Nginx, PHP 8.1, and MariaDB " on Web Site, does not work, is inadequate ! | ||||
Description: |
On https://wiki.almalinux.org/Howto.html, Procedure "WordPress with Nginx, PHP 8.1, and MariaDB " is just completely inadequate with ALMA LINUX 9.0 1) it uses yum, when dnf has been in use for a long time now. 2) it just does work... it seems to be made for older versions, where config files are not in the same place 3) There is just no procedure to debug it, when it does not work. ---- Note: NGNIX, dnf installed works "out of the box" there no need for more ! The issues are in getting dnf installed Wordpress to work. ---- My opinion is that the best would be to have separate dnf modules and/or groupInstall for Wordpress for LAMP/Apache and Wordpress for LEMP/NGINX Ideally the same should be applied for popular applications like Mediawiki, and Drupal, and more .... My expertise not being there I can only offer to test/validate these, if/when they come. ---- Thanks for the attention. Andre Gompel |
||||
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: |
237 | [AlmaLinux-8] dnf | minor | always | 2022-05-17 14:31 | 2022-05-17 14:31 |
Reporter: | jacp10 | Platform: | VMWare ESX | ||
Assigned To: | OS: | Alma Linux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | dnf updateinfo list --security --all is not listing an advisory I know is in the repository | ||||
Description: |
Security advisory ALSA-2022-0891 exists as evidenced by https://errata.almalinux.org/8/ALSA-2022-0891.html The command 'dnf updateinfo list --security --all' does not display this in the list, on my system. Some example output (with positive control) dnf updateinfo list --security --all | grep 'httpd' ALSA-2022:1915 Moderate/Sec. httpd-2.4.37-47.module_el8.6.0+2872+fe0ff7aa.1.alma.x86_64 ALSA-2022:1915 Moderate/Sec. httpd-filesystem-2.4.37-47.module_el8.6.0+2872+fe0ff7aa.1.alma.noarch ALSA-2022:1915 Moderate/Sec. httpd-tools-2.4.37-47.module_el8.6.0+2872+fe0ff7aa.1.alma.x86_64 i.e you can see httpd is installed because a later security update for it is listed, but the 2022:0891 is not. |
||||
Tags: | |||||
Steps To Reproduce: | I can reproduce this in the sense of it happens every time I run the command. I have run yum clean all then retried with the same result. I can see reference to ALSA-2022:0891 inside /var/cache/dnf/. | ||||
Additional Information: | I find the documentation on dnf a little unclear, so it is possible I have overlooked something, but I think the '--all' switch means all updates should be listed regardless of age/installation status. 2022:0891 I believe to be actually installed on this system. | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
235 | [AlmaLinux-8] -OTHER | feature | always | 2022-05-14 05:41 | 2022-05-17 13:31 |
Reporter: | pel | Platform: | x86_64 | ||
Assigned To: | OS: | Sky Tiger | |||
Priority: | high | OS Version: | 8.6 beta | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | no login possible | ||||
Description: | I'm a simple user. After update from "Software" to 8.6 beta (why I get this offered?) I'm no longer to login (no login window, I've to reset and reboot with the former version). I don't know the reason. | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000566)
pmdumuid 2022-05-17 13:21 |
I think this is the same problem I am facing. I recently updated my Almalinux from 8.5 to 8.6, and when using the latest kernel (initramfs-4.18.0-372.9.1.el8.x86_64.img) sddm hangs when starting, however when selecting an older kernel at the grub menu (e.g. 4.18.0-348.23.1.el8_5.x86_64) it works again. A notable difference when running each kernel is that the out of `journalctl -b -u sddm.service` using the failing kernel just shows: ``` May 17 20:25:50 linux-disp.kydlocal systemd[1]: Started Simple Desktop Display Manager. ``` however using an older kernel I get more: ``` May 17 20:25:50 linux-disp.kydlocal systemd[1]: Started Simple Desktop Display Manager. May 17 20:25:58 linux-disp.kydlocal sddm[1933]: Could not setup default cursor May 17 20:25:59 linux-disp.kydlocal sddm-helper[4193]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0) May 17 20:26:32 linux-disp.kydlocal sddm-helper[11443]: pam_unix(sddm:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=xxxx ``` |
(0000567)
pmdumuid 2022-05-17 13:31 |
Possibly relates to https://bugs.almalinux.org/view.php?id=236 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
194 | [AlmaLinux-8] -OTHER | minor | always | 2022-03-03 17:32 | 2022-05-17 08:49 |
Reporter: | rw | Platform: | AWS | ||
Assigned To: | elkhan | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.5.20211116 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | 8.4 | ||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Marketplace image does not support 6th-generation instance types | ||||
Description: | When trying to launch the us-east-1 x86_64 marketplace AMI (ami-003d8719443bc8563) on an m6a instance, I get an error that it is not supported. Launching the community AMI from the Wiki (ami-0b4dad3b4322e5151) is fine. Is it possible to enable the marketplace AMIs to support those latest generation types? | ||||
Tags: | aws, cloud | ||||
Steps To Reproduce: |
Try to launch an m6a.large instance in us-east-1 using the marketplace AMI. Example sanitized command: aws ec2 run-instances \ --region us-east-1 \ --instance-type m6a.large \ --image-id ami-003d8719443bc8563 \ --subnet-id subnet-<VPC subnet ID> \ --security-group-ids sg-<VPC security group ID> \ --key-name <SSH key name> The same command succeeds using the community AMI ami-0b4dad3b4322e5151 |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000565)
elkhan 2022-05-17 08:47 |
Hey rw, We've updated the supported instance type for both architectures. (x86_64 and AArch64) This update includes 3rd Generation Intel(M6i, C6i, R6i) and AMD ( M6a, C6a) instance types too. Thanks for the reporting! |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
209 | [AlmaLinux-8] -OTHER | minor | always | 2022-04-04 05:15 | 2022-05-11 03:49 |
Reporter: | trex-thedog | Platform: | |||
Assigned To: | OS: | ||||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | PXE Installer for 8.5 stuck at multipath | ||||
Description: |
PXE Installer for Almalinux that can install to either local hard drive or iscsi lun. On 8.4 it works ok but not on 8.5. On 8.5 the bootup process gets stuck at "Started cancel waiting for multipath siblings of sda". |
||||
Tags: | installation, installer, pxe | ||||
Steps To Reproduce: | 1. With PXE infra already setup, boot up the vmlinuz and initrd from the images/pxeboot location. | ||||
Additional Information: | I was able to resolve it (I think) by editing the initrd.img and removing the prefixdevname-tools from it. Once I repacked it, the pxe installer seems to work ok. | ||||
Attached Files: |
IMG-1304.jpg (648,917 bytes) 2022-04-04 05:15 https://bugs.almalinux.org/file_download.php?file_id=127&type=bug |
||||
Notes | |
(0000531)
alukoshko 2022-04-04 10:16 |
Hello. Have you seen curl errors and No free space left on device error? Could you try the same with CentOS 8.5 images? |
(0000532)
trex-thedog 2022-04-04 19:43 |
Forgot to mention, yes I'm seeing curl and 'No free space left on device' errors. I've just tried the latest Centos8 Stream and it is affected with this same issue. I did not bother doing an initrd.img surgery this time. I'm pretty sure it will work if I did that. |
(0000555)
patl 2022-05-02 23:30 |
I get this error when I copy the installation files to a USB stick (GPT formatted, bootable FAT32 partition) and boot it in UEFI mode. I have no iSCSI; just regular sSATA disks. No multipath. Nevertheless the Kickstart bootup hangs with "started cancel waiting for mutipath siblings" on each of the sSATA disks. Would love to know how to bypass this. |
(0000556)
patl 2022-05-03 01:18 |
Addendum: My volume label was 10 characters including a dash and some lower case letters. When I make it 8 upper-case letters, the installation still prints these messages (and stalls for a bit) but ultimately works. Not sure whether the length or the character set is making the difference. Also I have no theory to explain any of this. Perhaps someone with more knowledge/patience than I can figure it out. |
(0000561)
trex-thedog 2022-05-11 02:32 |
^ That's (GPT + FAT32) quite an uncommon setup you have there. Afaik, fat32 truncates filenames to 8.3 (8 chars for filenames + 3 for extension). Perhaps that is what's happening in your case? I was wondering how your usb stick ended up with fat32 with gpt partitioning scheme? Is that a multi-distro usb? |
(0000562)
patl 2022-05-11 03:49 |
GPT + FAT32 = UEFI boot partition. I am pretty much following the procedure at https://askubuntu.com/a/395880/. It is working for me now. I had to restrict the volume label and be very explicit in the kernel command line (e.g. "linuxefi /isolinux/vmlinuz inst.repo=cdrom:LABEL=MYMEDIA inst.ks=cdrom:LABEL=MYMEDIA:/path/to/ks.cfg"). I am using "cdrom:" because this grub.cfg is shared with my .iso installation media. It works even though this is a USB stick. If I try to let Anaconda hunt for the repo, it locks up the install with "Started cancel waiting for multipath siblings of sda". |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
232 | [AlmaLinux-8] anaconda | minor | always | 2022-05-05 10:23 | 2022-05-05 20:53 |
Reporter: | robbevl | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Anaconda can't mount XFS during kickstart installation | ||||
Description: |
We have a kickstart file that works great with RHEL8 but fails while trying to use with AL8. The installation starts but then Anaconda throws an error after formatting the xfs filesystems, apparently the mount program doesn't know xfs: DEBUG:blivet: XFS.setup: device: /dev/mapper/almalinux -root ; type: xfs ; status: False INFO:program:Running... mount -t xfs -o defaults /dev/mapper/almalinux-root /mnt/sysimage INFO:program:stderr: INFO:program:b"mount: /mnt/sysimage: unknown filesystem type 'xfs'." DEBUG:program:Return code: 32 INFO:anaconda.threading:Thread Failed: AnaTaskThread-MountFilesystemsTask -1 (139983618381568) Relevant lines in ks.cfs: zerombr ignoredisk --only-use=sda clearpart --drives=sda --initlabel --disklabel=gpt bootloader --append="crashkernel=auto" --location=mbr --boot-drive=sda part /boot --fstype="xfs" --ondisk=sda --size=1024 part /boot/efi --fstype="efi" --ondisk=sda --size=600 --fsoptions="umask=0077,shortname=winnt" part pv.1 --fstype="lvmpv" --ondisk=sda --size=5120 --grow volgroup almalinux pv.1 logvol swap --fstype="swap" --recommended --name=swap --vgname=almalinux logvol / --fstype="xfs" --size=8192 --name=root --vgname=almalinux logvol /var --fstype="xfs" --percent=100 --name=var --vgname=almalinux We're using the almalinux-8.5-x86_64-dvd.iso hosted on an NFS share as repo: nfs --server=my-nfs-server.example.com --dir=/kickstart/iso/almalinux-8.5-x86_64-dvd.iso We're booting from the dvd itself. We have a small iso that is bootable and has this line in grub,cfg: linuxefi /isolinux/vmlinuz inst.stage2=nfs:my-nfs-server.example.com:/kickstart/iso/almalinux-8.5-x86_64-dvd.iso inst.ks=nfs:my-nfs-server.example.com:/kickstart/ks/ks.cfg This is working with the rhel8.5 dvd so I was surprised to see this error. XFS is supposed to be the default fs, are the xfs drivers not loaded when booting from DVD? |
||||
Tags: | anaconda, installation, kickstart, not-a-bug, xfs | ||||
Steps To Reproduce: | Attempt kickstart installation while booting from almalinux-8.5-x86_64-dvd.iso and with almalinux-8.5-x86_64-dvd.iso as repo. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000558)
robbevl 2022-05-05 20:52 |
Found the problem. It's not a bug, please close. Anaconda was unable to load the xfs module (Required key not available). This is caused by EFI secure boot (which needs modules to be signed), or rather, because I used my modified rhel8 iso as stage 1 boot device and attempted to point it at the Almalinux dvd for stage 2. Apparently the difference was noticed, and as a result some modules (like xfs) did not load. I created a modified Almalinux 8.5 bootable iso to load the ks and all works as expected now. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
231 | [AlmaLinux-8] -OTHER | minor | always | 2022-05-05 09:54 | 2022-05-05 09:54 |
Reporter: | ronan | Platform: | AlmaLinux | ||
Assigned To: | OS: | Linux | |||
Priority: | normal | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Binaries RPM do not have RPM source available. | ||||
Description: |
In AlmaLinux some binaries packages do not have valid source in any RPM source repositories. ant-1.10.5-1.module_el8.0.0+6031+d80e135e.noarch . The src rpm wanted is ant-1.10.5-1.module_el8.0.0+6031+d80e135e.src.rpm aopalliance-1.0-17.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is aopalliance-1.0-17.module_el8.0.0+6035+97aff910.src.rpm apache-commons-cli-1.4-4.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is apache-commons-cli-1.4-4.module_el8.0.0+6035+97aff910.src.rpm apache-commons-codec-1.11-3.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is apache-commons-codec-1.11-3.module_el8.0.0+6035+97aff910.src.rpm apache-commons-io-1:2.6-3.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is apache-commons-io-2.6-3.module_el8.0.0+6035+97aff910.src.rpm apache-commons-lang3-3.7-3.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is apache-commons-lang3-3.7-3.module_el8.0.0+6035+97aff910.src.rpm apache-commons-logging-1.2-13.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is apache-commons-logging-1.2-13.module_el8.0.0+6035+97aff910.src.rpm aspnetcore-runtime-3.1-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm aspnetcore-targeting-pack-3.1-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm atinject-1-28.20100611svn86.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is atinject-1-28.20100611svn86.module_el8.0.0+6035+97aff910.src.rpm cdi-api-1.2-8.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is cdi-api-1.2-8.module_el8.0.0+6035+97aff910.src.rpm dotnet-apphost-pack-3.1-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-hostfxr-3.1-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-runtime-3.1-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-sdk-3.1-3.1.120-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-targeting-pack-3.1-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-templates-3.1-3.1.120-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm geronimo-annotation-1.0-23.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is geronimo-annotation-1.0-23.module_el8.0.0+6035+97aff910.src.rpm glassfish-el-api-3.0.1-0.7.b08.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is glassfish-el-3.0.1-0.7.b08.module_el8.0.0+6035+97aff910.src.rpm google-guice-4.1-11.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is google-guice-4.1-11.module_el8.0.0+6035+97aff910.src.rpm guava20-20.0-8.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is guava20-20.0-8.module_el8.0.0+6035+97aff910.src.rpm hawtjni-runtime-1.16-1.module_el8.0.0+6044+f3cbc35d.noarch . The src rpm wanted is hawtjni-1.16-1.module_el8.0.0+6044+f3cbc35d.src.rpm hawtjni-runtime-1.16-2.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is hawtjni-1.16-2.module_el8.0.0+6035+97aff910.src.rpm httpcomponents-client-4.5.5-4.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is httpcomponents-client-4.5.5-4.module_el8.0.0+6035+97aff910.src.rpm httpcomponents-core-4.4.10-3.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is httpcomponents-core-4.4.10-3.module_el8.0.0+6035+97aff910.src.rpm jansi-1.17.1-1.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is jansi-1.17.1-1.module_el8.0.0+6035+97aff910.src.rpm jansi-1.17.1-1.module_el8.0.0+6044+f3cbc35d.noarch . The src rpm wanted is jansi-1.17.1-1.module_el8.0.0+6044+f3cbc35d.src.rpm jansi-native-1.7-5.module_el8.0.0+6044+f3cbc35d.x86_64 . The src rpm wanted is jansi-native-1.7-5.module_el8.0.0+6044+f3cbc35d.src.rpm jansi-native-1.7-7.module_el8.0.0+6035+97aff910.x86_64 . The src rpm wanted is jansi-native-1.7-7.module_el8.0.0+6035+97aff910.src.rpm javapackages-filesystem-5.3.0-2.module_el8.0.0+6004+2fc32706.noarch . The src rpm wanted is javapackages-tools-5.3.0-2.module_el8.0.0+6004+2fc32706.src.rpm jboss-interceptors-1.2-api-1.0.0-8.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is jboss-interceptors-1.2-api-1.0.0-8.module_el8.0.0+6035+97aff910.src.rpm jcl-over-slf4j-1.7.25-4.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is slf4j-1.7.25-4.module_el8.0.0+6035+97aff910.src.rpm jline-2.14.6-2.module_el8.0.0+6044+f3cbc35d.noarch . The src rpm wanted is jline-2.14.6-2.module_el8.0.0+6044+f3cbc35d.src.rpm jsoup-1.11.3-3.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is jsoup-1.11.3-3.module_el8.0.0+6035+97aff910.src.rpm maven-1:3.5.4-5.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-3.5.4-5.module_el8.0.0+6035+97aff910.src.rpm maven-lib-1:3.5.4-5.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-3.5.4-5.module_el8.0.0+6035+97aff910.src.rpm maven-resolver-api-1:1.1.1-2.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-resolver-1.1.1-2.module_el8.0.0+6035+97aff910.src.rpm maven-resolver-connector-basic-1:1.1.1-2.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-resolver-1.1.1-2.module_el8.0.0+6035+97aff910.src.rpm maven-resolver-impl-1:1.1.1-2.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-resolver-1.1.1-2.module_el8.0.0+6035+97aff910.src.rpm maven-resolver-spi-1:1.1.1-2.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-resolver-1.1.1-2.module_el8.0.0+6035+97aff910.src.rpm maven-resolver-transport-wagon-1:1.1.1-2.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-resolver-1.1.1-2.module_el8.0.0+6035+97aff910.src.rpm maven-resolver-util-1:1.1.1-2.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-resolver-1.1.1-2.module_el8.0.0+6035+97aff910.src.rpm maven-shared-utils-3.2.1-0.1.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-shared-utils-3.2.1-0.1.module_el8.0.0+6035+97aff910.src.rpm maven-wagon-file-3.1.0-1.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-wagon-3.1.0-1.module_el8.0.0+6035+97aff910.src.rpm maven-wagon-http-3.1.0-1.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-wagon-3.1.0-1.module_el8.0.0+6035+97aff910.src.rpm maven-wagon-http-shared-3.1.0-1.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-wagon-3.1.0-1.module_el8.0.0+6035+97aff910.src.rpm maven-wagon-provider-api-3.1.0-1.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is maven-wagon-3.1.0-1.module_el8.0.0+6035+97aff910.src.rpm plexus-cipher-1.7-14.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is plexus-cipher-1.7-14.module_el8.0.0+6035+97aff910.src.rpm plexus-classworlds-2.5.2-9.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is plexus-classworlds-2.5.2-9.module_el8.0.0+6035+97aff910.src.rpm plexus-containers-component-annotations-1.7.1-8.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is plexus-containers-1.7.1-8.module_el8.0.0+6035+97aff910.src.rpm plexus-interpolation-1.22-9.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is plexus-interpolation-1.22-9.module_el8.0.0+6035+97aff910.src.rpm plexus-sec-dispatcher-1.4-26.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is plexus-sec-dispatcher-1.4-26.module_el8.0.0+6035+97aff910.src.rpm plexus-utils-3.1.0-3.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is plexus-utils-3.1.0-3.module_el8.0.0+6035+97aff910.src.rpm scala-2.10.6-14.module_el8.0.0+6044+f3cbc35d.noarch . The src rpm wanted is scala-2.10.6-14.module_el8.0.0+6044+f3cbc35d.src.rpm sisu-inject-1:0.3.3-6.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is sisu-0.3.3-6.module_el8.0.0+6035+97aff910.src.rpm sisu-plexus-1:0.3.3-6.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is sisu-0.3.3-6.module_el8.0.0+6035+97aff910.src.rpm slf4j-1.7.25-4.module_el8.0.0+6035+97aff910.noarch . The src rpm wanted is slf4j-1.7.25-4.module_el8.0.0+6035+97aff910.src.rpm centos-release-advanced-virtualization-1.0-2.el8.noarch . The src rpm wanted is centos-release-advanced-virtualization-1.0-2.el8.src.rpm centos-release-ansible-29-1-2.el8.noarch . The src rpm wanted is centos-release-ansible-29-1-2.el8.src.rpm centos-release-ceph-nautilus-1.2-2.el8.noarch . The src rpm wanted is centos-release-ceph-nautilus-1.2-2.el8.src.rpm centos-release-ceph-octopus-1.0-1.el8.noarch . The src rpm wanted is centos-release-ceph-octopus-1.0-1.el8.src.rpm centos-release-ceph-pacific-1.0-1.el8.noarch . The src rpm wanted is centos-release-ceph-pacific-1.0-1.el8.src.rpm centos-release-configmanagement-1-1.el8.noarch . The src rpm wanted is centos-release-configmanagement-1-1.el8.src.rpm centos-release-gluster6-1.0-1.el8.noarch . The src rpm wanted is centos-release-gluster6-1.0-1.el8.src.rpm centos-release-gluster7-1.0-2.el8.noarch . The src rpm wanted is centos-release-gluster7-1.0-2.el8.src.rpm centos-release-gluster8-1.0-1.el8.noarch . The src rpm wanted is centos-release-gluster8-1.0-1.el8.src.rpm centos-release-gluster9-1.0-1.el8.noarch . The src rpm wanted is centos-release-gluster9-1.0-1.el8.src.rpm centos-release-messaging-1-2.el8.noarch . The src rpm wanted is centos-release-messaging-1-2.el8.src.rpm centos-release-nfs-ganesha28-1.0-3.el8.noarch . The src rpm wanted is centos-release-nfs-ganesha28-1.0-3.el8.src.rpm centos-release-nfs-ganesha30-1.0-2.el8.noarch . The src rpm wanted is centos-release-nfs-ganesha30-1.0-2.el8.src.rpm centos-release-nfv-common-1-2.el8.noarch . The src rpm wanted is centos-release-nfv-1-2.el8.src.rpm centos-release-openstack-train-2-1.el8.noarch . The src rpm wanted is centos-release-openstack-train-2-1.el8.src.rpm centos-release-openstack-ussuri-1-4.el8.noarch . The src rpm wanted is centos-release-openstack-ussuri-1-4.el8.src.rpm centos-release-openstack-victoria-1-1.el8.noarch . The src rpm wanted is centos-release-openstack-victoria-1-1.el8.src.rpm centos-release-opstools-1-10.el8.noarch . The src rpm wanted is centos-release-opstools-1-10.el8.src.rpm centos-release-ovirt44-1.0-1.el8.noarch . The src rpm wanted is centos-release-ovirt44-1.0-1.el8.src.rpm centos-release-samba411-1.0-1.el8.noarch . The src rpm wanted is centos-release-samba411-1.0-1.el8.src.rpm centos-release-samba412-1.0-1.el8.noarch . The src rpm wanted is centos-release-samba412-1.0-1.el8.src.rpm centos-release-samba413-1.0-1.el8.noarch . The src rpm wanted is centos-release-samba413-1.0-1.el8.src.rpm centos-release-samba414-1.0-1.el8.noarch . The src rpm wanted is centos-release-samba414-1.0-1.el8.src.rpm centos-release-storage-common-2-2.el8.noarch . The src rpm wanted is centos-release-storage-common-2-2.el8.src.rpm centos-release-virt-common-1-2.el8.noarch . The src rpm wanted is centos-release-virt-common-1-2.el8.src.rpm dotnet-apphost-pack-3.1-debuginfo-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-hostfxr-3.1-debuginfo-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-runtime-3.1-debuginfo-3.1.20-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-sdk-3.1-debuginfo-3.1.120-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet3.1-debuginfo-3.1.120-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet3.1-debugsource-3.1.120-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm dotnet-sdk-3.1-source-built-artifacts-3.1.118-1.el8.x86_64 . The src rpm wanted is dotnet3.1-3.1.118-1.el8.src.rpm dotnet-sdk-3.1-source-built-artifacts-3.1.120-2.el8_5.x86_64 . The src rpm wanted is dotnet3.1-3.1.120-2.el8_5.src.rpm glassfish-jaxb-bom-2.2.11-11.module_el8.3.0+2058+6bf11631.noarch . The src rpm wanted is glassfish-jaxb-2.2.11-11.module_el8.3.0+2058+6bf11631.src.rpm glassfish-jaxb-bom-ext-2.2.11-11.module_el8.3.0+2058+6bf11631.noarch . The src rpm wanted is glassfish-jaxb-2.2.11-11.module_el8.3.0+2058+6bf11631.src.rpm glassfish-jaxb-codemodel-parent-2.2.11-11.module_el8.3.0+2058+6bf11631.noarch . The src rpm wanted is glassfish-jaxb-2.2.11-11.module_el8.3.0+2058+6bf11631.src.rpm glassfish-jaxb-external-parent-2.2.11-11.module_el8.3.0+2058+6bf11631.noarch . The src rpm wanted is glassfish-jaxb-2.2.11-11.module_el8.3.0+2058+6bf11631.src.rpm glassfish-jaxb-parent-2.2.11-11.module_el8.3.0+2058+6bf11631.noarch . The src rpm wanted is glassfish-jaxb-2.2.11-11.module_el8.3.0+2058+6bf11631.src.rpm glassfish-jaxb-runtime-parent-2.2.11-11.module_el8.3.0+2058+6bf11631.noarch . The src rpm wanted is glassfish-jaxb-2.2.11-11.module_el8.3.0+2058+6bf11631.src.rpm glassfish-jaxb-txw-parent-2.2.11-11.module_el8.3.0+2058+6bf11631.noarch . The src rpm wanted is glassfish-jaxb-2.2.11-11.module_el8.3.0+2058+6bf11631.src.rpm python3-sip-4.19.12-3.el8.i686 . The src rpm wanted is sip-4.19.12-3.el8.src.rpm python3-sip-debuginfo-4.19.12-3.el8.i686 . The src rpm wanted is sip-4.19.12-3.el8.src.rpm sip-debuginfo-4.19.12-3.el8.i686 . The src rpm wanted is sip-4.19.12-3.el8.src.rpm |
||||
Tags: | |||||
Steps To Reproduce: |
e.g.: apache-commons-cli sudo dnf search --enablerepo="*-source" apache-commons-cli ================================================================================================= Name Exactly Matched: apache-commons-cli ================================================================================================== apache-commons-cli.noarch : Command Line Interface Library for Java |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
229 | [AlmaLinux-8] -OTHER | minor | always | 2022-05-05 09:01 | 2022-05-05 09:01 |
Reporter: | ronan | Platform: | AlmaLinux | ||
Assigned To: | OS: | Linux | |||
Priority: | normal | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Can't find RPM source | ||||
Description: |
Some rpm src can't be find in AlmaLinux in the usual way. e.g.: aopalliance |
||||
Tags: | |||||
Steps To Reproduce: |
Let's take a working package: ansible-pcp #sudo dnf search -v --enablerepo="*-source" ansible-pcp ===================================================================================================== Name Exactly Matched: ansible-pcp ===================================================================================================== ansible-pcp.noarch : Ansible Metric collection for Performance Co-Pilot Repo : appstream Matched from: Provide : ansible-pcp = 2.2.1-1.el8 ansible-pcp.src : Ansible Metric collection for Performance Co-Pilot Repo : appstream-source Matched from: Other : ansible-pcp But with aopalliance #sudo dnf search -v --enablerepo="*-source" aopalliance ===================================================================================================== Name Exactly Matched: aopalliance ===================================================================================================== aopalliance.noarch : Java/J2EE AOP standards Repo : appstream Matched from: Provide : aopalliance = 1.0-17.module_el8.0.0+6035+97aff910 But if you query the specific repo you've got: #sudo dnf search -v --repo appstream-source aopalliance ==================================================================================================== Name Exactly Matched: aopalliance ===================================================================================================== aopalliance.src : Java/J2EE AOP standards Repo : appstream-source Matched from: Other : aopalliance Note: 1) The package is in source repository http://mirror.almalinux.ikoula.com/8/AppStream/Source/Packages/ 2) The primary.xml.gz is OK http://mirror.almalinux.ikoula.com/8/AppStream/Source/repodata/ 3) It's not comming from dnf (same result with dnf from fedora) 4) The same command work in fedora and centos |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
228 | [AlmaLinux-8] nginx | minor | always | 2022-05-05 04:13 | 2022-05-05 04:13 |
Reporter: | davidlai | Platform: | |||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | nginx config file has a typo | ||||
Description: |
Minor issue After installing nginx, there is a config file /etc/nginx/nginx.conf. At approx line 50 is: error_page 404 /404.html; location = /40x.html { } I believe this is a typo there, the /40x.html should be /404.html I think the correct lines should read: error_page 404 /404.html; location = /404.html { } I suspect this problem is introduced upstream of Alma, but downstream of Nginx. Possibly a typo introduced by Redhat? |
||||
Tags: | |||||
Steps To Reproduce: | Just install nginx | ||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
227 | [AlmaLinux-8] systemd | major | always | 2022-05-05 01:44 | 2022-05-05 01:45 |
Reporter: | m4 | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | System will not boot if raid goes into degraded mode while system is down, and "root" is not physically on those drives. | ||||
Description: |
If a raid1 (or other) that is not on the physical disks that 'root' is on, goes degraded while system is powered down -- and it is required for system to run (/etc/fstab listed), the system goes into dracut emergency mode, and "mdadm -R /dev/mdXYZ" needs to be run manually. If both the root disk(s) and a raid on a non-root physical disk goes degraded at the same time -- then "perhaps" both will go into degraded mode. See Additional information. |
||||
Tags: | |||||
Steps To Reproduce: |
System testing setup: 1) root raid1 on two SAS disks (sda/sdb ) and other raids on those too (home,var,etc.). 2) two other disks with a required (/etc/fstab) raid1 - say /media/private_date, lets say /dev/nvme0n1p1, and nvme1n1p1. Test cases to see if system runs with disks degraded: A) system running: a) unplug one SAS. cat /proc/mdstat, etc. Plug it back in. Fix if needed via mdadm. Repeat with other. b) unplug one NVMe. Etc. per "a)". B) Everything running nicely, powerdown: c) unplug one SAS. Power up, etc. d) everything is running nicely, then power down, unplug one NVMe. Power up, etc. With B)d) - the system will go into dracut emergency recovery mode - every time. Remember to have system running nicely before powerdown. :) |
||||
Additional Information: |
When root from initramfs layout is running and it is looking for the 'real root', the various raids are discovered, and systemd rules cause "mdadm -I /dev/ABCDWYXZ --export to be run" the first (and only FIRST) time that a software raid is created, which sets up a last-resort timer in case all members of the raid are not present -- while continuing to process udev devices to find disks/partitions. As soon as "root" is found and active (could be degraded when system went down, which is no different that having all disks present), the real root is setup for pivot root, systemd is taken down, the pivot root occurs, and at this time all the last-resort timers outstanding are lost. The real systemd starts and redoes the device discovery udev stuff -- but, any raid already known to the kernel already (root is important!), no last-resort timers are set. Any raid on the same physical devices as the root raid, "may" (most likely) will already have all it's devices found and last-resort timers will have gone off -- if one goes off for root. With the long time for a raid to become active -- most likely those raids are also active. Continuing thought process (ignoring side tracking paragraph above), when systemd is busy processing /etc/fstab for mounting file systems (asynchronously), everything is nice -- except for the mandatory raid that went into degraded mode while powered off. There is no last-resort timer to go off, and it will sit there inactive. I am attaching a work-around. Possible fixes: 1) clean out all md raids from kernel data structures (except root -- nested raids, etc. present complexity) when systemd goes down to restart up on the real root file system. 2) copy the last-resort timers into the real root structure before shutting systemd down -- and make sure they will still be run when the real systemd comes up. 3) Always have mdadm --export return the environment style variables -- not just when a /dev/mdXYZ is created for the first device found. 4) Eliminate the use of initramfs and taking systemd down and replaying the device discovery (udev) process. I don't know, all of this is convoluted ... and I expect other similar situations exist with all the messiness involved. |
||||
Attached Files: |
65-md-incremental.rules (3,840 bytes) 2022-05-05 01:44 https://bugs.almalinux.org/file_download.php?file_id=129&type=bug dracut.conf (207 bytes) 2022-05-05 01:44 https://bugs.almalinux.org/file_download.php?file_id=130&type=bug md-run-timer (728 bytes) 2022-05-05 01:44 https://bugs.almalinux.org/file_download.php?file_id=131&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
225 | [AlmaLinux-8] -OTHER | minor | always | 2022-04-29 23:45 | 2022-04-29 23:45 |
Reporter: | grandparoach | Platform: | Azure | ||
Assigned To: | OS: | almalinux-hpc | |||
Priority: | normal | OS Version: | 8_5-hpc-gen2 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | The Azure Marketplace image for the almalinux-hpc 8_5-gen2 is missing the NFS Utilities | ||||
Description: |
The Azure Marketplace image for almalinux-hpc 8_5-hpc-gen2 is missing the NFS Utilities. There are so many other things which are pre-installed on this image, it would be much more convenient if the NFS Utilities were pre-installed as well. |
||||
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: |
190 | [AlmaLinux-8] selinux-policy | major | always | 2022-02-22 15:04 | 2022-04-29 10:07 |
Reporter: | Blackclaws | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | k3s selinux not working on Almalinux | ||||
Description: |
The k3s selinux package does not work correctly on Almalinux in contrast to CentOS 8.5. By my understanding this should work out of the box as Almalinux is more or less a drop in replacement. Is this something the package has to address or is this something that Almalinux has to address? There is a related bug on github: https://github.com/k3s-io/k3s-selinux/issues/27 |
||||
Tags: | |||||
Steps To Reproduce: | See github bug. | ||||
Additional Information: | Works on CentOS 8.5 not tested on RHEL so far | ||||
Attached Files: | |||||
Notes | |
(0000496)
Blackclaws 2022-02-22 15:06 |
The reason why I classified this as major is because the update to Almalinux 8.5 broke my k3s cluster due to this issue. I had to deactivate SELinux in the meantime to resolve. As stated above it might not actually be Almalinux fault but I don't understand enough about how the policy systems might differ to correctly pin down the source of the problem. |
(0000523)
srbala 2022-03-26 10:48 |
@Blackclaws, GitHub issue indicates that this has been resolved on package update. Please verify. |
(0000550)
Blackclaws 2022-04-29 10:07 |
Unfortunately that doesn't seem to be the case. I still need to run with setenforce 0 in order to be able to run most containers. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
221 | [AlmaLinux-8] dnf | block | always | 2022-04-26 16:22 | 2022-04-29 08:57 |
Reporter: | thony62410 | Platform: | Google cloud plateform | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | high | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | TLS problem when i use DNF | ||||
Description: |
Hello, We encounter a problem during a fresh deployment of alma linux with openssl, I specify that we use the image provided on the Google marcketplace, it seems that there is a problem with the ciphers configured on openssl, i have this error when we try to update the server with dnf: [root@admny1ano01 ssl]# dnf update AlmaLinux 8 - BaseOS 0.0 B/s | 0 B 00:00 Errors during downloading metadata for repository 'baseos': - Curl error (35): SSL connect error for https://mirrors.almalinux.org/mirrorlist/8/baseos [OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to mirrors.almalinux.org:443 ] Error: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Curl error (35): SSL connect error for https://mirrors.almalinux.org/mirrorlist/8/baseos [OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to mirrors.almalinux.org:443 ] When i try to pass an connection with openssl, i have this error: SSL_connect:SSLv3/TLS write client hello read from 0x55ef7f703ea0 [0x55ef7f70e723] (5 bytes => -1 (0xFFFFFFFFFFFFFFFF)) SSL_connect:error in SSLv3/TLS write client hello write:errno=104 I have also the problem with an other site and curl command(i think that it's du to openssl) : [root@admny1ano01 ssl]# curl https://rpmfind.net/linux/RPM/centos/8-stream/appstream/x86_64/Packages/bind-utils-9.11.36-3.el8.x86_64.html --output bind-utils-9.11.36-3.el8.x86_64.rpm % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to rpmfind.net:443 Thanks a lot for your time. Regards |
||||
Tags: | cloud, gcp | ||||
Steps To Reproduce: | dnf update or curl command... | ||||
Additional Information: |
nss-3.67.0-7.el8_5.x86_64 [root@admny1ano01 ssl]# curl --version curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.6 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.2.0) libssh/0.9.4/openssl/zlib nghttp2/1.33.0 uname -a Linux admny1ano01.nl.gcp.dktinfra.cloud 4.18.0-348.20.1.el8_5.x86_64 #1 SMP Thu Mar 10 11:31:47 EST 2022 x86_64 x86_64 x86_64 GNU/Linux |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
102 | [AlmaLinux-8] NetworkManager | major | always | 2021-06-20 17:53 | 2022-04-26 08:50 |
Reporter: | adontz | Platform: | AWS | ||
Assigned To: | elkhan | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.4 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | 8.4 | ||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Incorrect SELinux label on /etc/sysconfig/network-scripts/ifcfg-eth0 | ||||
Description: |
Incorrect SELinux label on /etc/sysconfig/network-scripts/ifcfg-eth0 which is "system_u:object_r:unlabeled_t:s0" instead of "system_u:object_r:net_conf_t:s0" renders nmcli unusable. Try to update connection configuration logs similar error message NetworkManager[783]: <info> [1624210442.3384] audit: op="connection-update" uuid="5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03" name="eth0" args="ipv4.dns-search,connection.timestamp" pid=9325 uid=0 result="fail" reason="failed to update connection: Could not open file '/etc/sysconfig/network-scripts/ifcfg-eth0' for writing: Permission denied" |
||||
Tags: | |||||
Steps To Reproduce: |
Execute nmcli connection modify "eth0" ipv4.dns-search 'example.com' on a a fresh AWS image. |
||||
Additional Information: |
Executing chcon -t net_conf_t /etc/sysconfig/network-scripts/ifcfg* completely fixes the problem. |
||||
Attached Files: | |||||
Notes | |
(0000295)
alukoshko 2021-06-30 18:58 |
Hello and thank you! Nice catch. We are investigating it. |
(0000298)
ezamriy 2021-07-05 21:22 |
The problem is confirmed. I've created a GitHub issue https://github.com/AlmaLinux/cloud-images/issues/23 for it and wrote up my investigation results. We need to change our build pipeline to avoid Amazon's vmimport execution. |
(0000549)
elkhan 2022-04-26 08:50 |
Fixed by: https://github.com/AlmaLinux/cloud-images/commit/37958232da8f387f4bf5bb5ecd65e006b9eb71cb |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
93 | [AlmaLinux-8] -OTHER | minor | always | 2021-06-02 12:05 | 2022-04-26 08:47 |
Reporter: | obarrios | Platform: | AWS | ||
Assigned To: | elkhan | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.4 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | 8.4 | ||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | The UUID is always the same in the AWS official image of AlmaLinux 8.4 | ||||
Description: |
In my software, we identify instances by /etc/machine-id but in AWS the value is always the same. AMI Location: aws-marketplace/AlmaLinux OS 8.4 x86_64-c076b20a-2305-4771-823f-944909847a05 |
||||
Tags: | aws, cloud | ||||
Steps To Reproduce: |
cat /etc/machine-id 68eb8fb9b4544a189870301b79618f1d |
||||
Additional Information: |
I'm temporary workaround it by performing this just after create the instance: rm /etc/machine-id dbus-uuidgen --ensure=/etc/machine-id |
||||
Attached Files: | |||||
Notes | |
(0000547)
elkhan 2022-04-26 08:44 (Last edited: 2022-04-26 08:45) |
Hey, Thanks for making AlmaLinux Better. This issue fixed by: https://github.com/AlmaLinux/cloud-images/commit/37958232da8f387f4bf5bb5ecd65e006b9eb71cb |
(0000548)
elkhan 2022-04-26 08:47 |
https://github.com/AlmaLinux/cloud-images/commit/37958232da8f387f4bf5bb5ecd65e006b9eb71cb |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
215 | [AlmaLinux-8] -OTHER | trivial | always | 2022-04-21 05:51 | 2022-04-24 08:58 |
Reporter: | fiberkill | Platform: | HP Proliant | ||
Assigned To: | OS: | Almalinux | |||
Priority: | high | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Problem beim updaten ein frischen installation mit "yum update" | ||||
Description: |
Ich teste gerade unsere Kickstart-Umgebung mit Almalinux. Hiemit kann ich eine frische Installation ohne Probleme herstellen. Nach der Installation werden die .repo Dateien via Ansible auf unseren lokalen Mirror von BaseOS, AppStream, Extra usw. umgestellt. Diese Mirror habe kurz vorher aktualisiert. Danach kann ich ohne Problem Pakete über die lokalen Paketquellen installieren. Wenn ich nun auf den eben frisch installierten Server "yum udpdate" ausführe, bekommen folgende Fehlermeldung: Last metadata expiration check: 0:39:11 ago on Thu 21 Apr 2022 07:09:24 AM CEST. Error: Problem 1: package perl-Net-SSLeay-1.88-1.module_el8.3.0+2086+72f2d257.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - cannot install the best update candidate for package perl-libs-4:5.26.3-420.el8.x86_64 - cannot install the best update candidate for package perl-Net-SSLeay-1.88-1.module_el8.3.0+2086+72f2d257.x86_64 Problem 2: package net-snmp-agent-libs-1:5.8-22.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - package perl-Carp-1.50-439.module_el8.3.0+6149+d2c5d96d.noarch requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - cannot install the best update candidate for package perl-Carp-1.42-396.el8.noarch - cannot install the best update candidate for package net-snmp-agent-libs-1:5.8-22.el8.x86_64 Problem 3: package net-snmp-1:5.8-22.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - package perl-Data-Dumper-2.174-440.module_el8.3.0+6149+d2c5d96d.x86_64 requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - package perl-Data-Dumper-2.174-440.module_el8.3.0+6149+d2c5d96d.x86_64 requires libperl.so.5.30()(64bit), but none of the providers can be installed - cannot install the best update candidate for package perl-Data-Dumper-2.167-399.el8.x86_64 - cannot install the best update candidate for package net-snmp-1:5.8-22.el8.x86_64 Problem 4: perl-libs-4:5.26.3-420.el8.i686 has inferior architecture - package perl-Mozilla-CA-20160104-7.module_el8.3.0+2091+9eecfe51.noarch requires perl(:MODULE_COMPAT_5.26.3), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - package perl-Digest-1.17-396.module_el8.3.0+6149+d2c5d96d.noarch requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - cannot install the best update candidate for package perl-Mozilla-CA-20160104-7.module_el8.3.0+2091+9eecfe51.noarch - cannot install the best update candidate for package perl-Digest-1.17-395.el8.noarch Problem 5: package perl-IO-Socket-SSL-2.066-4.module_el8.3.0+2086+72f2d257.noarch requires perl(Net::SSLeay) >= 1.46, but none of the providers can be installed - package perl-Net-SSLeay-1.88-1.module_el8.3.0+2086+72f2d257.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - package perl-Digest-MD5-2.55-397.module_el8.3.0+6149+d2c5d96d.x86_64 requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - package perl-Digest-MD5-2.55-397.module_el8.3.0+6149+d2c5d96d.x86_64 requires libperl.so.5.30()(64bit), but none of the providers can be installed - cannot install the best update candidate for package perl-IO-Socket-SSL-2.066-4.module_el8.3.0+2086+72f2d257.noarch - cannot install the best update candidate for package perl-Digest-MD5-2.55-396.el8.x86_64 - package perl-Net-SSLeay-1.88-1.module_el8.3.0+2018+449fe210.x86_64 is filtered out by modular filtering - package perl-Net-SSLeay-1.88-1.module_el8.3.0+2088+ac7a9534.x86_64 is filtered out by modular filtering Problem 6: problem with installed package perl-Net-SSLeay-1.88-1.module_el8.3.0+2086+72f2d257.x86_64 - package perl-Net-SSLeay-1.88-1.module_el8.3.0+2086+72f2d257.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - package perl-Encode-4:3.01-439.module_el8.3.0+6149+d2c5d96d.x86_64 requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - package perl-Encode-4:3.01-439.module_el8.3.0+6149+d2c5d96d.x86_64 requires libperl.so.5.30()(64bit), but none of the providers can be installed - cannot install the best update candidate for package perl-Encode-4:2.97-3.el8.x86_64 Problem 7: problem with installed package net-snmp-agent-libs-1:5.8-22.el8.x86_64 - package net-snmp-agent-libs-1:5.8-22.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - package perl-Errno-1.30-452.module_el8.4.0+2179+01326e37.x86_64 requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - package perl-Errno-1.30-452.module_el8.4.0+2179+01326e37.x86_64 requires perl-libs(x86-64) = 4:5.30.1-452.module_el8.4.0+2179+01326e37, but none of the providers can be installed - cannot install the best update candidate for package perl-Errno-1.28-420.el8.x86_64 Problem 8: problem with installed package net-snmp-1:5.8-22.el8.x86_64 - package net-snmp-1:5.8-22.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - package perl-Exporter-5.73-440.module_el8.3.0+6149+d2c5d96d.noarch requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - cannot install the best update candidate for package perl-Exporter-5.72-396.el8.noarch Problem 9: problem with installed package perl-IO-Socket-SSL-2.066-4.module_el8.3.0+2086+72f2d257.noarch - package perl-IO-Socket-SSL-2.066-4.module_el8.3.0+2086+72f2d257.noarch requires perl(Net::SSLeay) >= 1.46, but none of the providers can be installed - package perl-Net-SSLeay-1.88-1.module_el8.3.0+2086+72f2d257.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64 - package perl-File-Path-2.16-439.module_el8.3.0+6149+d2c5d96d.noarch requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - cannot install the best update candidate for package perl-File-Path-2.15-2.el8.noarch - package perl-Net-SSLeay-1.88-1.module_el8.3.0+2018+449fe210.x86_64 is filtered out by modular filtering - package perl-Net-SSLeay-1.88-1.module_el8.3.0+2088+ac7a9534.x86_64 is filtered out by modular filtering (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) |
||||
Tags: | ansible, kickstart, yum update | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000537)
alukoshko 2022-04-21 11:31 |
Hello. Do you have the same issue with original AlmaLinux repos? |
(0000545)
fiberkill 2022-04-24 08:58 |
I'll try but i have to download the repo. What is in your opinion the best URL for this mirror? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
218 | [AlmaLinux-8] dhcp | major | always | 2022-04-22 10:21 | 2022-04-22 10:22 |
Reporter: | godzillante | Platform: | x86_64 | ||
Assigned To: | OS: | ||||
Priority: | normal | OS Version: | |||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | network service removes IP from ethernet configured as DHCP after 24 hours | ||||
Description: |
I noticed this pattern on three different VMs hosted on Scaleway and Hetzner, which use DHCP for IP assignment. After I installed AlmaLinux 8.5 successfully, I installed cPanel DNSOnly, which disables NetworkManager (it does during the installation phase, I guess because it conflicts with cPanel's management of IPs). Then after 24 hours I lost all three VMs at the same time, and the only way to have them reachable again was to disable the "network" service and re-enable NetworkManager. On another, similar VM which uses static IP addressing I have no problem. Latest updates are installed via dns. |
||||
Tags: | |||||
Steps To Reproduce: |
1. Set up DHCP network 2. Disable NetworkManager and enable the old network daemon 3. Wait 24 hours 4. Notice there's no IP address on the main network interface |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000541)
godzillante 2022-04-22 10:22 |
typo on last line of description: "Latest updates are installed via dnf" |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
112 | [AlmaLinux-8] anaconda | minor | always | 2021-07-06 04:29 | 2022-04-22 05:08 |
Reporter: | lee | Platform: | Linux | ||
Assigned To: | alukoshko | OS: | Alma Linux | ||
Priority: | normal | OS Version: | 8.3 | ||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | reopened | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Closest Mirror while installing | ||||
Description: |
Hi, It would be great if the installation source were the closest mirror, like in CentOS 8. We could install the latest version of the OS with all the patches in a fresh install. Thanks |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000299)
alukoshko 2021-07-07 18:09 |
Unfortunately it's not possible without rebuilding the ISO images. aarch64 version was released a bit later and includes this feature. x86_64 will have to wait for 8.5 I believe or some emergency rebuild. |
(0000301)
lee 2021-07-08 09:22 |
Thanks �. We will wait. |
(0000345)
alukoshko 2021-10-14 14:43 |
Yesterday we've released 8.5-beta with automatic closest mirror choosing during install https://wiki.almalinux.org/release-notes/8.5-beta Please try it. |
(0000419)
alukoshko 2021-11-22 20:10 |
8.5 stable is out with automatic closest mirror choosing during netinstall. |
(0000538)
lee 2022-04-22 05:08 |
Hi, Tested and working on install iso. Please enable on the Live media install also. Thanks |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
212 | [AlmaLinux-8] systemd | minor | have not tried | 2022-04-10 09:13 | 2022-04-11 13:52 |
Reporter: | vk | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | systemd permission denied due to assigned context | ||||
Description: |
Tried to create a service that executes a binary. The binary was downloaded to /tmp/mybinary/mybinary then moved to /usr/bin/mybinary and its permissions were changed to: -rwxr-xr-x. 1 mybinary_user mybinary_user 14049280 Apr 2 02:43 /usr/bin/mybinary The I created a unit file to execute the "mybinary" by User=mybinary_user Group=mybinary_user Systemctl was failing with permission denied journalctl snippet: systemd[1]: Starting MyBinary... systemd[1745]: mybinary.service: Failed to execute command: Permission denied systemd[1745]: mybinary.service: Failed at step EXEC spawning /usr/bin/mybinary.: Permission denied systemd[1]: mybinary.service: Control process exited, code=exited status=203 systemd[1]: mybinary.service: Failed with result 'exit-code'. systemd[1]: Failed to start MyBinary. But the mybinary_user and root were both able to run the binary. After a lot of digging around I found out that my issue was similar to this one bug: https://bugzilla.redhat.com/show_bug.cgi?id=1177202 I checked my binary had this context output # ls -Z /usr/bin/mybinary unconfined_u:object_r:user_tmp_t:s0 /usr/bin/mybinary so I "chcon" the type to from "user_tmp_t" to "bin_t" (same as most of the /usr/bin/* files) Systemd then was able to run the binary. I am new to linux so I am not sure if this is expected but I thought I should let you know. |
||||
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: |
214 | [AlmaLinux-8] dnf | minor | always | 2022-04-11 09:54 | 2022-04-11 09:54 |
Reporter: | kiwi | Platform: | All | ||
Assigned To: | OS: | Alma Linux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Alma Linux repository uses too weak certificate for enhanched security | ||||
Description: |
If you security harden your serverusing RedHats proposed method (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening): update-crypto-policies --set FUTURE ...you can no longer use dnf (with underlying curl) since it reports that the repository certificate is too weak: [root@server~]# dnf update AlmaLinux 8 - BaseOS 0.0 B/s | 0 B 00:07 Errors during downloading metadata for repository 'baseos': - Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mirrors.almalinux.org/mirrorlist/8/baseos?countme=3 [SSL certificate problem: EE certificate key too weak] - Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mirrors.almalinux.org/mirrorlist/8/baseos [SSL certificate problem: EE certificate key too weak] Error: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mirrors.almalinux.org/mirrorlist/8/baseos [SSL certificate problem: EE certificate key too weak] [root@server~]# |
||||
Tags: | |||||
Steps To Reproduce: |
update-crypto-policies --set FUTURE dnf update |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
211 | [AlmaLinux-8] asciidoc | minor | always | 2022-04-06 13:48 | 2022-04-06 13:48 |
Reporter: | wadeh | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | a2x conversion to PDF or PS broken | ||||
Description: |
The a2x command (part of asciidoc) fails to create PDF or PS documents from text files due to a Python error. Note that this worked fine on CentOS 6 and 7. I suspect this is broken upstream but have not tested it yet on RHEL or CentOS 8 Stream. |
||||
Tags: | |||||
Steps To Reproduce: |
1. Create test document "test.txt" 2. Run "a2x -d article -f pdf test.txt" 3. It fails each time with and error (note, this should keep the test.xml temp file) 4. Manually run dblatex to see the details of the error: dblatex -t pdf -p "/etc/asciidoc/dblatex/asciidoc-dblatex.xsl" -s "/etc/asciidoc/dblatex/asciidoc-dblatex.sty" "./test.xml" Errors reported: Build the book set list... Build the listings... XSLT stylesheets DocBook - LaTeX 2e (0.3.10) =================================================== Image 'dblatex' not found Unexpected error occured Error: %b requires a bytes-like object, or an object that implements __bytes__# , not 'str' |
||||
Additional Information: |
RPMS: asciidoc-8.6.10-0.5.20180627gitf7c2274.el8.noarch dblatex-0.3.10-8.el8.noarch test.txt, a simple test document: Test Document ============= Joe Blo <joeblo@example.com> 1.0, 4/6/2022: created as a test document Synopsis: --------- This is a test document using asciidoc "The asciidoc(1) command translates the AsciiDoc text file FILE to DocBook or HTML. If FILE is - then the standard input is used." Notes: ------ 1. This would be a list of notes. 2. And some more notes. |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
210 | [AlmaLinux-8] -OTHER | crash | always | 2022-04-05 12:17 | 2022-04-05 13:57 |
Reporter: | olahaye74 | Platform: | x86_64 | ||
Assigned To: | OS: | CentOS | |||
Priority: | normal | OS Version: | 7 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Leapp preupgrade crashes UnicodeDecodeError: 'utf8' codec can't decode byte 0xef in position 3: invalid continuation byte | ||||
Description: |
# LC_ALL=C leapp preupgrade ==> Processing phase `configuration_phase` ====> * ipu_workflow_config IPU workflow config actor ==> Processing phase `FactsCollection` ====> * scan_kernel_cmdline No documentation has been provided for the scan_kernel_cmdline actor. ====> * removed_pam_modules_scanner Scan PAM configuration for modules that are not available in RHEL-8. ====> * scan_sap_hana Gathers information related to SAP HANA instances on the system. ====> * scan_subscription_manager_info Scans the current system for subscription manager information ====> * system_facts Provides data about many facts from system. ====> * udevadm_info Produces data exported by the "udevadm info" command. Process Process-187: Traceback (most recent call last): File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap self.run() File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", line 72, in _do_run actor_instance.run(*args, **kwargs) File "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", line 335, in run self.process(*args) File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/udev/udevadminfo/actor.py", line 18, in process out = run(['udevadm', 'info', '-e'])['stdout'] File "/usr/lib/python2.7/site-packages/leapp/libraries/stdlib/__init__.py", line 181, in run stdin=stdin, env=env, encoding=encoding) File "/usr/lib/python2.7/site-packages/leapp/libraries/stdlib/call.py", line 179, in _call **extra File "/usr/lib/python2.7/site-packages/leapp/libraries/stdlib/call.py", line 59, in _multiplex linebufs[fd] += decoders[fd].decode(read) File "/usr/lib64/python2.7/codecs.py", line 296, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xef in position 3: invalid continuation byte ============================================================================================= Actor udevadm_info unexpectedly terminated with exit code: 1 - Please check the above details ============================================================================================= Debug output written to /var/log/leapp/leapp-preupgrade.log ============================================================ REPORT ============================================================ A report has been generated at /var/log/leapp/leapp-report.json A report has been generated at /var/log/leapp/leapp-report.txt ============================================================ END OF REPORT ============================================================ Answerfile has been generated at /var/log/leapp/answerfile |
||||
Tags: | |||||
Steps To Reproduce: | sudo Leapp preupgrade | ||||
Additional Information: | |||||
Attached Files: |
udevadm_info-e.txt (303,641 bytes) 2022-04-05 12:50 https://bugs.almalinux.org/file_download.php?file_id=128&type=bug |
||||
Notes | |
(0000533)
olahaye74 2022-04-05 12:50 |
Attachment: the output of udevadm info -e as you will notice, some output is written in Chinese. (example: line 3089). This is obviously not ASCII, thus the crash. |
(0000534)
olahaye74 2022-04-05 13:27 |
It seems to crash when decoding this line: E: HID_UNIQ=香晦晦香香晦晦香 (added a print(read) at line 59 in /usr/lib/python2.7/site-packages/leapp/libraries/stdlib/call.py (just before the crash). |
(0000535)
olahaye74 2022-04-05 13:57 |
It seems that the device that raises the problem is a Belkin USB+VGA KVM adapter-module (need to physically check) # lsusb -t -d 3032: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 6: Dev 3, If 0, Class=Hub, Driver=hub/6p, 480M [root@drtcloud leapp]# lsusb -v -d 3032: Bus 002 Device 003: ID 3032:1b1c Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x3032 idProduct 0x1b1c bcdDevice dd.28 iManufacturer 4 ??? iProduct 70 ???????????????????????????????? iSerial 136 ?????????????????????????????? bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.00 bCountryCode 33 US bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 63 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 64 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.00 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 52 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 10 Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
206 | [AlmaLinux-8] kernel | minor | have not tried | 2022-03-28 17:50 | 2022-03-29 10:53 |
Reporter: | kashanlinux | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | PMU to ignore in linux “initcall_blacklist=arm_pmu_acpi_init” in ARM64 Support | ||||
Description: | There’s a quick fix in Linux for the PMU problem: on the Linux kernel boot line, add “initcall_blacklist=arm_pmu_acpi_init”. This option will keep the PMU driver from loading, and should avoid all the PMU problems. | ||||
Tags: | aarch64 | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: |
image.png (1,736 bytes) 2022-03-28 17:50 https://bugs.almalinux.org/file_download.php?file_id=120&type=bug image-2.png (1,376 bytes) 2022-03-28 17:50 https://bugs.almalinux.org/file_download.php?file_id=121&type=bug image-3.png (7,171 bytes) 2022-03-28 17:50 https://bugs.almalinux.org/file_download.php?file_id=122&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
192 | [AlmaLinux-8] -OTHER | tweak | always | 2022-02-24 05:16 | 2022-03-26 10:46 |
Reporter: | lee | Platform: | x86_64 | ||
Assigned To: | OS: | Linux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Enable Content trust in Alma Linux Docker images | ||||
Description: |
docker trust inspect --pretty almalinux:latest gives “No signatures or cannot access almalinux:latest” docker trust inspect --pretty centos:8 gives " SIGNED TAG DIGEST SIGNERS 8 76d24f3ba3317fa945743bb3746fbaf3a0b752f10b10376960de01da70685fbd (Repo Admin) Administrative keys for centos:8 Repository Key: f4880e657b5b47e2a5eec7d7c5700245e9fde28754c84faada67115c523f7488 Root Key: 95eadfb9877a06161261e4ebed7c8c9f1cbc49ab7f0a5ab246dfcce0d20c3e8c " Kindly look into this. |
||||
Tags: | Docker | ||||
Steps To Reproduce: | docker trust inspect --pretty almalinux:latest | ||||
Additional Information: |
https://docs.docker.com/engine/reference/commandline/trust_inspect/ https://docs.docker.com/engine/security/trust/ |
||||
Attached Files: |
alma-dct.txt (1,370 bytes) 2022-03-26 10:46 https://bugs.almalinux.org/file_download.php?file_id=119&type=bug |
||||
Notes | |
(0000522)
srbala 2022-03-26 10:46 |
It looks like our March release resolved `almalinux:latest` tag. Other tags 8, 8.5, minimal, still have issues. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
204 | [AlmaLinux-8] almalinux-release | minor | always | 2022-03-24 01:28 | 2022-03-24 01:28 |
Reporter: | karlberry | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | 8.5 boot.iso too big for CD media? | ||||
Description: |
AlmaLinux-8.5-x86_64-boot.iso has size 773,849,088 bytes. I tried to burn it to a blank CD with cdrecord -dev=... (I still have old systems where CD is the most convenient way to install), but it bailed out with: Blocks total: 359849 Blocks current: 359849 Blocks remaining: -18009 wodim: WARNING: Data may not fit on current disk. And when I tried overburning the media anyway, it could not be read correctly. Any chance of reducing the size? The 8.4 *boot.iso is considerably smaller: 709,885,952. Thanks. |
||||
Tags: | boot | ||||
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: |
203 | [AlmaLinux-8] passwd | major | random | 2022-03-22 07:40 | 2022-03-23 17:23 |
Reporter: | elialum | Platform: | Almalinux | ||
Assigned To: | OS: | Almalinux | |||
Priority: | urgent | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | User level permissionts/settings randomly destroyed (su: failed to execute /bin/bash: No such file or directory) | ||||
Description: |
We are getting hit by random system-level user errors in which the user is completely unable to function, nothing basically works, here is one simple example of trying to SU to the user - su username su: failed to execute /bin/bash: No such file or directory As these are mostly users that related to websites, everything is dead obviously (websites, crons, anything) Our quick & dirty workaround currently is to recreate the user - userdel username useradd username chown -R username.username userhomedir One thing we noted is that "nobody" user on this server is different from than usual system: ~>grep nobody /etc/passwd nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin usually, it's like ~>grep nobody /etc/passwd nobody:x:99:99:Nobody:/:/sbin/nologin nobody uid=65534, pid=65534 is unusual as far as I can tell? Not sure if it's related though Thanks, Eli. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | Kernel: 4.18.0-348.20.1.el8_5.x86_64 | ||||
Attached Files: | |||||
Notes | |
(0000519)
alukoshko 2022-03-22 08:12 |
Hello. Both nobody users are correct but for different os versions. RHEL8: ~>grep nobody /etc/passwd nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin RHEL7: ~>grep nobody /etc/passwd nobody:x:99:99:Nobody:/:/sbin/nologin Is it possible that your server OS was attacked or unintentionally damaged by someone? AlmaLinux itself doesn't modify users or their dirs in any way. Does /bin/bash actually present in system? |
(0000520)
danielsan 2022-03-22 08:26 |
Hello alukosho, Thank you for your reply, /bin/bash is present in the system. Do you have any clue how can we investigate that issue? |
(0000521)
elialum 2022-03-23 17:23 |
Found the issue, an internal script that runs daily on the users and doing something on their group ownership (security-wise) if some conditions are met. Worked perfectly on COS7, so we didn't catch it initially when upgraded to ALM8 We can close this one |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
201 | [AlmaLinux-8] dnf | major | always | 2022-03-21 09:49 | 2022-03-21 11:49 |
Reporter: | Fozzy Admins | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | high | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Error: Failed to download metadata for repo «centos-openstack-train»: Cannot prepare internal mirrorlist: No URLs in mirrorlist | ||||
Description: |
Openstack-Train repository installed via dnf does not work due to the end of life of CentOS 8. For its correct operation, it is required to specify the Vault repositories in yum.repos.d configs. |
||||
Tags: | |||||
Steps To Reproduce: | Install centos-release-openstack-train repo via dnf/yum and make cache. | ||||
Additional Information: | I see 2 solutions: creating an openstack repo for Alma Linux 8, or replacing the repo with vault. | ||||
Attached Files: | |||||
Notes | |
(0000518)
sboldyreva 2022-03-21 11:49 |
Hello! There's a related bug, you may want to check it: https://bugs.almalinux.org/view.php?id=186 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
200 | [AlmaLinux-8] pulseaudio | major | always | 2022-03-18 20:08 | 2022-03-18 20:08 |
Reporter: | dufgrinder | Platform: | ASUS 55A - Intel Pentium B970 | ||
Assigned To: | OS: | AlmanLinux 8.5 | |||
Priority: | normal | OS Version: | 4.18.0-348.20.1 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Speakers always Mute | ||||
Description: |
Hi, On a quite old laptop, Speakers never play. Knowing that: * They worked may years under Centos 7 and always work with Fedora 35 and Centos 9 * Headphones are working KR, Olivier |
||||
Tags: | |||||
Steps To Reproduce: |
Just play a movie: - Try to mute / unmute with pulseaudio |
||||
Additional Information: |
lspci -v | grep -B1 -A12 -i audio 00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc. Device 1c33 Flags: bus master, fast devsel, latency 0, IRQ 30 Memory at f7e10000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 24 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: [disabled] |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
199 | [AlmaLinux-8] dnf | major | always | 2022-03-11 04:44 | 2022-03-11 08:39 |
Reporter: | chris hutchinson | Platform: | |||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | /etc/yum.repos.d/almalinux-resilientstorage.repo has repeated [resilientstorage] entries | ||||
Description: |
/etc/yum.repos.d/almalinux-resilientstorage.repo contains repeated entries for [resilientstorage] and causes puppet v7 to fail. Manually editing the repo file to give the entries unique names fixed things. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000514)
alukoshko 2022-03-11 08:39 |
Hi. There was a bug in released AlmaLinux 8.5 that was then quickly fixed by almalinux-release version 8.5-3. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
197 | [AlmaLinux-8] firefox | major | have not tried | 2022-03-07 19:04 | 2022-03-10 22:05 |
Reporter: | repulsive-gravity | Platform: | el8 | ||
Assigned To: | OS: | ||||
Priority: | urgent | OS Version: | 8.5 ArcticSphinx | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | CVE-2022-26485 and CVE-2022-26486 Use-After-Free memory exploits; | ||||
Description: |
I'm relatively new to Linux, I hope I've brought this to the proper place. I'm sure everyone is aware of this; but, I am wondering if Alma is working on adding these patches to the official repository? Those being : Firefox 91.6.1 esr ; Firefox 97.0.2 Currently, dnf thinks Firefox 91.6.0 is up to date. CVE-2022-26485 and CVE-2022-26486 are the use-after-free memory exploits. Cheers |
||||
Tags: | cve-2022-26485, cve-2022-26486, firefox, zeroday | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000505)
sboldyreva 2022-03-09 10:28 |
Hello! As AlmaLinux is 1:1 compatible with RHEL, we release updates after Red Hat. For now, there's not such an update yet. |
(0000513)
alukoshko 2022-03-10 22:05 |
Hello. firefox-91.7.0-3.el8_5.alma was just released with the following vulnerabilities closed: CVE-2022-25235 CVE-2022-25236 CVE-2022-25315 CVE-2022-26381 CVE-2022-26383 CVE-2022-26384 CVE-2022-26386 CVE-2022-26387 CVE-2022-26485 CVE-2022-26486 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
165 | [AlmaLinux-8] -OTHER | block | always | 2021-12-21 02:58 | 2022-03-09 20:17 |
Reporter: | edb | Platform: | M1 Max (aarm64) | ||
Assigned To: | OS: | macOS | |||
Priority: | immediate | OS Version: | 12.1 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Unable to install Alma Linux 8.x aarm64 macOS 12.1 M1 | ||||
Description: |
Unable to install Alma Linux 8.x aarm64 macOS 12.1 M1 Max Virtualization platforms: Parallels, VMware Fusion, QEMU Description: The ISO's boot into the install select menu. Selecting any of the options brings you right back to the same menu of selecting the media verification or going straight to the install. |
||||
Tags: | |||||
Steps To Reproduce: | With M1 based Mac, using Parallels, or VMware Fusion or QEMU, boot the iso for install with default settings or other settings. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000456)
alukoshko 2021-12-21 19:07 |
RHEL8 (and all its derivatives) doesn't support Apple M1. RHEL9 will do. |
(0000457)
edb 2021-12-22 04:27 |
How soon to see this supported? My organization is standardizing with Alma Linux and the added support for Apple M1 Arm would be great. |
(0000458)
edb 2021-12-22 04:29 |
Specifically this is to run as a VM, not necessarily on M1 bare metal. Thanks advance! |
(0000464)
akdev 2021-12-31 02:48 |
What happens when you try to boot from a Centos 8 Stream image? does it work? unfortunately this is difficult to troubleshoot as it requires special hardware - are you using an aarch64 image or x86 image? does the x86-64 work? |
(0000500)
edb 2022-03-04 01:41 |
Checking in. What would be the expected timing for this? Regards. |
(0000507)
toracat 2022-03-09 20:17 |
As @alukoshko noted, you have to wait for EL9, which *might* be out around May (but please don't quote me :) https://access.redhat.com/solutions/6545411 "Can I run RHEL in a VM in a Mac using the Apple M1 processor?" |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
196 | [AlmaLinux-8] -OTHER | trivial | always | 2022-03-05 05:16 | 2022-03-05 05:16 |
Reporter: | aboschke | Platform: | |||
Assigned To: | OS: | Arctic Sphynx | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Group 'Additional Development' has EL7 artifact package hmaccalc should now be libkcapi-hmaccalc | ||||
Description: |
Package name change from EL7 to EL8 (see A.2. Package replacements): [ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index ] |
||||
Tags: | |||||
Steps To Reproduce: |
# dnf install \@"Additional Development" No match for group package "hmaccalc" |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
195 | [AlmaLinux-8] crypto-policies | major | always | 2022-03-04 21:51 | 2022-03-04 21:51 |
Reporter: | hirschQ | Platform: | vmware virtual machine | ||
Assigned To: | OS: | Almalinux | |||
Priority: | high | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | crypto mismatch: baseos mirrolist SSL certificate problem: EE certificate key too weak | ||||
Description: |
It is not possible to use the almalinux baseos mirrorlist when crypto policy set = FUTURE Errors during downloading metadata for repository 'baseos': - Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mirrors.almalinux.org/mirrorlist/8/baseos [SSL certificate problem: EE certificate key too weak] Error: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mirrors.almalinux.org/mirrorlist/8/baseos [SSL certificate problem: EE certificate key too weak] |
||||
Tags: | installation, selinux | ||||
Steps To Reproduce: |
I installed minimal Almalinux with Security Profile: CIS Benchmark Level 2 for Server and tried to update or install. But changing crypto-policy to future will reproduce the error, too: update-crypto-policies --set FUTURE reboot dnf install nano |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
191 | [AlmaLinux-8] cronie | minor | always | 2022-02-23 13:19 | 2022-02-23 13:19 |
Reporter: | domen | Platform: | Vmware | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Mail on error not sent from cron files | ||||
Description: |
I have following lines in root crontab file: MAILTO="domen.setar@izum.si" 0 10 * * * /tmp/nonexistent_file.sh Error message about non existent file is not sent via mail but is written into /var/log/cron: Feb 23 14:07:01 testsrv CROND[2503686]: (root) CMDOUT (/bin/sh: /tmp/nonexistent_file.sh: No such file or directory) Mail system on testsrv works fine, because I can send mail from the command line. This functionality works in Centos 7 and 8 releases. |
||||
Tags: | cron | ||||
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: |
186 | [AlmaLinux-8] almalinux-release | major | always | 2022-02-11 14:55 | 2022-02-21 15:57 |
Reporter: | pete | Platform: | x68_64 | ||
Assigned To: | OS: | Almalinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | centos-release-openstack-train repos are broken | ||||
Description: |
I was using the centos-release-openstack-train repos for the installation of, among others, etcd. Some days after CentOS 8 went EOL the Cloud SIG repo seems to have gone offline (or moved elsewhere) as well. As a result, the repos installed with the centos-release-openstack-train package are broken now. |
||||
Tags: | |||||
Steps To Reproduce: |
Using a fresh install of Almalinux 8.5 (Vagrant box "almalinux/8"): [root@localhost ~]# dnf install centos-release-openstack-train AlmaLinux 8 - BaseOS 2.0 MB/s | 5.9 MB 00:03 AlmaLinux 8 - AppStream 2.0 MB/s | 9.1 MB 00:04 AlmaLinux 8 - Extras 17 kB/s | 12 kB 00:00 Dependencies resolved. ==================================================================================================================================== Package Architecture Version Repository Size ==================================================================================================================================== Installing: centos-release-openstack-train noarch 2-1.el8 extras 11 k Installing dependencies: centos-release-messaging noarch 1-2.el8 extras 9.2 k centos-release-rabbitmq-38 noarch 1-2.el8 extras 8.1 k centos-release-storage-common noarch 2-2.el8 extras 9.2 k Transaction Summary ==================================================================================================================================== Install 4 Packages Total download size: 37 k Installed size: 8.2 k Is this ok [y/N]: y Downloading Packages: (1/4): centos-release-messaging-1-2.el8.noarch.rpm 88 kB/s | 9.2 kB 00:00 (2/4): centos-release-openstack-train-2-1.el8.noarch.rpm 101 kB/s | 11 kB 00:00 (3/4): centos-release-rabbitmq-38-1-2.el8.noarch.rpm 71 kB/s | 8.1 kB 00:00 (4/4): centos-release-storage-common-2-2.el8.noarch.rpm 223 kB/s | 9.2 kB 00:00 ------------------------------------------------------------------------------------------------------------------------------------ Total 52 kB/s | 37 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : centos-release-storage-common-2-2.el8.noarch 1/4 Installing : centos-release-messaging-1-2.el8.noarch 2/4 Installing : centos-release-rabbitmq-38-1-2.el8.noarch 3/4 Installing : centos-release-openstack-train-2-1.el8.noarch 4/4 Verifying : centos-release-messaging-1-2.el8.noarch 1/4 Verifying : centos-release-openstack-train-2-1.el8.noarch 2/4 Verifying : centos-release-rabbitmq-38-1-2.el8.noarch 3/4 Verifying : centos-release-storage-common-2-2.el8.noarch 4/4 Installed: centos-release-messaging-1-2.el8.noarch centos-release-openstack-train-2-1.el8.noarch centos-release-rabbitmq-38-1-2.el8.noarch centos-release-storage-common-2-2.el8.noarch Complete! [root@localhost ~]# dnf makecache CentOS-8 - RabbitMQ 38 83 B/s | 38 B 00:00 Error: Failed to download metadata for repo 'centos-rabbitmq-38': Cannot prepare internal mirrorlist: No URLs in mirrorlist |
||||
Additional Information: |
Looking at http://mirror.centos.org/centos/8/, the "cloud" and "messaging" directories have gone, which explains the problem. Unfortunately I could not figure out yet where they have moved, so it's not trivial to fix. Anyway, the -release RPMs should be updated to reflect that change. |
||||
Attached Files: | |||||
Notes | |
(0000492)
pete 2022-02-20 12:12 |
The issue has obviously been caused by the SIG repositories moving over to the CentOS Stream mirrors, at least some of them. As for the repositories I require (mainly Centos-OpenStack), the following workaround seems to do the trick: <code> [root@localhost ~]# sed -i 's/\$releasever/8-stream/g' /etc/yum.repos.d/CentOS-Ceph-Nautilus.repo [root@localhost ~]# sed -i 's/\$releasever/8-stream/g' /etc/yum.repos.d/CentOS-OpenStack-victoria.repo [root@localhost ~]# sed -i 's/\$releasever/8-stream/g' /etc/yum.repos.d/CentOS-Messaging-rabbitmq.repo [root@localhost ~]# sed -i 's/\$releasever/8-stream/g' /etc/yum.repos.d/CentOS-NFV-OpenvSwitch.repo [root@localhost ~]# yum makecache CentOS-8 - Advanced Virtualization 5.0 kB/s | 3.0 kB 00:00 CentOS-8-stream - Ceph Nautilus 16 kB/s | 3.0 kB 00:00 CentOS-8 - RabbitMQ 38 17 kB/s | 3.0 kB 00:00 CentOS-8-stream - NFV OpenvSwitch 377 kB/s | 111 kB 00:00 CentOS-8-stream - OpenStack victoria 17 kB/s | 3.0 kB 00:00 AlmaLinux 8 - BaseOS 5.9 kB/s | 4.3 kB 00:00 AlmaLinux 8 - AppStream 7.9 kB/s | 4.7 kB 00:00 AlmaLinux 8 - Extras 1.7 kB/s | 3.9 kB 00:02 Metadata cache created. </code> Disclaimer: If the SIGs actually build against Centos Stream, there might be incompatibilities with plain AlmaLinux 8/Rocky Linux 8. This is something that might need to be resolved on a different level. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
189 | [AlmaLinux-8] dnf | block | have not tried | 2022-02-18 13:35 | 2022-02-21 15:57 |
Reporter: | pomichel | Platform: | |||
Assigned To: | OS: | AlmaLinux release 8.5 | |||
Priority: | urgent | OS Version: | Arctic Sphynx | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Cant't update OS via yum or dnf | ||||
Description: |
Get an error : CentOS-8 - Ceph Nautilus 1.1 kB/s | 38 B 00:00 Erreur : Échec du téléchargement des métadonnées pour le dépôt « centos-ceph-nautilus » : Cannot prepare internal mirrorlist: No URLs in mirrorlist Problem can be reproduced on any of my 6 production servers. Please urgently help ! |
||||
Tags: | |||||
Steps To Reproduce: |
Run yum update of dnf install net-tools for instance |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000493)
pete 2022-02-20 12:13 |
This is the same issue as https://bugs.almalinux.org/view.php?id=186 See my latest updaten to that issue for an at least partial workaround. |
(0000494)
pomichel 2022-02-21 09:28 |
OK, thanks. The workaround is working though I don't feel secure to work with Centos Stream repositories. |
(0000495)
pete 2022-02-21 15:56 |
I also don't think this is an ideal situation, for the reasons mentioned in 0000186. I strongly hope it can be solved in a reasonable way rather sooner than later. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
142 | [AlmaLinux-8] kernel | major | always | 2021-11-04 05:43 | 2022-02-17 21:17 |
Reporter: | sbhat | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Intermittent I/O block, timeout of disks in ZFS on Almalinux8 | ||||
Description: |
I have two servers A & B and both the servers intermittently rejecting IO, aborting IO commands & causing hiccup in the IO. zpool status turns to warning due to this incident. Server A: [root@server-A]$/opt/MegaRAID/storcli/storcli64 /c0 show CLI Version = 007.1907.0000.0000 Sep 13, 2021 Operating system = Linux 4.18.0-305.el8.x86_64 Controller = 0 Status = Success Description = None Product Name = LSI3008-IR Serial Number = 500304801cca7901 SAS Address = 500304801cca7901 PCI Address = 00:01:00:00 System Time = 11/03/2021 10:43:37 FW Package Build = 00.00.00.00 FW Version = 13.00.00.00 BIOS Version = 08.31.00.00 NVDATA Version = 11.02.49.39 Driver Name = mpt3sas Driver Version = 35.101.00.00 Bus Number = 1 Device Number = 0 Function Number = 0 Domain ID = 0 Vendor Id = 0x1000 Device Id = 0x97 SubVendor Id = 0x15D9 SubDevice Id = 0x808 Board Name = LSI3008-IR Board Assembly = N/A Board Tracer Number = N/A Security Protocol = None Physical Drives = 14 Server A Intermittent Errors: [Wed Nov 3 03:25:16 2021] mpt3sas_cm0: log_info(0x31120b10): originator(PL), code(0x12), sub_code(0x0b10) [Wed Nov 3 03:25:16 2021] mpt3sas_cm0: log_info(0x31120b10): originator(PL), code(0x12), sub_code(0x0b10) [Wed Nov 3 03:25:16 2021] mpt3sas_cm0: log_info(0x31120b10): originator(PL), code(0x12), sub_code(0x0b10) [Wed Nov 3 03:25:16 2021] sd 0:0:10:0: [sdk] tag#2497 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK cmd_age=0s [Wed Nov 3 03:25:16 2021] sd 0:0:10:0: [sdk] tag#2498 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK cmd_age=0s [Wed Nov 3 03:25:16 2021] sd 0:0:10:0: [sdk] tag#2547 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK cmd_age=0s [Wed Nov 3 03:25:16 2021] sd 0:0:10:0: [sdk] tag#2498 CDB: Write(16) 8a 00 00 00 00 01 52 7f 81 a2 00 00 00 11 00 00 [Wed Nov 3 03:25:16 2021] sd 0:0:10:0: [sdk] tag#2547 CDB: Write(16) 8a 00 00 00 00 01 52 7f 81 91 00 00 00 11 00 00 [Wed Nov 3 03:25:16 2021] sd 0:0:10:0: [sdk] tag#2497 CDB: Write(16) 8a 00 00 00 00 01 52 7f 81 b3 00 00 00 11 00 00 [Wed Nov 3 03:25:16 2021] blk_update_request: I/O error, dev sdk, sector 5679055249 op 0x1:(WRITE) flags 0x700 phys_seg 1 prio class 0 [Wed Nov 3 03:25:16 2021] blk_update_request: I/O error, dev sdk, sector 5679055283 op 0x1:(WRITE) flags 0x700 phys_seg 1 prio class 0 [Wed Nov 3 03:25:16 2021] blk_update_request: I/O error, dev sdk, sector 5679055266 op 0x1:(WRITE) flags 0x700 phys_seg 1 prio class 0 [Wed Nov 3 03:25:16 2021] zio pool=backups vdev=/dev/sdk1 error=5 type=2 offset=2907675256320 size=8704 flags=180880 [Wed Nov 3 03:25:16 2021] zio pool=backups vdev=/dev/sdk1 error=5 type=2 offset=2907675247616 size=8704 flags=180880 [Wed Nov 3 03:25:16 2021] zio pool=backups vdev=/dev/sdk1 error=5 type=2 offset=2907675238912 size=8704 flags=180880 [Wed Nov 3 03:25:17 2021] sd 0:0:10:0: Power-on or device reset occurred Server B: [root@server-B]$ /opt/MegaRAID/storcli/storcli64 /c0 show CLI Version = 007.1907.0000.0000 Sep 13, 2021 Operating system = Linux 4.18.0-305.10.2.el8_4.x86_64 Controller = 0 Status = Success Description = None Product Name = SAS9300-4i Serial Number = SP83910736 SAS Address = 500605b00e807090 PCI Address = 00:01:00:00 System Time = 11/03/2021 04:31:03 FW Package Build = 00.00.00.00 FW Version = 16.00.01.00 <--------< BIOS Version = 08.37.00.00_18.00.00.00 NVDATA Version = 14.01.00.07 Driver Name = mpt3sas Driver Version = 35.101.00.00 Bus Number = 1 Device Number = 0 Function Number = 0 Domain ID = 0 Vendor Id = 0x1000 Device Id = 0x96 SubVendor Id = 0x1000 SubDevice Id = 0x3110 Board Name = SAS9300-4i Board Assembly = H3-25473-00G Board Tracer Number = SP83910736 Security Protocol = None Physical Drives = 12 Server B Intermittent Errors: [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5085 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 [Wed Nov 3 06:41:07 2021] scsi target0:0:0: handle(0x0006), sas_address(0x50030480180ec340), phy(0) [Wed Nov 3 06:41:07 2021] scsi target0:0:0: enclosure logical id(0x50030480180ec37f), slot(0) [Wed Nov 3 06:41:07 2021] scsi target0:0:0: enclosure level(0x0000), connector name( ) [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: task abort: SUCCESS scmd(0x000000004e58e27c) [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: attempting task abort!scmd(0x00000000e6d2bb01), outstanding for 30408 ms & timeout 30000 ms [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5117 CDB: Write(16) 8a 00 00 00 00 02 a2 c0 e1 f8 00 00 00 40 00 00 [Wed Nov 3 06:41:07 2021] scsi target0:0:0: handle(0x0006), sas_address(0x50030480180ec340), phy(0) [Wed Nov 3 06:41:07 2021] scsi target0:0:0: enclosure logical id(0x50030480180ec37f), slot(0) [Wed Nov 3 06:41:07 2021] scsi target0:0:0: enclosure level(0x0000), connector name( ) [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: No reference found at driver, assuming scmd(0x00000000e6d2bb01) might have completed [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: task abort: SUCCESS scmd(0x00000000e6d2bb01) [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5117 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5117 CDB: Write(16) 8a 00 00 00 00 02 a2 c0 e1 f8 00 00 00 40 00 00 [Wed Nov 3 06:41:07 2021] blk_update_request: I/O error, dev sdc, sector 11320484344 op 0x1:(WRITE) flags 0x700 phys_seg 8 prio class 0 [Wed Nov 3 06:41:07 2021] zio pool=backups vdev=/dev/sdc1 error=5 type=2 offset=5796086935552 size=32768 flags=180880 [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: attempting task abort!scmd(0x00000000c1d8d569), outstanding for 30408 ms & timeout 30000 ms [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5116 CDB: Write(16) 8a 00 00 00 00 02 a2 c0 e2 78 00 00 00 40 00 00 [Wed Nov 3 06:41:07 2021] scsi target0:0:0: handle(0x0006), sas_address(0x50030480180ec340), phy(0) [Wed Nov 3 06:41:07 2021] scsi target0:0:0: enclosure logical id(0x50030480180ec37f), slot(0) [Wed Nov 3 06:41:07 2021] scsi target0:0:0: enclosure level(0x0000), connector name( ) [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: No reference found at driver, assuming scmd(0x00000000c1d8d569) might have completed [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: task abort: SUCCESS scmd(0x00000000c1d8d569) [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5116 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5116 CDB: Write(16) 8a 00 00 00 00 02 a2 c0 e2 78 00 00 00 40 00 00 [Wed Nov 3 06:41:07 2021] blk_update_request: I/O error, dev sdc, sector 11320484472 op 0x1:(WRITE) flags 0x700 phys_seg 8 prio class 0 [Wed Nov 3 06:41:07 2021] zio pool=backups vdev=/dev/sdc1 error=5 type=2 offset=5796087001088 size=32768 flags=180880 [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: attempting task abort!scmd(0x000000000a3a05e3), outstanding for 30533 ms & timeout 30000 ms [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5115 CDB: Write(16) 8a 00 00 00 00 02 a2 c0 e2 38 00 00 00 40 00 00 [Wed Nov 3 06:41:07 2021] scsi target0:0:0: handle(0x0006), sas_address(0x50030480180ec340), phy(0) [Wed Nov 3 06:41:07 2021] scsi target0:0:0: enclosure logical id(0x50030480180ec37f), slot(0) [Wed Nov 3 06:41:07 2021] scsi target0:0:0: enclosure level(0x0000), connector name( ) [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: No reference found at driver, assuming scmd(0x000000000a3a05e3) might have completed [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: task abort: SUCCESS scmd(0x000000000a3a05e3) [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5115 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s [Wed Nov 3 06:41:07 2021] sd 0:0:0:0: [sdc] tag#5115 CDB: Write(16) 8a 00 00 00 00 02 a2 c0 e2 38 00 00 00 40 00 00 [Wed Nov 3 06:41:07 2021] blk_update_request: I/O error, dev sdc, sector 11320484408 op 0x1:(WRITE) flags 0x700 phys_seg 8 prio class 0 [Wed Nov 3 06:41:07 2021] zio pool=backups vdev=/dev/sdc1 error=5 type=2 offset=5796086968320 size=32768 flags=180880 [Wed Nov 3 06:41:08 2021] sd 0:0:0:0: Power-on or device reset occurred |
||||
Tags: | almalinux8, disk, io-abort, megaraidsas, mpt3sas, smartctl, zfs | ||||
Steps To Reproduce: |
Supermicro Almalinux8 Server with ZFS |
||||
Additional Information: |
1. Both servers A,B are Broadcom HBA controllers communicate to kernel via mpt3sas driver. 2. We have another server C which has megaraid_sas as driver & not seeing this issue. 3. We have 5 OmniOS (solaris based) servers with both mpt3sas/megaraid_sas drivers but not seeing any IO/disk hiccups at all. 4. smartctl says drives are all good. 5. The IO isn't for one disk but for all the disks randomly. 6. Server has no special IO write or anything, the timing is random too, as if disks are waking up from sleep. Any suggestions will be very greatly appreciated. |
||||
Attached Files: | |||||
Notes | |
(0000377)
sbhat 2021-11-09 14:13 |
Anyone? help |
(0000435)
alukoshko 2021-12-01 08:32 |
Hello. Have you tried AlmaLinux 8.5? It has updated kernel. And it would be great to try to reproduce the same on CentOS or RHEL to understand if it's AlmaLinux specific or upstream issue. |
(0000437)
sbhat 2021-12-01 12:01 |
The current OS is Alma 8.4. We haven't tried to reproduce it on centos/rhel since this happens on a zfs storage with large data sets. It doesn't happen on OmniOS though. Anyway, thanks! |
(0000444)
toracat 2021-12-12 18:22 |
Another thing you can do is to test-install ELRepo's kernel-ml. With this, you'll be testing the latest stable kernel from kernel.org. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
187 | [AlmaLinux-8] general | major | always | 2022-02-14 22:59 | 2022-02-14 22:59 |
Reporter: | bhnysu | Platform: | x86-64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | minimal ISO missing rsyslog and plymouth packages from Core package group | ||||
Description: |
AlmaLinux-8.5-x86_64-minimal.iso The above does not include rsyslog and (less importantly) plymouth RPMs which are listed as mandatory for the 'core' package group. The core group is mandatory for the 'minimal-environment' group, which I would expect the minimal.iso to be able to fully install. I gather this is due to those packages being in the Appstream repo and the minimal iso including only the BaseOS repo. But nonetheless I think rsyslog would be an expected part of any minimal install. Plymouth not as much. |
||||
Tags: | installation, minimal-install | ||||
Steps To Reproduce: |
Install from AlmaLinux-8.5-x86_64-minimal.iso After installing, find that rsyslog (and plymouth) are not present in the system. |
||||
Additional Information: |
Simply doing dnf install group minimal-environment after the fact will pull in the missing packages but that shouldn't be necessary. |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
185 | [AlmaLinux-8] gnome-shell | major | always | 2022-02-09 01:39 | 2022-02-09 01:39 |
Reporter: | amcrae42 | Platform: | x86_64 | ||
Assigned To: | OS: | Almalinux | |||
Priority: | high | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Severe memory leak eventually causes processes to hang/crash | ||||
Description: |
top shows gnome-shell grows over time until swap starts to get used up. Difficult to say what I am doing that causes it. I am using Xwayland. I have to logout/in every 2-3 days to reset the memory use. I am using three screens over two graphics cards if that is relevant. System patched to current yum update. Probably caused by a relatively recent update. Did not have problems last year (Dec 2021). |
||||
Tags: | |||||
Steps To Reproduce: | Run logged in session. Run top. | ||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
125 | [AlmaLinux-8] -OTHER | minor | N/A | 2021-09-02 20:59 | 2022-02-07 14:46 |
Reporter: | fdr | Platform: | azure | ||
Assigned To: | OS: | ||||
Priority: | normal | OS Version: | |||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | It's harder to reference images on Azure than necessary | ||||
Description: |
I have a prototype switching from Microsoft's "endorsed" CentOS images from RogueWave/OpenLogic as indicated by the portal's drop-down and https://docs.microsoft.com/en-us/azure/virtual-machines/linux/endorsed-distros to AlmaLinux. It's harder to use AlmaLinux for some reason. With the "endorsed" images, all I need to do is set the ImageReference, https://docs.microsoft.com/en-us/rest/api/compute/virtual-machines/create-or-update#imagereference. With AlmaLinux, I need to do two more things: Most annoyingly, I need to enable AlmaLinux on my subscriptions at https://portal.azure.com/#blade/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/almalinux.almalinux/product/. This is troublesome when setting up new subscriptions. Also the error message given by Azure to do this is not very good. Secondly, the API call needs more stuff in it, namely, the "Plan" field: (https://docs.microsoft.com/en-us/rest/api/compute/virtual-machines/create-or-update#plan). Neither are necessary with the "endorsed" CentOS images. |
||||
Tags: | azure, cloud | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000330)
fdr 2021-09-03 18:40 |
I was messing around with my API calls and it seems there is some way to make a non-marketplace image "offer": "Creating a virtual machine from a non-Marketplace image does not need Plan information. Please remove the Plan information from VM..." |
(0000487)
abo1787 2022-02-07 14:46 |
Thanks for reporting this one we're hitting this one here with our automated pipelines. Were hoping it would be a simple swap from centos to alma, but have to rebuild off alma base image instead of converting. Hope this helps as a plus 1 to this ticket as I cannot find a way to do so. Also Azure support sent me this way, there may be other coming, and maybe they see this comment. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
183 | [AlmaLinux-8] open-vm-tools | major | always | 2022-02-07 08:35 | 2022-02-07 08:41 |
Reporter: | Mover | Platform: | AMD Ryzen 7 4800U with Radeon | ||
Assigned To: | OS: | Windows 10 专业工作站版 | |||
Priority: | urgent | OS Version: | 21H2 v19044.1387 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Copy file from win10 to almalinux have bug | ||||
Description: |
很高兴贵公司开发了如此优秀而且免费的Linux,他非常稳定非常实用和华丽,谢谢。同时我也很机智,继centos后,在RockyLinux 与AlmaLinux与openEuler与openAnolis中选择了AlmaLinux,哈哈。AlmaLinux太过于完美,这不得使我介绍给我的 同学 学校 老师 网友 朋友。 我把AlmaLinux通过VMware16 Pro安装到了电脑,在使用过程中想要复制文件到虚拟机,这似乎是件很平常的事,但是在AlmaLinux中失败了,我尝试重新安装了open-vm-tools也是不可以,依然显示错误。但是可以从AlmaLinux复制文件到Windows10. I am very pleased that your company developed such excellent and free Linux, it is very stable, very useful and gorgeous, thank you. I chose AlmaLinux between RockyLinux and AlmaLinux and openEuler and openAnolis after centos. AlmaLinux is too perfect for me to introduce to my classmates, school teachers, online friends. I installed AlmaLinux on my computer using VMware16 Pro and it seems to be normal to try to copy files to the virtual machine during use, but it failed in AlmaLinux and I tried to reinstall open-vm-tools and it still failed. But you can copy files from AlmaLinux to Windows10. |
||||
Tags: | open-vm-tools | ||||
Steps To Reproduce: |
复制任意文件到虚拟机AlmaLinux即可复现 Copy any file to virtual machine AlmaLinux |
||||
Additional Information: | |||||
Attached Files: |
QQ截图20220207163530.png (39,021 bytes) 2022-02-07 08:35 https://bugs.almalinux.org/file_download.php?file_id=113&type=bug QQ图片20220207155021.png (173,652 bytes) 2022-02-07 08:35 https://bugs.almalinux.org/file_download.php?file_id=114&type=bug |
||||
Notes | |
(0000486)
Mover 2022-02-07 08:41 |
I make a video show error :AlmaLinux copy file error.mp4 url:https://hub.ficc.cc/hub2/video/AlmaLinux%20copy%20file%20error.mp4?preview |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
182 | [AlmaLinux-8] -OTHER | minor | always | 2022-02-04 19:42 | 2022-02-04 19:42 |
Reporter: | gtb | Platform: | x86_64 | ||
Assigned To: | OS: | Alma | |||
Priority: | normal | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Almalinux devel repo causes mock install failures | ||||
Description: |
Running mock (on a Fedora system with the latest mock-core-configs) and enabling the devel repo in almalinux (necessary to build some software) results in uninstallable packages due to conflicts. |
||||
Tags: | |||||
Steps To Reproduce: |
mock --root /etc/mock/alma+epel-8-x86_64.cfg --enablerepo=devel install perl-IO-Socket-INET6 |
||||
Additional Information: |
Expected result: perl-IO-Socket-INET6 installed Actual result: Error: Problem: package perl-IO-Socket-INET6-2.72-12.module_el8.3.0+2009+2dd00f05.noarch requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - cannot install the best candidate for the job - package perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 is filtered out by modular filtering (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) I am not sure if this is an issue with mock, the mock core configs, or the alma repo, but the equivalent request works with the centos-stream+epel-next-8 mock cfg (i.e. mock --root /etc/mock/centos-stream+epel-next-8-x86_64.cfg --enablerepo=Stream-Devel install perl-IO-Socket-INET6 ) |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
181 | [AlmaLinux-8] grub2 | major | always | 2022-02-01 14:19 | 2022-02-01 14:19 |
Reporter: | spomata | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | grub.cfg generated under /boot/efi/EFI/centos | ||||
Description: |
While upgrading from CentOS 7 to Alma Linux 8 through the leapp/elevate solution, during the initrd phase the grub.cfg file will be generated under the centos EFI directory rather than under almalinux causing the successive reboot to fail. Booting with a usb stick and copying the file to the proper location will allow to boot correctly using the "insmod blscfg" method as per the autogenerated grub.cfg file. Mattermost link: https://chat.almalinux.org/almalinux/pl/gae885ubfjbu7bmwxpspitj73r |
||||
Tags: | elevate, grub, leapp | ||||
Steps To Reproduce: |
- Start from a CentOS 7.9.2009 - Install leapp and elevate packages for migration to AlmaLinux - Complete the migration process |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
180 | [AlmaLinux-8] libselinux | minor | always | 2022-02-01 10:12 | 2022-02-01 10:12 |
Reporter: | p-fruck | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | selinux python bindings missing for python3.9 | ||||
Description: |
Not quite sure whether this is on purpose, but when using python 3.6 the selinux bindings are preinstalled whereas when using python 3.9 they are not. I'd love to see python-selinux bindings for python 3.9 out of the box. |
||||
Tags: | python, selinux | ||||
Steps To Reproduce: |
# Make sure both python versions are installed sudo dnf install python36 python39 # Check for selinux packages with python 3.9, no output is returned for me /usr/bin/pip3.9 freeze | grep '^se' # Check for selinux packages with python 3.6, the below output is returned for me /usr/bin/pip3.6 freeze | grep '^se' selinux==2.9 sepolicy==1.1 setools==4.3.0 setroubleshoot==1.1 |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
179 | [AlmaLinux-8] jq | minor | always | 2022-01-24 22:18 | 2022-01-25 07:55 |
Reporter: | Znuff | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | jq doesn't depend on libonig | ||||
Description: |
[root@cpdev ~]# yum install jq Last metadata expiration check: 1:31:16 ago on Mon 24 Jan 2022 10:41:39 PM EET. Dependencies resolved. =========================================================================================================================================================================================================================================================================================================================================================================== Package Architecture Version Repository Size =========================================================================================================================================================================================================================================================================================================================================================================== Installing: jq x86_64 1.5-12.el8 appstream 161 k Transaction Summary =========================================================================================================================================================================================================================================================================================================================================================================== Install 1 Package Total download size: 161 k Installed size: 359 k Is this ok [y/N]: y Downloading Packages: jq-1.5-12.el8.x86_64.rpm 3.6 MB/s | 161 kB 00:00 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 212 kB/s | 161 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : jq-1.5-12.el8.x86_64 1/1 Running scriptlet: jq-1.5-12.el8.x86_64 1/1 Verifying : jq-1.5-12.el8.x86_64 1/1 Installed: jq-1.5-12.el8.x86_64 Complete! [root@cpdev ~]# jq .user.allow.json jq: error while loading shared libraries: libonig.so.5: cannot open shared object file: No such file or directory |
||||
Tags: | |||||
Steps To Reproduce: |
- yum install jq - no libonig being installed - jq will complain about missing libonig |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000483)
alukoshko 2022-01-25 07:55 |
Hi. How to reproduce this? For me jq is installing with dependency: sh-4.4# dnf install jq AlmaLinux 8 - BaseOS 1.8 MB/s | 5.8 MB 00:03 AlmaLinux 8 - AppStream 1.9 MB/s | 8.7 MB 00:04 AlmaLinux 8 - Extras 9.6 kB/s | 12 kB 00:01 Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing: jq x86_64 1.5-12.el8 appstream 161 k Installing dependencies: oniguruma x86_64 6.8.2-2.el8 appstream 187 k Transaction Summary ================================================================================ Install 2 Packages Total download size: 348 k Installed size: 1.0 M Is this ok [y/N]: y Downloading Packages: (1/2): jq-1.5-12.el8.x86_64.rpm 321 kB/s | 161 kB 00:00 (2/2): oniguruma-6.8.2-2.el8.x86_64.rpm 319 kB/s | 187 kB 00:00 -------------------------------------------------------------------------------- Total 287 kB/s | 348 kB 00:01 ... sh-4.4# jq . 1.json { "name": "John", "age": 30, "car": null } |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
176 | [AlmaLinux-8] rsync | major | always | 2022-01-22 18:11 | 2022-01-24 10:05 |
Reporter: | slayerduck | Platform: | |||
Assigned To: | OS: | Almalinux | |||
Priority: | urgent | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Rsync memleak percpu | ||||
Description: |
I’m using lsyncd to keep folders up to date between servers. This calls upon rsync and thus I’m doing a lot of rsyncs, a couple 1000 per hour. After upgrading from C8 to Almalinux my ram is filling up on destination servers and that eventually crashes the entire server. When i check /proc/meminfo the “percpu” is the one that fills up. I tried swtiching kernel to elrepo’s and this did not fix the issue. It has to be some lib that was replaced when i converted. I can reproduce this on all servers i update to alma, the more rsyncs i do the faster it fills up. Cloudlinux also has the issue. Munin mem attached of two production servers, one was actually crashed the other one with 256GB ram nearly when this issue was found. |
||||
Tags: | |||||
Steps To Reproduce: |
#! /bin/bash # Example test for percpu/rsync memleak. Needs two servers, source can be any linux with rsync. Destination with CD or Alma will leak percpu. # Can reproduce in Cloudlinux and AlmaLinux # STEP 1: Generate random files for rsync. CD into any empty DIR workdir=/opt/test3/ cd $workdir for n in {1..5000}; do dd if=/dev/urandom of=file$( printf %03d "$n" ).bin bs=1 count=$(( RANDOM + 1024 )) done # STEP 2: Generate SSH keys and make sure you can SSH into remote machine (Alma or Cloud) ls $workdir | xargs -n1 -P10 -I% rsync -Pa % 192.168.0.212:$workdir # Open new window, check: cat /proc/meminfo | grep Percpu # running rm -rf on dir with tranfered files will lower Percpu again. Otherwise no other way i know of so far to reduce mem besides reboot. Dropping caches does not work. |
||||
Additional Information: | |||||
Attached Files: |
memory-week.png (48,859 bytes) 2022-01-22 18:11 https://bugs.almalinux.org/file_download.php?file_id=111&type=bug memory-week-crashed.png (54,778 bytes) 2022-01-22 18:11 https://bugs.almalinux.org/file_download.php?file_id=112&type=bug |
||||
Notes | |
(0000480)
alukoshko 2022-01-24 08:40 |
Hello. Have you tried the same with RHEL or CentOS 8.5? |
(0000481)
slayerduck 2022-01-24 10:05 |
I have today, and rhel 8.5 is showing the same symptoms. If i replace rsync with scp the bug occurs still to. So this doesn't seem like an rsync issue. It also seems like it takes some time for it to go all the way up, if i try to do it on a small VM with 2gb ram it fills up the whole server then somehow does drops back down. So it might only be an issue with machines with larger amounts of ram or over a longer time. scp or rsyncing 100k files/2gb data with 8 threads, server with 128GB ram: Percpu: 8447616 kB |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
178 | [AlmaLinux-8] -OTHER | trivial | have not tried | 2022-01-24 02:12 | 2022-01-24 02:12 |
Reporter: | d1ng1383rry | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Total system RAM differs | ||||
Description: |
When using free -m Centos7 shows 32009 total AlmaLinux 8.5 shows 31890 total Same system, standalone installations within 24 hours of each other. Wouldn't have caught it, but server software I was installing does a RAM check and refuses to work on AL 8.5, so had to go back to CentOS on that machine. |
||||
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: |
177 | [AlmaLinux-8] almalinux-release | minor | always | 2022-01-22 21:15 | 2022-01-22 21:15 |
Reporter: | ayuri | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | don't include repo config into release package | ||||
Description: |
Project states it's 1:1 compatible with CentOS while the first and foremost important package is obviously not. It includes hard-coded repos instead of doing what CentOS does (which is absolutely the right thing) of depending on another package that in its turn supplies the repo info. Why you came up with this "brilliant" idea is beyond me. We customize our repos and don't use "upstream" URIs to fetch the repo info, as we sync from our repo server to avoid unnecessary hassle and to have special configuration like repo priority settings. |
||||
Tags: | |||||
Steps To Reproduce: |
# rpm -qR centos-linux-release |grep repo | head -1 centos-repos(8) # # rpm -qlv centos-linux-release |grep yum.repo # # rpm -qlv -p almalinux-release-8.5-4.el8.x86_64.rpm |grep yum.repo warning: almalinux-release-8.5-4.el8.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID c21ad6ea: NOKEY -rw-r--r-- 1 root root 951 Dec 21 19:51 /etc/yum.repos.d/almalinux-ha.repo -rw-r--r-- 1 root root 893 Dec 21 19:51 /etc/yum.repos.d/almalinux-plus.repo -rw-r--r-- 1 root root 971 Dec 21 19:51 /etc/yum.repos.d/almalinux-powertools.repo -rw-r--r-- 1 root root 1049 Dec 21 19:51 /etc/yum.repos.d/almalinux-resilientstorage.repo -rw-r--r-- 1 root root 2690 Dec 21 19:51 /etc/yum.repos.d/almalinux.repo # |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
174 | [AlmaLinux-8] -OTHER | trivial | always | 2022-01-17 15:01 | 2022-01-18 16:51 |
Reporter: | adstak | Platform: | |||
Assigned To: | OS: | AlmaLinux | |||
Priority: | low | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | I believe I have found an miss assigned ID in the updateinfo in the BaseOs repo | ||||
Description: |
So long story short as this is either an easy fix or intended and I simply miss understand. So we have a a tool I wrote at my company which parses updateinfo in the repo and reports security info to a central place for patch reporting etc. As part of this I recently added alma info as we moved away from centos. As part of this I stumbled across the id --> ALBA-2019:3693 This seems to be labelled ALBA in the updateinfo but from my understanding this should be an ALSA as it applies a fix for CVE-2018-18074 going from its own description. My understanding to add context is ALBA is the Alma Linux Bug Announce and ALSA is the ALMA Linux Security Announce. ( This is a guess going from centos's CESA and other updateinfo formats from other providers) So put simply is ALBA-2019:3693 correct or should this be ALSA-2019:3693 or does it not matter? |
||||
Tags: | |||||
Steps To Reproduce: | Read the updateinfo file from the BaseOS almalinux8 repo | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000479)
alukoshko 2022-01-18 16:36 |
Hello. ALBA is correct. Original bulletin is RHBA-2019:3693 - Bug Fix Advisory https://access.redhat.com/errata/RHBA-2019:3693 This update doesn't fix vulnerability. It fixes bug that was added in previous security update of this package. So it's bugfix release. Bug fix: The fix CVE-2018-18074 leads to a regression (BZ#1758261) |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
171 | [AlmaLinux-8] dnf | minor | always | 2022-01-05 13:47 | 2022-01-14 09:48 |
Reporter: | mvrk | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Unable to lock release version | ||||
Description: |
I'm unable to lock release version. I tried with different ways: 1 - echo "8.4" > /etc/dnf/vars/releasever 2 - Modify the /etc/dnf.conf and add distroverpkg=8.4 to main section Every time i run dnf upgrade i still get all packages updates to 8.5 If i run: python3 -c 'import dnf, json; db = dnf.dnf.Base(); print(json.dumps(db.conf.substitutions, indent=2))' Always shows 8 instead of 8.4: { "arch": "x86_64", "basearch": "x86_64", "releasever": "8" } I also tried with: dnf --releasever=8.4 upgrade but i still get the 8.5 packages. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000477)
eabdullin 2022-01-14 09:48 |
Hello. Thank you, for your question. It is expected behavior, version 8.4 is no longer supported because 8.5 is released. If you want to use 8.4, you can uncomment and change 'baseurl' in config files from '/etc/yum.repos.d/' to 'https://repo.almalinux.org/vault/8.4/{BaseOS\AppStream\etc}/{x86_64\aarch64}/os', and comment 'mirrorlist' line. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
167 | [AlmaLinux-8] -OTHER | major | always | 2021-12-31 09:38 | 2022-01-11 18:17 |
Reporter: | sabas3dgh | Platform: | X86_64 | ||
Assigned To: | OS: | Amlalinux | |||
Priority: | immediate | OS Version: | 8 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | rtl8192eu (USB WIFI Dongle) drivers - DKMS build - From Github - Fails [related Bug_ID 0000047] | ||||
Description: |
============================ Linux localhost.localdomain 4.18.0-348.7.1.el8_5.x86_64 #1 SMP Tue Dec 21 13:57:48 EST 2021 x86_64 x86_64 x86_64 GNU/Linux AlmaLinux release 8.5 (Arctic Sphynx) ============================= rtl8192eu (USB WIFI Dongle) drivers - DKMS build - From Github - Fails I used the modified driver repository and I can't build the driver/module; → make make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/4.18.0-348.7.1.el8_5.x86_64/build M=/home/admin/Downloads/rtl8192eu-linux-driver modules make[1]: Entering directory '/usr/src/kernels/4.18.0-348.7.1.el8_5.x86_64' CC [M] /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.o In file included from /home/admin/Downloads/rtl8192eu-linux-driver/include/drv_types.h:30, from /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c:17: /home/admin/Downloads/rtl8192eu-linux-driver/include/wifi.h:1038: warning: "IEEE80211_MAX_AMPDU_BUF" redefined #define IEEE80211_MAX_AMPDU_BUF 0x40 In file included from /home/admin/Downloads/rtl8192eu-linux-driver/include/osdep_service_linux.h:83, from /home/admin/Downloads/rtl8192eu-linux-driver/include/osdep_service.h:50, from /home/admin/Downloads/rtl8192eu-linux-driver/include/drv_types.h:27, from /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c:17: ./include/linux/ieee80211.h:1660: note: this is the location of the previous definition #define IEEE80211_MAX_AMPDU_BUF 0x100 /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c: In function ‘rtw_cfg80211_ch_switch_notify’: /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c:445:3: error: too few arguments to function ‘cfg80211_ch_switch_started_notify’ cfg80211_ch_switch_started_notify(adapter->pnetdev, &chdef, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/admin/Downloads/rtl8192eu-linux-driver/include/osdep_service_linux.h:93, from /home/admin/Downloads/rtl8192eu-linux-driver/include/osdep_service.h:50, from /home/admin/Downloads/rtl8192eu-linux-driver/include/drv_types.h:27, from /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c:17: ./include/net/cfg80211.h:7673:6: note: declared here void cfg80211_ch_switch_started_notify(struct net_device *dev, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c: At top level: /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c:9952:3: error: ‘struct cfg80211_ops’ has no member named ‘mgmt_frame_register’ .mgmt_frame_register = cfg80211_rtw_mgmt_frame_register, ^~~~~~~~~~~~~~~~~~~ /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c:9952:25: error: initialization of ‘int (*)(struct wiphy *, struct wireless_dev *, u64)’ {aka ‘int (*)(struct wiphy *, struct wireless_dev *, long long unsigned int)’} from incompatible pointer type ‘void (*)(struct wiphy *, struct wireless_dev *, u16, bool)’ {aka ‘void (*)(struct wiphy *, struct wireless_dev *, short unsigned int, _Bool)’} [-Werror=incompatible-pointer-types] .mgmt_frame_register = cfg80211_rtw_mgmt_frame_register, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.c:9952:25: note: (near initialization for ‘rtw_cfg80211_ops.mgmt_tx_cancel_wait’) cc1: some warnings being treated as errors make[2]: *** [scripts/Makefile.build:316: /home/admin/Downloads/rtl8192eu-linux-driver/os_dep/linux/ioctl_cfg80211.o] Error 1 make[1]: *** [Makefile:1571: _module_/home/admin/Downloads/rtl8192eu-linux-driver] Error 2 make[1]: Leaving directory '/usr/src/kernels/4 the same error (more or less would happen when building from original repositories) |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: |
related to this bug https://bugs.almalinux.org/view.php?id=47 lsusb: >>> [87939.234099] Code: 1f 44 00 00 f3 0f 1e fa 55 48 89 f5 53 48 89 fb 48 83 ec 08 e8 4b ff ff ff 48 8b 3b 48 89 c6 e8 e0 a7 f8 ff 48 89 ee 48 89 df <48> 8b 40 10 48 83 c4 08 5b 5d ff e0 66 66 2e 0f 1f 84 00 00 00 00 [301735.457109] usb 7-1: USB disconnect, device number 2 [301742.027067] usb 2-3: new high-speed USB device number 4 using ehci-pci [301742.157244] usb 2-3: New USB device found, idVendor=2357, idProduct=0109, bcdDevice= 2.00 [301742.157249] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [301742.157253] usb 2-3: Product: 802.11n NIC [301742.157256] usb 2-3: Manufacturer: Realtek [301742.157258] usb 2-3: SerialNumber: 00e04c000001 [301742.636990] usb 2-3: Vendor: Realtek [301742.636993] usb 2-3: Product: 802.11n NI [301742.636994] usb 2-3: Serial: [301742.636996] usb 2-3: rtl8192eu_parse_efuse: dumping efuse (0x200 bytes): [301742.636998] usb 2-3: 00: 29 81 00 7c 01 40 03 00 [301742.637000] usb 2-3: 08: 40 74 04 50 14 00 00 00 [301742.637013] usb 2-3: 10: 27 27 28 29 29 29 2b 2b [301742.637014] usb 2-3: 18: 2b 2c 2c f2 ef ef ff ff [301742.637016] usb 2-3: 20: ff ff ff ff ff ff ff ff [301742.637017] usb 2-3: 28: ff ff ff ff ff ff ff ff [301742.637018] usb 2-3: 30: ff ff ff ff ff ff ff ff [301742.637020] usb 2-3: 38: ff ff 2b 2b 2b 2b 2b 2b [301742.637021] usb 2-3: 40: 2d 2d 2d 2c 2c f2 ef ef [301742.637023] usb 2-3: 48: ff ff ff ff ff ff ff ff [301742.637025] usb 2-3: 50: ff ff ff ff ff ff ff ff [301742.637026] usb 2-3: 58: ff ff ff ff ff ff ff ff [301742.637027] usb 2-3: 60: ff ff ff ff ff ff ff ff [301742.637029] usb 2-3: 68: ff ff ff ff ff ff ff ff [301742.637030] usb 2-3: 70: ff ff ff ff ff ff ff ff [301742.637032] usb 2-3: 78: ff ff ff ff ff ff ff ff [301742.637033] usb 2-3: 80: ff ff ff ff ff ff ff ff [301742.637035] usb 2-3: 88: ff ff ff ff ff ff ff ff [301742.637036] usb 2-3: 90: ff ff ff ff ff ff ff ff [301742.637038] usb 2-3: 98: ff ff ff ff ff ff ff ff [301742.637039] usb 2-3: a0: ff ff ff ff ff ff ff ff [301742.637041] usb 2-3: a8: ff ff ff ff ff ff ff ff [301742.637042] usb 2-3: b0: ff ff ff ff ff ff ff ff [301742.637044] usb 2-3: b8: a1 1f 1e 00 00 00 ff ff [301742.637045] usb 2-3: c0: ff 01 00 10 00 00 00 ff [301742.637047] usb 2-3: c8: 00 00 ff ff ff ff ff ff [301742.637048] usb 2-3: d0: 57 23 09 01 e7 47 02 50 [301742.637049] usb 2-3: d8: 3e aa 83 f2 4b 0a 03 52 [301742.637051] usb 2-3: e0: 65 61 6c 74 65 6b 20 0e [301742.637052] usb 2-3: e8: 03 38 30 32 2e 31 31 6e [301742.637054] usb 2-3: f0: 20 4e 49 43 20 00 00 ff [301742.637055] usb 2-3: f8: ff ff ff ff ff ff ff ff [301742.637057] usb 2-3: 100: ff ff ff ff ff ff ff ff [301742.637058] usb 2-3: 108: ff ff ff ff ff ff ff ff [301742.637060] usb 2-3: 110: ff ff ff ff ff ff ff 0d [301742.637061] usb 2-3: 118: 03 00 05 00 30 00 00 00 [301742.637063] usb 2-3: 120: 00 93 ff ff ff ff ff ff [301742.637064] usb 2-3: 128: ff ff ff ff ff ff ff ff [301742.637066] usb 2-3: 130: f6 a8 98 2d 03 92 98 00 [301742.637067] usb 2-3: 138: fc 8c 00 11 9b 44 02 0a [301742.637069] usb 2-3: 140: ff ff ff ff ff ff ff ff [301742.637070] usb 2-3: 148: ff ff ff ff ff ff ff ff [301742.637072] usb 2-3: 150: ff ff ff ff ff ff ff ff [301742.637073] usb 2-3: 158: ff ff ff ff ff ff ff ff [301742.637074] usb 2-3: 160: ff ff ff ff ff ff ff ff [301742.637076] usb 2-3: 168: ff ff ff ff ff ff ff ff [301742.637077] usb 2-3: 170: ff ff ff ff ff ff ff ff [301742.637079] usb 2-3: 178: ff ff ff ff ff ff ff ff [301742.637080] usb 2-3: 180: ff ff ff ff ff ff ff ff [301742.637082] usb 2-3: 188: ff ff ff ff ff ff ff ff [301742.637083] usb 2-3: 190: ff ff ff ff ff ff ff ff [301742.637085] usb 2-3: 198: ff ff ff ff ff ff ff ff [301742.637086] usb 2-3: 1a0: ff ff ff ff ff ff ff ff [301742.637088] usb 2-3: 1a8: ff ff ff ff ff ff ff ff [301742.637089] usb 2-3: 1b0: ff ff ff ff ff ff ff ff [301742.637091] usb 2-3: 1b8: ff ff ff ff ff ff ff ff [301742.637093] usb 2-3: 1c0: ff ff ff ff ff ff ff ff [301742.637094] usb 2-3: 1c8: ff ff ff ff ff ff ff ff [301742.637096] usb 2-3: 1d0: ff ff ff ff ff ff ff ff [301742.637097] usb 2-3: 1d8: ff ff ff ff ff ff ff ff [301742.637098] usb 2-3: 1e0: ff ff ff ff ff ff ff ff [301742.637100] usb 2-3: 1e8: ff ff ff ff ff ff ff ff [301742.637101] usb 2-3: 1f0: ff ff ff ff ff ff ff ff [301742.637103] usb 2-3: 1f8: ff ff ff ff ff ff ff ff [301742.637106] usb 2-3: RTL8192EU rev B (SMIC) 2T2R, TX queues 3, WiFi=1, BT=0, GPS=0, HI PA=0 [301742.637108] usb 2-3: RTL8192EU MAC: 50:3e:aa:83:f2:4b [301742.637110] usb 2-3: rtl8xxxu: Loading firmware rtlwifi/rtl8192eu_nic.bin [301742.664017] usb 2-3: Firmware revision 19.0 (signature 0x92e1) [301743.708628] usbcore: registered new interface driver rtl8xxxu [301743.777950] rtl8xxxu 2-3:1.0 wlp0s29f7u3: renamed from wlan0 [301743.806331] IPv6: ADDRCONF(NETDEV_UP): wlp0s29f7u3: link is not ready [301743.840926] IPv6: ADDRCONF(NETDEV_UP): wlp0s29f7u3: link is not ready [301743.946174] IPv6: ADDRCONF(NETDEV_UP): wlp0s29f7u3: link is not ready [301743.966340] IPv6: ADDRCONF(NETDEV_UP): wlp0s29f7u3: link is not ready [301745.272812] IPv6: ADDRCONF(NETDEV_UP): wlp0s29f7u3: link is not ready [301746.480838] wlp0s29f7u3: authenticate with 5c:6a:80:48:ea:d8 [301746.505111] wlp0s29f7u3: send auth to 5c:6a:80:48:ea:d8 (try 1/3) [301746.712442] wlp0s29f7u3: send auth to 5c:6a:80:48:ea:d8 (try 2/3) [301746.920260] wlp0s29f7u3: send auth to 5c:6a:80:48:ea:d8 (try 3/3) [301747.128056] wlp0s29f7u3: authentication with 5c:6a:80:48:ea:d8 timed out [301748.624730] wlp0s29f7u3: authenticate with 5c:6a:80:48:ea:d8 [301748.651316] wlp0s29f7u3: send auth to 5c:6a:80:48:ea:d8 (try 1/3) [301748.856053] wlp0s29f7u3: send auth to 5c:6a:80:48:ea:d8 (try 2/3) [301749.065199] wlp0s29f7u3: send auth to 5c:6a:80:48:ea:d8 (try 3/3) [301749.273067] wlp0s29f7u3: authentication with 5c:6a:80:48:ea:d8 timed out |
||||
Attached Files: |
rtl8192eu.patch (1,258 bytes) 2022-01-02 20:07 https://bugs.almalinux.org/file_download.php?file_id=110&type=bug |
||||
Notes | |
(0000467)
sabas3dgh 2021-12-31 16:00 |
it seems that it won't build under 4.18 alma linux kernel. Need a fix; thanks. |
(0000469)
toracat 2022-01-02 20:07 |
@sabas3dgh I uploaded a patch file that will allow compiling the code. I don't have the relevant device, so have no idea if the driver actually works. |
(0000476)
toracat 2022-01-11 18:17 |
@sabas3dgh Did the patch work? If so, could you confirm it so that this ticket can be closed as 'resolved'? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
172 | [AlmaLinux-8] dnf | minor | always | 2022-01-06 06:17 | 2022-01-06 06:17 |
Reporter: | kfujinaga | Platform: | XenServer | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Did not update grub.cfg automatically after kernel update in AlmaLinux 8.5 | ||||
Description: |
In the AlmaLinux 8.5 enviroment created from 8.5 install media, I executed "dnf upgrade". In this action, new kernel "4.18.0-348.7.1.el8_5.x86_64" was installed. But /boot/grub2/grub.cfg was not updated. If I execute "grub2-mkconfig -o /boot/grub2/grub.cfg" manually, boot/grub2/grub.cfg is updated. I can not find this problem in AlmaLinux 8.4, |
||||
Tags: | |||||
Steps To Reproduce: |
1. Install AlmaLinux 8.5 (AlmaLinux-8.5-x86_64-dvd.iso, Server(GUI) mode) 2. Check kernel version # uname -r 4.18.0-348.el8.x86_64 # rpm -qa |grep kernel |sort kernel-4.18.0-348.el8.x86_64 kernel-core-4.18.0-348.el8.x86_64 kernel-modules-4.18.0-348.el8.x86_64 kernel-tools-4.18.0-348.el8.x86_64 kernel-tools-libs-4.18.0-348.el8.x86_64 2. Check boot settings. (grubby) # grubby --info=ALL | grep -E "^kernel|^index" index=0 kernel="/boot/vmlinuz-4.18.0-348.el8.x86_64" index=1 kernel="/boot/vmlinuz-0-rescue-f2cfcd79b1db49188a987dffe9c4ee73" (grub.cfg) # grep "^menuentry" /boot/grub2/grub.cfg menuentry 'AlmaLinux (4.18.0-348.el8.x86_64) 8.5 (Arctic Sphynx)' --class almalinux --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.18.0-348.el8.x86_64-advanced-9a24da02-c767-4dad-a0f4-05bbd22909c7' { menuentry 'AlmaLinux (0-rescue-f2cfcd79b1db49188a987dffe9c4ee73) 8.5 (Arctic Sphynx)' --class almalinux --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-f2cfcd79b1db49188a987dffe9c4ee73-advanced-9a24da02-c767-4dad-a0f4-05bbd22909c7' { 4. system update (kernel "4.18.0-348.7.1.el8_5.x86_64" was installed) Update all packages. # dnf upgrade 5. check kernel verson kernel 4.18.0-348.7.1.el8_5.x86_64 was installed. # uname -r 4.18.0-348.el8.x86_64 # rpm -qa |grep kernel |sort kernel-4.18.0-348.7.1.el8_5.x86_64 kernel-4.18.0-348.el8.x86_64 kernel-core-4.18.0-348.7.1.el8_5.x86_64 kernel-core-4.18.0-348.el8.x86_64 kernel-modules-4.18.0-348.7.1.el8_5.x86_64 kernel-modules-4.18.0-348.el8.x86_64 kernel-tools-4.18.0-348.7.1.el8_5.x86_64 kernel-tools-libs-4.18.0-348.7.1.el8_5.x86_64 6. Check boot settings. gubby return new setting, but grub.conf was not updated. (grubby) # grubby --info=ALL | grep -E "^kernel|^index" index=0 kernel="/boot/vmlinuz-4.18.0-348.7.1.el8_5.x86_64" index=1 kernel="/boot/vmlinuz-4.18.0-348.el8.x86_64" index=2 kernel="/boot/vmlinuz-0-rescue-f2cfcd79b1db49188a987dffe9c4ee73" (grub.cfg) # grep "^menuentry" /boot/grub2/grub.cfg menuentry 'AlmaLinux (4.18.0-348.el8.x86_64) 8.5 (Arctic Sphynx)' --class almalinux --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.18.0-348.el8.x86_64-advanced-9a24da02-c767-4dad-a0f4-05bbd22909c7' { menuentry 'AlmaLinux (0-rescue-f2cfcd79b1db49188a987dffe9c4ee73) 8.5 (Arctic Sphynx)' --class almalinux --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-f2cfcd79b1db49188a987dffe9c4ee73-advanced-9a24da02-c767-4dad-a0f4-05bbd22909c7' { 7. Reboot. # reboot 8. Check booted kernel version Old kernel was booted. # uname -r 4.18.0-348.el8.x86_64 |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
57 | [AlmaLinux-8] -OTHER | feature | always | 2021-04-06 16:10 | 2022-01-03 17:56 |
Reporter: | enigma131 | Platform: | Server - Desktop | ||
Assigned To: | OS: | Amalinux | |||
Priority: | normal | OS Version: | 8.3 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | rtl8188eu (USB WIFI Dongle) drivers - build fails- From Github | ||||
Description: |
I have a popular wifi usb dongle (a Realtek TL-WN725N), and I try to make it work under Alama. When i insert dongle after system boot, i got, from dmesg : [ 90.432685] usb 1-5: new high-speed USB device number 7 using xhci_hcd [ 90.559175] usb 1-5: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 [ 90.559176] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 90.559177] usb 1-5: Product: 802.11n NIC [ 90.559178] usb 1-5: Manufacturer: Realtek Since kernel module isn't include in Kernel 4.18, I have try to compile it following this : https://tutorialforlinux.com/2020/06/05/step-by-step-centos-8-realtek-rtl8188eu-driver-installation Then I got error at make stage : /home/alma/rtl8188eu/os_dep/ioctl_linux.c:7814:3: error: « struct iw_handler_def » no member « private » .private = rtw_private_handler, ^~~~~~~ I it possible to make it work ? I need to transfer the internet trafic to the dongle and use RJ45 for the server part. |
||||
Tags: | not-a-bug | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: |
dmesg (69,610 bytes) 2021-04-07 11:19 https://bugs.almalinux.org/file_download.php?file_id=70&type=bug |
||||
Notes | |
(0000127)
alukoshko 2021-04-06 17:13 |
Hello. Have a look at the following issue: https://github.com/lwfinger/rtl8188eu/issues/302 Looks like it's impossible with stock kernel. |
(0000128)
enigma131 2021-04-06 17:35 |
Hi, yes I see, the author don't seems want to make changes for CentOs 8 series.. I have found a other github here : https://github.com/aircrack-ng/rtl8188eus I will try it tomorrow and tell you informed |
(0000131)
enigma131 2021-04-07 11:19 |
I've tested the aircrak one, I had to modify 3 files: grep -r almalinux os_dep/linux/rtw_android.c:#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 18, 0)) // almalinux ex 5,0 os_dep/linux/os_intfs.c: #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 18, 0) // almalinux ex 4,19 core/rtw_mlme_ext.c: /* fallthrough */ // almalinux And after then it compiles and isntalls: lsmod | grep 80211 cfg80211 806912 1 8188eu rfkill 28672 4 cfg80211 But there is a but. After inserting the usb dongle, i get error message in dmesg and no wifi, see attached file at the end |
(0000134)
enigma131 2021-04-08 16:45 |
So if I understand well, there is no way to correct this ? I'm frustrating because this dongle is working everywhere else ( Debian 11, Ubuntu 20.04, Fedora 33, Windows 10 ...) without compiling / installing a piece of code / driver. My understanding for solving the issue : changing kernel or changing dongle. 1) In case of changing dongle, where could I find certified hardware compatibility list ? 2) In case of changing kernel, which one would be a good target ? (I don't want a 'rolling' type kernel, I'm searching a LTS type which doesn't increment each week) . And according to https://www.kernel.org/category/releases.html, standard kernel LTS have EOL previous to 2029. |
(0000135)
alukoshko 2021-04-08 16:50 |
1) We're compatible with RHEL8 so supported hardware is the same: https://catalog.redhat.com/hardware 2) http://elrepo.org provides newer kernels for RHEL-based distros. I believe kernel-lt (Long Term) package will fit your needs. |
(0000136)
enigma131 2021-04-08 17:25 |
This one gives only 1 response https://catalog.redhat.com/hardware/components/search?q=wifi&p=1 and seems not really a dongle. I think a internet search engine will give better responses, or Redhat have definitivelly bad wifi support (it's possible!). I will continue to search this way, but I don't want buy and buy without be sure of result. I will look too for elrepo and kernels, thanks for the trick! |
(0000137)
enigma131 2021-04-09 07:42 |
Following your link http://elrepo.org/tiki/HomePage , I discover "latest stable mainline kernels" . Are theses related to my link from kernel.org? If yes I don't see the real benefit over Debian , because I'm searching a long term Kernel like the one from Redhat (4.18) -> support up to 2019. Concerning searching a other Wifi dongle, i discover the other thread you have solved https://bugs.almalinux.org/view.php?id=47 with rtl8192, I found one here : https://www.amazon.fr/KuWFi-300Mbps-Realtek-RTL8192-Adaptateur/dp/B01D2L1U4S But not sure for me it will work in future for kernel 4.18 and Alma 8.x. (x >=4) Take my example witk rtl8188eu, It was compiling with early stages of CenntOs8 , and now we are at stage 8.3 and compiles fails. |
(0000138)
alukoshko 2021-04-09 07:56 |
Of course if you going to buy another dongle you should buy the one supported out of the box. Unofficial drivers from github are always kind of lottery. kernel-lt from elrepo.org will stay on 5.4 version for long time and then someday will change to 5.10. If you need the same kernel version till 2029 then yes, elrepo's kernel doesn't fit your needs. |
(0000139)
enigma131 2021-04-09 10:39 |
I don't know where are located Alma's kernel sources, but if they are same as Centos I've look at vault's site. In drivers/staging there are 5 Realtek drivers sources including rtl8192 and rtl8188eu's one and no one is working from the begining without compilation/modifications/adaptation ! Strange situation! |
(0000140)
enigma131 2021-04-09 18:12 |
I've finally make it work. How I did it? First I've look with modinfo, all other distros (Fedora, Debian unbuntu) are based on version 4.14 from feb. 2013 and are fully fonctionnal. I'll go back to lwfinger and see 4 branches, including Master. I've git clone branch v4.1.8_9499 (this one is from dec. 2013) Made modifications: os_dep/rtw_android.c:#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 18, 0)) // 5,0 alma line 359 os_dep/os_intfs.c:#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 18, 0)) // 4,19 alma line 419 Then it compiles and WORKS ! Package includes dkms install. ps: branch v5.2.2.4 compiles too but haven't try, but Master and branch kernel_code didn't compile Could be closed, but I would be great if method could be sticked for other peoples (or would it be better to post solution at lwfinger git ?) |
(0000141)
alukoshko 2021-04-09 18:22 |
I've found that elrepo-testing repo contain that driver: http://mirror.rc.usf.edu/elrepo/testing/el8/x86_64/RPMS/kmod-r8188eu-0.0-1.el8_3.elrepo.x86_64.rpm Maybe you should try it too, it won't require dkms. |
(0000142)
enigma131 2021-04-09 19:10 |
Hum this one is stamped with first -240 serie and not with latest -240.15 , so it can't load. It's the problem with testing, compilations are not always made every kernel upgrades. I prefer have a dkms build, until source is compatible with upcoming kernels of course. Thanks for the link in case of ... |
(0000143)
enigma131 2021-04-09 20:07 |
I have added the solution to lwfinger's git bug track 302, but if he don't react i will fork the correct branch on my git. |
(0000156)
toracat 2021-04-23 17:58 |
Please note that ELRepo's kmod packages are kABI-tracking, meaning they survive kernel updates. This is the main point that is different from the dkms method which requires rebuilding upon every kernel update. So, usually kmods are built against the first (GA) kernel of a major release (for example RHEL 8.0) and they should continue to work withing that release (8.x). However there could be a kABI breakage withing a point release. In this case ELRepo will rebuild and update the kmod. If you encounter this situation, you can file a report at their bug tracker, https://elrepo.org/bugs . |
(0000157)
toracat 2021-04-23 18:18 |
@enigma131 By the way why kmod-r8188eu-0.0-1.el8_3.elrepo.x86_64.rpm is in the testing repository is the following. Someone requested to provide a kmod-rtl8188eu package in: https://elrepo.org/bugs/view.php?id=1062#c7541 As you can see, ELRepo fulfilled the request within a day and asked the submitter to test it. However there was no response. Without feedback, the package has to stay in the testing repo. If you could give it a try and report the result, that would be much appreciated. It you'd rather not open an account there, you could reply here, too. |
(0000158)
toracat 2021-04-23 18:20 |
@enigma131 Also, the source code can be found here: https://github.com/elrepo/packages/tree/master/r8188eu-kmod/el8 |
(0000161)
toracat 2021-04-23 21:49 |
OK, I just found out that there was indeed a kABI breakage in RHEL 8 and kmod-r8188eu-0.0-1.el8_3 (which was built for kernel-4.18.0-240.el8) does not work for newer kernels. It will need to be rebuilt against the latest kernel. I will update the status here with any progress. |
(0000162)
enigma131 2021-04-24 06:26 |
Ok toracat, thanks for report. As I'm a Github regitered user, I will try to compile the kmod package next week and report there if error(s). Yes of course it would be great if we can have working kmod modules for our wireless devices for all 8.x kernel updates Concerning DKMS, I was looking at the Lwfinger's source, it is very complete and was (and is still) updated since many years. The branch v4.1.8_9499 is updated now and is fully functionnal now without errors (I had posted there my compile errors). I have some experience concerning dkms and my DVB cards, but no experience for kmod building. |
(0000163)
toracat 2021-04-24 07:39 |
@enigma131 Since you have been successfully building and using the Lwfinger's source, it's probably a good idea for you to stick with it. The kmod method is a better choice [only] when the kABI is stable. It looks to me like the code being used in ELRepo's kmod keeps breaking with kernel updates. In a situation like this, dkms would be the way to go. |
(0000174)
enigma131 2021-04-27 16:38 |
I've tested the kmod driver today: sudo dnf --enablerepo="elrepo-testing" install kmod-r8188eu ... depmod: WARNING: /lib/modules/4.18.0-240.el8.x86_64/extra/r8188eu/r8188eu.ko needs unknown symbol iwe_stream_add_event depmod: WARNING: /lib/modules/4.18.0-240.el8.x86_64/extra/r8188eu/r8188eu.ko needs unknown symbol lib80211_get_crypto_ops depmod: WARNING: /lib/modules/4.18.0-240.el8.x86_64/extra/r8188eu/r8188eu.ko needs unknown symbol wireless_send_event depmod: WARNING: /lib/modules/4.18.0-240.el8.x86_64/extra/r8188eu/r8188eu.ko needs unknown symbol iwe_stream_add_point But installed. Removing dkms, pulled out the dongle, rebooting, then : dmesg -w , Pull in the dongle I got: [ 454.338365] usb 1-5: new high-speed USB device number 8 using xhci_hcd [ 454.464961] usb 1-5: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 [ 454.464963] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 454.464964] usb 1-5: Product: 802.11n NIC [ 454.464965] usb 1-5: Manufacturer: Realtek [ 454.464966] usb 1-5: SerialNumber: 00xxxxxxxx [ 454.479010] r8188eu: loading out-of-tree module taints kernel. [ 454.479156] r8188eu: module verification failed: signature and/or required key missing - tainting kernel [ 454.479267] r8188eu: Unknown symbol iwe_stream_add_event (err 0) [ 454.479442] r8188eu: Unknown symbol lib80211_get_crypto_ops (err 0) [ 454.479476] r8188eu: Unknown symbol wireless_send_event (err 0) [ 454.479529] r8188eu: Unknown symbol iwe_stream_add_point (err 0) Conclusion kmod module did not work , yes. I will post this on Kmod's git next days |
(0000175)
toracat 2021-04-27 16:44 |
Thanks for testing and reporting the result. |
(0000177)
enigma131 2021-04-30 06:37 |
Bug posted on elrepo's Git : https://github.com/elrepo/packages/issues/238 |
(0000189)
enigma131 2021-05-10 11:11 |
Package removed from elrepo, and maintainer didn't want to investigate more work. So DKMS is the only solution that work. |
(0000190)
toracat 2021-05-11 00:38 |
It is not that we (ELRepo) do not want to investigate more work but rather the source code for this particular driver does not make using kmod packages practical. As noted earlier here or in this link: https://github.com/elrepo/packages/issues/238#issuecomment-832336150 I was able to build the kmod package from the source code in the Lwfinger's branch v4.1.8_9499. However it contains many kernel symbols that cause kABI breakage. To take advantage the kmod method, it is critically important the code does not break at each kernel update. There is nothing we (ELrepo) can do about it, unfortunately. |
(0000462)
akdev 2021-12-31 02:34 |
this looks very off-topic for this issue tracker. I presume the linked module never built for RHEL8 to begin with. In any case - the only thing to do is to file an issue with the owner of the github repo. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
168 | [AlmaLinux-8] -OTHER | crash | always | 2022-01-02 15:05 | 2022-01-02 15:05 |
Reporter: | Arbich | Platform: | x86_64 | ||
Assigned To: | OS: | almalinux kde plasma 5 | |||
Priority: | high | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | After updating the KDE Plasma 5 components, the operating system is not loaded. | ||||
Description: |
Installed Almalinux KDE Plasma 5 8.4 on a Lenovo G550 (Core 2 Duo) laptop. Executed a package update in the terminal. The update ended up freezing the laptop. Performed hardreset. Loading the laptop ended with the issuance of a diagnostic message: "The current theme cannot be loaded due to the errors below, please select another theme. file:///usr/share/sddm/themes/01-breeze-fedora/Main.qml:14:1: plugin cannot be loaded for module "org.kde.plasma.core": Cannot load library /usr/lib64/qt5/qml/org/kde/plasma/ core/libcorebindingsplugin.so: (/lib64/libKF5XmlGui.so.5: undefined symbol: _ZN19KeySequenceRecorder16recordingChangedEv)" and laptop freezing. The laptop is not operational at this time. Sorry for the bad english. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: |
IMG_20220101_193052483_m.jpg (452,549 bytes) 2022-01-02 15:05 https://bugs.almalinux.org/file_download.php?file_id=108&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
30 | [AlmaLinux-8] selinux-policy | minor | have not tried | 2021-02-24 21:37 | 2021-12-31 03:05 |
Reporter: | wadeh | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Launched firefox and tried to play a video, got SELinux alert | ||||
Description: | SELinux alert displayed while playing audio on youtube in firefox. | ||||
Tags: | |||||
Steps To Reproduce: |
1. Loaded AlmaLinux RC1 in a VM on Fedora 33. 2. in background installed epel and installed some packages: dnf install marble marble-astro marble-qt 3. Launched firefox and opened a tab, entered youtube.com 4. Selected some classical music and it started playing 5. The selinux alert was displayed |
||||
Additional Information: | See attached | ||||
Attached Files: |
selinuxaltert.txt (2,447 bytes) 2021-02-24 21:37 https://bugs.almalinux.org/file_download.php?file_id=58&type=bug |
||||
Notes | |
(0000446)
akdev 2021-12-13 04:03 |
>Loaded AlmaLinux RC1 in a VM on Fedora 33. It's been a while since RC1 was released. I will have to check if this alert happens on latest release. |
(0000466)
akdev 2021-12-31 03:05 |
installed AlmaLinux 8.5, installed firefox, played music on youtube - no SELinux alerts and no avc denials in the logs |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
120 | [AlmaLinux-8] flatpak | minor | always | 2021-08-24 16:35 | 2021-12-31 03:00 |
Reporter: | nahumcastro | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | KDE flatpak apps do not show any text | ||||
Description: |
Install QGIS as advised here https://qgis.org/es/site/forusers/alldownloads.html#flatpak and the app shows no text, just buttons, there are no menus, dialogs, all text is missing The same behavior happened with KDevelop. |
||||
Tags: | not-a-bug | ||||
Steps To Reproduce: |
Install QGIS as advised here https://qgis.org/es/site/forusers/alldownloads.html#flatpak and the app shows no text, just buttons, there are no menus, dialogs, all text is missing |
||||
Additional Information: | QGIS version 3.16LTS | ||||
Attached Files: | |||||
Notes | |
(0000465)
akdev 2021-12-31 03:00 |
this works fine for me - the application crashes on Wayland as it probably a Qt version that doesn't support Wayland fully. I was able to execute the application on a fresh AlmaLinux 8.5 instance with `QT_QPA_PLATFORM=xcb flatpak --user run org.qgis.qgis` |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
91 | [AlmaLinux-8] glusterfs | minor | always | 2021-06-01 15:41 | 2021-12-31 02:44 |
Reporter: | figless | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | glusterfs packages are built from incorrect sources | ||||
Description: |
The versions of glusterfs, glusterfs-client, glusterfs-fuse, glusterfs-libs, glusterfs-rdma (BaseOS), and glusterfs-api, glusterfs-cli (AppStream) are all version 6.0:56 which does not match what exists in RHEL (BaseOS, AppStream), which is version 6.0:49.1. It seems that the srpm for gluster has been rebuilt from "Red Hat Storage Native Client for RHEL 8" rather than BaseOS/AppStream |
||||
Tags: | not-a-bug | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000463)
akdev 2021-12-31 02:44 |
[akdev@virt0 ~]$ cat /etc/redhat-release CentOS Stream release 8 [akdev@virt0 ~]$ sudo dnf info glusterfs | awk '/Version/ || /Release/' Version : 6.0 Release : 56.4.el8 [akdev@almalinux8 ~]$ cat /etc/redhat-release AlmaLinux release 8.5 (Artic Sphynx) [akdev@virt0 ~]$ sudo dnf info glusterfs | awk '/Version/ || /Release/' Version : 3.12.2 Release : 40.2.el8 Version : 6.0 Release : 56.4.el8 looks like AlmaLinux offers the correct version - 56.4.el8 matching centos 8 stream |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
60 | [AlmaLinux-8] almalinux-release | major | N/A | 2021-04-07 18:16 | 2021-12-31 02:32 |
Reporter: | hvdkooij | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Minimal ISO does require network repository during installation | ||||
Description: |
Minimal ISO does require network repository during installation from an USB thumbdrive. I have not found a way to install a minimal system from that ISO image. It always asks for a repository. This is not expected behaviour. |
||||
Tags: | not-a-bug | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000145)
hvdkooij 2021-04-12 18:55 |
I have now also tested the full DVD ISO. If I write it to a USB device and try to install from it the system fails to setup a repository. So installing from USB on a clean system is not possible at this time. |
(0000146)
hvdkooij 2021-04-12 18:59 |
How to reproduce: 1. Download ISO image of AlmaLinux. 2. Use Rufus on Windows 10 to create a boootable USB drive. 3. Boot test machine from this USB device. 4. Installer will fail to find a source to install from and only presents a network install option for which I don't know the URL. |
(0000147)
enigma131 2021-04-13 16:21 |
It was working here via same way. Had you verifed checksum of downloaded iso ? |
(0000461)
akdev 2021-12-31 02:32 |
works for me on latest 8.5 image - I was able to install from the minimal ISO with no internet |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
166 | [AlmaLinux-8] almalinux-release | major | always | 2021-12-28 18:59 | 2021-12-30 07:25 |
Reporter: | regobk | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Running almalinux-deploy.sh results in Download RPM-GPG-KEY-AlmaLinux Error | ||||
Description: |
After running an update on a centos 8 server to ensure compatibility with AlmaLinux 8.5, the typical download of the deploy script is ran. After the download and making it executable, running ./almalinux-deploy.sh results in: "Check root privileges OK Download RPM-GPG-KEY-AlmaLinux ERROR curl: (60) SSL certificate problem: certificate has expired More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above." |
||||
Tags: | |||||
Steps To Reproduce: | Unsure of steps to reproduce as this has only happened on one server. | ||||
Additional Information: | Running CentOS Linux release 8.5.2111 - All updates have been ran. | ||||
Attached Files: | |||||
Notes | |
(0000459)
regobk 2021-12-28 19:13 |
Update: I edited the script to add the -k flag for curl to disable the strict cert check. This fixed the issue I was having. |
(0000460)
alukoshko 2021-12-30 07:25 |
I see repo.almalinux.org cert was renewed exactly 2021-12-28. Could you recheck please? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
117 | [AlmaLinux-8] lynx | minor | have not tried | 2021-08-12 16:49 | 2021-12-13 14:14 |
Reporter: | moredaylight | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | CVE-2021-38165: Lynx through 2.8.9 can expose credentials via SNI | ||||
Description: |
https://nvd.nist.gov/vuln/detail/CVE-2021-38165 Lynx through 2.8.9 mishandles the userinfo subcomponent of a URI, which allows remote attackers to discover cleartext credentials because they may appear in SNI data. https://www.openwall.com/lists/oss-security/2021/08/07/1 |
||||
Tags: | |||||
Steps To Reproduce: |
If you have an HTTPS server listening on localhost, this is pretty easy to reproduce. Use tcpdump or wireshark to watch traffic. tcpdump -vvA -i lo port 443 Attempt to connect to localhost passing credentials in the URL. lynx https://user:password@localhost/ You will see "user:password@localhost" in the plaintext of the tcpdump output. |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000445)
akdev 2021-12-13 03:59 |
this is something to be reported and fixed upstream |
(0000451)
alukoshko 2021-12-13 14:14 |
RHEL8 is not listed for some reason. https://access.redhat.com/security/cve/cve-2021-38165 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
34 | [AlmaLinux-8] acpid | tweak | sometimes | 2021-02-26 19:23 | 2021-12-13 04:05 |
Reporter: | Shii Cube Kakinden | Platform: | HP APU Note 15inch HD TFT | ||
Assigned To: | OS: | ||||
Priority: | immediate | OS Version: | |||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Kit Command-based Prompt Producer Program Bug | ||||
Description: | / home [AMD 3] or [AMD 4] or [AMD 5] There are many problems with Hee Cmd.com systems that do not have Cloud Native nest tiles related to $$ Mcode in the folder. | ||||
Tags: | fp, incomplete | ||||
Steps To Reproduce: |
https://en.wikipedia.org/wiki/Cron In the weakness less than the problem-solving program, it includes subtle problems. |
||||
Additional Information: | https://en.wikipedia.org/wiki/Scheduling_(computing) | ||||
Attached Files: | |||||
Notes | |
(0000447)
akdev 2021-12-13 04:05 |
this may well be spam |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
106 | [AlmaLinux-8] lvm2 | crash | always | 2021-06-25 23:35 | 2021-12-13 04:02 |
Reporter: | toni | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | solved | ||||
Description: |
i use to create lvm always. after creating i proceed for installation, and installation report about one volym group. vg= log /var/log we cant give a name "log" to a volym group, since it's exist . |
||||
Tags: | incomplete | ||||
Steps To Reproduce: | |||||
Additional Information: | naming this vg to logg will solve the problem. | ||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
151 | [AlmaLinux-8] almalinux-release | major | always | 2021-11-15 23:15 | 2021-12-11 22:19 |
Reporter: | cshabazian | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | rpm -K on https://repo.almalinux.org/almalinux/almalinux-release-latest-8.x86_64.rpm fails | ||||
Description: | Reported as high priority in case the package has been compromised | ||||
Tags: | |||||
Steps To Reproduce: | Run the conversion script, or download the rpm and run rpm -K on it | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000391)
akdev 2021-11-16 13:36 |
I wasn't able to reproduce on a clean Alma Linux system, it doesn't seem like the package was compromised but your system might be missing some keys? (on my systems I have /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux which is provided by almalinux-release) $ curl "https://repo.almalinux.org/almalinux/almalinux-release-latest-8.x86_64.rpm" -LOJ 2>/dev/null&& rpm -K almalinux-release-latest-8.x86_64.rpm almalinux-release-latest-8.x86_64.rpm: digests signatures OK seems like this would be a bug in the migration script |
(0000392)
cshabazian 2021-11-16 17:03 |
That was my second guess, that it was a bug in the migration script as the AlmaLinux keys aren't on my system and the script doesn't add them first. It looks like the problem is in the install_rpm_pubkey() function. In order to get it to run, I had to comment out: # if get_status_of_stage "install_rpm_pubkey"; then # return 0 # fi Add define pubkey_url: #local -r pubkey_url="${ALMA_PUBKEY_URL:-https://repo.almalinux.org/almalinux/RPM-GPG-KEY-AlmaLinux}" local -r pubkey_url="https://repo.almalinux.org/almalinux/RPM-GPG-KEY-AlmaLinux" Sorry, no time to dig deeper into it. After I did the above, it worked fine. |
(0000441)
akdev 2021-12-11 19:24 |
coming back to this, I just realized there's very little detail on the original report so I assume you mean this script: https://github.com/AlmaLinux/almalinux-deploy could you elaborate on what you were migrating from? |
(0000442)
akdev 2021-12-11 19:29 |
I looked at the source code and the relevant function looks fine, this is called unconditionally from the main function of the script. the only thing is that there's a check to skip the function if it already ran but that seems correct as well. |
(0000443)
cshabazian 2021-12-11 22:19 |
I was converting from CentOS to Alma using the conversion script. It seems to be working now, so I don't know if it got fixed or if I used an old script. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
65 | [AlmaLinux-8] -OTHER | minor | always | 2021-04-21 16:14 | 2021-12-10 12:12 |
Reporter: | Znuff | Platform: | |||
Assigned To: | sfokin | OS: | |||
Priority: | normal | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | virt-sysprep created images do not run the --firstboot script | ||||
Description: |
As per title, we usually create our own templates/images for deployment. Normally we just install the OS minimally, then install the packages that we need, dump to an image to a file, then run `virt-sysprep -a file.img --firstboot our-script.sh`. This works fine with CentOS 8, Ubuntu 20 and so on -- as expected, on first boot the script runs via the installed `guestfs-firstboot.service` without issues. On AlmaLinux 8.3 the initial script doesn't run at all. I'm not sure what prevents it from running. I've run `virt-sysprep -v` against both CentOS 8 and AlmaLinux 8.3, and the output is the same in regards to the `--firstboot` part. |
||||
Tags: | |||||
Steps To Reproduce: |
1. Install AlmaLinux as a guest in a VM 2. Dump it to an image file (ie: qemu-img convert -O raw /block/device almalinux.img) 3. Run virt-sysprep on it -- virt-sysprep -a almalinux.img --firstboot our-script.sh 4. Deploy the newly created image in your environment 5. Expect our-script.sh to run via the installed guestfs-firstboot.service 6. Script doesn't run on first boot |
||||
Additional Information: |
https://libguestfs.org/virt-sysprep.1.html#firstboot-vs-script |
||||
Attached Files: | |||||
Notes | |
(0000281)
sfokin 2021-06-24 13:34 |
Could you please help me with reproducing bug. I've had a problem on step 3. Ive tried on Centos 8.4 =================== # virt-sysprep -a /media/sf_mount/almalinux.img --firstboot our-script.sh [ 0.0] Examining the guest ... virt-sysprep: error: libguestfs error: could not create appliance through libvirt. Try running qemu directly without libvirt using this environment variable: export LIBGUESTFS_BACKEND=direct Original error from libvirt: internal error: qemu unexpectedly closed the monitor: 2021-06-24T11:59:11.781802Z qemu-kvm: -blockdev {"driver":"file","filename":"/media/sf_mount/almalinux.img","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}: Could not open '/media/sf_mount/almalinux.img': Permission denied [code=1 int1=-1] If reporting bugs, run virt-sysprep with debugging enabled and include the complete output: virt-sysprep -v -x [...] =================== i add LIBGUESTFS_BACKEND=direct and get =================== # LIBGUESTFS_BACKEND=direct virt-sysprep -a /media/sf_mount/almalinux.img --firstboot our-script.sh [ 0.0] Examining the guest ... virt-sysprep: warning: mount_options: mount_options_stub: /dev/mapper/cl-root: expecting a device name (ignored) [ 21.2] Performing "abrt-data" ... virt-sysprep: error: libguestfs error: glob_expand: glob_expand_stub: you must call 'mount' first to mount the root filesystem If reporting bugs, run virt-sysprep with debugging enabled and include the complete output: virt-sysprep -v -x [...] =================== |
(0000439)
Znuff 2021-12-09 04:10 |
Sorry this has been taking me so long to get back to this. I'm not sure about your issue with virt-sysprep, mine just works without having done anything special. It does seem that the mount that contains the disk image doesn't seem to be a local one and libvirt has issues accessing it? --- That being said, the issue is still present. It seems to be something about systemd not liking... something. Again, the issue is **not** present on CentOS8. There's a discussion on the systemd issue tracker at https://github.com/systemd/systemd/issues/6334 that might seem relevant. Also, worth mentioning that this is not only happening on Alma Linux, but it's also happening on Rocky Linux 8.4. Relevant snippets from the virt-sysprep log: [ 9.5] Installing firstboot script: our-script.sh commandrvf: ln -sf -- /usr/lib/systemd/system/guestfs-firstboot.service /sysroot/etc/systemd/system/multi-user.target.wants In the output image the file is present in the proper systemd directory: [root@test multi-user.target.wants]# cat /usr/lib/systemd/system/guestfs-firstboot.service [Unit] Description=libguestfs firstboot service After=network.target Before=prefdm.service [Service] Type=oneshot ExecStart=/usr/lib/virt-sysprep/firstboot.sh start RemainAfterExit=yes StandardOutput=journal+console StandardError=inherit [Install] WantedBy=multi-user.target [root@test multi-user.target.wants]# systemctl status guestfs-firstboot.service ● guestfs-firstboot.service - libguestfs firstboot service Loaded: loaded (/usr/lib/systemd/system/guestfs-firstboot.service; bad; vendor preset: disabled) Active: inactive (dead) And the symlink is present: [root@test multi-user.target.wants]# stat $(pwd)/guestfs-firstboot.service File: /etc/systemd/system/multi-user.target.wants/guestfs-firstboot.service -> /usr/lib/systemd/system/guestfs-firstboot.service Size: 49 Blocks: 0 IO Block: 4096 symbolic link Device: fd01h/64769d Inode: 140550 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:unlabeled_t:s0 Access: 2021-12-09 06:02:49.352448191 +0200 Modify: 2021-12-09 05:05:40.532000000 +0200 Change: 2021-12-09 05:05:40.532000000 +0200 Birth: 2021-12-09 05:05:40.532000000 +0200 systemd reports the unit "bad" though, and I can't figure out why: [root@test multi-user.target.wants]# systemctl status guestfs-firstboot.service ● guestfs-firstboot.service - libguestfs firstboot service Loaded: loaded (/usr/lib/systemd/system/guestfs-firstboot.service; bad; vendor preset: disabled) Active: inactive (dead) The default target seems to be reached: [root@test multi-user.target.wants]# systemctl status default.target ● multi-user.target - Multi-User System Loaded: loaded (/usr/lib/systemd/system/multi-user.target; bad; vendor preset: disabled) Active: active since Thu 2021-12-09 07:10:03 EET; 1h 0min left Docs: man:systemd.special(7) Dec 09 07:10:03 test.web-host.ro systemd[1]: Reached target Multi-User System. So I'm not sure at this point what else is preventing this from being run. |
(0000440)
Znuff 2021-12-10 12:12 |
Hello again, Going back to this, the issue was SELinux. Running: virt-sysprep -a almalinux.img --firstboot our-script.sh --selinux-relabel Fixes the problem. Seems that our reference CentOS image was an 8.1, and between 8.1 > 8.4 some SELinux stuff changed. This can be closed now. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
162 | [AlmaLinux-8] -OTHER | minor | N/A | 2021-12-02 20:33 | 2021-12-02 20:33 |
Reporter: | almalinuxjack | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | The AlmaLinux OS 8.x documentation does not incorporate WCAG 2.0 AA | ||||
Description: |
The AlmaLinux OS 8.x documentation does not incorporate WCAG 2.0 AA. See: https://www.w3.org/WAI/WCAG2AA-Conformance |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
161 | [AlmaLinux-8] -OTHER | minor | N/A | 2021-12-02 20:24 | 2021-12-02 20:25 |
Reporter: | almalinuxjack | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | The AlmaLinux OS 8.x documentation does not currently have an Accessibility User Guide | ||||
Description: | The AlmaLinux OS 8.x documentation does not currently have an Accessibility User Guide | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000438)
almalinuxjack 2021-12-02 20:25 |
This is required for VPAT. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
147 | [AlmaLinux-8] initial-setup | major | always | 2021-11-13 22:38 | 2021-12-01 08:33 |
Reporter: | sges | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux 8.5 Boot installer Cannot install without formatting | ||||
Description: | I tried to install on a preformatted ext4 empty partition mounting it as root. The installer would not proceed until I selected format and ext4. So there is no way to install on a partition with preexisting data, for example, a /home directory | ||||
Tags: | |||||
Steps To Reproduce: | Try to mount root on a prexisting formatted partition using the boot installer without formatting | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000436)
alukoshko 2021-12-01 08:33 |
Hello. I suppose that is normal behavior for Anaconda installer. Have you tried the same on CentOS or RHEL? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
135 | [AlmaLinux-8] setup | block | always | 2021-10-20 19:44 | 2021-11-24 18:47 |
Reporter: | GeskoSmart | Platform: | |||
Assigned To: | OS: | ||||
Priority: | immediate | OS Version: | |||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Installation can not be finished | ||||
Description: |
When configuring the Installation I'm asked to add an Installation-Source and an Software selection. When I click on installation-source and just leave the new screen with the finished button, I get the yellow warning sign on it, and I can't go to this menu again. Also the installation can not be continued. Some for the Software selection button. Wenn ich die Installation starte komme ich in die Zusammenfassung der Installation. Dort gibt es den Button Installationquelle und Software Auswahl. Beide haben eine rote Warnung! Wenn ich in Installationquelle gehe und dann sofort wieder raus über den FERTIG Button, dann habe ich nur noch das gelbe Warnsymbol. Aber die Installation kann nicht fortgesetzt werden. Ich kann den Button Installationquelle auch nicht noch mal klicken. Das gleich gilt für den Button Software-Auswahl. Die Installation kann nicht fortgesetzt werden. |
||||
Tags: | block, installation, setup | ||||
Steps To Reproduce: |
Download ISO Start installation Select Language GERMAN Continue Selete Installationsquelle Klick FERTIG See the installation can not be continued and also the Button Installationsquelle can not be klicked anymore. |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000425)
alukoshko 2021-11-24 16:59 |
Hello. Sorry for delay. Have you tried AlmaLinux 8.5? It detects the nearest mirror for network install automatically. |
(0000426)
GeskoSmart 2021-11-24 18:30 |
Thanks for coming back. I already thought this forum is dead. Anyway, after trying and trying for hours I then tried it on a different system and I found out it's indeed a network issue. Even at 8.5 it doesn't automatically detect network at all. I also don't understand why it is necessary to have ntwork connectivity while doing the install from an iso. Why is there no option to configure the network? Why is there no option to skip network usage and configure later? This is really very stupid and makes AlmaLinux for me unusable. Meanwhile I switched back to Ubuntu although I hate it. But it still installs like a charme. |
(0000427)
alukoshko 2021-11-24 18:47 |
You have to setup network only on boot (netinstall) ISO because it doens't contain any packages. Minimal and DVD ISOs don't require network to install. You can just not enable network during install. What ISO are you trying? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
155 | [AlmaLinux-8] -OTHER | block | always | 2021-11-19 06:54 | 2021-11-22 08:56 |
Reporter: | nikk2000 | Platform: | x86_64 | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Cannot boot after finished minimal installations with NIST 800-171 policy | ||||
Description: | After finished installations, boot failed because modprobe is blocked. | ||||
Tags: | boot | ||||
Steps To Reproduce: |
1) Minimal installations 2) Use LVM partitions 3) Use NIST 800-171 security policy |
||||
Additional Information: | |||||
Attached Files: |
Screenshot_20211119_141112.png (32,186 bytes) 2021-11-19 06:54 https://bugs.almalinux.org/file_download.php?file_id=106&type=bug |
||||
Notes | |
(0000406)
nikk2000 2021-11-19 10:21 |
I have tried disable fapolicyd and SELinux (by mounting and editing config files), but still cannot boot. |
(0000407)
nikk2000 2021-11-20 09:20 |
I guess boot got lockup because I don't have TPM module. I have tested on machines with TPM module and found no issues. |
(0000408)
nikk2000 2021-11-20 20:32 |
I've just found the problem, I need to remove `fips=1` from kernel option. Also I already have HMAC file in /boot/. Perhaps, AMD Ryzen 2700 doesn't support FIPS? Because Intel Core i7-10750H boot just fine with `fips=1`. Probably related to: * https://almalinux.discourse.group/t/kernel-4-18-0-240-22-1-with-fips-1-will-not-boot/88 |
(0000409)
alukoshko 2021-11-22 08:38 |
Hello. Thanks for report and investigation. No, it's not related to issues with 4.18.0-240.22.1, that was broken kernel version and since then all kernel versions are checked to not repeat that problem. Usually we ask to check on CentOS or RHEL to find out if this AlmaLinux specific or upstream problem. If it's upstream one then the best option would be check on CentOS Stream to find out if the problem is fixed already. If not, then you can open a bug to CentOS Stream bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream Of course it's up to you. But it would be great if you could check it because working with CentOS Stream bugs helps the whole EL community. |
(0000410)
nikk2000 2021-11-22 08:56 |
You're welcome. Thank you for reply. Noted, I'll try and check on CentOS Stream. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
146 | [AlmaLinux-8] -OTHER | crash | always | 2021-11-12 14:37 | 2021-11-15 16:14 |
Reporter: | Nick | Platform: | VMWare | ||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | VMWare - KDE crash on login | ||||
Description: |
I have installed KDE on a VM (VMWare) using: yum groupinstall "KDE Plasma Workspaces" The install goes well with the PowerTools repo enabled. After reboot, upon logging in and selecting Plasma, kwin crashes (see attached). |
||||
Tags: | KDE, kwin, Plasma, segfault, VMWare | ||||
Steps To Reproduce: |
1. Install KDE using yum groupinstall "KDE Plasma Workspaces" 2. Reboot 3. Login selecting Plasma |
||||
Additional Information: | See attached crash dump. | ||||
Attached Files: |
kwin_x11-20211112-161114.kcrash.txt (5,346 bytes) 2021-11-12 14:37 https://bugs.almalinux.org/file_download.php?file_id=102&type=bug |
||||
Notes | |
(0000378)
Nick 2021-11-12 14:41 |
Not entirely sure this crash should be reported to AlmaLinux or KDE but since the the live ISO has a KDE-beta I thought I might report it here as well. |
(0000379)
alukoshko 2021-11-12 22:49 |
Hello and thanks for report! It would be useful to recheck this on CentOS or RHEL to find out is it AlmaLinux specific bug or not. This will help in investigation. |
(0000381)
Nick 2021-11-12 23:11 |
I will install a CentOS 8 in a similar VM and come back with the result. |
(0000382)
alukoshko 2021-11-12 23:18 |
Also if AlmaLinux version is 8.5 please try epel-next because KDE in epel built with Qt 5.12 and RHEL/CentOS/AlmaLinux/whatever 8.5 has Qt 5.15. |
(0000388)
Nick 2021-11-14 07:59 |
KDE has a successful install on Alma 8.5 having enabled/installed the following: epel-release epel-next-release powertools It works with both X server and Wayland. |
(0000389)
srbala 2021-11-15 16:14 |
This is not AlmaLinux issue, current `epel` is broken, which needs update |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
149 | [AlmaLinux-8] -OTHER | minor | have not tried | 2021-11-15 04:47 | 2021-11-15 04:47 |
Reporter: | gralex | Platform: | |||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.5 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | needs-restarting from Yum-utils does not report a reboot | ||||
Description: |
Hello, Running: AlmaLinux release 8.5 (Arctic Sphynx) With yum-utils-4.0.21-3.el8.noarch : Yum-utils CLI compatibility layer Updated kernel today: 2021-11-15T11:01:25+0700 DEBUG Installed: kernel-4.18.0-348.el8.x86_64 2021-11-15T11:01:25+0700 DEBUG Installed: kernel-core-4.18.0-348.el8.x86_64 2021-11-15T11:01:25+0700 DEBUG Installed: kernel-devel-4.18.0-348.el8.x86_64 2021-11-15T11:01:25+0700 DEBUG Installed: kernel-modules-4.18.0-348.el8.x86_64 2021-11-15T11:01:25+0700 DEBUG Installed: libbpf-0.4.0-1.el8.x86_64 2021-11-15T11:01:25+0700 DEBUG Installed: python3-cloud-what-1.28.21-3.el8.alma.x86_64 And the tool needs-restarting reports false negative results: # needs-restarting -r No core libraries or services have been updated since boot-up. Reboot should not be necessary. # Kindly advice. Regards, Alex, |
||||
Tags: | needs-restarting, yum-utils | ||||
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: |
144 | [AlmaLinux-8] -OTHER | major | random | 2021-11-09 06:58 | 2021-11-12 23:19 |
Reporter: | johnnyxalma | Platform: | Linux | ||
Assigned To: | OS: | Alama Linux | |||
Priority: | high | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Server Shutdown randomly when installing Alma Linux 8.4 on HP ProLiant DL560 Gen9 | ||||
Description: | We tried installing AlmaLinux 8.4 on HP ProLiant DL560 Gen9 server, but the server would shutdown randomly without any warning or error log. This behavior would occur during installation and even after successful installation. | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: |
We tried installing the same OS (Alma Linux 8.4) on another HP ProLiant DL560 gen 9 server and did not face any shutdown issue during or after installation. Both servers have the exact same hardware specifications. We later installed Ubuntu 20 on the server without any such issues. I am uploading a file containing the DMESG details of the server. |
||||
Attached Files: |
dmesg.txt (155,477 bytes) 2021-11-09 06:58 https://bugs.almalinux.org/file_download.php?file_id=101&type=bug |
||||
Notes | |
(0000383)
alukoshko 2021-11-12 23:19 |
Could you try recently released 8.5 ? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
136 | [AlmaLinux-8] selinux-policy | minor | always | 2021-10-22 11:30 | 2021-11-08 09:31 |
Reporter: | joystick | Platform: | |||
Assigned To: | OS: | AlmaLinux | |||
Priority: | normal | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | container-selinux doesn't remove selinux modules | ||||
Description: | Package container-selinux doesn't remove the selinux modules it installs. Why is this happening? Beacuse the package is trying to remove the module with the wrong priority. | ||||
Tags: | selinux | ||||
Steps To Reproduce: |
Before installation container-selinux package: root@alma:~ dnf list installed | grep container-selinux root@alma:~ semodule -l | grep container Aftef installation: root@alma:~ dnf list installed | grep container-selinux container-selinux.noarch 2:2.167.0-1.module_el8.4.0+2535+b6fd1bdf @AppStream root@alma:~ semodule -l | grep container container pcpupstream-container After remove package: root@alma:~ dnf remove container-selinux Dependencies resolved. =========================================================================================================================================================================================================== Package Architecture Version Repository Size =========================================================================================================================================================================================================== Removing: container-selinux noarch 2:2.167.0-1.module_el8.4.0+2535+b6fd1bdf @AppStream 48 k Transaction Summary =========================================================================================================================================================================================================== Remove 1 Package Freed space: 48 k Is this ok [y/N]: y Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: container-selinux-2:2.167.0-1.module_el8.4.0+2535+b6fd1bdf.noarch 1/1 Erasing : container-selinux-2:2.167.0-1.module_el8.4.0+2535+b6fd1bdf.noarch 1/1 Running scriptlet: container-selinux-2:2.167.0-1.module_el8.4.0+2535+b6fd1bdf.noarch 1/1 Verifying : container-selinux-2:2.167.0-1.module_el8.4.0+2535+b6fd1bdf.noarch 1/1 Removed: container-selinux-2:2.167.0-1.module_el8.4.0+2535+b6fd1bdf.noarch Complete! root@alma:~ dnf list installed | grep container-selinux root@alma:~ semodule -l | grep container container pcpupstream-container Package is trying to remove the module with the wrong priority: root@alma:/var/lib/selinux/targeted/active/modules/200 ls | grep container drwx------. 2 root root 44 Oct 21 11:28 container root@alma:~ semodule -r container libsemanage.semanage_direct_remove_key: Unable to remove module container at priority 400. (No such file or directory). semodule: Failed! root@alma:~ semodule -X 200 -r container libsemanage.semanage_direct_remove_key: Removing last container module (no other container module exists at another priority). |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000375)
alukoshko 2021-11-08 09:04 |
Hi. Could you try to reproduce this on CentOS 8 and CentOS Stream 8? If it's upstream bug then we have to submit it to Red Hat. |
(0000376)
joystick 2021-11-08 09:31 |
Hi, I managed to reproduce this problem on CentOS 8 (Linux), I haven't tested it on stream. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
143 | [AlmaLinux-8] almalinux-release | major | have not tried | 2021-11-06 00:15 | 2021-11-08 08:46 |
Reporter: | Vee | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Failure to install Gnome Desktop on Raspberry Pi 4 | ||||
Description: |
I am installing Almalinux on my Pi. I am getting this error Error: Failed to download metadata for repo 'raspberrypi': Cannot download repomd.xml : Cannot download repodata/repomd.xml: All mirrors were tried Another error is - Curl error (6): Couldn't resolve host name for https://repo.almalinux.org/almalinux/8/raspberrypi/aarch64/os/repodata/repomd.xml [Could not resolve host: repo.almalinux.org] |
||||
Tags: | aarch64, Raspberrypi, raspberrypi 4 | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000373)
alukoshko 2021-11-08 08:46 |
Hi. Looks like network/DNS issue. Please check network setup, try to ping some internet sites. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
140 | [AlmaLinux-8] -OTHER | minor | always | 2021-10-31 06:27 | 2021-11-01 12:29 |
Reporter: | kfujinaga | Platform: | Virtuozzo Hybrid Server | ||
Assigned To: | alukoshko | OS: | CentOS | ||
Priority: | normal | OS Version: | 8.4 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | almalinux-deploy: almalinux-deploy install unnecessary kernel packages in the Virtuozzo/OpenVZ container enviroments. | ||||
Description: |
In the Virtuozzo/OpenVZ container enviroments, each container use host's kernel. So kernel packages are not installed in the container. But almalinux-deploy install kernel packages at the migration. These packages are unnecessary and are not used. # NOTE: The migration was successful, and AlmaLinux container works fine. On the other hand, the migration tools of Rocky Linux and CentOS Stream doesn't install kernel packages in the Virtuozzo/OpenVZ container enviroments. Unnecessary kernel packages cause a misunderstanding for users. So I want you to fix this problem. |
||||
Tags: | |||||
Steps To Reproduce: |
Run almalinux-deploy in the Virtuozzo/OpenVZ container enviroments. 1. Check enviroment before migration ------------ [root@fujinaga-test ~]# uname -a Linux fujinaga-test 4.18.0 #1 SMP Tue Jun 9 12:58:54 MSK 2020 x86_64 x86_64 x86_64 GNU/Linux [root@fujinaga-test ~]# cat /etc/redhat-release CentOS Linux release 8.4.2105 [root@fujinaga-test ~]# ls /boot/ efi grub2 [root@fujinaga-test ~]# ls /lib/modules [root@fujinaga-test ~]# rpm -qa |grep kernel [root@fujinaga-test ~]# ------------ No kernel package is installed. 2. Run almalinux-deploy ------------ [root@fujinaga-test ~]# bash almalinux-deploy.sh ... Complete! Run dnf distro-sync -y OK Restoring of alternatives is done OK Install AlmaLinux kernel OK Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.18.0-305.19.1.el8_4.x86_64 Found initrd image: /boot/initramfs-4.18.0-305.19.1.el8_4.x86_64.img done grep: /boot/grub2/grubenv: No such file or directory All Secure Boot related packages which were released by not AlmaLinux are reinstalledOK Migration to AlmaLinux is completed ------------ Migration is completed. But following message is outputed. "grep: /boot/grub2/grubenv: No such file or directory" 3. Check enviroment after migration ------------ [root@fujinaga-test ~]# uname -a Linux fujinaga-test 4.18.0 #1 SMP Tue Jun 9 12:58:54 MSK 2020 x86_64 x86_64 x86_64 GNU/Linux [root@fujinaga-test ~]# cat /etc/redhat-release AlmaLinux release 8.4 (Electric Cheetah) [root@fujinaga-test ~]# ls /boot/ System.map-4.18.0-305.19.1.el8_4.x86_64 config-4.18.0-305.19.1.el8_4.x86_64 efi grub2 initramfs-4.18.0-305.19.1.el8_4.x86_64.img loader vmlinuz-4.18.0-305.19.1.el8_4.x86_64 [root@fujinaga-test ~]# ls /lib/modules 4.18.0-305.19.1.el8_4.x86_64 [root@fujinaga-test ~]# rpm -qa |grep kernel kernel-core-4.18.0-305.19.1.el8_4.x86_64 kernel-4.18.0-305.19.1.el8_4.x86_64 kernel-modules-4.18.0-305.19.1.el8_4.x86_64 [root@fujinaga-test ~]# ------------ Kernel packages are installed. These kernel packages are unnecessary. If the container is restarted, the container use host's kernel. |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000369)
alukoshko 2021-11-01 12:29 |
Hi. Thanks for report. Right now almalinux-deploy detects only LXC containers, we're working on detection of others too. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
139 | [AlmaLinux-8] rpcbind | major | always | 2021-10-30 11:25 | 2021-10-30 11:25 |
Reporter: | commandline-be | Platform: | x86 | ||
Assigned To: | OS: | Alma Linux | |||
Priority: | high | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | rpcbind fatal flaw on boot/start of service | ||||
Description: |
During boot [ 8.777218] traps: rpcbind[767] general protection fault ip:7f94de660bb8 sp:7ffe8e484960 error:0 in libc-2.28.so[7f94de57a000+1bc000] [FAILED] Failed to start RPC Bind. See 'systemctl status rpcbind.service' for details. |
||||
Tags: | |||||
Steps To Reproduce: |
boot the system run rpcbind start the rpcbind service |
||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
132 | [AlmaLinux-8] -OTHER | minor | always | 2021-10-13 09:55 | 2021-10-25 09:11 |
Reporter: | atapy | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | [Cloud/AWS]AMI wrongly assumes RTC as LOCALTIME | ||||
Description: |
Official AMI assumes syetem real-time-clock as LOCALTIME, but it is incorrect because EC2 supplies their RTC clock as UTC. Refer: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html > Update the /etc/sysconfig/clock file with the new time zone. (snip) > Do not change the UTC=true entry to another value. > This entry is for the hardware clock, > and does not need to be adjusted > when you're setting a different time zone on your instance. It may cause inaccurate time settings, espacially time zone is set OTHER THAN UTC. Please consider changing default RTC setting, to UTC. |
||||
Tags: | aws, Bug, cloud | ||||
Steps To Reproduce: |
[ec2-user@ip-172-31-44-137 ~]$ timedatectl status Local time: Wed 2021-10-13 09:46:11 UTC Universal time: Wed 2021-10-13 09:46:11 UTC RTC time: Wed 2021-10-13 09:46:11 Time zone: UTC (UTC, +0000) System clock synchronized: yes NTP service: active RTC in local TZ: yes <------ INCORRECT FOR AWS Warning: The system is configured to read the RTC time in the local time zone. This mode cannot be fully supported. It will create various problems with time zone changes and daylight saving time adjustments. The RTC time is never updated, it relies on external facilities to maintain it. If at all possible, use RTC in UTC by calling 'timedatectl set-local-rtc 0'. |
||||
Additional Information: |
Tested at ap-northeast-1. AlmaLinux OS 8.4 x86_64-stage2-c076b20a-2305-4771-823f-944909847a05 RHEL 8, CentOS 8 and Rocky Linux 8 do not have this bug. This bug exists only on AlmaLinux 8. |
||||
Attached Files: | |||||
Notes | |
(0000353)
elkhan 2021-10-17 15:05 |
Hey atapy, Thanks for making AlmaLinux better. You can get the updated AMIs from the Community AMI wiki page or AWS Marketplace. You'll get the product subscription e-mail when the second one is published on the AWS Marketplace by Amazon. [1] Community AMI wiki page: https://wiki.almalinux.org/cloud/AWS.html |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
137 | [AlmaLinux-8] gdm | crash | sometimes | 2021-10-23 21:27 | 2021-10-23 21:48 |
Reporter: | spatial25 | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | GDM sometimes crashes on image and pdf use | ||||
Description: |
When I am using Libreoffice writer and recently Evince the system crashes and I am taken back to the command line login interface. I don't have graphical.target set to load automatically. I log in with my credentials and type "sudo systemctl start graphical.target" nothing happens after the crash and it requires a reboot to load start again. I think it is the gdm but I am not sure and can't sort through my log.messages accurately enough to identify why it crashed. Its happened when moving images around in libreoffice and when clicking on a pdf to select text on evince. If anyone can guide me to what log info I need to put please let me know. I am looking through it now. |
||||
Tags: | |||||
Steps To Reproduce: |
attach images to libreoffice writer document and resize and position pictures in it. Have doc open for 1/2 an hour and move pictures around and crash. view document on evince and have it up while also searching info on browser. Go back to highlight text and crash. |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000364)
spatial25 2021-10-23 21:48 |
Every time it crashed I noticed the user@42.service and a starting Mark boot. Looking through these logs I found Oct 23 16:17:25 spaced pia-client.desktop[6509]: [2021-10-23 21:17:25.294][f273][qml][qrc:/components/core/LoaderCleaner.qml:31][info] Clean up again in 6000 ms Oct 23 16:17:26 spaced dnscrypt-proxy[2089]: System DNS configuration not usable yet, exceptionally resolving [dns2.dnscrypt.ca] using fallback resolvers over tcp Oct 23 16:17:26 spaced dbus-daemon[5280]: [session uid=1000 pid=5280] Activating via systemd: service name='org.gnome.Terminal' unit='gnome-terminal-server.service' requested by ':1.74' (uid=1000 pid=7611 comm="gnome-terminal " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") Oct 23 16:17:26 spaced systemd[5236]: Starting GNOME Terminal Server... Oct 23 16:17:26 spaced gnome-terminal-server[7616]: Display does not support owner-change; copy/paste will be broken! Oct 23 16:17:26 spaced dbus-daemon[5280]: [session uid=1000 pid=5280] Successfully activated service 'org.gnome.Terminal' Oct 23 16:17:26 spaced systemd[5236]: Started GNOME Terminal Server. Oct 23 16:17:26 spaced org.gnome.Terminal.desktop[7611]: # watch_fast: "/org/gnome/desktop/interface/" (establishing: 0, active: 0) Thanks or the help, let me know if I can send more. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
127 | [AlmaLinux-8] -OTHER | block | always | 2021-09-20 14:38 | 2021-10-19 12:09 |
Reporter: | karelklic | Platform: | |||
Assigned To: | alukoshko | OS: | AlmaLinux 8 | ||
Priority: | high | OS Version: | 8.4 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux fails to install via virt-install | ||||
Description: |
I can set up a CentOS virtual machine using virt-install from the command line, but the same procedure fails with AlmaLinux. |
||||
Tags: | |||||
Steps To Reproduce: |
1. Use a typical workstation with fully updated AlmaLinux 8, virt-manager, libvirt, virt-install, and firewalld. 2. Try to install CentOS 8 VM: sudo virt-install \ --memory 3072 \ --vcpus 2 \ --graphics none \ --network bridge=virbr0 \ --os-type=linux \ --os-variant=centos8 \ --location http://mirror.centos.org/centos-8/8/BaseOS/x86_64/os/ \ --noreboot \ --hvm \ --wait -1 \ --extra-args "console=ttyS0,115200" 3. See that the textual Anaconda installer starts after a few minutes time, allowing to proceed with the installation. 4. Now let's try to install AlmaLinux 8 VM with equivalent arguments: sudo virt-install \ --memory 3072 \ --vcpus 2 \ --graphics none \ --network bridge=virbr0 \ --os-type=linux \ --os-variant=almalinux8 \ --location https://repo.almalinux.org/almalinux/8/BaseOS/x86_64/os/ \ --noreboot \ --hvm \ --wait -1 \ --extra-args "console=ttyS0,115200" 5. See that the VM startup is stuck and the Anaconda installer never starts: [ OK ] Reached target Basic System. [ 12.114346] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready [ 12.117493] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready [ 12.118667] 8021q: adding VLAN 0 to HW filter on device enp1s0 [ 12.122468] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready [ 12.125027] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready [ 12.319085] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready [ 160.556064] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 161.187649] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 161.781877] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 162.376911] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 162.974903] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 163.568660] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 164.179282] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 164.777730] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 165.378744] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 165.996595] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 166.612907] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 167.230635] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 167.846792] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 168.446548] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 169.059694] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 169.668433] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 170.264853] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 170.887612] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts [ 171.482921] dracut-initqueue[981]: Warning: dracut-initqueue timeout - starting timeout scripts |
||||
Additional Information: |
The kickstart repo (https://repo.almalinux.org/almalinux/8/BaseOS/x86_64/kickstart/) fails as well. The older 8.3 repo (https://repo.almalinux.org/almalinux/8.3/BaseOS/x86_64/os/) fails as well. I tried to change the --os-variant argument and it has no effect (CentOS 8 installer starts fine with --os-variant almalinux8). |
||||
Attached Files: | |||||
Notes | |
(0000346)
sej7278 2021-10-14 22:47 |
Looking at the process list, the only difference i can find between a working centos8 and non-working alma8 is the centos commandline includes: inst.repo=http://mirror.centos.org/centos-8/8/BaseOS/x86_64/os/ looks like the following is missing from the osinfo-db entry: <kernel-url-argument>inst.repo</kernel-url-argument> or something like that - the above is found in rhel/fedora, i think centos bakes it into the initrd or something, lots of chat here: https://github.com/coreos/fedora-coreos-tracker/issues/221 |
(0000348)
sej7278 2021-10-15 09:01 |
if you turn on virt-install --debug you can see centos has inst.repo injected (by osinfo-db?): <cmdline>console=ttyS0,115200 inst.repo=http://mirror.centos.org/centos-8/8/BaseOS/x86_64/os/</cmdline> but almalinux only has what you've set: <cmdline>console=ttyS0,115200</cmdline> as a workaround, inject the inst.repo yourself: --extra-args "console=ttyS0,115200 inst.repo=http://repo.almalinux.org/almalinux/8/BaseOS/x86_64/os/" but this needs fixing by the osinfo-db folks, although not really sure where as the centos and almalinux xml seems to use a totally different setup: https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/almalinux.org/almalinux-8.xml.in https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/centos.org/centos-8.xml.in possibly something needs changing here: https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/install-script/redhat.com/rhel-kickstart-jeos.xml.in |
(0000350)
alukoshko 2021-10-15 12:15 |
Thank you for report and for updates. Could you please test the same with updated osinfo-sb from 8.5 beta? https://repo.almalinux.org/almalinux/8.5-beta/AppStream/x86_64/os/Packages/osinfo-db-20210809-1.el8.noarch.rpm |
(0000351)
karelklic 2021-10-15 13:39 |
sej7278, thank you for figuring out the workaround, adding inst.repo to extra-args works great! alukoshko, the osinfo-db-20210809-1 package doesn't solve the issue for me. The workaround is still required. |
(0000352)
sej7278 2021-10-15 15:26 |
yeah, its not fixed in git and i'm running a debian host anyway, so the 8.5 beta rpm isn't going to include the fix as its not been written yet. not really sure what needs to be fixed in the osinfo-db code though otherwise i'd report it to them. |
(0000355)
alukoshko 2021-10-19 12:09 |
The problem is on virt-install side. PR to upstream: https://github.com/virt-manager/virt-manager/pull/314 Also released virt-install-2.2.1-4.el8.alma to fix this issue. Thanks everyone. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
133 | [AlmaLinux-8] -OTHER | minor | always | 2021-10-16 15:33 | 2021-10-16 15:33 |
Reporter: | andreas_reschke | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Raspberry Pi boot from SD-Card vs USB | ||||
Description: |
Hi there, I’ve installed my Raspberry PI 4 with installation tips from GitHub - AlmaLinux/raspberry-pi: AlmaLinux Raspberry Pi 2. boot from SD-Card boot from USB With boot from SD-Card WiFi works fine with nmcli --ask dev wifi connect network-ssid, but not with boot from USB. Failure: Error: Connection activation failed: (7) Secrets were required, but not provided. All with same hardware but different boot method SDCard <> USB |
||||
Tags: | AlmaLinux | ||||
Steps To Reproduce: |
Update: I’ve made the same experience with CentOS, Rocky Linux and Fedora. boot from SD-Card: Wifi is working boot from USB: Wifi is not working All tests on Raspberry Pi 4 with 8 GB and same OS on SD-Card and USB. [root@raspi4 ~]# nmcli device wifi connect FRITZTuxNetzwerk password password Error: Connection activation failed: (7) Secrets were required, but not provided. [root@raspi4 ~]# Andreas |
||||
Additional Information: |
Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.1260] audit: op="connection-update" uuid="0bd11f75-aa9d-4d1f-bdd7-3ae662f24e48" name="FRITZTuxNetzwerk" args="802-11-wireless-security.psk" pid=27875 uid=0 result="success" Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.1359] device (wlan0): state change: need-auth -> deactivating (reason 'new-activation', sys-iface-state: 'managed') Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.1382] device (wlan0): disconnecting for new activation request. Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.1384] audit: op="connection-activate" uuid="0bd11f75-aa9d-4d1f-bdd7-3ae662f24e48" name="FRITZTuxNetzwerk" pid=27875 uid=0 result="success" Okt 16 17:30:38 raspi4.reschke.lan dbus-daemon[326]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.13' (uid=0 pid=413 comm="/usr/sbin/NetworkManager --no-daemon " label="system_u:system_r:NetworkManager_t:s0") Okt 16 17:30:38 raspi4.reschke.lan systemd[1]: Starting Network Manager Script Dispatcher Service... Okt 16 17:30:38 raspi4.reschke.lan dbus-daemon[326]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <warn> [1634398238.1854] device (wlan0): Deactivation failed: GDBus.Error:fi.w1.wpa_supplicant1.NotConnected: This interface is not connected Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.1858] device (wlan0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed') Okt 16 17:30:38 raspi4.reschke.lan gnome-shell[900]: An active wireless connection, in infrastructure mode, involves no access point? Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2036] device (wlan0): Activation: starting connection 'FRITZTuxNetzwerk' (0bd11f75-aa9d-4d1f-bdd7-3ae662f24e48) Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2061] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2074] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2084] device (wlan0): Activation: (wifi) access point 'FRITZTuxNetzwerk' has security, but secrets are required. Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2085] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed') Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2184] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed') Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2196] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2578] device (wlan0): Activation: (wifi) connection 'FRITZTuxNetzwerk' has security, and secrets exist. No new secrets needed. Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2579] Config: added 'ssid' value 'FRITZTuxNetzwerk' Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2580] Config: added 'scan_ssid' value '1' Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2580] Config: added 'bgscan' value 'simple:30:-70:86400' Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2581] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256' Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2581] Config: added 'auth_alg' value 'OPEN' Okt 16 17:30:38 raspi4.reschke.lan NetworkManager[413]: <info> [1634398238.2581] Config: added 'psk' value '<hidden>' Okt 16 17:30:38 raspi4.reschke.lan systemd[1]: Started Network Manager Script Dispatcher Service. Okt 16 17:30:38 raspi4.reschke.lan chronyd[1796]: Source 2a01:4f8:212:2058::99 offline Okt 16 17:30:39 raspi4.reschke.lan NetworkManager[413]: <info> [1634398239.3133] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:30:39 raspi4.reschke.lan NetworkManager[413]: <info> [1634398239.3134] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:30:40 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Trying to associate with SSID 'FRITZTuxNetzwerk' Okt 16 17:30:40 raspi4.reschke.lan NetworkManager[413]: <info> [1634398240.2579] device (wlan0): supplicant interface state: scanning -> associating Okt 16 17:30:40 raspi4.reschke.lan NetworkManager[413]: <info> [1634398240.2580] device (p2p-dev-wlan0): supplicant management interface state: scanning -> associating Okt 16 17:30:41 raspi4.reschke.lan wpa_supplicant[461]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=04:f0:21:0a:62:c7 status_code=16 Okt 16 17:30:41 raspi4.reschke.lan wpa_supplicant[461]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="FRITZTuxNetzwerk" auth_failures=1 duration=10 reason=CONN_FAILED Okt 16 17:30:41 raspi4.reschke.lan NetworkManager[413]: <info> [1634398241.5285] device (wlan0): supplicant interface state: associating -> disconnected Okt 16 17:30:41 raspi4.reschke.lan NetworkManager[413]: <info> [1634398241.5286] device (p2p-dev-wlan0): supplicant management interface state: associating -> disconnected Okt 16 17:30:48 raspi4.reschke.lan systemd[1]: NetworkManager-dispatcher.service: Succeeded. Okt 16 17:30:51 raspi4.reschke.lan NetworkManager[413]: <info> [1634398251.5498] device (wlan0): supplicant interface state: disconnected -> scanning Okt 16 17:30:51 raspi4.reschke.lan NetworkManager[413]: <info> [1634398251.5499] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> scanning Okt 16 17:30:52 raspi4.reschke.lan wpa_supplicant[461]: wlan0: CTRL-EVENT-SSID-REENABLED id=0 ssid="FRITZTuxNetzwerk" Okt 16 17:30:52 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Trying to associate with SSID 'FRITZTuxNetzwerk' Okt 16 17:30:52 raspi4.reschke.lan NetworkManager[413]: <info> [1634398252.5154] device (wlan0): supplicant interface state: scanning -> associating Okt 16 17:30:52 raspi4.reschke.lan NetworkManager[413]: <info> [1634398252.5155] device (p2p-dev-wlan0): supplicant management interface state: scanning -> associating Okt 16 17:30:53 raspi4.reschke.lan wpa_supplicant[461]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=04:f0:21:0a:62:c7 status_code=16 Okt 16 17:30:53 raspi4.reschke.lan wpa_supplicant[461]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="FRITZTuxNetzwerk" auth_failures=2 duration=20 reason=CONN_FAILED Okt 16 17:30:53 raspi4.reschke.lan NetworkManager[413]: <info> [1634398253.4553] device (wlan0): supplicant interface state: associating -> disconnected Okt 16 17:30:53 raspi4.reschke.lan NetworkManager[413]: <info> [1634398253.4554] device (p2p-dev-wlan0): supplicant management interface state: associating -> disconnected Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <warn> [1634398263.4589] device (wlan0): Activation: (wifi) association took too long Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <info> [1634398263.4590] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed') Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <warn> [1634398263.4620] device (wlan0): Activation: (wifi) asking for new secrets Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <warn> [1634398263.4628] device (wlan0): no secrets: No agents were available for this request. Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <info> [1634398263.4629] device (wlan0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed') Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <warn> [1634398263.4799] device (wlan0): Activation: failed for connection 'FRITZTuxNetzwerk' Okt 16 17:31:03 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Reject scan trigger since one is already pending Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <info> [1634398263.4915] device (wlan0): supplicant interface state: disconnected -> scanning Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <info> [1634398263.4916] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> scanning Okt 16 17:31:03 raspi4.reschke.lan NetworkManager[413]: <info> [1634398263.4941] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') Okt 16 17:31:04 raspi4.reschke.lan NetworkManager[413]: <info> [1634398264.4237] device (wlan0): supplicant interface state: scanning -> disconnected Okt 16 17:31:04 raspi4.reschke.lan NetworkManager[413]: <info> [1634398264.4239] device (p2p-dev-wlan0): supplicant management interface state: scanning -> disconnected Okt 16 17:31:06 raspi4.reschke.lan NetworkManager[413]: <info> [1634398266.4845] device (wlan0): supplicant interface state: disconnected -> scanning Okt 16 17:31:06 raspi4.reschke.lan NetworkManager[413]: <info> [1634398266.4846] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> scanning Okt 16 17:31:07 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:07 raspi4.reschke.lan NetworkManager[413]: <info> [1634398267.4257] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:07 raspi4.reschke.lan NetworkManager[413]: <info> [1634398267.4259] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:31:09 raspi4.reschke.lan NetworkManager[413]: <info> [1634398269.4843] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:31:09 raspi4.reschke.lan NetworkManager[413]: <info> [1634398269.4844] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:31:10 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:10 raspi4.reschke.lan NetworkManager[413]: <info> [1634398270.4279] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:10 raspi4.reschke.lan NetworkManager[413]: <info> [1634398270.4280] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:31:15 raspi4.reschke.lan NetworkManager[413]: <info> [1634398275.4846] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:31:15 raspi4.reschke.lan NetworkManager[413]: <info> [1634398275.4847] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:31:16 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:16 raspi4.reschke.lan NetworkManager[413]: <info> [1634398276.4248] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:16 raspi4.reschke.lan NetworkManager[413]: <info> [1634398276.4250] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:31:16 raspi4.reschke.lan NetworkManager[413]: <info> [1634398276.4650] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:31:16 raspi4.reschke.lan NetworkManager[413]: <info> [1634398276.4652] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:31:17 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:17 raspi4.reschke.lan NetworkManager[413]: <info> [1634398277.4048] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:17 raspi4.reschke.lan NetworkManager[413]: <info> [1634398277.4050] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:31:20 raspi4.reschke.lan NetworkManager[413]: <info> [1634398280.4846] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:31:20 raspi4.reschke.lan NetworkManager[413]: <info> [1634398280.4847] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:31:21 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:21 raspi4.reschke.lan NetworkManager[413]: <info> [1634398281.4246] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:21 raspi4.reschke.lan NetworkManager[413]: <info> [1634398281.4247] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:31:25 raspi4.reschke.lan NetworkManager[413]: <info> [1634398285.4865] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:31:25 raspi4.reschke.lan NetworkManager[413]: <info> [1634398285.4866] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:31:26 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:26 raspi4.reschke.lan NetworkManager[413]: <info> [1634398286.4249] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:26 raspi4.reschke.lan NetworkManager[413]: <info> [1634398286.4250] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:31:32 raspi4.reschke.lan NetworkManager[413]: <info> [1634398292.4867] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:31:32 raspi4.reschke.lan NetworkManager[413]: <info> [1634398292.4868] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:31:33 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:33 raspi4.reschke.lan NetworkManager[413]: <info> [1634398293.4268] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:33 raspi4.reschke.lan NetworkManager[413]: <info> [1634398293.4269] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:31:42 raspi4.reschke.lan NetworkManager[413]: <info> [1634398302.4840] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:31:42 raspi4.reschke.lan NetworkManager[413]: <info> [1634398302.4841] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:31:43 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:43 raspi4.reschke.lan NetworkManager[413]: <info> [1634398303.4236] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:43 raspi4.reschke.lan NetworkManager[413]: <info> [1634398303.4237] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:31:56 raspi4.reschke.lan NetworkManager[413]: <info> [1634398316.4871] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:31:56 raspi4.reschke.lan NetworkManager[413]: <info> [1634398316.4872] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:31:57 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:31:57 raspi4.reschke.lan NetworkManager[413]: <info> [1634398317.4271] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:31:57 raspi4.reschke.lan NetworkManager[413]: <info> [1634398317.4272] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive Okt 16 17:32:16 raspi4.reschke.lan NetworkManager[413]: <info> [1634398336.4971] device (wlan0): supplicant interface state: inactive -> scanning Okt 16 17:32:16 raspi4.reschke.lan NetworkManager[413]: <info> [1634398336.4972] device (p2p-dev-wlan0): supplicant management interface state: inactive -> scanning Okt 16 17:32:17 raspi4.reschke.lan wpa_supplicant[461]: wlan0: Failed to initiate sched scan Okt 16 17:32:17 raspi4.reschke.lan NetworkManager[413]: <info> [1634398337.4368] device (wlan0): supplicant interface state: scanning -> inactive Okt 16 17:32:17 raspi4.reschke.lan NetworkManager[413]: <info> [1634398337.4369] device (p2p-dev-wlan0): supplicant management interface state: scanning -> inactive |
||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
121 | [AlmaLinux-8] -OTHER | minor | always | 2021-08-27 22:02 | 2021-10-14 14:41 |
Reporter: | Berkey | Platform: | x86_64 | ||
Assigned To: | OS: | alma | |||
Priority: | normal | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Anaconda doesnt support Rufus default/recommended iso creation method | ||||
Description: | It seems anaconda installer does not fully support offline usb iso based installation. Although installer boots up normally, the 9gb usb iso key isn't available for use as the install source. Installer keeps trying to force user to setup online repo. | ||||
Tags: | |||||
Steps To Reproduce: | Tried multiple times, and experienced the same outcome. Once I had created the usb installer using Rufus with DD mode instead of ISO based anaconda properly detected the files from my usb key instead prompting to setup an online repo. | ||||
Additional Information: | Apologies if I have formatted this report incorrectly or in the wrong place, I have never reported a bug before, but I thought this information might be helpful to others. I understand technically I was doing it wrong, but I hope there is a good reason to only support DD mode. | ||||
Attached Files: | |||||
Notes | |
(0000344)
alukoshko 2021-10-14 14:41 |
AFAIK it's upstream issue and latest RHEL/CentOS versions require DD too |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
105 | [AlmaLinux-8] -OTHER | feature | N/A | 2021-06-23 05:15 | 2021-10-14 14:40 |
Reporter: | ziex | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Parsable errata format | ||||
Description: |
Huge fan that errata is available via errata.almalinux.org. However, we use a platform for patching servers automatically and thus we parse errata. For CentOS we have been using unofficial errata cefs[.]steve-meier[.]de. For AlmaLinux we would like errata to be published in a structured format (such as JSON or XML), so we won't have to parse HTML that will likely change some day. |
||||
Tags: | |||||
Steps To Reproduce: | - | ||||
Additional Information: | - | ||||
Attached Files: | |||||
Notes | |
(0000291)
alukoshko 2021-06-29 15:16 |
Hello. Errata is also available in traditional updateinfo.xml format for dnf, for example: https://repo.almalinux.org/almalinux/8/BaseOS/x86_64/os/repodata/321c965c99e4179149d63e824b6e2f168e2b6761358681cb54ea41adda030f4e-updateinfo.xml.gz Is it an option for you? |
(0000343)
alukoshko 2021-10-14 14:40 |
We now also have it in JSON: https://errata.almalinux.org/8/errata.json |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
131 | [AlmaLinux-8] thunderbird | minor | have not tried | 2021-10-05 13:33 | 2021-10-09 01:37 |
Reporter: | arrfab | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | [RFE] Enable openGPG support in thunderbird | ||||
Description: |
Long story short : opengpg support is there by default in upstream thunderbird, but disabled by Red Hat for RHEL (see https://bugzilla.redhat.com/show_bug.cgi?id=1886958) We (CentOS Side) decided to rebuild it with a specific patch that in fact revert the rhel patch, and so provide a thunderbird package that can be use for openpgp. The simple patch can be seen in the centosplus branch : https://git.centos.org/rpms/thunderbird/c/fac902a8f3bb58e71da8144a54061da4dcbf1735?branch=c8-plus This is a RFE to consider either rebuilding thunderbird with that feature, or just do like for centos : rebuild in/for another repository Reason is simple : we saw people (including RHEL users) using that pkg as they needed gpg support in thunderbird, and as CentOS 8 will disappear end of this year (and so centosplus repository) people switching to another compatible rebuild will start searching for same level of compatibility |
||||
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: |
130 | [AlmaLinux-8] selinux-policy | block | always | 2021-10-04 22:25 | 2021-10-04 22:52 |
Reporter: | jtremblay | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | when using CHEF to manage SELINUX the cookbook fails | ||||
Description: |
- selinux (2.1.1) - selinux_policy (2.4.3) Recipe: selinux::_common * selinux_install[selinux os prep] action install ================================================================================ Error executing action `install` on resource 'selinux_install[selinux os prep]' ================================================================================ RuntimeError ------------ not supported! Cookbook Trace: --------------- /var/chef/cache/cookbooks/selinux/resources/install.rb:29:in `block in class_from_file' Resource Declaration: --------------------- # In /var/chef/cache/cookbooks/selinux/recipes/_common.rb 2: selinux_install 'selinux os prep' Compiled Resource: ------------------ # Declared in /var/chef/cache/cookbooks/selinux/recipes/_common.rb:2:in `from_file' selinux_install("selinux os prep") do action [:install] default_guard_interpreter :default declared_type :selinux_install cookbook_name "selinux" recipe_name "_common" end System Info: ------------ chef_version=13.12.14 platform=almalinux platform_version=8.4 ruby=ruby 2.4.5p335 (2018-10-18 revision 65137) [x86_64-linux] program_name=chef-client worker: ppid=9037;start=17:59:19; executable=/opt/chef/bin/chef-client |
||||
Tags: | |||||
Steps To Reproduce: | install almalinux 8.4 with chef-client 13.12.14 and assign the cookbook recipe "selinux::disabled" | ||||
Additional Information: | this works on an identical RHEL 8.4 box both installed and bootstrapped into CHEF with the same runlist. | ||||
Attached Files: |
chef-stacktrace.out (8,006 bytes) 2021-10-04 22:25 https://bugs.almalinux.org/file_download.php?file_id=98&type=bug |
||||
Notes | |
(0000339)
jtremblay 2021-10-04 22:35 |
it seems that when CHEF is trying to identify Alma it fails when 'rhel', 'fedora', 'amazon' 26 package %w(policycoreutils selinux-policy selinux-policy-targeted libselinux-utils mcstrans) 27 else 28 # implement support for your platform here! 29 raise "#{node['platform_family']} not supported!" 30 end 31 |
(0000340)
jtremblay 2021-10-04 22:39 |
1 # 2 # Cookbook:: selinux 3 # Resource:: install 4 # 5 # Copyright:: 2016-2017, Chef Software, Inc. 6 # 7 # Licensed under the Apache License, Version 2.0 (the "License"); 8 # you may not use this file except in compliance with the License. 9 # You may obtain a copy of the License at 10 # 11 # http://www.apache.org/licenses/LICENSE-2.0 12 # 13 # Unless required by applicable law or agreed to in writing, software 14 # distributed under the License is distributed on an "AS IS" BASIS, 15 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 # See the License for the specific language governing permissions and 17 # limitations under the License. 18 19 action :install do 20 case node['platform_family'] 21 when 'debian' 22 package 'selinux-basics' 23 when 'ubuntu' 24 package %w(selinux-basics selinux-policy-default auditd) 25 when 'rhel', 'fedora', 'amazon','centos' 26 package %w(policycoreutils selinux-policy selinux-policy-targeted libselinux-utils mcstrans) 27 else 28 # implement support for your platform here! 29 raise "#{node['platform_family']} not supported!" 30 end 31 32 directory '/etc/selinux' do 33 owner 'root' 34 group 'root' 35 mode '0755' 36 action :create 37 end 38 end ~ |
(0000341)
jtremblay 2021-10-04 22:52 |
I added and removed 'centos' for testing I also changed the os-release to NAME="AlmaLinux" VERSION="8.4 (Electric Cheetah)" ID="almalinux" ID_LIKE="fedora" VERSION_ID="8.4" PLATFORM_ID="platform:el8" PRETTY_NAME="AlmaLinux 8.4 (Electric Cheetah)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:almalinux:almalinux:8.4:GA" HOME_URL="https://almalinux.org/" DOCUMENTATION_URL="https://wiki.almalinux.org/" BUG_REPORT_URL="https://bugs.almalinux.org/" ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8" ALMALINUX_MANTISBT_PROJECT_VERSION="8.4" No change |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
119 | [AlmaLinux-8] -OTHER | minor | always | 2021-08-21 20:48 | 2021-09-30 23:46 |
Reporter: | kissumisha | Platform: | |||
Assigned To: | sfokin | OS: | Alma | ||
Priority: | normal | OS Version: | 8.4 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | NetworkManager-wifi missing | ||||
Description: | The package is in the BaseOS/packages folder in the Minimal install (NetworkManager-wifi-1.30.0-7.el8.x86_64), but this package doesn't get installed. Of couse with an Ethernet connection it's as easy as "dnf install" but if Ethernet is not available it becomes a pain because of all dependencies need to be installed. | ||||
Tags: | |||||
Steps To Reproduce: | Every fresh install of AlmaLinux 8.4 | ||||
Additional Information: | |||||
Attached Files: |
01.jpg (133,260 bytes) 2021-08-26 13:46 https://bugs.almalinux.org/file_download.php?file_id=95&type=bug 02.jpg (122,633 bytes) 2021-08-26 13:46 https://bugs.almalinux.org/file_download.php?file_id=96&type=bug 03.jpg (255,011 bytes) 2021-08-26 13:46 https://bugs.almalinux.org/file_download.php?file_id=97&type=bug |
||||
Notes | |
(0000326)
sfokin 2021-08-26 13:46 |
Hi. I setup alma 8.4 on virtual machine. chose profile 'Server with GUI'. NetworkManager-wifi was installed by anaconda. could you check it again? |
(0000338)
kissumisha 2021-09-30 23:46 |
No I haven't tried with GUI. I go with the most minimal installation, so it's CLI interface. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
129 | [AlmaLinux-8] -OTHER | minor | have not tried | 2021-09-26 03:11 | 2021-09-26 03:11 |
Reporter: | netroby | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Missing packages for install kcm-fcitx | ||||
Description: |
Missing packages for install kcm-fcitx, But the upstream RHEL packages looks have these packages. # dnf install kcm-fcitx Last metadata expiration check: 0:03:30 ago on Sun 26 Sep 2021 11:07:18 AM CST. Error: Problem: package kcm-fcitx-0.5.5-7.el8.x86_64 requires libFcitxQt5WidgetsAddons.so.1()(64bit), but none of the providers can be installed - package kcm-fcitx-0.5.5-7.el8.x86_64 requires libFcitxQt5DBusAddons.so.1()(64bit), but none of the providers can be installed - conflicting requests - nothing provides libQt5Gui.so.5(Qt_5.11.1_PRIVATE_API)(64bit) needed by fcitx-qt5-1.2.4-3.el8.x86_64 - nothing provides qt5-qtbase(x86-64) = 5.11.1 needed by fcitx-qt5-1.2.4-3.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) |
||||
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 | [AlmaLinux-8] -OTHER | minor | N/A | 2021-09-02 02:53 | 2021-09-02 22:45 |
Reporter: | fdr | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Improve AWS AMI ID acquisition instructions | ||||
Description: |
AlmaLinux's documentation on how to find AMIs could be expanded for the benefit of those that want to automatically acquire new base images. Compare https://web.archive.org/web/20210720172500/https://wiki.almalinux.org/cloud/AWS.html to https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html. Some differences: * AlmaLinux has both Marketplace and "Community" AMIs. Is the Marketplace one "official?" is the "community" account number -- not documented anywhere -- held in as strict confidence as images that make it to the marketplace? Why would I use one or the other? Why am I given this choice? Whereas, Amazon Linux really has only one method: public images, most comparable to "community" AMIs. "System Manager" is used to retrieve latest AMI ID. An older way to do something similar is to make careful use of naming conventions and a well-known account number. CentOS offers their account number, https://wiki.centos.org/Cloud/AWS. So does Oracle Linux, https://community.oracle.com/tech/apps-infra/discussion/4417739/launch-an-oracle-linux-instance-in-aws * A major downside of Marketplace is that it's necessary to associate the product subscription with each account using it. This has different APIs, different SDKs, different IAM policies required than what would be required for most programs using EC2. * AWS provides precise API calls used to get the latest AMI, indicating how they anticipate you will source new image IDs, and will keep it working. None of the other systems do, but they should, and in practice, code of this kind works practically indefinitely: images( owners: ["764336703387"], filters: [ {name: "name", values: ["AlmaLinux OS 8.* x86_64"]}, {name: "state", values: ["available"]} ] ).max_by { |img| img.creation_date }.id The following such wildcarded strings can be useful for different levels of automatic updates: AlmaLinux OS * x86_64 AlmaLinux OS 8.* x86_64 AlmaLinux OS 8.4.* x86_64 |
||||
Tags: | aws, cloud | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000329)
fdr 2021-09-02 02:58 |
For more information about this "parameter store" that Amazon Linux uses, see https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html. I haven't used this much myself, but I seem to remember following AWS instructions to use it in the past and it was no sweat. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
118 | [AlmaLinux-8] anaconda | feature | always | 2021-08-20 06:39 | 2021-08-20 06:39 |
Reporter: | lee | Platform: | Linux | ||
Assigned To: | OS: | EL8 | |||
Priority: | normal | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | VirtualBox Guest Additions in AlmaLinux | ||||
Description: |
It would be great to have guest editions in the Alma Linux installer, and the final install like Fedora does. The above makes deploying in VMs very pleasant. |
||||
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: |
115 | [AlmaLinux-8] almalinux-logos | minor | N/A | 2021-08-11 05:16 | 2021-08-12 10:53 |
Reporter: | srbala | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Add a `PNG` format background image in `almalinux-backgrounds` package for XFCE Live use | ||||
Description: |
Note: This is feature request to `almalinux-backgrounds` package, Category missing for his package. XFCE window manager expects desktop default background at `/usr/share/backgrounds/images/default.png` Since current package only includes only `.jpg` format, XFCE Live ISO loads with empty background. |
||||
Tags: | |||||
Steps To Reproduce: |
Convert one of high res image and named it to `/usr/share/backgrounds/images/default.png` (Almalinux-dark?) |
||||
Additional Information: |
1. Needed this for AlmaLinux XFCE Live image. 2. Prefer to have one of each type background should be added. 3. Added one image XFCE Beta use. |
||||
Attached Files: |
Alma-dark-2048x1536.png (642,903 bytes) 2021-08-11 05:16 https://bugs.almalinux.org/file_download.php?file_id=94&type=bug |
||||
Notes | |
(0000322)
srbala 2021-08-11 11:57 |
Reverse link to channel discussion https://chat.almalinux.org/almalinux/pl/yethkf1wdjbgujmihie7knqdja Sample XFCE https://user-images.githubusercontent.com/1273137/129016230-1921cc3b-f949-421e-a31a-18336507a632.png |
(0000323)
srbala 2021-08-11 12:27 |
Need to update/replace `/etc/xdg/kcm-about-distrorc` with following content to fix KInfo [General] LogoPath=/usr/share/icons/hicolor/256x256/apps/fedora-logo-icon.png Website=https://almalinux.org/ |
(0000324)
srbala 2021-08-12 10:53 |
Created a repo for contents of the `extras` package and rpm post install script https://github.com/srbala/almalinux-backgrounds-extras |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
116 | [AlmaLinux-8] targetcli | major | always | 2021-08-11 14:06 | 2021-08-11 14:06 |
Reporter: | nicolae | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | db_root: cannot open: /etc/target | ||||
Description: |
After installing (fresh install) AlmaLinux 8.4 on three Supermicro servers at boot i have the error db_root: cannot open: /etc/target . All servers have Avago 3108 Raid card. Also at boot, after showing the available kernel, it stays with blinking cursor more than a minute. If i install targetcli that error disappears, but it still stays too long with blinking cursor. The servers are set to boot in legacy mode. [root@localhost ~]# systemd-analyze blame 6.204s NetworkManager-wait-online.service 1.295s systemd-udev-settle.service 592ms dracut-initqueue.service 439ms tuned.service 277ms initrd-switch-root.service 223ms vdo.service 222ms rdma-load-modules@rdma.service 176ms sssd.service 162ms lvm2-monitor.service |
||||
Tags: | |||||
Steps To Reproduce: | Fresh install on Supermicro server. | ||||
Additional Information: | |||||
Attached Files: | |||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
114 | [AlmaLinux-8] libva | block | always | 2021-08-01 22:21 | 2021-08-10 07:50 |
Reporter: | puya | Platform: | |||
Assigned To: | OS: | AlmaLinux | |||
Priority: | high | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | vainfo: vaInitialize failed with error code -1 (unknown libva error) | ||||
Description: |
Background ----------------- I've been trying to build gstreamer-vaapi (needed by Qt) as it is missing from EPEL. The build/installation seems to go fine but when I run: > gst-inspect-1.0 vaapi All I get is "0 features". (e.g. missing vaapisink needed by Qt's runtime). Not sure if this matters but running with `GST_DEBUG=7` I get: ``` extension is not recognized as module file, ignoring file /usr/lib64/gstreamer-1.0/include/gst/gl/gstglconfig.h extension is not recognized as module file, ignoring file /usr/lib64/gstreamer-1.0/libgstvaapi.la ``` In any case, in order to debug the above I tried installing `libva-utils` and running vainfo, this returns: ``` vaInitialize failed with error code -1 (unknown libva error) ``` The Issue -------- Any ideas why I would get "0 Features" for my gstreamer-vaapi installation? How do I fix my va-api installation so that vainfo does not fail to initialize the deriver? |
||||
Tags: | AlmaLinux, Bug | ||||
Steps To Reproduce: |
``` $ dnf install libva-devel libva-utils libva-intel-driver ... $ vainfo libva info: VA-API version 1.5.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_4 libva error: /usr/lib64/dri/i965_drv_video.so init failed libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit ``` |
||||
Additional Information: |
Please let me know what other information would be useful. I am out of my depth here since my original issue was the Qt runtime failing. So any help / hint / ideas or info you may have that might nudge me in the right direction are greatly appreciated! |
||||
Attached Files: | |||||
Notes | |
(0000321)
enigma131 2021-08-10 07:50 |
Without information coming from your hardware (GPU part) , difficult to answer |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
110 | [AlmaLinux-8] almalinux-release | block | always | 2021-06-29 11:58 | 2021-07-27 12:05 |
Reporter: | Wumbeer | Platform: | Dell PowerEdge T340 | ||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.4 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Fresh install - do all updates - reboot - BIOS does not find OS - no grub | ||||
Description: |
Fresh install of AlmaLinux will not boot after updates - BIOS message about no bootable device or operating system. You do not even get to grub menu showing kernels. Been running AlamaLinux for few months on this server and was just doing updates and killed it. I reinstalled again and did a yum update and it broke again, exact same way, so it is reproducible. Not sure what is killing it, I assume a grub problem. I found https://www.reddit.com/r/CentOS/comments/i0ozrs/cant_boot_in_after_latest_kernel_update_for/ 3 which seems similar, but 11 months ago, so we tried it - and I get same problem user Joeg1484 got. Gave up and just not going to install updates. |
||||
Tags: | |||||
Steps To Reproduce: |
1. Install AlmaLinux 2. Update all packages (coming from CentOS so I been using yum) 3. Reboot |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000290)
alukoshko 2021-06-29 13:15 |
Hello. Are you in BIOS or UEFI mode? Is Secure Boot enabled? What version I should install to reproduce update bug 8.3 or 8.4? |
(0000296)
Wumbeer 2021-06-30 19:28 |
UEFI mode. Secure boot is not enabled. 8.4 was the version. |
(0000297)
Wumbeer 2021-06-30 19:35 |
I verified just to make sure I was not incorrect about the above: [root@virtual1 ~]# mokutil --sb-state SecureBoot disabled [root@virtual1 ~]# ls -l /sys/firmware/efi total 0 -r--r--r--. 1 root root 4096 Jun 30 15:29 config_table drwxr-xr-x. 2 root root 0 Jun 27 14:08 efivars -r--r--r--. 1 root root 4096 Jun 30 15:29 fw_platform_size -r--r--r--. 1 root root 4096 Jun 30 15:29 fw_vendor drwxr-xr-x. 2 root root 0 Jun 30 15:29 mok-variables -r--r--r--. 1 root root 4096 Jun 30 15:29 runtime drwxr-xr-x. 9 root root 0 Jun 30 15:29 runtime-map -r--------. 1 root root 4096 Jun 30 15:29 systab drwxr-xr-x. 2 root root 0 Jun 30 15:29 tables drwxr-xr-x. 77 root root 0 Jun 30 15:29 vars |
(0000319)
sfokin 2021-07-27 12:05 |
I have the same situation for 'mokutil --sb-state' and 'ls -l /sys/firmware/efi'. I've installed system, update them by 'yum update' and it rebooted without any problem. I've repeated this twice. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
73 | [AlmaLinux-8] almalinux-release | minor | sometimes | 2021-05-02 05:40 | 2021-07-24 10:47 |
Reporter: | kfujinaga | Platform: | |||
Assigned To: | sfokin | OS: | |||
Priority: | normal | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | The specified timezone is not set. | ||||
Description: |
In the Installation, I set a timezone value to Asia/Tokyo(JST : +9:00). But the timezone value was Shanghai/China(CST : +8:00) after after Installation, At first login, the system required authentication of administrator. Before the authentication, timezone was correct. (see "2021-05-02_12h51_22.png". Time was 12:51.) After the authentication, timezone was incorrect. (see "2021-05-02_12h51_33.png". Time was 11:51. (-1 hour)) After all, timezone was CST.(see "2021-05-02_12h52_22.png") I found the same bug at CentOS 8.3 and Rocky Linux 8.3RC1. |
||||
Tags: | |||||
Steps To Reproduce: |
Step 1: Boot almalinux-8.3 image. Step 2: Set "Language" value to "English". Step 3: Set "Timezone" value to "Asia/Tokyo(JST)" in "Time & Date".(see "2021-05-02_12h33_16.png") Step 4: Set root password in "Root Password". Step 5: Create user "testuser" in "User Creation". Step 6: Select automatic partitioning in "Installation Destination". Step 7: Set network and hostname in "Network & Host Name" Step 8: Begin "Installation". Step 9: Reboot. Step 10: Accept license. Step 11: Login (testuser). Step 12: System require authentication. input password. (Timezone is changed!!) (see "2021-05-02_12h51_22.png" and "2021-05-02_12h51_33.png") Step 13: Perform the rest of the Installation. Step 14: See "Settings -> Details -> Date & Time". (Timezone is CST)(See "2021-05-02_12h52_22.png") |
||||
Additional Information: | |||||
Attached Files: |
2021-05-02_12h33_16.png (582,014 bytes) 2021-05-02 05:40 https://bugs.almalinux.org/file_download.php?file_id=71&type=bug 2021-05-02_12h51_22.png (225,651 bytes) 2021-05-02 05:40 https://bugs.almalinux.org/file_download.php?file_id=72&type=bug 2021-05-02_12h51_33.png (76,904 bytes) 2021-05-02 05:40 https://bugs.almalinux.org/file_download.php?file_id=73&type=bug 2021-05-02_12h52_22.png (95,430 bytes) 2021-05-02 05:40 https://bugs.almalinux.org/file_download.php?file_id=74&type=bug |
||||
Notes | |
(0000270)
alukoshko 2021-06-09 22:07 |
Hello! Have you tried 8.4? Is bug still here? |
(0000271)
kfujinaga 2021-06-09 23:39 |
AlmaLinux 8.4 (and rhel 8.4, rocky linux 8.4 rc) has the same problem. |
(0000310)
carlwgeorge 2021-07-21 21:17 |
Being reproducible on RHEL 8.4 is a good data point. My suggestion would be to also attempt to reproduce on CentOS Stream 8. If it's already fixed there, it will be easiest to just wait until the fix propagates through RHEL 8.5. If it's not fixed there, we can work on this as a contribution under the Stream model. You may also consider trying to reproduce on CentOS Stream 9 or Fedora, to help determine if this is already fixed this in a newer version of anaconda. Backporting an upstream commit (if it exists) is preferable to writing a brand new patch for RHEL 8's version of anaconda. |
(0000311)
sfokin 2021-07-23 11:45 |
CentOS Stream 8 reproduced. Where I can get Stream 9 iso for trying reproduce bug? |
(0000313)
carlwgeorge 2021-07-23 20:56 |
It's still early in the CS9 development, but the CentOS Stream download page [0] links to this email [1] about the new compose infrastructure, which includes this link [2]. Digging into the directory structure, you can find the current ISO in this directory [3]. [0] https://centos.org/centos-stream/ [1] https://lists.centos.org/pipermail/centos-devel/2021-April/076802.html [2] https://composes.stream.centos.org/ [3] https://composes.stream.centos.org/development/latest-CentOS-Stream/compose/BaseOS/x86_64/iso/ |
(0000314)
kfujinaga 2021-07-24 10:01 |
I can't reproduce this bug on CentOS Stream 9. (I tried three times, the system didn't require the authentication) I will post a bug report about centos stream 8 to the centos.org. |
(0000315)
alukoshko 2021-07-24 10:13 |
Hi! CentOS Stream bugs should be reported to Red Hat Bugzilla https://wiki.centos.org/ReportBugs |
(0000316)
kfujinaga 2021-07-24 10:46 |
I post a report to to Red Hat Bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=1985607 |
(0000317)
kfujinaga 2021-07-24 10:47 |
I post a report to Red Hat Bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=1985607 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
111 | [AlmaLinux-8] hplip | minor | always | 2021-06-29 18:11 | 2021-07-20 09:33 |
Reporter: | lcohen999 | Platform: | |||
Assigned To: | sfokin | OS: | |||
Priority: | normal | OS Version: | |||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | hp-plugin does not recognize almalinux | ||||
Description: | It pops up with a message about it and continues but says unrecognized | ||||
Tags: | |||||
Steps To Reproduce: | hp-plugin -i | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000306)
sfokin 2021-07-16 12:55 |
We delivered fixed version hplip-3.18.4-9.el8.alma to our repo. Check it please. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
107 | [AlmaLinux-8] lvm2 | major | always | 2021-06-27 21:53 | 2021-07-19 09:32 |
Reporter: | SteffanCline | Platform: | |||
Assigned To: | sfokin | OS: | Alma Linux 8 | ||
Priority: | normal | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | lvcreate/lvremove not honoring lvm.conf | ||||
Description: |
Per RHEL's bugzilla, the issue of lvcreate/lvremove was fixed years ago to automatically ignore previous signatures when wipe_signatures_when_zeroing_new_lvs=1 is set in /etc/lvm/lvm.conf. # lvcreate -L 10G -n test vg_h6 WARNING: ext4 signature detected on /dev/vg_h6/test at offset 1080. Wipe it? [y/n]: n Aborted wiping of ext4. 1 existing signature left on the device. Failed to wipe signatures on logical volume vg_h6/test. Aborting. Failed to wipe start of new LV. While the -y flag exists and does work, it's not supposed to be required. # lvcreate -y -L 10G -n test vg_h6 Wiping ext4 signature on /dev/vg_h6/test. Logical volume "test" created. I have tested this on Fedora 33, RHEL8, CentOS 6/7/8 and Amazon Linux and they honor the lvm.conf Below are some previously reported issues about this. https://bugzilla.redhat.com/show_bug.cgi?id=997223 https://bugzilla.redhat.com/show_bug.cgi?id=1946199 |
||||
Tags: | lvcreate, lvm, lvm.conf, lvremove, signatures | ||||
Steps To Reproduce: |
Fresh install of AL 8 Create a LVM Remove the LVM Create again Remove again. You'll be prompted to enter y/n. |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000293)
pastfu 2021-06-30 07:44 |
I ran into this when doing a fresh install over an existing CentOS installation. After installation I was unable to boot from the HD with an error indicating dracut scan for cl/root and cl/swap failed. I could only boot by using the installation thumb drive, which I could then remove. Practical solution for this instance was to rename the volume group name to cl. I can now boot normally from the HD. I used the one line script from here to accomplish the renaming: https://forums.centos.org/viewtopic.php?t=62406 |
(0000308)
sfokin 2021-07-19 09:32 |
I've tested one method in 3 OS and here are results: =================== # cat /etc/redhat-release CentOS Linux release 8.4.2105 # grep 'wipe_signatures_when_zeroing_new_lvs' /etc/lvm/lvm.conf # Configuration option allocation/wipe_signatures_when_zeroing_new_lvs. wipe_signatures_when_zeroing_new_lvs = 1 # lvremove /dev/test1/stor1 Do you really want to remove active logical volume test1/stor1? [y/n]: y Logical volume "stor1" successfully removed # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # mkfs -t xfs /dev/test1/lvol0 meta-data=/dev/test1/lvol0 isize=512 agcount=4, agsize=624896 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 data = bsize=4096 blocks=2499584, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed # lvcreate -l 100%FREE test1 WARNING: xfs signature detected on /dev/test1/lvol0 at offset 0. Wipe it? [y/n]: y Wiping xfs signature on /dev/test1/lvol0. Logical volume "lvol0" created. =================== # cat /etc/redhat-release CentOS Stream release 8 # grep 'wipe_signatures_when_zeroing_new_lvs' /etc/lvm/lvm.conf # Configuration option allocation/wipe_signatures_when_zeroing_new_lvs. wipe_signatures_when_zeroing_new_lvs = 1 # lvremove /dev/test1/stor1 Do you really want to remove active logical volume test1/stor1? [y/n]: y Logical volume "stor1" successfully removed. # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed. # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed. # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # mkfs -t xfs /dev/test1/lvol0 meta-data=/dev/test1/lvol0 isize=512 agcount=4, agsize=624896 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 data = bsize=4096 blocks=2499584, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed. # lvcreate -l 100%FREE test1 WARNING: xfs signature detected on /dev/test1/lvol0 at offset 0. Wipe it? [y/n]: y Wiping xfs signature on /dev/test1/lvol0. Logical volume "lvol0" created. =================== # cat /etc/redhat-release AlmaLinux release 8.4 (Electric Cheetah) # grep 'wipe_signatures_when_zeroing_new_lvs' /etc/lvm/lvm.conf # Configuration option allocation/wipe_signatures_when_zeroing_new_lvs. wipe_signatures_when_zeroing_new_lvs = 1 # lvremove /dev/test1/stor1 Do you really want to remove active logical volume test1/stor1? [y/n]: y Logical volume "stor1" successfully removed # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed # lvcreate -l 100%FREE test1 Logical volume "lvol0" created. # mkfs -t xfs /dev/test1/lvol0 meta-data=/dev/test1/lvol0 isize=512 agcount=4, agsize=624896 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 data = bsize=4096 blocks=2499584, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 # lvremove /dev/test1/lvol0 Do you really want to remove active logical volume test1/lvol0? [y/n]: y Logical volume "lvol0" successfully removed # lvcreate -l 100%FREE test1 WARNING: xfs signature detected on /dev/test1/lvol0 at offset 0. Wipe it? [y/n]: y Wiping xfs signature on /dev/test1/lvol0. Logical volume "lvol0" created. =================== As you can see all OS have the same result. Is it normal behavior? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
35 | [AlmaLinux-8] anaconda | major | always | 2021-03-01 22:34 | 2021-07-14 13:27 |
Reporter: | bviktor | Platform: | |||
Assigned To: | ezamriy | OS: | |||
Priority: | normal | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Not bootable on Vultr | ||||
Description: |
I'm trying to install Alma Linux on Vultr via the custom ISO option. However, when I start the VPS instance, it gives me this error: Booting from DVD/CD... Boot failed: Could not read from CDROM (code 0003) Then proceeds to iPXE. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: |
Screenshot from 2021-03-01 23-33-55.png (258,089 bytes) 2021-03-01 22:34 https://bugs.almalinux.org/file_download.php?file_id=60&type=bug |
||||
There are no notes attached to this issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
77 | [AlmaLinux-8] -OTHER | feature | N/A | 2021-05-17 09:23 | 2021-07-14 07:21 |
Reporter: | lee | Platform: | All | ||
Assigned To: | OS: | All | |||
Priority: | normal | OS Version: | All | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Mailing Lists | ||||
Description: |
Hi, Kindly consider starting few mailing lists for Alma Linux. Thanks |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000204)
almalinuxjack 2021-05-20 18:37 |
Hi lee. I will look into this. Is there anything specific you are looking for besides a general list and a -devel? |
(0000205)
lee 2021-05-20 22:31 |
A -announce list also would be nice. Thanks. |
(0000303)
NeilW 2021-07-14 07:21 |
Particularly including the security alerts as CentOs does: https://lists.centos.org/pipermail/centos-announce/2021-July/048341.html |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
99 | [AlmaLinux-8] -OTHER | text | have not tried | 2021-06-09 21:50 | 2021-06-25 16:17 |
Reporter: | alma-devel | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Document install ISO preparation | ||||
Description: | How is the ISO generated? I need to make modifications and test due to an upstream bug in anaconda. | ||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000282)
mstauber 2021-06-25 16:17 |
I second that question. For the sake of reproducibility the Lorax and/or osbuilder configs to create ISO images should be published. It's not healthy that everyone (CentOS, AlmaLinux and RockyLinux) treats these as if they were state secrets. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
104 | [AlmaLinux-8] kernel | minor | always | 2021-06-22 16:21 | 2021-06-23 11:36 |
Reporter: | brlx | Platform: | |||
Assigned To: | OS: | ALMA | |||
Priority: | normal | OS Version: | 8.4 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Keyboard useless after wakeup | ||||
Description: |
After closing the laptop-lid Alma goes into suspended mode. When i wake up the machine by opening the lid, keystrokes into the password-field are either lagging, extremly repeating or not accepted. Switching to console provides the same: keyboard inputs are unusable |
||||
Tags: | |||||
Steps To Reproduce: |
- Have a full installed Laptop - in my case a fujitsu Lifebook E-series, - Close the Lid - wait for all LEDs to go off - open the lid - try to enter a password |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000280)
brlx 2021-06-23 11:36 |
After cross checking with Rocky this bug appears to be upstream |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
97 | [AlmaLinux-8] -OTHER | minor | always | 2021-06-04 12:40 | 2021-06-09 18:24 |
Reporter: | figless | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | several packages exist in BaseOS that should be in AppStream instead | ||||
Description: |
The following list details packages that exist in AlmaLinux BaseOS, which do not exist in RHEL BaseOS. The below packages instead exist in RHEL AppStream PackageKit:x86_64 exists in BaseOS, instead of AppStream PackageKit-glib:x86_64 exists in BaseOS, instead of AppStream abattis-cantarell-fonts:noarch exists in BaseOS, instead of AppStream bind-libs:x86_64 exists in BaseOS, instead of AppStream bind-libs-lite:x86_64 exists in BaseOS, instead of AppStream bind-license:noarch exists in BaseOS, instead of AppStream bind-utils:x86_64 exists in BaseOS, instead of AppStream cairo:x86_64 exists in BaseOS, instead of AppStream cairo-gobject:x86_64 exists in BaseOS, instead of AppStream cockpit-packagekit:noarch exists in BaseOS, instead of AppStream fstrm:x86_64 exists in BaseOS, instead of AppStream geolite2-city:noarch exists in BaseOS, instead of AppStream geolite2-country:noarch exists in BaseOS, instead of AppStream libX11:x86_64 exists in BaseOS, instead of AppStream libX11-common:noarch exists in BaseOS, instead of AppStream libXau:x86_64 exists in BaseOS, instead of AppStream libXext:x86_64 exists in BaseOS, instead of AppStream libXrender:x86_64 exists in BaseOS, instead of AppStream libatasmart:x86_64 exists in BaseOS, instead of AppStream libblockdev:x86_64 exists in BaseOS, instead of AppStream libblockdev-crypto:x86_64 exists in BaseOS, instead of AppStream libblockdev-fs:x86_64 exists in BaseOS, instead of AppStream libblockdev-loop:x86_64 exists in BaseOS, instead of AppStream libblockdev-mdraid:x86_64 exists in BaseOS, instead of AppStream libblockdev-part:x86_64 exists in BaseOS, instead of AppStream libblockdev-swap:x86_64 exists in BaseOS, instead of AppStream libblockdev-utils:x86_64 exists in BaseOS, instead of AppStream libbytesize:x86_64 exists in BaseOS, instead of AppStream libmaxminddb:x86_64 exists in BaseOS, instead of AppStream libudisks2:x86_64 exists in BaseOS, instead of AppStream libxcb:x86_64 exists in BaseOS, instead of AppStream libxkbcommon:x86_64 exists in BaseOS, instead of AppStream man-pages-overrides:noarch exists in BaseOS, instead of AppStream nmap-ncat:x86_64 exists in BaseOS, instead of AppStream nspr:x86_64 exists in BaseOS, instead of AppStream nss:x86_64 exists in BaseOS, instead of AppStream nss-softokn:x86_64 exists in BaseOS, instead of AppStream nss-softokn-freebl:x86_64 exists in BaseOS, instead of AppStream nss-sysinit:x86_64 exists in BaseOS, instead of AppStream nss-util:x86_64 exists in BaseOS, instead of AppStream pinentry:x86_64 exists in BaseOS, instead of AppStream pixman:x86_64 exists in BaseOS, instead of AppStream protobuf-c:x86_64 exists in BaseOS, instead of AppStream python3-bind:noarch exists in BaseOS, instead of AppStream python3-cairo:x86_64 exists in BaseOS, instead of AppStream python3-gobject:x86_64 exists in BaseOS, instead of AppStream python3-html5lib:noarch exists in BaseOS, instead of AppStream python3-lxml:x86_64 exists in BaseOS, instead of AppStream python3-pexpect:noarch exists in BaseOS, instead of AppStream python3-psutil:x86_64 exists in BaseOS, instead of AppStream python3-ptyprocess:noarch exists in BaseOS, instead of AppStream python3-pydbus:noarch exists in BaseOS, instead of AppStream python3-systemd:x86_64 exists in BaseOS, instead of AppStream python3-tracer:noarch exists in BaseOS, instead of AppStream python3-unbound:x86_64 exists in BaseOS, instead of AppStream python3-webencodings:noarch exists in BaseOS, instead of AppStream setroubleshoot-plugins:noarch exists in BaseOS, instead of AppStream setroubleshoot-server:x86_64 exists in BaseOS, instead of AppStream sscg:x86_64 exists in BaseOS, instead of AppStream tracer-common:noarch exists in BaseOS, instead of AppStream udisks2:x86_64 exists in BaseOS, instead of AppStream unbound-libs:x86_64 exists in BaseOS, instead of AppStream volume_key-libs:x86_64 exists in BaseOS, instead of AppStream xkeyboard-config:noarch exists in BaseOS, instead of AppStream |
||||
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: |
90 | [AlmaLinux-8] libyang | minor | always | 2021-06-01 15:28 | 2021-06-08 16:21 |
Reporter: | figless | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | libyang-devel does not match upstream | ||||
Description: |
The version of libyang-devel currently in AlmaLinux is currently 1.0.184-1, however the version available in RHEL is 0.16.105-3 Note that the version of libyang in RHEL is 1.0.184-1 |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000263)
alukoshko 2021-06-08 16:20 |
Hi! You're right. Red Hat stopped releasing libyang-devel long before AlmaLinux even born. I've moved libyang-devel packages to devel repo and keep only the following packages in AppStream: libyang-1.0.184-1.el8.i686.rpm libyang-1.0.184-1.el8.x86_64.rpm That matches CentOS 8.4 behavior. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
94 | [AlmaLinux-8] -OTHER | crash | have not tried | 2021-06-02 14:57 | 2021-06-04 17:41 |
Reporter: | mcarrafiello | Platform: | x86_64 | ||
Assigned To: | alukoshko | OS: | almalinux | ||
Priority: | normal | OS Version: | 8.4 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | 8.4 Minimal ISO fails to install when using PCI-DSS security baseline due to missing packages | ||||
Description: |
I'm trying out the 8.4 minimal ISO on a HPE server over iLO. The machine, has no networking, and thus, the minimal installation has to pull everything from the ISO image. When using the PCI:DSS security profile, the installer correctly states it is going to include more packages like openscap & aide. During the installation process, and error is tripped when trying to install those same packages, and if you ignore them, then a more fatal error is tripped when the process seemingly tries to use the openscap program which it previously couldn't install. The installation fails. I think the root cause is that any "extra packages" which the security baselines need may not be included in the minimal ISO, and on a machine without networking, it makes a mess. So this issue is less of a problem with AlmaLinux or the Anaconda installer, and more about how the ISO is packed up. I'm a very experienced CentOS user, but I honestly don't know if I have ever tried to install the "minimal" ISO while the machine has absolutely no networking. I'm adapting and using our own [internal] instructions for "setting up CentOS 7 minimal on bare metal" to be used with AlmaLinux 8. It's possible this minimal ISO issue goes all the way up the foodchain to RHEL as well? -Marc |
||||
Tags: | |||||
Steps To Reproduce: | Try to install AlmaLinux 8.4 on a machine, using the minimal ISO file, without any networking configured at installation. Use the PCI:DSS security profile when configuring the installation. | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000255)
alukoshko 2021-06-04 17:41 |
Hello. Thanks for report. Minimal ISO includes only BaseOS repo and should only be used for simple minimal installations. Packages needed for OpenSCAP are in AppStream repo. You should try with full DVD ISO image to get OpenSCAP working. I'll add this to known issue. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
92 | [AlmaLinux-8] -OTHER | minor | have not tried | 2021-06-01 23:02 | 2021-06-04 17:27 |
Reporter: | phj557 | Platform: | alma linux | ||
Assigned To: | ezamriy | OS: | arm 8.4 beta | ||
Priority: | normal | OS Version: | arm 8.4 beta | ||
Status: | acknowledged | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | How to use arm .iso files? | ||||
Description: |
I have a raspberry pi 4. I've read https://wiki.almalinux.org/release-notes/8.4-beta-arm.html#providing-feedback-and-getting-help. There are no instructions on how to use the .iso files. There are instructions on how to download and verify AlmaLinux-8.4-beta-1-aarch64-minimal.iso, for example, but no instructions on how to use AlmaLinux-8.4-beta-1-aarch64-minimal.iso to boot my raspberry pi 4. How do I proceed? Thanks. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000253)
ezamriy 2021-06-04 17:25 |
Unfortunately, right now there is no way to install AlmaLinux on Raspberry PI. The same is true for CentOS and RHEL arm ISOs. The main problem is the EL8 kernel which doesn't support all required drivers, there are many small problems too. But RPi support is something we really want to implement and our ARM team is starting work on that very soon. Probably, it will be a special image with a custom kernel built specially for such devices. If you have some experience with such things, please join our AltArch SIG and participate in the development. If no, please stay tuned, you will have something to test this summer. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
71 | [AlmaLinux-8] autofs | major | always | 2021-04-27 18:48 | 2021-05-28 18:56 |
Reporter: | mleisher | Platform: | Penguin server | ||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.3 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Automount and LDAP problem | ||||
Description: |
Context: version 8.3, minimal install, sssd and autofs, ldaps. When I start automount via systemd (systemctl start autofs), automounting with LDAP lookups fails with the message: bind_ldap_simple: lookup(ldap): Unable to bind to the LDAP server: , error Can't contact LDAP server When I start automount from the command line with the same params as the systemd unit file (/usr/sbin/automount --systemd-service --dont-check-daemon), automounting from LDAP lookups works fine. |
||||
Tags: | |||||
Steps To Reproduce: |
Configure sssd for ldaps access for the usual suspects, including autofs. Configure PAM to use sssd. Start everything. Log in as any user with homespace on a separate NFS server. |
||||
Additional Information: | |||||
Attached Files: |
ldap (4,136 bytes) 2021-05-28 18:56 https://bugs.almalinux.org/file_download.php?file_id=90&type=bug |
||||
Notes | |
(0000194)
mleisher 2021-05-13 21:41 |
I reinstalled Alma Linux today and now get the "Unable to bind to the LDAP server: ," error no matter how I run automount. |
(0000195)
mleisher 2021-05-13 21:58 |
Now I'm getting the following error consistently: be[default][DDDD]: Could not start TLS encryption. error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (unable to get issuer certificate) This is with letsencrypt certs that have been working for years and still work on CentOS 8 and Oracle Linux configured exactly the same way I configured this Alma Linux dist: 1. authselect select sssd 2. sssd.conf and auto.master (below). 3. systemctl enable sssd ; systemctl start sssd 4. systemctl enable autofs ; systemctl start autofs sssd.conf ------------- [sssd] config_file_version = 2 services = nss, pam, autofs domains = default [nss] filter_groups = root filter_users = root [pam] [domain/default] auth_provider = ldap cache_credentials = True chpass_provider = ldap entry_cache_timeout = 30 enumerate = False id_provider = ldap ldap_basedn = dc=example,dc=com ldap_group_object_class = posixGroup ldap_group_search_base = ou=Group,dc=example,dc=com ldap_group_basedn = ou=Group,dc=example,dc=com ldap_id_use_start_tls = False ldap_schema = rfc2307 ldap_search_base = dc=example,dc=com ldap_tls_cert = /etc/openldap/certs/dapper.pem ldap_tls_reqcert = allow ldap_uri = ldaps://dapper.example.com ldap_user_basedn = ou=People,dc=example,dc=com ldap_user_search_base = ou=People,dc=example,dc=com [autofs] auto.master ----------------- /home ldaps://dapper/nisMapName=auto.home,dc=example,dc=com /user ldaps://dapper/nisMapName=auto.user,dc=example,dc=com |
(0000249)
alukoshko 2021-05-28 16:32 |
AlmaLinux 8.4 is released. Could you check LDAP connection on updated system? Thanks. |
(0000252)
mleisher 2021-05-28 18:56 |
No change with 8.4 update. Attached are the relevant log messages. I have tried modifying autofs.conf and autofs_ldap_auth.conf, and see the same error. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
84 | [AlmaLinux-8] kernel | block | always | 2021-05-27 01:47 | 2021-05-27 06:56 |
Reporter: | KarstenL680 | 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: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Building kmod drivers for VMWare Worksation Pro 16 crashed with Kernel 4.18.0-305.el8.x86_64 | ||||
Description: |
Installation of VMWare Workstation Pro16 not possible with Release 8.4 and the new Kernel, building the kmod frivers vmnet and vmmon not possible. Reproduceable any time by trying to install |
||||
Tags: | |||||
Steps To Reproduce: |
Rund the Installer as root, when starting VMWare Worksation you will be asked again to build the modules and this will also break. With the Kernel of 8.3 it was no problem. dnf yum groupinstall "Development Tools" will install normally all things needed before install VMware Workstation Pro 16 |
||||
Additional Information: | Without VMWare Workstation Pro it is not usable for me. | ||||
Attached Files: | |||||
Notes | |
(0000229)
KarstenL680 2021-05-27 06:56 |
Update, RedHat has the same problem and testing from my side showed CentOS 8 Steam to. https://access.redhat.com/discussions/6067831 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
79 | [AlmaLinux-8] anaconda | major | always | 2021-05-19 16:45 | 2021-05-25 23:03 |
Reporter: | j.a.duke | Platform: | x86_64 | ||
Assigned To: | alukoshko | OS: | ESXi | ||
Priority: | normal | OS Version: | 7.0u1 | ||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Full DVD installer fails with checksum error for Python 3.6 | ||||
Description: |
When running the 8.4 beta 1 full DVD ISO installer the creating a new VM in ESXi 7.0u1, I receive this message: anaconda 33.16.4.11 exception report Traceback (most recent call first): File "/usr/lib/python3.6/site-packages/dnf/base.py", line 2529, in _select_remote_pkgs _("Some packages from local repository have incorrect checksum")) File /usr/lib/python3.6/site-packages/dnf/base.py", line 1212, in download_packages remote_pkgs, local_pkgs = self._select_remote_pkgs(pkglist) File "/usr/lib64/python3.6/site-packages/pyanaconda/payload/dnf/payload.py", line 1383, in install self._base.download_packages(pkgs_to_download, progress) |
||||
Tags: | |||||
Steps To Reproduce: |
1. Download full DVD ISO of 8.4beta1 from any site (I used mirror.vtti.vt.edu and mirror.siena.edu) 2. Upload ISO to ESXi 7 datastore. 3. Create new VM (8 GB RAM, 250 GB drive) and select uploaded ISO for optical disc. 4. Accept most defaults in installer, connecting to Internet, creating root password and an administrator account. 5. Installer fails with checksum error in python installation. |
||||
Additional Information: |
I assumed, that even though my initial ISO download checksum matched, that there might be a problem, so I downloaded from a different mirror site. Results for second download were identical. Both the Minimal and Boot ISOs work correctly and don't generate this error (there may be other errors but I've not encountered them). I was unable to capture log files, but have screenshots of the error information (at least all the ones I could navigate to). These are attached. |
||||
Attached Files: |
Screen Shot 2021-05-18 at 4.31.34 PM.png (551,510 bytes) 2021-05-20 17:43 https://bugs.almalinux.org/file_download.php?file_id=81&type=bug Screen Shot 2021-05-18 at 4.37.21 PM.png (777,363 bytes) 2021-05-20 17:44 https://bugs.almalinux.org/file_download.php?file_id=82&type=bug Screen Shot 2021-05-18 at 4.37.40 PM.png (597,045 bytes) 2021-05-20 17:45 https://bugs.almalinux.org/file_download.php?file_id=83&type=bug |
||||
Notes | |
(0000200)
j.a.duke 2021-05-20 14:44 |
For some reason the screen shots referenced in the initial report didn't survive the submission. Please find them attached here. |
(0000201)
j.a.duke 2021-05-20 17:43 |
Screenshot the First (initial error presented during installation) |
(0000202)
j.a.duke 2021-05-20 17:44 |
Screenshot the Second (backtrace data) |
(0000203)
j.a.duke 2021-05-20 17:45 |
Screenshot the Third (environment data) |
(0000211)
alukoshko 2021-05-25 23:02 |
Hello and thanks for report. Please make sure that ISO file is correctly uploaded to datastore. We've never experienced problems like that with any release including 8.4 beta. It was tested a lot in different scenarios including installation on VMware. Is it possible to find in logs what exact package caused installation fail? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
78 | [AlmaLinux-8] lynx | minor | always | 2021-05-18 14:07 | 2021-05-25 22:55 |
Reporter: | beepmode | Platform: | |||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | low | OS Version: | 8.3 | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Lynx | ||||
Description: | When you run the command lynx with no options it tries to open /usr/share/doc/HTML/en-US/index.html. That file doesn't exist, and lynx therefore exists with an error. | ||||
Tags: | |||||
Steps To Reproduce: |
Run the command `lynx`. The output is as follows: [me@almalinux ~]$ lynx Can't Access `file://localhost/usr/share/doc/HTML/en-US/index.html' Alert!: Unable to access document. lynx: Can't access startfile |
||||
Additional Information: | On Centos the package centos-indexhtml is a dependency of lynx. The package provides the home page shown when you open lynx without specifying a URL. | ||||
Attached Files: | |||||
Notes | |
(0000210)
alukoshko 2021-05-25 22:55 |
Hello! Thanks for report, nice catch. In AlmaLinux lynx has dependency on almalinux-indexhtml too but path to our index page is: /usr/share/doc/HTML/index.html We'll update almalinux-indexhtml package to provide index page in /usr/share/doc/HTML/en-US/index.html too. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
67 | [AlmaLinux-8] -OTHER | major | always | 2021-04-21 21:13 | 2021-04-21 21:13 |
Reporter: | AlmaMorii | Platform: | Linux | ||
Assigned To: | OS: | AlmaLinux 8 | |||
Priority: | high | OS Version: | 1st Stable | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | After waking up from suspend, it automatically suspends every 30 seconds | ||||
Description: |
I am not sure if it is specific to my hardware (Toshiba Satellite T110 or Dynabook MX33/KBL), but after the first installation, I have been having this "suspend-wake-up" problem every time I try to use this AlmaLinux computer (workstation). I leave the computer as suspended when I do not use it for a while, then when I use it again, I'd expect it wakes up and use the OS as usual. It actually wakes up, however, only after 30 seconds or so, it automatically goes to sleep again. I press the power button and it wakes up again, but the symptom persists, so every 30 seconds or so, it goes to sleep. When I turn it off completely and reboot the computer, it works fine. It is only after the suspend mode, the computer goes to sleep every 30 seconds. Maybe this is happening to others, too. So I was hoping to be able to contribute to the debugging process for this wonderful new OS. |
||||
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: |
49 | [AlmaLinux-8] WALinuxAgent | minor | always | 2021-03-31 10:38 | 2021-04-07 15:42 |
Reporter: | almalinux4all | Platform: | MS Azure | ||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.3 | ||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | WALinuxAgent gives the following message on boot: WARNING ExtHandler Unable to load distro implementation for almalinux. Using d | ||||
Description: |
We created an AlmaLinux image for Azure, using the exact same config we do for CentOS. In Azure, any linux instance must run the Azure Linux Agent. This package exist in AlmaLinux as well, but it gives the following warning on console: 2021-03-31T10:23:10.420170Z WARNING ExtHandler Unable to load distro implementation for almalinux. Using default distro implementation instead. # rpm -q WALinuxAgent WALinuxAgent-2.2.46-8.el8.noarch Regards, |
||||
Tags: | |||||
Steps To Reproduce: |
Create AlmaLinux Azure image Make sure Azure Linux Agent WALinuxAgent-2.2.46-8.el8.noarch is installed and started during boot Check also that Azure Linux Agent uses cloud-init as provisioning agent # cat /etc/waagent.conf [...] Provisioning.Agent=cloud-init [...] Thanks and regards |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000090)
almalinux4all 2021-03-31 10:53 |
trying to find out which file has such warning text available, I did the following: # grep -r "Using default distro implementation instead" /lib/ Binary file /lib/python3.6/site-packages/azurelinuxagent/common/osutil/__pycache__/factory.cpython-36.opt-1.pyc matches Binary file /lib/python3.6/site-packages/azurelinuxagent/common/osutil/__pycache__/factory.cpython-36.pyc matches looking in /lib/python3.6/site-packages/azurelinuxagent/common/osutil/__pycache__/ folder, there are a lot of *.cpython-36.opt-1.pyc, but not for almalinux: # ls -al /lib/python3.6/site-packages/azurelinuxagent/common/osutil/__pycache__/ total 376 drwxr-xr-x. 2 root root 4096 Mar 31 09:45 . drwxr-xr-x. 3 root root 4096 Mar 31 09:45 .. -rw-r--r--. 2 root root 1628 Nov 5 18:32 alpine.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 1628 Nov 5 18:32 alpine.cpython-36.pyc -rw-r--r--. 2 root root 2364 Nov 5 18:32 arch.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 2364 Nov 5 18:32 arch.cpython-36.pyc -rw-r--r--. 2 root root 13120 Nov 5 18:32 bigip.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 13120 Nov 5 18:32 bigip.cpython-36.pyc -rw-r--r--. 2 root root 3651 Nov 5 18:32 clearlinux.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 3651 Nov 5 18:32 clearlinux.cpython-36.pyc -rw-r--r--. 2 root root 2944 Nov 5 18:32 coreos.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 2944 Nov 5 18:32 coreos.cpython-36.pyc -rw-r--r--. 2 root root 3210 Nov 5 18:32 debian.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 3210 Nov 5 18:32 debian.cpython-36.pyc -rw-r--r--. 2 root root 45485 Nov 5 18:32 default.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 45485 Nov 5 18:32 default.cpython-36.pyc -rw-r--r--. 2 root root 2731 Nov 5 18:32 factory.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 2731 Nov 5 18:32 factory.cpython-36.pyc -rw-r--r--. 2 root root 21365 Nov 5 18:32 freebsd.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 21365 Nov 5 18:32 freebsd.cpython-36.pyc -rw-r--r--. 2 root root 7623 Nov 5 18:32 gaia.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 7623 Nov 5 18:32 gaia.cpython-36.pyc -rw-r--r--. 2 root root 185 Nov 5 18:32 __init__.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 185 Nov 5 18:32 __init__.cpython-36.pyc -rw-r--r--. 2 root root 2937 Nov 5 18:32 iosxe.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 2937 Nov 5 18:32 iosxe.cpython-36.pyc -rw-r--r--. 2 root root 5901 Nov 5 18:32 nsbsd.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 5901 Nov 5 18:32 nsbsd.cpython-36.pyc -rw-r--r--. 2 root root 12531 Nov 5 18:32 openbsd.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 12531 Nov 5 18:32 openbsd.cpython-36.pyc -rw-r--r--. 2 root root 5971 Nov 5 18:32 openwrt.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 5971 Nov 5 18:32 openwrt.cpython-36.pyc -rw-r--r--. 2 root root 5874 Nov 5 18:32 redhat.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 5874 Nov 5 18:32 redhat.cpython-36.pyc -rw-r--r--. 2 root root 5104 Nov 5 18:32 suse.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 5104 Nov 5 18:32 suse.cpython-36.pyc -rw-r--r--. 2 root root 6479 Nov 5 18:32 ubuntu.cpython-36.opt-1.pyc -rw-r--r--. 2 root root 6479 Nov 5 18:32 ubuntu.cpython-36.pyc I am not sure this is related to WALinuxAgent anymore, but the /lib/python3.6/site-packages/azurelinuxagent/common/osutil/__pycache__/factory.cpython-36.opt-1.pyc file is part of WALinuxAgent package: # rpm -qf /lib/python3.6/site-packages/azurelinuxagent/common/osutil/__pycache__/factory.cpython-36.opt-1.pyc WALinuxAgent-2.2.46-8.el8.noarch |
(0000091)
almalinux4all 2021-03-31 10:56 |
The Azure image works good, so this far, this issue looks more like a cosmetic issue... |
(0000099)
alukoshko 2021-04-01 06:27 |
Hello and thanks for report. Looks like we have to patch WALinuxAgent in our repo and make pull request to https://github.com/Azure/WALinuxAgent I'll keep this bug open. |
(0000100)
almalinux4all 2021-04-01 08:29 |
Indeed. Thank you so much for looking into this. |
(0000132)
alukoshko 2021-04-07 15:41 |
WALinuxAgent-2.2.46-8.el8.alma was released with this bug fixed We've also created pull request: https://github.com/Azure/WALinuxAgent/pull/2219 |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
52 | [AlmaLinux-8] gnu-free-fonts | minor | always | 2021-04-01 18:07 | 2021-04-05 09:07 |
Reporter: | catselbow | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Some "provides" are missing from gnu-free-serif-fonts and gnu-free-sans-fonts | ||||
Description: | The root-core package in epel, on which all the other root-* packages depend, requires font(freeserif) and font(freesans), which are provided by gnu-free-serif-fonts and gnu-free-sans-fonts in Centos 8. The Alma Linux versions of the gnu-free-*-fonts packages don't provide these strings, so installation of any root-* packages fails. | ||||
Tags: | |||||
Steps To Reproduce: |
dnf -y install root-core Error: Problem: conflicting requests - nothing provides font(freesans) needed by root-core-6.22.06-1.el8.x86_64 - nothing provides font(freeserif) needed by root-core-6.22.06-1.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000118)
alukoshko 2021-04-03 11:13 |
Thanks for pointing this out. Fix will be released soon. |
(0000123)
alukoshko 2021-04-05 09:07 |
Updated gnu-free-serif-fonts and gnu-free-sans-fonts with correct provides was released. It'll take some time before update hit the mirrors. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
51 | [AlmaLinux-8] initial-setup | major | always | 2021-04-01 15:34 | 2021-04-05 08:54 |
Reporter: | porala | Platform: | x86 | ||
Assigned To: | OS: | Alma Linux | |||
Priority: | normal | OS Version: | 8.3 | ||
Status: | new | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Problem with kickstart file | ||||
Description: |
Hello Everyone, We have started using Alma Linux in our organization. However we have an issue when we tried to automate the installation but manual installation works fine. This is my kickstart file but we have not mentioned the "autopart --type=lvm" directions in this kickstart file but installation takes the automation partitioning but it works fine with CentOS 8. Due to the customization in my company, we have to use specific size for each installation, so we do not wish to make the automatic partitioning. Please help. $ cat /root/kickstart.ks #version=Alma Linux 8 ignoredisk --only-use=sda # System bootloader configuration bootloader --append="rhgb quiet crashkernel=auto" --location=mbr --boot-drive=sda # Clear the Master Boot Record zerombr # Partition clearing information clearpart --all --initlabel --drives=sda # Reboot after installation reboot # Use graphical install graphical # Use CDROM installation media cdrom # Keyboard layouts # old format: keyboard us # new format: keyboard --xlayouts='us' # System language lang en_US.UTF-8 # Root password # rootpw --iscrypted xxxxxx # System authorization information auth --passalgo=sha512 --useshadow # SELinux configuration selinux --disabled firstboot --disable # Do not configure the X Window System skipx # System services services --enabled="chronyd" # System timezone timezone Europe/Berlin %post --logfile=/root/ks-post.log %end %packages @^server-product-environment @system-tools %end %addon com_redhat_kdump --enable --reserve-mb='auto' %end |
||||
Tags: | |||||
Steps To Reproduce: | Automatic partition is happening without specifying the autopart options in kickstart file | ||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000108)
alukoshko 2021-04-02 06:08 |
Hello. Did you use https://repo.almalinux.org/almalinux/8/BaseOS/x86_64/kickstart/ or https://repo.almalinux.org/almalinux/8/BaseOS/x86_64/os/ as repo for kickstart installation? |
(0000109)
porala 2021-04-02 06:12 |
Hello, No, I am using the local server as a Kickstart server and not using any repo. Basically mounting the Alma Linux ISO to the system and using the kickstart to do the installation. Thank you |
(0000121)
porala 2021-04-05 08:51 |
Anyone can help me please? |
(0000122)
alukoshko 2021-04-05 08:54 |
Hi. I'm trying to understand your case. So you want to be asked for partition scheme during installation? You want it non-interactive? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
39 | [AlmaLinux-8] almalinux-release | minor | always | 2021-03-17 17:42 | 2021-03-23 11:55 |
Reporter: | mdmufaad | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | while using docker in AlmaLinux | ||||
Description: |
docker run --rm -v $(pwd):/app composer install Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. Completed short name "composer" with unqualified-search registries (origin: /etc/containers/registries.conf) Trying to pull registry.access.redhat.com/composer:latest... name unknown: Repo not found Trying to pull registry.redhat.io/composer:latest... unable to retrieve auth token: invalid username/password: unauthorized: Please login to the Red Hat Registry using your Customer Portal credentials. Further instructions can be found here: https://access.redhat.com/RegistryAuthentication Trying to pull docker.io/library/composer:latest. i am getting this error while running => docker run --rm -v $(pwd):/app composer install This command |
||||
Tags: | AlmaLinux, Bug, Docker | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000062)
alukoshko 2021-03-19 08:25 |
Thanks for pointing this out. We'll soon prepare an update for containers-common package with modified default registries. |
(0000066)
mdmufaad 2021-03-19 18:59 |
Excellent thanks guys. coz i suppose to use AlmaOS for production servers. Docker containers are very important in this case. Thanks looking forward for your updates.... |
(0000071)
alukoshko 2021-03-21 21:57 |
Updated containers-common package from default module container-tools:rhel8 is already in repos. Updates for container-tools:1.0 and container-tools:2.0 will follow. Default configuration was changed and now docker.io is the only registry enabled by default. You can change this behavior at any time by editing /etc/containers/registries.conf file. Thank you for report. |
(0000077)
alukoshko 2021-03-23 11:55 |
Updated containers-common packages released for all container-tools module streams. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
43 | [AlmaLinux-8] bind | minor | always | 2021-03-22 15:41 | 2021-03-22 17:29 |
Reporter: | sector-one | Platform: | x86_64 | ||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.3-rc | ||
Status: | assigned | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Potential debranding issue regarding version string | ||||
Description: |
Binaries of the AlmaLinux 8.3-rc RPMs based on bind-9.11.20-5.el8_3.1.src.rpm (https://repo.almalinux.org/almalinux/8.3-rc/BaseOS/Source/Packages/bind-9.11.20-5.el8_3.1.src.rpm takes as a reference) contain a hard-coded version string which mentions the brand of upstream. I would suggest to replace the upstream's braning against "AlmaLinux". by applying following trivial patch: --- a/bind.spec 2021-03-05 12:50:23.000000000 +0100 +++ b/bind.spec 2021-03-22 16:30:48.023132150 +0100 @@ -609,7 +609,7 @@ sed -i -e \ -'s/RELEASEVER=\(.*\)/RELEASEVER=\1-RedHat-%{version}-%{release}/' \ +'s/RELEASEVER=\(.*\)/RELEASEVER=\1-AlmaLinux-%{version}-%{release}/' \ version libtoolize -c -f; aclocal -I libtool.m4 --force; autoconf -f |
||||
Tags: | |||||
Steps To Reproduce: |
$ dig -version DiG 9.11.20-RedHat-9.11.20-5.el8.1 |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000073)
alukoshko 2021-03-22 16:26 |
Hello and thank you for report. I had a look at CentOS and Oracle Linux packages and both have this string RedHat-branded. Usually Oracle Linux packages are highly debranded so we should be careful and find out what side effects can possibly occur if we change RELEASEVER. |
(0000074)
sector-one 2021-03-22 17:29 |
Right, https://bugs.centos.org/view.php?id=15686 is open for years but has neither been rejected nor fixed. A "reject" would have made it clear that any rebuilds are okay to use the upstream branding at this place or that there a known technical side-effects. A "fix" would have meant that this needs to be fixed. The current, untouched state might mean anything, even a legal time bomb which can be nuked whenever upstream decides. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
31 | [AlmaLinux-8] PackageKit | block | always | 2021-02-25 15:13 | 2021-03-21 21:40 |
Reporter: | liberodark | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | urgent | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Add Errata support to AlmaLinux | ||||
Description: |
Hi, On AlmaLinux 8.3 RC no see information from packages update : [b] Other Exemple Terminal with check_update on CentOS 7 :[/b] [code] ./check_updates The following packages are security updates: apr-1.4.8-5.el7.x86_64 (SECURITY) bind-libs-lite-32:9.11.4-9.P2.el7.x86_64 (SECURITY) bind-libs-32:9.11.4-9.P2.el7.x86_64 (SECURITY) bind-license-32:9.11.4-9.P2.el7.noarch (SECURITY) bind-utils-32:9.11.4-9.P2.el7.x86_64 (SECURITY) curl-7.29.0-54.el7.x86_64 (SECURITY) elfutils-default-yama-scope-0.176-2.el7.noarch (SECURITY) elfutils-libelf-0.176-2.el7.x86_64 (SECURITY) elfutils-libs-0.176-2.el7.x86_64 (SECURITY) ghostscript-9.25-2.el7_7.2.x86_64 (SECURITY) kernel-headers-3.10.0-1062.1.2.el7.x86_64 (SECURITY) kernel-tools-libs-3.10.0-1062.1.2.el7.x86_64 (SECURITY) kernel-tools-3.10.0-1062.1.2.el7.x86_64 (SECURITY) kernel-3.10.0-1062.1.2.el7.x86_64 (SECURITY) libarchive-3.1.2-12.el7.x86_64 (SECURITY) libcurl-7.29.0-54.el7.x86_64 (SECURITY) libjpeg-turbo-1.2.90-8.el7.x86_64 (SECURITY) libmspack-0.5-0.7.alpha.el7.x86_64 (SECURITY) libsmbclient-4.9.1-6.el7.x86_64 (SECURITY) libssh2-1.8.0-3.el7.x86_64 (SECURITY) libtiff-4.0.3-32.el7.x86_64 (SECURITY) libtirpc-0.2.4-0.16.el7.x86_64 (SECURITY) libwbclient-4.9.1-6.el7.x86_64 (SECURITY) mariadb-libs-1:5.5.64-1.el7.x86_64 (SECURITY) mariadb-server-1:5.5.64-1.el7.x86_64 (SECURITY) mariadb-1:5.5.64-1.el7.x86_64 (SECURITY) nagios-common-4.4.3-1.el7.x86_64 (SECURITY) nagios-4.4.3-1.el7.x86_64 (SECURITY) ntp-4.2.6p5-29.el7.centos.x86_64 (SECURITY) ntpdate-4.2.6p5-29.el7.centos.x86_64 (SECURITY) pango-1.42.4-4.el7_7.x86_64 (SECURITY) patch-2.7.1-11.el7.x86_64 (SECURITY) polkit-0.112-22.el7_7.1.x86_64 (SECURITY) python-libs-2.7.5-86.el7.x86_64 (SECURITY) python-perf-3.10.0-1062.1.2.el7.x86_64 (SECURITY) python-2.7.5-86.el7.x86_64 (SECURITY) rsyslog-mysql-8.24.0-41.el7_7.x86_64 (SECURITY) rsyslog-8.24.0-41.el7_7.x86_64 (SECURITY) samba-client-libs-4.9.1-6.el7.x86_64 (SECURITY) samba-client-4.9.1-6.el7.x86_64 (SECURITY) samba-common-libs-4.9.1-6.el7.x86_64 (SECURITY) samba-common-4.9.1-6.el7.noarch (SECURITY) systemd-libs-219-67.el7_7.1.x86_64 (SECURITY) systemd-sysv-219-67.el7_7.1.x86_64 (SECURITY) systemd-219-67.el7_7.1.x86_64 (SECURITY) unzip-6.0-20.el7.x86_64 (SECURITY) vim-common-2:7.4.629-6.el7.x86_64 (SECURITY) vim-enhanced-2:7.4.629-6.el7.x86_64 (SECURITY) vim-filesystem-2:7.4.629-6.el7.x86_64 (SECURITY) vim-minimal-2:7.4.629-6.el7.x86_64 (SECURITY) UPDATE OK - Security-Update = 50 | 'Total Update' = 276 [/code] Work [b]Other Exemple Terminal with check_update on Redhat 8 :[/b] [code] ./check_updates The following packages are security updates: bind-export-libs-32:9.11.4-17.P2.el8_0.1.x86_64 (SECURITY) kernel-core-4.18.0-80.11.2.el8_0.x86_64 (SECURITY) kernel-modules-4.18.0-80.11.2.el8_0.x86_64 (SECURITY) kernel-tools-libs-4.18.0-80.11.2.el8_0.x86_64 (SECURITY) kernel-tools-4.18.0-80.11.2.el8_0.x86_64 (SECURITY) kernel-4.18.0-80.11.2.el8_0.x86_64 (SECURITY) libnghttp2-1.33.0-1.el8_0.1.x86_64 (SECURITY) python3-perf-4.18.0-80.11.2.el8_0.x86_64 (SECURITY) vim-minimal-2:8.0.1763-11.el8_0.x86_64 (SECURITY) UPDATE OK - Security-Update = 9 | 'Total Update' = 70 [/code] Work [b]Other Exemple Terminal with check_update on AlmaLinux 8.3 :[/b] [code] ./check_updates Role: refresh-cache Allow cancel: true Caller active: true Progress: 0% Status: wait Status: waiting-for-auth Status: wait Status: setup Status: loading-cache Progress: 1% Status: download-repository Progress: 18% Status: loading-cache Progress: 22% Progress: 24% Status: download-repository Progress: 40% Status: loading-cache Progress: 46% Progress: 48% Status: download-repository Progress: 64% Status: loading-cache Progress: 70% Progress: 72% Status: download-repository Progress: 89% Status: loading-cache Progress: 94% Progress: 96% Status: query Status: loading-cache Progress: 97% Progress: 98% Progress: 99% Progress: 100% Status: finished Role: get-updates Allow cancel: true Caller active: true Progress: 0% Status: wait Status: setup Progress: 39% Progress: 89% Progress: 90% Progress: 91% Progress: 100% Status: finished Role: get-update-detail Allow cancel: true Caller active: true Progress: 0% Status: wait Status: setup Status: query Progress: 4% Status: loading-cache Progress: 15% Progress: 16% Progress: 27% Progress: 38% Progress: 50% Progress: 99% Progress: 100% Status: finished The following packages are security updates: WARN: Missing update detail for package bpftool-4.18.0-240.15.1.el8_3.x86_64 WARN: Missing update detail for package kernel-core-4.18.0-240.15.1.el8_3.x86_64 WARN: Missing update detail for package kernel-modules-4.18.0-240.15.1.el8_3.x86_64 WARN: Missing update detail for package kernel-tools-libs-4.18.0-240.15.1.el8_3.x86_64 WARN: Missing update detail for package kernel-tools-4.18.0-240.15.1.el8_3.x86_64 WARN: Missing update detail for package kernel-4.18.0-240.15.1.el8_3.x86_64 WARN: Missing update detail for package perf-4.18.0-240.15.1.el8_3.x86_64 WARN: Missing update detail for package perl-DBD-SQLite-1.58-2.module_el8.3.0+2074+0df5c3bb.x86_64 WARN: Missing update detail for package perl-DBI-1.641-3.module_el8.3.0+2054+fbe55708.x86_64 WARN: Missing update detail for package perl-IO-Socket-SSL-2.066-4.module_el8.3.0+2086+72f2d257.noarch WARN: Missing update detail for package perl-Mozilla-CA-20160104-7.module_el8.3.0+2091+9eecfe51.noarch WARN: Missing update detail for package perl-Net-SSLeay-1.88-1.module_el8.3.0+2086+72f2d257.x86_64 WARN: Missing update detail for package python3-perf-4.18.0-240.15.1.el8_3.x86_64 (none) UPDATE OK - Security-Update = 0 | 'Total Update' = 13 Security updates: (none) [/code] Not Work (check_update says that there are no security updates but it's wrong it's only that there is no information about packages.) Source of check_update : https://github.com/liberodark/nrpe-installer/wiki/Plugin-check_updates PS : Is very important issue for me and my company . |
||||
Tags: | |||||
Steps To Reproduce: |
[code] yum install -y PackageKit systemctl start packagekit.socket pkcon get-update-detail bpftool pkcon get-update-detail python3-perf [/code] |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000036)
ezamriy 2021-02-25 22:50 |
Yes, that's a known issue. The stable AlmaLinux version will have the Errata information available, we are working on this. |
(0000039)
liberodark 2021-02-27 13:02 |
A big thank you to you I look forward to testing this when it becomes available. Best Regards |
(0000070)
alukoshko 2021-03-21 21:38 |
Errata is now available. It's accessible using dnf updateinfo and also can be browsed here: https://errata.almalinux.org/8/ It's in beta state at the moment so we would really appreciate your feedback. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
38 | [AlmaLinux-8] general | tweak | always | 2021-03-11 17:52 | 2021-03-17 15:20 |
Reporter: | prymar56 | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Minimal ISO is missing authselect-compat.x86_64 from AppStream causing the post config install step to fail. | ||||
Description: |
AlmaLinux-8.3-rc-1-x86_64-minimal.iso Using the above ISO, I expected a complete package set sufficient to complete a Minimal install. There is one important package, authselect-compat, that is not on the ISO. In my kickstart I had to configure an external Repo, mirror for AppStream, to install authselect-compat*rpm. |
||||
Tags: | minimal-install, pv, xen | ||||
Steps To Reproduce: |
boot the Minimal ISO with cmdline: text ks=http://192.168.1.3/public_html/alma8-ks.cfg inst.repo=cdrom:xvdc install fails to complete, missing */bin/authconfig, and the post-install configure scripts cannot run. |
||||
Additional Information: | This install was a pv domU install in C8 Xen dom0 (xen-4.13.2) with the kernel-ml (vmlinuz) and an initrd.img, repacked with elrepo modules. The method has worked with a CentOS 8.3 domU. | ||||
Attached Files: | |||||
Notes | |
(0000053)
alukoshko 2021-03-11 22:06 (Last edited: 2021-03-11 22:35) |
Hello. authselect-compat package is in AppStream repo but Minimal ISO includes only BaseOS repo. Have you tried your method with full DVD iso image? BTW CentOS project doesn't provide Minimal ISO images, what image you used? |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
20 | [AlmaLinux-8] systemd | tweak | always | 2021-02-13 06:09 | 2021-02-22 16:39 |
Reporter: | zkt2202 | Platform: | VMware Virtual Platform | ||
Assigned To: | alukoshko | OS: | AlmaLinux-8.3 | ||
Priority: | normal | OS Version: | Beta 1 | ||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | Not start service kdumb on boot | ||||
Description: |
February 13, 2021 6:04 PM Failed to start Crash recovery kernel arming. systemd 6:04 PM kdump.service: Failed with result 'exit-code'. systemd 6:04 PM kdump.service: Main process exited, code=exited, status=1/FAILURE systemd 6:04 PM Starting kdump: [FAILED] kdumpctl 6:04 PM No memory reserved for crash kernel kdumpctl 6:04 PM Starting Crash recovery kernel arming... systemd 6:02 PM Failed to start Crash recovery kernel arming. systemd 6:02 PM kdump.service: Failed with result 'exit-code'. systemd 6:02 PM kdump.service: Main process exited, code=exited, status=1/FAILURE systemd 6:02 PM Starting kdump: [FAILED] kdumpctl 6:02 PM No memory reserved for crash kernel kdumpctl 6:02 PM Starting Crash recovery kernel arming... systemd 5:56 PM Failed to start Crash recovery kernel arming. systemd 5:56 PM kdump.service: Failed with result 'exit-code'. systemd 5:56 PM kdump.service: Main process exited, code=exited, status=1/FAILURE systemd 5:56 PM Starting kdump: [FAILED] kdumpctl 5:56 PM No memory reserved for crash kernel kdumpctl 5:56 PM Starting Crash recovery kernel arming... systemd 5:54 PM Failed to start Crash recovery kernel arming. systemd 5:54 PM kdump.service: Failed with result 'exit-code'. systemd 5:54 PM kdump.service: Main process exited, code=exited, status=1/FAILURE systemd 5:54 PM Starting kdump: [FAILED] kdumpctl 5:54 PM No memory reserved for crash kernel kdumpctl 5:54 PM Starting Crash recovery kernel arming... systemd |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000028)
alukoshko 2021-02-13 21:26 |
Thanks for report. Have you disabled kdump during install? If so and you don't need kdump it's safe to disable it: systemctl disable kdump.service Anaconda installer doesn't disable kdump.service no matter kdump was disabled or enabled during installation. That's upstream behavior since the following commit: https://github.com/daveyoung/kdump-anaconda-addon/commit/06ad89188047cc28fde514ab722a1bf4637b60ad |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
21 | [AlmaLinux-8] chrony | minor | always | 2021-02-13 11:03 | 2021-02-22 16:38 |
Reporter: | almalinux4all | Platform: | |||
Assigned To: | alukoshko | OS: | AlmaLinux | ||
Priority: | normal | OS Version: | 8.3_beta | ||
Status: | feedback | Product Version: | |||
Product Build: | Resolution: | open | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | incorrect ownership of /var/log/chorny | ||||
Description: |
Folder /var/log/chrony has incorrect ownership: [root@ip-172-31-18-24 ~]# ls -lda /var/log/chrony/ drwxr-xr-x. 2 990 986 6 Jan 26 15:39 /var/log/chrony/ As you see above, user with id 990 and group with id 986 does not exit. [root@ip-172-31-18-24 ~]# cat /etc/passwd | grep chrony chrony:x:994:991::/var/lib/chrony:/sbin/nologin [root@ip-172-31-18-24 ~]# cat /etc/group | grep chrony chrony:x:991: Instead, user id 994 and group id 991 should be used. |
||||
Tags: | |||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000024)
alukoshko 2021-02-13 18:03 |
Thanks for report. I can't reproduce the problem actually: [alukoshko@almalinux ~]$ ls -lda /var/log/chrony/ drwxr-xr-x. 2 chrony chrony 6 Jan 26 18:39 /var/log/chrony/ [alukoshko@almalinux ~]$ id chrony uid=991(chrony) gid=987(chrony) groups=987(chrony) uid and gid for chrony aren't reserved and may differ from installation to installation. But of course file permissions must match chrony user. How can I reproduce the issue? Was it fresh installation or migration from other OS? Please provide steps that I would able to follow. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
4 | [AlmaLinux-8] -OTHER | trivial | always | 2021-01-28 21:23 | 2021-02-16 13:35 |
Reporter: | ezamriy | Platform: | |||
Assigned To: | sfokin | OS: | |||
Priority: | low | OS Version: | |||
Status: | resolved | Product Version: | 8.3 | ||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | 8.3 | ||||
abrt_hash: | |||||
URL: | |||||
Summary: | satellite-5-client module should be in the AppStream repository | ||||
Description: | In the first beta, the satellite-5-client module is located in the BaseOS repository instead of the AppStream. This happened due to a mistake in a variants.xml file and should be solved in upcoming releases. | ||||
Tags: | modularity, pungi | ||||
Steps To Reproduce: | |||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000030)
sfokin 2021-02-16 13:35 |
Will be fixed in next release |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
9 | [AlmaLinux-8] php | minor | always | 2021-02-03 21:31 | 2021-02-16 13:12 |
Reporter: | tahder | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | php 7.4 got issue | ||||
Description: |
I can't run php 7.4, specifically 7.4.6-4. But so far no issues on 7.2 and 7.3 |
||||
Tags: | |||||
Steps To Reproduce: |
sudo yum module list php AlmaLinux 8.3 - AppStream Name Stream Profiles Summary php 7.2 [d][e] common [d], devel, minimal PHP scripting language php 7.3 common [d], devel, minimal PHP scripting language php 7.4 common [d], devel, minimal PHP scripting language Reset the module... sudo yum module reset php Enabling 7.4... yum module enable php:7.4 Remove older php 7.2... to make it sure not conflicting... sudo yum remove php Install php... based on enabled php 7.4 sudo yum install php Last metadata expiration check: 1:57:22 ago on Wed 03 Feb 2021 14:27:03 EST. Error: Problem: conflicting requests - nothing provides php-common(x86-64) = 7.4.6-4.module_el8.3.0+6140+77b1a879.cloudlinux needed by php-7.4.6-4.module_el8.3.0+6140+77b1a879.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) |
||||
Additional Information: |
yumdownloader --source php As per notice on the php.spec at line 0000077 %global release %{?release}.cloudlinux Maybe that's causing the issue as can't recompile as too many needed dependencies package. I also tried on the CentOS 8, this almalinux.repo It seems works well as long as you remove the original centos or centos stream repos |
||||
Attached Files: | |||||
Notes | |
(0000017)
alukoshko 2021-02-09 14:35 |
php:7.4 module has been fixed and will be available in next AlmaLinux Beta/RC release. Many thanks for mentioning that. |
View Issue Details | |||||
ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
17 | [AlmaLinux-8] redhat-rpm-config | minor | always | 2021-02-11 01:22 | 2021-02-16 10:01 |
Reporter: | alma-devel | Platform: | |||
Assigned To: | alukoshko | OS: | |||
Priority: | normal | OS Version: | |||
Status: | resolved | Product Version: | |||
Product Build: | Resolution: | fixed | |||
Projection: | none | ||||
ETA: | none | Fixed in Version: | |||
Target Version: | |||||
abrt_hash: | |||||
URL: | |||||
Summary: | AlmaLinux not valid grep match in dist.sh | ||||
Description: |
/usr/lib/rpm/redhat/dist.sh is searching for egrep -q '(Enterprise|Advanced|CloudLinux)' /etc/redhat-release and not "AlmaLinux" leading to no output. |
||||
Tags: | |||||
Steps To Reproduce: |
install redhat-rpm-config run /usr/lib/rpm/redhat/dist.sh |
||||
Additional Information: | |||||
Attached Files: | |||||
Notes | |
(0000020)
alukoshko 2021-02-11 12:27 |
Thank you for report. Fixed redhat-rpm-config package is ready and will be available soon with next AlmaLinux Beta/RC release. |