AlmaLinux Bug Tracker

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
138	[AlmaLinux-8] basesystem	major	always	2021-10-27 17:04	2021-10-27 17:04

Reporter:	ryankhgb	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:	AlmaLinux 8.5-beta - BaseOS - Error
Description:	Hello, I have installed latest version on Almalinux on a dedicated server but having continuously same error. I was able to access my server via SSH over the internet and this means my server can easily communicate with the internet but when I try to install anything it ends up with the following error. Totally stuck. AlmaLinux 8.5-beta - BaseOS 0.0 B/s \| 0 B 00:00 Errors during downloading metadata for repository 'baseos': - Curl error (6): Couldn't resolve host name for https://mirrors.almalinux.org/mirrorlist/8.5-beta/baseos [Could not resolve host: mirrors.almalinux.org] Error: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.almalinux.org/mirrorlist/8.5-beta/baseos [Could not resolve host: mirrors.almalinux.org] I have checked everything, ip a and its showing that I'm connected to internet but don't know what's wrong further.
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:
27	[AlmaLinux-8] open-vm-tools	major	always	2021-02-24 15:17	2021-10-25 09:58

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

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

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:	[[email protected] ~]$ 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) lkhn 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:
134	[AlmaLinux-8] -OTHER	major	always	2021-10-20 18:17	2021-10-24 16:38

