RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1873561 - Anaconda crashes when configuring wifi device
Summary: Anaconda crashes when configuring wifi device
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: anaconda
Version: 8.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.0
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
: 1847868 (view as bug list)
Depends On:
Blocks: 1812825
TreeView+ depends on / blocked
 
Reported: 2020-08-28 15:49 UTC by Jan Stodola
Modified: 2021-05-18 15:47 UTC (History)
11 users (show)

Fixed In Version: anaconda-33.16.4.5-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1912441 (view as bug list)
Environment:
Last Closed: 2021-05-18 15:47:06 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
screenshot (622.20 KB, image/jpeg)
2020-08-28 15:50 UTC, Jan Stodola 		no flags Details
anaconda.log (17.13 KB, text/plain)
2020-08-28 15:54 UTC, Jan Stodola 		no flags Details
program.log (3.46 KB, text/plain)
2020-08-28 15:54 UTC, Jan Stodola 		no flags Details
syslog (553.93 KB, text/plain)
2020-08-28 15:55 UTC, Jan Stodola 		no flags Details
backtrace and debug information (20.90 KB, text/plain)
2020-11-27 12:57 UTC, Beniamino Galvani 		no flags Details
View All

Description Jan Stodola 2020-08-28 15:49:45 UTC 
Description of problem:
Anaconda crashes when trying to configure a wifi network device and when opening the configuration dialog window for the third time (exactly, and always). Unable to reproduce with a wired network device. Reproduced on two laptops - Lenovo T450s and T480s, booting from a USB flash drive with DVD.iso image.

Version-Release number of selected component (if applicable):
anaconda-33.16.3.21-1.el8

How reproducible:
Always (7 out of 7 attempts)

Steps to Reproduce:
1. Start a graphical installation (used dvd.iso).
2. Proceed to the Network & Host Name spoke.
3. Select the wifi device and pick a SSID from the list of network names.
4. Enter the password and connect to the network.
5. Click on the "Configure..." button and close the newly opened window without making any changes.
6. Click on the "Configure..." button and close the newly opened window without making any changes.
7. Click on the "Configure..." button.

Actual results:
Anaconda crashes.

Expected results:
Able to configure the wifi device.

