Bug 1873561
Summary: | Anaconda crashes when configuring wifi device | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Jan Stodola <jstodola> | ||||||||||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> | ||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||
Priority: | medium | ||||||||||||||
Version: | 8.3 | CC: | acardace, atragler, bgalvani, lrintel, nm-team, pzatko, rkhan, rvykydal, sukulkar, thaller, till | ||||||||||||
Target Milestone: | rc | Keywords: | Triaged | ||||||||||||
Target Release: | 8.0 | ||||||||||||||
Hardware: | Unspecified | ||||||||||||||
OS: | Unspecified | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | anaconda-33.16.4.5-1 | Doc Type: | If docs needed, set a value | ||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | |||||||||||||||
: | 1912441 (view as bug list) | Environment: | |||||||||||||
Last Closed: | 2021-05-18 15:47:06 UTC | Type: | Bug | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Bug Depends On: | |||||||||||||||
Bug Blocks: | 1812825 | ||||||||||||||
Attachments: |
|
Description
Jan Stodola
2020-08-28 15:49:45 UTC
Created attachment 1712973 [details]
screenshot
Created attachment 1712974 [details]
anaconda.log
Created attachment 1712975 [details]
program.log
Created attachment 1712976 [details]
syslog
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. (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? (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) (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. (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? (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/ 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. (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! 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 ? 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. 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. Created attachment 1734096 [details]
backtrace and debug information
possible fix: https://github.com/rhinstaller/anaconda/pull/3045 (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? (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. *** Bug 1847868 has been marked as a duplicate of this bug. *** Reassigning to Anaconda per comment #22. (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 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. 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 |