Reporter:	Adrien_D	Platform:	VMWare Workstation
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:	ELevate : UEFI not updated
Description:	I installed CentOS 7 to test the ELevate update to Alma Linux 8 : https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html precheck : some warnings, i applied solutions : OK Reboot : upgrading : OK Reboot after upgrading : nothing. The UEFI not updated (because the efi file is before in the centos folder, and after update it's in almalinux folder.
Tags:
Steps To Reproduce:	1- Install CentOS 7 on vmware workstation with UEFI 2- Update CentOS 7 3- Elevate the system as https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html 4- See the system doesn't reboot after upgrading
Additional Information:
Attached Files:

Notes
(0000362) alukoshko 2021-10-22 13:48	Thanks for report. Looks like Leapp doesn't support changing efi dirs because is developed just for Red Hat. We have to develop a new actor for this. BTW could you also check CentOS 7 -> CentOS Stream 8 update in your environment?

(0000365) Adrien_D 2021-10-24 16:38	Yes i know leapp. Before making a video on my youtube channel i made a snapshot of the VM in CentOS 7. So i make the test on the SAME VM. (i didn't destroyed it) After upgrading from CentOS 7 to CentOS 8 Stream : All is okay because efi is in centos folder in the EFI partition

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 [email protected] 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:
136	[AlmaLinux-8] selinux-policy	minor	always	2021-10-22 11:30	2021-10-22 11:30

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: [email protected]:~ dnf list installed \| grep container-selinux [email protected]:~ semodule -l \| grep container Aftef installation: [email protected]:~ dnf list installed \| grep container-selinux container-selinux.noarch 2:2.167.0-1.module_el8.4.0+2535+b6fd1bdf @AppStream [email protected]:~ semodule -l \| grep container container pcpupstream-container After remove package: [email protected]:~ 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! [email protected]:~ dnf list installed \| grep container-selinux [email protected]:~ semodule -l \| grep container container pcpupstream-container Package is trying to remove the module with the wrong priority: [email protected]:/var/lib/selinux/targeted/active/modules/200 ls \| grep container drwx------. 2 root root 44 Oct 21 11:28 container [email protected]:~ semodule -r container libsemanage.semanage_direct_remove_key: Unable to remove module container at priority 400. (No such file or directory). semodule: Failed! [email protected]:~ 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:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
135	[AlmaLinux-8] setup	block	always	2021-10-20 19:44	2021-10-20 19:44

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:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
128	[AlmaLinux-8] fwupdate	minor	always	2021-09-23 12:13	2021-10-19 13:03

Reporter:	olahaye74	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:	fwupdate-efi installs in /boot/efi/EFI/redhat instead of /boot/efi/EFI/almalinux
Description:	fwupdate-efi installs in /boot/efi/EFI/redhat instead of /boot/efi/EFI/almalinux
Tags:
Steps To Reproduce:	dnf -y install fwupdate-efi ; rpm -ql fwupdate-efi\|grep redhat
Additional Information:
Attached Files:

Notes
(0000356) alukoshko 2021-10-19 13:03	Updated fwupdate-efi was released with correct path. Sorry for delay.

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. [[email protected] ~]# nmcli device wifi connect FRITZTuxNetzwerk password password Error: Connection activation failed: (7) Secrets were required, but not provided. [[email protected] ~]# 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:
112	[AlmaLinux-8] anaconda	minor	always	2021-07-06 04:29	2021-10-14 14:43

Reporter:	lee	Platform:	Linux
Assigned To:	alukoshko	OS:	Alma Linux
Priority:	normal	OS Version:	8.3
Status:	feedback	Product Version:
Product Build:		Resolution:	open
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.

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:
45	[AlmaLinux-8] dmidecode	minor	always	2021-03-27 08:20	2021-09-23 15:35

Reporter:	imran.mna	Platform:	KVM
Assigned To:	alukoshko	OS:	Linux 4.18.0-240.15.1.el8_3.x86_
Priority:	normal	OS Version:	AlmaLinux 8.3 RC
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
abrt_hash:
URL:

Summary:	Segmentation fault occurs while executing 'dmidecode -u'
Description:	In order to dump the contents as hexadecimal the dmidecode executable provides partial output and exits with 'Segmentation fault (core dumped)' error message.
Tags:	Bug
Steps To Reproduce:	1. dmidecode -u FILENAME 2. dmidecode -u
Additional Information:
Attached Files:	dmidecode-hexadecimal-bug (937 bytes) 2021-03-27 08:20 https://bugs.almalinux.org/file_download.php?file_id=63&type=bug

Notes
(0000080) imran.mna 2021-03-27 08:29	The Severity should be minor, apology for the input.

(0000081) alukoshko 2021-03-27 13:57	Hello and thanks for report. It looks like an upstream distro issue: https://bugzilla.redhat.com/show_bug.cgi?id=1885823 We'll have to wait for update. Fortunately, the previous version of dmidecode doesn't have this issue. But we don't have it in AlmaLinux as we're new distribution so if you need to mitigate the issue right now you should install the previous version of dmidecode from other distro. Here is example with CloudLinux 8.2 package I've tested: # Downgrade to previous version dnf downgrade https://repo.cloudlinux.com/cloudlinux/8.2/BaseOS/x86_64/os/Packages/dmidecode-3.2-5.el8.x86_64.rpm # Install dnf versionlock plugin dnf install 'dnf-command(versionlock)' # Lock dmidecode to previous version until fixed package will be relesed dnf versionlock add dmidecode

(0000133) rschu68 2021-04-08 10:29	Also: https://github.com/mirror/dmidecode/issues/13 and: https://bugzilla.redhat.com/show_bug.cgi?id=1947352

(0000264) alukoshko 2021-06-08 16:25	https://bugzilla.redhat.com/show_bug.cgi?id=1885823 looks like issue will be fixed soon in dmidecode-3.2-10.el8

(0000335) rschu68 2021-09-23 15:33	Confirm working with version 3.2-10 .. but not in repo's rhel8.4 ? https://rpmfind.net/linux/rpm2html/search.php?query=dmidecode(x86-64) http://linuxsoft.cern.ch/cern/centos/s8/BaseOS/x86_64/os/Packages/

(0000336) alukoshko 2021-09-23 15:35	Yep right now this version is in CentOS Stream 8 only. Most likely RHEL 8.5 will include it.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
125	[AlmaLinux-8] -OTHER	minor	N/A	2021-09-02 20:59	2021-09-03 18:40

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..."

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:
120	[AlmaLinux-8] flatpak	minor	always	2021-08-24 16:35	2021-08-24 16:35

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:
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:

There are no notes attached to this issue.

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:
117	[AlmaLinux-8] lynx	minor	have not tried	2021-08-12 16:49	2021-08-12 16:49

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:[email protected]/ You will see "user:[email protected]" in the plaintext of the tcpdump output.
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. [[email protected] ~]# 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 [email protected] 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: [[email protected] ~]# mokutil --sb-state SecureBoot disabled [[email protected] ~]# 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:
56	[AlmaLinux-8] grub2	minor	have not tried	2021-04-04 05:32	2021-07-23 15:28

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", [[email protected] ~]# 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 [[email protected] ~]# 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.

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:
50	[AlmaLinux-8] -OTHER	minor	always	2021-04-01 10:01	2021-07-08 12:22

Reporter:	brimioulle	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:	Alma AppStream, BaseOS, and Kickstart Repository cannot be synced with pulp/katello on foreman
Description:	When trying to synchronize the Alma 8 AppStream, BaseOS and Kickstart repositories the sync throws following error: "AttributeError: 'Repository' object has no attribute 'repo_id'\n", Exception: Katello::Errors::PulpError: PLP0000: 'Repository' object has no attribute 'repo_id' In February the repositories for the beta version synchronized without any error. Has something in the repository structure changed?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000102) brimioulle 2021-04-01 13:51	Affected Repos are the following: https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/ https://repo.almalinux.org/almalinux/8/BaseOS/x86_64/os/ https://repo.almalinux.org/almalinux/8/BaseOS/x86_64/kickstart/

(0000103) alukoshko 2021-04-01 14:18	Hello and thanks for report. So PowerTools and HighAvailability repos are OK?

(0000104) alukoshko 2021-04-01 15:04	Actually we haven't changed anything in repos since beta.

(0000105) brimioulle 2021-04-01 18:50	Haven't tested HighAvailability but yes, extras and PowerTools are ok. Strange, the repo syncs broke at the moment when I switched from beta to the release versions ...

(0000110) secker 2021-04-02 11:10	Hi, we have that problem too. PowerTools, HighAvailability and Extras Repos are providing valid Distribution Information. BaseOS and AppStream does not. We´ve had the same problem with CloudLinux 8 in May 2020 -> #82641

(0000112) alukoshko 2021-04-02 14:10	Thanks for details provided. I'll take some time to reproduce and fix it.

(0000117) alukoshko 2021-04-03 09:39	https://www.reddit.com/r/AlmaLinux/comments/mj3nex/almalinux_and_foreman_katello/gt8b9z8/?utm_source=reddit&utm_medium=web2x&context=3

(0000124) secker 2021-04-06 07:52	Hi, BaseOS is working now. But AppStream still fails during Katello Distribution Data Import.

(0000125) alukoshko 2021-04-06 16:02	Could you please provide some more details? Full log would be useful. And what exact version of Foreman/Katello used? I'll try to reproduce.

(0000126) brimioulle 2021-04-06 16:15	Hi, we are using foreman 2.1.3 (but also reproduced with 2.1.4) with katello 3.16.2. The traceback is as follows: -------------------------------------------------- Action: Actions::Pulp::Repository::Sync Input: {"source_url"=>nil, "repo_id"=>3314, "smart_proxy_id"=>1, "remote_user"=>"admin", "remote_cp_user"=>"admin", "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {"pulp_tasks"=> [{"exception"=>nil, "task_type"=>"pulp.server.managers.repo.sync.sync", "_href"=>"/pulp/api/v2/tasks/53bd24f3-c4cb-496f-a825-e17ec1ae2cd5/", "task_id"=>"53bd24f3-c4cb-496f-a825-e17ec1ae2cd5", "tags"=> ["pulp:repository:a9efe03c-6934-429c-87ad-0d62859cff7b", "pulp:action:sync"], "finish_time"=>"2021-04-06T02:00:24Z", "_ns"=>"task_status", "start_time"=>"2021-04-06T02:00:19Z", "traceback"=>nil, "spawned_tasks"=> [{"_href"=>"/pulp/api/v2/tasks/ebc66a85-9bd6-4e13-b075-744effba267e/", "task_id"=>"ebc66a85-9bd6-4e13-b075-744effba267e"}], "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"=>"FINISHED"}, "purge_duplicates"=>{"state"=>"FINISHED"}, "distribution"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "items_left"=>0}, "modules"=>{"state"=>"FINISHED"}, "errata"=>{"state"=>"FINISHED"}, "metadata"=>{"state"=>"FINISHED"}}}, "queue"=>"[email protected]", "state"=>"finished", "worker_name"=>"[email protected]", "result"=> {"result"=>"success", "importer_id"=>"yum_importer", "exception"=>nil, "repo_id"=>"a9efe03c-6934-429c-87ad-0d62859cff7b", "traceback"=>nil, "started"=>"2021-04-06T02:00:19Z", "_ns"=>"repo_sync_results", "completed"=>"2021-04-06T02:00:24Z", "importer_type_id"=>"yum_importer", "error_message"=>nil, "summary"=> {"modules"=>{"state"=>"FINISHED"}, "content"=>{"state"=>"FINISHED"}, "comps"=>{"state"=>"FINISHED"}, "purge_duplicates"=>{"state"=>"FINISHED"}, "distribution"=>{"state"=>"FINISHED"}, "errata"=>{"state"=>"FINISHED"}, "metadata"=>{"state"=>"FINISHED"}}, "added_count"=>0, "removed_count"=>0, "updated_count"=>0, "id"=>"606bc0b824143f27c650b443", "details"=> {"modules"=>{"state"=>"FINISHED"}, "content"=> {"size_total"=>0, "items_left"=>0, "items_total"=>0, "state"=>"FINISHED", "size_left"=>0, "details"=> {"rpm_total"=>0, "rpm_done"=>0, "drpm_total"=>0, "drpm_done"=>0}, "error_details"=>[]}, "comps"=>{"state"=>"FINISHED"}, "purge_duplicates"=>{"state"=>"FINISHED"}, "distribution"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "items_left"=>0}, "errata"=>{"state"=>"FINISHED"}, "metadata"=>{"state"=>"FINISHED"}}}, "error"=>nil, "_id"=>{"$oid"=>"606bc0b28d181860021b0a95"}, "id"=>"606bc0b28d181860021b0a95"}, {"exception"=>nil, "task_type"=>"pulp.server.managers.repo.publish.publish", "_href"=>"/pulp/api/v2/tasks/ebc66a85-9bd6-4e13-b075-744effba267e/", "task_id"=>"ebc66a85-9bd6-4e13-b075-744effba267e", "tags"=> ["pulp:repository:a9efe03c-6934-429c-87ad-0d62859cff7b", "pulp:action:publish"], "finish_time"=>"2021-04-06T02:00:30Z", "_ns"=>"task_status", "start_time"=>"2021-04-06T02:00:30Z", "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 1142, in publish\n" + " result = check_publish(repo_obj, dist_id, dist_inst, transfer_repo, conduit, call_config)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py\", line 1251, in check_publish\n" + " result = _do_publish(repo_obj, dist_id, dist_inst, transfer_repo, conduit, call_config)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py\", line 1303, in _do_publish\n" + " publish_report = publish_repo(transfer_repo, conduit, call_config)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py\", line 905, in wrap_f\n" + " return f(args, *kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/distributor.py\", line 185, in publish_repo\n" + " return self._publisher.process_lifecycle()\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 573, in process_lifecycle\n" + " super(PluginStep, self).process_lifecycle()\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 164, in process_lifecycle\n" + " step.process()\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 240, in process\n" + " self._process_block(item=item)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 302, in _process_block\n" + " self.process_main(item=item)\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/publish.py\", line 991, in process_main\n" + " self._publish_distribution_packages_link(unit)\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/publish.py\", line 1126, in _publish_distribution_packages_link\n" + " % {'repo': self.get_repo().repo_id, 'packagedir': package_path})\n" + "AttributeError: 'Repository' object has no attribute 'repo_id'\n", "spawned_tasks"=>[], "progress_report"=> {"a9efe03c-6934-429c-87ad-0d62859cff7b"=> [{"num_success"=>1, "description"=>"Initializing repo metadata", "step_type"=>"initialize_repo_metadata", "items_total"=>1, "state"=>"FINISHED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"bade4e82-bf2d-4263-9410-1631587e09cf", "num_processed"=>1}, {"num_success"=>0, "description"=>"Publishing Distribution files", "step_type"=>"distribution", "items_total"=>1, "state"=>"FAILED", "error_details"=> [{"traceback"=> " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 240, in process\n" + " self._process_block(item=item)\n" + "\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 302, in _process_block\n" + " self.process_main(item=item)\n" + "\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/publish.py\", line 991, in process_main\n" + " self._publish_distribution_packages_link(unit)\n" + "\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/publish.py\", line 1126, in _publish_distribution_packages_link\n" + " % {'repo': self.get_repo().repo_id, 'packagedir': package_path})\n", "error"=>"'Repository' object has no attribute 'repo_id'"}], "details"=>"", "num_failures"=>1, "step_id"=>"3a465015-99a4-496c-b72c-2b78e020a2cb", "num_processed"=>1}, {"num_success"=>0, "description"=>"Publishing RPMs", "step_type"=>"rpms", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"3202a248-1e2d-4930-9a37-c92c37b4defa", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Delta RPMs", "step_type"=>"drpms", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"fe786dfc-acf1-4633-abed-1a2e4f21d273", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Errata", "step_type"=>"errata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"17932483-6fca-44f5-8d74-e14122147407", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Modules", "step_type"=>"modules", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"d735789c-bafc-4af9-b65c-da54fb1e7b1e", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Comps file", "step_type"=>"comps", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"b60e5d52-5752-4aaf-b1e2-950ec310511a", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Metadata.", "step_type"=>"metadata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"1affa266-f6e3-42d8-8e60-84df0072ee92", "num_processed"=>0}, {"num_success"=>0, "description"=>"Closing repo metadata", "step_type"=>"close_repo_metadata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"f15a6d80-38d6-4a96-822d-25dd061d8e8f", "num_processed"=>0}, {"num_success"=>0, "description"=>"Generating sqlite files", "step_type"=>"generate sqlite", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"f760c0cd-f520-4aae-8c82-99da80fd23bc", "num_processed"=>0}, {"num_success"=>0, "description"=>"Removing old repodata", "step_type"=>"remove_old_repodata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"d48d03ba-53ca-4cc6-959f-63444127c737", "num_processed"=>0}, {"num_success"=>0, "description"=>"Generating HTML files", "step_type"=>"repoview", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"6e0dcf5c-ce5f-4ec5-b266-f73bbd9cd581", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing files to web", "step_type"=>"publish_directory", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"c4ff4e01-d902-4541-8acb-e7b5c789a4c7", "num_processed"=>0}, {"num_success"=>0, "description"=>"Writing Listings File", "step_type"=>"initialize_repo_metadata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"86ccd505-e429-46dc-827f-7ed4c2a2eec0", "num_processed"=>0}, {"num_success"=>0, "description"=>"Writing Listings File", "step_type"=>"initialize_repo_metadata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"2edb96ca-ad8a-4326-805f-5886e4a623d7", "num_processed"=>0}]}, "queue"=>"[email protected]", "state"=>"error", "worker_name"=>"[email protected]", "result"=>nil, "error"=> {"code"=>"PLP0000", "data"=>{}, "description"=>"'Repository' object has no attribute 'repo_id'", "sub_errors"=>[]}, "_id"=>{"$oid"=>"606bc0b88d181860021b1002"}, "id"=>"606bc0b88d181860021b1002"}], "contents_changed"=>false, "poll_attempts"=>{"total"=>12, "failed"=>1}} Exception: Katello::Errors::PulpError: PLP0000: 'Repository' object has no attribute 'repo_id' Backtrace: /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/pulp/abstract_async_task.rb:121:in `block in external_task=' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/pulp/abstract_async_task.rb:119:in `each' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/pulp/abstract_async_task.rb:119:in `external_task=' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/pulp/repository/sync.rb:29:in `external_task=' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action/polling.rb:100:in `poll_external_task_with_rescue' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action/polling.rb:22:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action/cancellable.rb:14:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/pulp/abstract_async_task.rb:45:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:571:in `block (3 levels) in execute_run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:32:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/middleware/remote_action.rb:16:in `block in run' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/middleware/remote_action.rb:40:in `block in as_remote_user' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/models/katello/concerns/user_extensions.rb:21:in `cp_config' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/middleware/remote_action.rb:27:in `as_cp_user' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/middleware/remote_action.rb:39:in `as_remote_user' /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.16.2/app/lib/actions/middleware/remote_action.rb:16:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/rails_executor_wrap.rb:14:in `block in run' /opt/theforeman/tfm/root/usr/share/gems/gems/activesupport-6.0.3.1/lib/active_support/execution_wrapper.rb:88:in `wrap' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/rails_executor_wrap.rb:13:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action/progress.rb:31:in `with_progress_calculation' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action/progress.rb:17:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_request_id.rb:15:in `block in run' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_request_id.rb:49:in `restore_current_request_id' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_request_id.rb:15:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_timezone.rb:15:in `block in run' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_timezone.rb:44:in `restore_curent_timezone' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_timezone.rb:15:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_user.rb:15:in `block in run' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_user.rb:44:in `restore_curent_user' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_user.rb:15:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_taxonomies.rb:15:in `block in run' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_taxonomies.rb:45:in `restore_current_taxonomies' /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-2.0.2/app/lib/actions/middleware/keep_current_taxonomies.rb:15:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:27:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:19:in `pass' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware.rb:32:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/stack.rb:23:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/middleware/world.rb:31:in `execute' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:570:in `block (2 levels) in execute_run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:569:in `catch' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:569:in `block in execute_run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:472:in `block in with_error_handling' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:472:in `catch' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:472:in `with_error_handling' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:564:in `execute_run' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/action.rb:285:in `execute' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/execution_plan/steps/abstract_flow_step.rb:18:in `block (2 levels) in execute' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/execution_plan/steps/abstract.rb:167:in `with_meta_calculation' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/execution_plan/steps/abstract_flow_step.rb:17:in `block in execute' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/execution_plan/steps/abstract_flow_step.rb:32:in `open_action' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/execution_plan/steps/abstract_flow_step.rb:16:in `execute' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/director.rb:93:in `execute' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/executors/sidekiq/worker_jobs.rb:11:in `block (2 levels) in perform' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/executors.rb:18:in `run_user_code' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/executors/sidekiq/worker_jobs.rb:9:in `block in perform' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/executors/sidekiq/worker_jobs.rb:25:in `with_telemetry' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/executors/sidekiq/worker_jobs.rb:8:in `perform' /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.4.7/lib/dynflow/executors/sidekiq/serialization.rb:27:in `perform' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:192:in `execute_job' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:165:in `block (2 levels) in process' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/middleware/chain.rb:128:in `block in invoke' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/middleware/chain.rb:133:in `invoke' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:164:in `block in process' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:137:in `block (6 levels) in dispatch' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/job_retry.rb:109:in `local' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:136:in `block (5 levels) in dispatch' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq.rb:37:in `block in <module:Sidekiq>' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:132:in `block (4 levels) in dispatch' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:250:in `stats' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:127:in `block (3 levels) in dispatch' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/job_logger.rb:8:in `call' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:126:in `block (2 levels) in dispatch' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/job_retry.rb:74:in `global' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:125:in `block in dispatch' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/logging.rb:48:in `with_context' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/logging.rb:42:in `with_job_hash_context' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:124:in `dispatch' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:163:in `process' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:83:in `process_one' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:71:in `run' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/util.rb:16:in `watchdog' /opt/theforeman/tfm/root/usr/share/gems/gems/sidekiq-5.2.7/lib/sidekiq/util.rb:25:in `block in safe_thread' /opt/theforeman/tfm/root/usr/share/gems/gems/logging-2.2.2/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context' Action: Actions::Pulp::Repository::Sync Input: {"source_url"=>nil, "repo_id"=>3314, "smart_proxy_id"=>1, "remote_user"=>"admin", "remote_cp_user"=>"admin", "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {"pulp_tasks"=> [{"exception"=>nil, "task_type"=>"pulp.server.managers.repo.sync.sync", "_href"=>"/pulp/api/v2/tasks/53bd24f3-c4cb-496f-a825-e17ec1ae2cd5/", "task_id"=>"53bd24f3-c4cb-496f-a825-e17ec1ae2cd5", "tags"=> ["pulp:repository:a9efe03c-6934-429c-87ad-0d62859cff7b", "pulp:action:sync"], "finish_time"=>"2021-04-06T02:00:24Z", "_ns"=>"task_status", "start_time"=>"2021-04-06T02:00:19Z", "traceback"=>nil, "spawned_tasks"=> [{"_href"=>"/pulp/api/v2/tasks/ebc66a85-9bd6-4e13-b075-744effba267e/", "task_id"=>"ebc66a85-9bd6-4e13-b075-744effba267e"}], "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"=>"FINISHED"}, "purge_duplicates"=>{"state"=>"FINISHED"}, "distribution"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "items_left"=>0}, "modules"=>{"state"=>"FINISHED"}, "errata"=>{"state"=>"FINISHED"}, "metadata"=>{"state"=>"FINISHED"}}}, "queue"=>"[email protected]", "state"=>"finished", "worker_name"=>"[email protected]", "result"=> {"result"=>"success", "importer_id"=>"yum_importer", "exception"=>nil, "repo_id"=>"a9efe03c-6934-429c-87ad-0d62859cff7b", "traceback"=>nil, "started"=>"2021-04-06T02:00:19Z", "_ns"=>"repo_sync_results", "completed"=>"2021-04-06T02:00:24Z", "importer_type_id"=>"yum_importer", "error_message"=>nil, "summary"=> {"modules"=>{"state"=>"FINISHED"}, "content"=>{"state"=>"FINISHED"}, "comps"=>{"state"=>"FINISHED"}, "purge_duplicates"=>{"state"=>"FINISHED"}, "distribution"=>{"state"=>"FINISHED"}, "errata"=>{"state"=>"FINISHED"}, "metadata"=>{"state"=>"FINISHED"}}, "added_count"=>0, "removed_count"=>0, "updated_count"=>0, "id"=>"606bc0b824143f27c650b443", "details"=> {"modules"=>{"state"=>"FINISHED"}, "content"=> {"size_total"=>0, "items_left"=>0, "items_total"=>0, "state"=>"FINISHED", "size_left"=>0, "details"=> {"rpm_total"=>0, "rpm_done"=>0, "drpm_total"=>0, "drpm_done"=>0}, "error_details"=>[]}, "comps"=>{"state"=>"FINISHED"}, "purge_duplicates"=>{"state"=>"FINISHED"}, "distribution"=> {"items_total"=>0, "state"=>"FINISHED", "error_details"=>[], "items_left"=>0}, "errata"=>{"state"=>"FINISHED"}, "metadata"=>{"state"=>"FINISHED"}}}, "error"=>nil, "_id"=>{"$oid"=>"606bc0b28d181860021b0a95"}, "id"=>"606bc0b28d181860021b0a95"}, {"exception"=>nil, "task_type"=>"pulp.server.managers.repo.publish.publish", "_href"=>"/pulp/api/v2/tasks/ebc66a85-9bd6-4e13-b075-744effba267e/", "task_id"=>"ebc66a85-9bd6-4e13-b075-744effba267e", "tags"=> ["pulp:repository:a9efe03c-6934-429c-87ad-0d62859cff7b", "pulp:action:publish"], "finish_time"=>"2021-04-06T02:00:30Z", "_ns"=>"task_status", "start_time"=>"2021-04-06T02:00:30Z", "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 1142, in publish\n" + " result = check_publish(repo_obj, dist_id, dist_inst, transfer_repo, conduit, call_config)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py\", line 1251, in check_publish\n" + " result = _do_publish(repo_obj, dist_id, dist_inst, transfer_repo, conduit, call_config)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py\", line 1303, in _do_publish\n" + " publish_report = publish_repo(transfer_repo, conduit, call_config)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py\", line 905, in wrap_f\n" + " return f(args, **kwargs)\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/distributor.py\", line 185, in publish_repo\n" + " return self._publisher.process_lifecycle()\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 573, in process_lifecycle\n" + " super(PluginStep, self).process_lifecycle()\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 164, in process_lifecycle\n" + " step.process()\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 240, in process\n" + " self._process_block(item=item)\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 302, in _process_block\n" + " self.process_main(item=item)\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/publish.py\", line 991, in process_main\n" + " self._publish_distribution_packages_link(unit)\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/publish.py\", line 1126, in _publish_distribution_packages_link\n" + " % {'repo': self.get_repo().repo_id, 'packagedir': package_path})\n" + "AttributeError: 'Repository' object has no attribute 'repo_id'\n", "spawned_tasks"=>[], "progress_report"=> {"a9efe03c-6934-429c-87ad-0d62859cff7b"=> [{"num_success"=>1, "description"=>"Initializing repo metadata", "step_type"=>"initialize_repo_metadata", "items_total"=>1, "state"=>"FINISHED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"bade4e82-bf2d-4263-9410-1631587e09cf", "num_processed"=>1}, {"num_success"=>0, "description"=>"Publishing Distribution files", "step_type"=>"distribution", "items_total"=>1, "state"=>"FAILED", "error_details"=> [{"traceback"=> " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 240, in process\n" + " self._process_block(item=item)\n" + "\n" + " File \"/usr/lib/python2.7/site-packages/pulp/plugins/util/publish_step.py\", line 302, in _process_block\n" + " self.process_main(item=item)\n" + "\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/publish.py\", line 991, in process_main\n" + " self._publish_distribution_packages_link(unit)\n" + "\n" + " File \"/usr/lib/python2.7/site-packages/pulp_rpm/plugins/distributors/yum/publish.py\", line 1126, in _publish_distribution_packages_link\n" + " % {'repo': self.get_repo().repo_id, 'packagedir': package_path})\n", "error"=>"'Repository' object has no attribute 'repo_id'"}], "details"=>"", "num_failures"=>1, "step_id"=>"3a465015-99a4-496c-b72c-2b78e020a2cb", "num_processed"=>1}, {"num_success"=>0, "description"=>"Publishing RPMs", "step_type"=>"rpms", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"3202a248-1e2d-4930-9a37-c92c37b4defa", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Delta RPMs", "step_type"=>"drpms", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"fe786dfc-acf1-4633-abed-1a2e4f21d273", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Errata", "step_type"=>"errata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"17932483-6fca-44f5-8d74-e14122147407", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Modules", "step_type"=>"modules", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"d735789c-bafc-4af9-b65c-da54fb1e7b1e", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Comps file", "step_type"=>"comps", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"b60e5d52-5752-4aaf-b1e2-950ec310511a", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing Metadata.", "step_type"=>"metadata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"1affa266-f6e3-42d8-8e60-84df0072ee92", "num_processed"=>0}, {"num_success"=>0, "description"=>"Closing repo metadata", "step_type"=>"close_repo_metadata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"f15a6d80-38d6-4a96-822d-25dd061d8e8f", "num_processed"=>0}, {"num_success"=>0, "description"=>"Generating sqlite files", "step_type"=>"generate sqlite", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"f760c0cd-f520-4aae-8c82-99da80fd23bc", "num_processed"=>0}, {"num_success"=>0, "description"=>"Removing old repodata", "step_type"=>"remove_old_repodata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"d48d03ba-53ca-4cc6-959f-63444127c737", "num_processed"=>0}, {"num_success"=>0, "description"=>"Generating HTML files", "step_type"=>"repoview", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"6e0dcf5c-ce5f-4ec5-b266-f73bbd9cd581", "num_processed"=>0}, {"num_success"=>0, "description"=>"Publishing files to web", "step_type"=>"publish_directory", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"c4ff4e01-d902-4541-8acb-e7b5c789a4c7", "num_processed"=>0}, {"num_success"=>0, "description"=>"Writing Listings File", "step_type"=>"initialize_repo_metadata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"86ccd505-e429-46dc-827f-7ed4c2a2eec0", "num_processed"=>0}, {"num_success"=>0, "description"=>"Writing Listings File", "step_type"=>"initialize_repo_metadata", "items_total"=>1, "state"=>"NOT_STARTED", "error_details"=>[], "details"=>"", "num_failures"=>0, "step_id"=>"2edb96ca-ad8a-4326-805f-5886e4a623d7", "num_processed"=>0}]}, "queue"=>"[email protected]", "state"=>"error", "worker_name"=>"[email protected]", "result"=>nil, "error"=> {"code"=>"PLP0000", "data"=>{}, "description"=>"'Repository' object has no attribute 'repo_id'", "sub_errors"=>[]}, "_id"=>{"$oid"=>"606bc0b88d181860021b1002"}, "id"=>"606bc0b88d181860021b1002"}], "contents_changed"=>false, "poll_attempts"=>{"total"=>12, "failed"=>1}} Action: Actions::Pulp::Orchestration::Repository::Sync Input: {"subaction_output"=>Step(4).output, "remote_user"=>"admin", "remote_cp_user"=>"admin", "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {} Action: Actions::Katello::Repository::IndexContent Input: {"id"=>3314, "contents_changed"=>Step(6).output[:contents_changed], "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {} Action: Actions::Katello::Repository::ErrataMail Input: {"repo"=>3314, "last_updated"=>"2021-03-31 15:35:17 UTC", "contents_changed"=>Step(6).output[:contents_changed], "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {} Action: Actions::Katello::Repository::ErrataMail Input: {"repo"=>3314, "last_updated"=>"2021-03-31 15:35:17 UTC", "contents_changed"=>Step(6).output[:contents_changed], "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {} Action: Actions::Pulp::Repository::RegenerateApplicability Input: {"repository_id"=>3314, "contents_changed"=>Step(6).output[:contents_changed], "remote_user"=>"admin", "remote_cp_user"=>"admin", "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {} Action: Actions::Katello::Repository::Sync Input: {"repository"=>{"id"=>3314, "name"=>"BaseOS", "label"=>"BaseOS"}, "product"=> {"id"=>197, "name"=>"AlmaLinux 8", "label"=>"AlmaLinux_8", "cp_id"=>"234775337781"}, "provider"=>{"id"=>1, "name"=>"Anonymous"}, "organization"=>{"id"=>1, "name"=>"ATIX", "label"=>"ATIX"}, "services_checked"=>["pulp", "pulp_auth"], "id"=>3314, "sync_result"=>Step(6).output, "skip_metadata_check"=>false, "validate_contents"=>false, "contents_changed"=>Step(6).output[:contents_changed], "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {} Action: Actions::Katello::Repository::Sync Input: {"repository"=>{"id"=>3314, "name"=>"BaseOS", "label"=>"BaseOS"}, "product"=> {"id"=>197, "name"=>"AlmaLinux 8", "label"=>"AlmaLinux_8", "cp_id"=>"234775337781"}, "provider"=>{"id"=>1, "name"=>"Anonymous"}, "organization"=>{"id"=>1, "name"=>"ATIX", "label"=>"ATIX"}, "services_checked"=>["pulp", "pulp_auth"], "id"=>3314, "sync_result"=>Step(6).output, "skip_metadata_check"=>false, "validate_contents"=>false, "contents_changed"=>Step(6).output[:contents_changed], "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {} Action: Actions::Katello::Repository::ImportApplicability Input: {"repo_id"=>3314, "contents_changed"=>Step(6).output[:contents_changed], "current_request_id"=>nil, "current_timezone"=>"UTC", "current_user_id"=>1, "current_organization_id"=>1, "current_location_id"=>nil} Output: {}