Additional info:
Could be related to bug 1847868, which describes a similar crash, but with different steps.
Comment 1 Jan Stodola 2020-08-28 15:50:39 UTC 
Created attachment 1712973 [details]
screenshot
Comment 3 Jan Stodola 2020-08-28 15:54:17 UTC 
Created attachment 1712974 [details]
anaconda.log
Comment 4 Jan Stodola 2020-08-28 15:54:35 UTC 
Created attachment 1712975 [details]
program.log
Comment 5 Jan Stodola 2020-08-28 15:55:19 UTC 
Created attachment 1712976 [details]
syslog
Comment 8 Radek Vykydal 2020-10-08 12:42:15 UTC 
Thomas, just asking if backtrace from https://bugzilla.redhat.com/show_bug.cgi?id=1873561#c1 or from https://bugzilla.redhat.com/show_bug.cgi?id=1847868#c1 (another BZ) does ring any bell. I guess no, but I rather ask before diving into debugging. It started to happen in RHEL 8 when configuring wireless devices in Anaconda.
Comment 9 Thomas Haller 2020-10-08 15:26:17 UTC 
(In reply to Radek Vykydal from comment #8)
> Thomas, just asking if backtrace from
> https://bugzilla.redhat.com/show_bug.cgi?id=1873561#c1 or from
> https://bugzilla.redhat.com/show_bug.cgi?id=1847868#c1 (another BZ) does
> ring any bell. I guess no, but I rather ask before diving into debugging. It
> started to happen in RHEL 8 when configuring wireless devices in Anaconda.

No it does not ring a bell. It looks like a libnm problem, but without debugging symbols it is hard to tell.

Usually I would suggest to reassign to NetworkManager. However, with the provided information so far, I wouldn't know how to fix it. Could you dig a bit further to find out more?
Comment 10 Radek Vykydal 2020-10-14 09:23:53 UTC 
(In reply to Thomas Haller from comment #9)
 
> Usually I would suggest to reassign to NetworkManager. However, with the
> provided information so far, I wouldn't know how to fix it. Could you dig a
> bit further to find out more?

Hello Thomas, I've added some more debugging info (source code references) in https://bugzilla.redhat.com/show_bug.cgi?id=1847868#c9. Could you take a look ?

(I am suspecting a bit Anaconda still using dbus-python for SecretAgent service while using dasbus (-> GLib) for all other internal services, but maybe it is something in NM)
Comment 11 Radek Vykydal 2020-10-19 12:35:51 UTC 
(In reply to Radek Vykydal from comment #10)
 
> (I am suspecting a bit Anaconda still using dbus-python for SecretAgent
> service while using dasbus (-> GLib) for all other internal services, but
> maybe it is something in NM)

The issue is present also after migrating of SecretAgent to dasbus.
Comment 12 Thomas Haller 2020-10-19 14:08:03 UTC 
(In reply to Radek Vykydal from comment #10)

it does look like a libnm bug, but with this backtrace it's not easy to understand.

Are you able to actually reproduce this? Could I get access to such a machine (to look around with gdb?)
Or can I give you a patched scratch-build with more debugging info?
Comment 13 Radek Vykydal 2020-10-19 16:11:25 UTC 
(In reply to Thomas Haller from comment #12)
> (In reply to Radek Vykydal from comment #10)
> 
> it does look like a libnm bug, but with this backtrace it's not easy to
> understand.
> 
> Are you able to actually reproduce this?

I am able to reproduce it always (in installer), as described in Description of bug 1847868.
It is reproducible on RHEL 8.3, RHEL 8.4 (I think 8.2 as well) or Fedora (I reproduced with F32).
Just start installation on some machine with wireless device, connect to one AP and then try to connect (desn't have to be a successful connection using correct credentials) to another one. In the office I'd use PXE installation, at home I am putting boot.iso or dvd iso (or Fedora network installation Server iso) on usb stick [1] and run installation from it, using another usb stick to get updates image (like inst.updates=hd:sda1/updates.img, it has to be ext or xfs IIRC). But you can use also wired connection to fetch updates image via http which is way easier.

Could I get access to such a
> machine (to look around with gdb?)

Currently my testing machine is at home with no wired connection. In the office it would be possible.
Also the pain here is that the installation image does not contain any debuginfos and it is not easy to add them to the environment - one way would be using updates.img with added debuginfo packages - see below.
It is not so hard to reproduce the issue locally (if you have a laptop to use for it).

> Or can I give you a patched scratch-build with more debugging info?

Yes, I could run it. It can be applied with updates.img as well like (NM rpms in the NNMrpms folder):

scripts/makeupdates -a NMrpms/*

the makeupdates tool:
https://github.com/rhinstaller/anaconda/blob/master/scripts/makeupdates

updates.img doc:
https://fedoraproject.org/wiki/Anaconda/Updates

It is not complicated, just a bit laborous (without some additional scripting) - you could add both scratch build of NM and debuginfo packages to the installer environment with updates.img. Another option would be to build the installer iso completely using lorax with additional repository of NM scratch build repo added [2] but it would not include the debuginfo packages and building the iso takes some time (15-20 mins?).

[1] https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/
[2] example:
lorax --product="Red Hat Enterprise Linux" --version=8.3 --release=8.3 \
  --workdir ./lorax-work \
  --variant=BaseOS --nomacboot --buildarch=x86_64 --volid=RHEL-8-3-0-BaseOS-x86_64 \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8/compose/BaseOS/x86_64/os/ \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8/compose/AppStream/x86_64/os/ \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8/compose/CRB/x86_64/os/ \
  -s http://brew-task-repos.usersys.redhat.com/repos/scratch/acardace/NetworkManager/1.26.0/7.el8/x86_64/ \
  -s http://brew-task-repos.usersys.redhat.com/repos/scratch/rvykydal/anaconda/33.16.3.21/5.el8/x86_64/ \
  ./test/
Comment 14 Jan Stodola 2020-10-19 16:50:15 UTC 
Thomas/Radek, you might be able to reproduce it also on an installed system:
Install the anaconda package, run "anaconda" and follow the steps from bug 1847868#c0. This way I was able to reproduce bug 1847868 on Fedora 32.
Comment 15 Radek Vykydal 2020-10-19 16:58:25 UTC 
(In reply to Jan Stodola from comment #14)
> Thomas/Radek, you might be able to reproduce it also on an installed system:
> Install the anaconda package, run "anaconda" and follow the steps from bug
> 1847868#c0. This way I was able to reproduce bug 1847868 on Fedora 32.

Oh great, thank you Jan!
Comment 16 Radek Vykydal 2020-10-27 09:24:36 UTC 
Thomas, would someone from NM team be able to look at the issue given it can be reproduced and debugged on installed system (comment #14). Should we reassign the bug 1847868 and this one to NM ?
Comment 17 Jan Stodola 2020-11-27 09:11:40 UTC 
Hi folks,
could you please have a look at this bug and let us know if you need any further help? As written in comment 14, the crash can be reproduced also on an installed system.
Comment 18 Beniamino Galvani 2020-11-27 12:56:16 UTC 
Hi,

I reproduced the crash on F33 and gathered some debug information. It looks like a bug in libnm object cache implementation. I don't think we need further information, just some time to investigate the issue further. I'm attaching the backtrace and other information.
Comment 19 Beniamino Galvani 2020-11-27 12:57:31 UTC 
Created attachment 1734096 [details]
backtrace and debug information
Comment 20 Thomas Haller 2020-12-09 17:10:07 UTC 
possible fix: https://github.com/rhinstaller/anaconda/pull/3045
Comment 21 Radek Vykydal 2020-12-11 08:20:40 UTC 
(In reply to Thomas Haller from comment #20)
> possible fix: https://github.com/rhinstaller/anaconda/pull/3045

Updated patch for rhel-8 branch:
https://github.com/rhinstaller/anaconda/pull/3052

Based on the commit message of the patch I'd propose to:
- mark the bug 1847868 as duplicate of this bug
- reassingn this bug to Anaconda and fix it with the PR 3052
- clone this bug for NM with title "libnm functions ... causing client crash" for future reference or work on the issue

What do you think, Jan, Thomas?
Comment 22 Jan Stodola 2020-12-14 21:35:23 UTC 
(In reply to Radek Vykydal from comment #21)

> Based on the commit message of the patch I'd propose to:
> - mark the bug 1847868 as duplicate of this bug
> - reassingn this bug to Anaconda and fix it with the PR 3052
> - clone this bug for NM with title "libnm functions ... causing client
> crash" for future reference or work on the issue
> 
> What do you think, Jan, Thomas?

approved.
Comment 23 Radek Vykydal 2021-01-04 13:54:52 UTC 
*** Bug 1847868 has been marked as a duplicate of this bug. ***
Comment 24 Radek Vykydal 2021-01-04 14:03:06 UTC 
Reassigning to Anaconda per comment #22.
Comment 25 Radek Vykydal 2021-01-04 14:04:18 UTC 
(In reply to Jan Stodola from comment #22)

> > - clone this bug for NM with title "libnm functions ... causing client
> > crash" for future reference or work on the issue

bug 1912441
Comment 27 Jan Stodola 2021-01-12 14:12:35 UTC 
I tried to reproduce a crash in the updated UI (anaconda-33.16.4.5-1.el8), but all my attempts we not successful and anaconda survived without a crash or traceback.
The only problem I noticed is reported as a new bug 1915354.
Comment 32 errata-xmlrpc 2021-05-18 15:47:06 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (anaconda bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1844
Note You need to log in before you can comment on or make changes to this bug.