(0000266) alukoshko 2021-06-08 19:50	Could you check if issue is still here with 8.4 repos?

(0000267) secker 2021-06-09 06:44	Hi, yes the error is still the same. AppStream: Distribution Information No distribution available

(0000294) mpetuhov 2021-06-30 16:37	Hello, i can't reproduce the error. I am using Foreman 2.1.4 with Katello 3.16.2. What OS are you use ? And could you describe algorithm that leads to the error ?

(0000302) mpetuhov 2021-07-08 12:22	According to your traceback you are using Pulp 2, but since Katello 3.16 Pulp 3 is used I am checked that issue on Foreman 1.24.3 with Katello 3.14.1 (Pulp 2) and no errors occurs. We fixed issue with our repos: https://github.com/AlmaLinux/mirrors/issues/101 Maybe they are connected somehow. Please check sync and write here if issue is still here.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
102	[AlmaLinux-8] NetworkManager	major	always	2021-06-20 17:53	2021-07-05 21:22

Reporter:	adontz	Platform:	AWS
Assigned To:	ezamriy	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:	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.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
106	[AlmaLinux-8] lvm2	crash	always	2021-06-25 23:35	2021-06-25 23:35

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:
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:
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:
65	[AlmaLinux-8] -OTHER	minor	always	2021-04-21 16:14	2021-06-24 13:34

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 [...] ===================

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:
89	[AlmaLinux-8] -OTHER	feature	always	2021-05-31 16:25	2021-06-18 14:56

Reporter:	ppyy	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:	please add plus repo
Description:	we use CentOSPlus kernel from CentOS. and fail to migrate to AlmaLinux. https://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000274) toracat 2021-06-12 19:05	As the maintainer of the centosplus kernel, I am curious to know which feature(s) you are interested in that are not in the distro kernel.

(0000276) ppyy 2021-06-14 14:48	CONFIG_MLX4_CORE_GEN2 please refer to: https://elrepo.org/bugs/view.php?id=1037

(0000277) toracat 2021-06-14 15:42	ELRepo has a kmod package for that: https://elrepo.org/linux/elrepo/el8/x86_64/RPMS/kmod-mlx4-4.0-5.el8_4.elrepo.x86_64.rpm I believe the above kmod was built with MLX4_CORE_GEN2 enabled.

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:
93	[AlmaLinux-8] -OTHER	minor	always	2021-06-02 12:05	2021-06-04 17:32

Reporter:	obarrios	Platform:	AWS
Assigned To:	ezamriy	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:	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:
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:

There are no notes attached to this 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:
91	[AlmaLinux-8] glusterfs	minor	always	2021-06-01 15:41	2021-06-01 15:41

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:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
71	[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:
85	[AlmaLinux-8] almalinux-release	minor	always	2021-05-27 06:19	2021-05-27 06:19

Reporter:	kfujinaga	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:	A input method "kkc" is not translated in japanese enviroment.
Description:	In AlmaLinux 8.4, A input method "kkc" is not translated into Japanese. In RHEL 8.4, "kkc" is translated as "日本語(かな漢字)". # "日本語(かな漢字)" means "Japanese (Kana - Chinese characters)" Because "kkc" can't be understood by most japanese users, I want you to translate "kkc" into japanese. # Notice: "kkc" is the default value of the input method in japanese enviroment. The default value can't be understood by most japanese users.
Tags:
Steps To Reproduce:	Step1. Install AlmaLinux 8.4 - language : Japanese - software: Server(GUI) Step2. Reboot Step3. Accept license. Step4. Login Step5. Select "japanese" in language selection. Step6. Show input method selection.
Additional Information:
Attached Files:	AlmaLinux84.png (87,718 bytes) 2021-05-27 06:19 https://bugs.almalinux.org/file_download.php?file_id=85&type=bug RHEL84.png (123,103 bytes) 2021-05-27 06:19 https://bugs.almalinux.org/file_download.php?file_id=86&type=bug

There are no notes attached to this issue.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
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: [[email protected] ~]$ 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:
80	[AlmaLinux-8] lorax	crash	always	2021-05-20 13:45	2021-05-21 23:13

Reporter:	tiny	Platform:	X86_64
Assigned To:	alukoshko	OS:	Alma Linux
Priority:	normal	OS Version:	8.4
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
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

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

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
57	[AlmaLinux-8] -OTHER	feature	always	2021-04-06 16:10	2021-05-11 00:38

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:
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.

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:
60	[AlmaLinux-8] almalinux-release	major	N/A	2021-04-07 18:16	2021-04-13 16:21

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:
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 ?

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:
29	[AlmaLinux-8] -OTHER	feature	always	2021-02-24 21:04	2021-03-17 15:33

Reporter:	lnx1991	Platform:	x86_64
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:	Feature Request: RS Repository
Description:	This is an enhancement/followup to a previous issue requesting the HighAvailability repo which has been completed (thank you): https://bugs.almalinux.org/view.php?id=16 The Resilient Storage (RS) repository "next to HA" (sister channel?) contains complementary RPMs for building the GFS2 cluster while using pacemaker, corosync et. al and in general is mostly a duplicate of the HA repo, however it does include more required software than what is in HA which revolves around shared storage between the cluster nodes. The most notable RPM needed is the "dlm" parent package (the child package from the rpmbuild process, "dlm-lib", is in BaseOS) which only exists in binary RPM form in the RS repo in Red Hat's upstream design. We need this additional package to complete the HA cluster setup with shared storage between the nodes (there may be others, DLM is just the big one of note). There is no corresponding CentOS 8 RS repository due the project not building it (it is/was there in CentOS 7 and earlier), see the bug report with details here: https://bugs.centos.org/view.php?id=16939
Tags:
Steps To Reproduce:	N/A; packages do not exist in any AlmaLinux Repository as of today.
Additional Information:
Attached Files:

Notes
(0000059) alukoshko 2021-03-17 15:33	cmirror and dlm packages were added to HighAvailability repo. Thanks for pointing this out!

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:
36	[AlmaLinux-8] selinux-policy	minor	sometimes	2021-03-07 12:52	2021-03-07 17:39

Reporter:	Alexander	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 is preventing rhsmcertd-worke from node_bind access on the tcp_socket port
Description:	Occasionally the SELinux Troubleshooter Window pops up with the following message: SELinux is preventing rhsmcertd-worke from node_bind access on the tcp_socket port I am not sure about this, but I assume that rhsmcertd should not be present on almalinux at all.
Tags:
Steps To Reproduce:	The SElinux-Troubleshooter pops up once a week.
Additional Information:	Almalinux RC1
Attached Files:

Notes
(0000041) alukoshko 2021-03-07 17:39	Thanks for report. It seems to be an upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1932158 rhsmcertd is part of subscription-manager. Users asked for it after we released AlmaLinux 8.3 Beta without subscription-manager because they want to register AlmaLinux to local Satellite and Katello installations.

View Issue Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
34	[AlmaLinux-8] acpid	tweak	sometimes	2021-02-26 19:23	2021-02-26 19:23

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
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:

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-02-24 21:37

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

There are no notes attached to this issue.

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: [[email protected] ~]# 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. [[email protected] ~]# cat /etc/passwd \| grep chrony chrony:x:994:991::/var/lib/chrony:/sbin/nologin [[email protected] ~]# 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: [[email protected] ~]$ ls -lda /var/log/chrony/ drwxr-xr-x. 2 chrony chrony 6 Jan 26 18:39 /var/log/chrony/ [[email protected] ~]$ 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.