|
Bugzilla – Full Text Bug Listing |
| Summary: | Many YaST modules crash when they're opened on TW Snapshot 20190108 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Antonio Larrosa <alarrosa> |
| Component: | YaST2 | Assignee: | Josef Reidinger <jreidinger> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P1 - Urgent | CC: | alarrosa, dgonzalez, dimstar, jreidinger, mbrugger, sainthyoga2003, schubi |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://trello.com/c/eXDlLeyV | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Yast logs
YaST logs from 20190103 Snapshot with Y2DEBUG=1 Full y2log plain txt file |
||
Could you please add y2logs ? Additional note to reproduce it: Run: sudo yast Go to System / Boot Loader and press Enter. The module crashes and the view returns to the main view. But if I instead run: sudo yast bootloader The module starts fine. Created attachment 794081 [details]
Yast logs
I guess mainly the y2log file is needed but I attached the whole /var/log/YaST2 directory just in case. I also added a line "antlarr -- Execution starts here:" to separate the last failing execution from the previous tries.
Btw, if you want to reproduce it, you can grab the TW iso from https://openqa.opensuse.org/tests/827852#downloads and do a fresh install (I tried both with KDE and GNOME installations and both show the same problem). Also you can find there a qcow image that I also checked that can be used to reproduce the issue. Also reproducible in with the openSUSE TW 20190103 snapshot, which I had installed to test other bug. Tracking it in our Trello board. Thank you Antonio. Created attachment 794090 [details]
YaST logs from 20190103 Snapshot with Y2DEBUG=1
looks like there is some change in calling module from modules in ncurses window manager. As it pass single argument and in return yast module think it is CLI. see 2019-01-10 14:13:43 <1> linux-9x6v(3261) [Interpreter] bin/y2start:62 Calling YaST client bootloader 2019-01-10 14:13:43 <0> linux-9x6v(3261) [Interpreter] bin/y2start:62 (arguments: [""]) and 2019-01-10 14:13:44 <0> linux-9x6v(3261) [libscr] SCR.cc(SCRWrite2):67 Running SCR::Write (2 args) on SCR agent 0xf244a0 2019-01-10 14:13:44 <0> linux-9x6v(3261) [scr] ScriptingAgent.cc(executeSubagentCommand):589 ScriptingAgent::executeSubagentCommand: Write 2019-01-10 14:13:44 <0> linux-9x6v(3261) [scr] ScriptingAgent.cc(executeSubagentCommand):590 path: .dev.tty.stderr 2019-01-10 14:13:44 <0> linux-9x6v(3261) [scr] ScriptingAgent.cc(executeSubagentCommand):591 arg: "This YaST2 module does not support the command line interface." 2019-01-10 14:13:44 <0> linux-9x6v(3261) [scr] ScriptingAgent.cc(executeSubagentCommand):592 opt: null 2019-01-10 14:13:44 <0> linux-9x6v(3261) [libycp] parser.yy(yyparse):403 In the end looks like result of execution hardening when nil arguments are passed. Will fix it. fix is in review https://github.com/yast/yast-yast2/pull/887 and merged. Thanks for report. jenkins is currently down due to some scheduled maintainence so I send it manually to TW as SR#664404 Very fast fix, that's great! Thank you! To me, isn't resolved. I have updated TW 3 days ago. I still get this issue. In addition (I think it will go in another new "bug" report) GUI Yast2 is never opened if I do click in YaST Menu option. Created attachment 794396 [details]
Full y2log plain txt file
(In reply to Néstor Acevedo from comment #12) > To me, isn't resolved. I have updated TW 3 days ago. I still get this issue. > In addition (I think it will go in another new "bug" report) GUI Yast2 is > never opened if I do click in YaST Menu option. I still see in logs same issue. Maybe yast2.rpm is still in staging project? What version do you use? Fix is in 4.1.49. You can get version with rpm -q yast2 (In reply to Josef Reidinger from comment #14) > (In reply to Néstor Acevedo from comment #12) > > To me, isn't resolved. I have updated TW 3 days ago. I still get this issue. > > In addition (I think it will go in another new "bug" report) GUI Yast2 is > > never opened if I do click in YaST Menu option. > > I still see in logs same issue. Maybe yast2.rpm is still in staging project? > What version do you use? Fix is in 4.1.49. You can get version with > > rpm -q yast2 That's curious. I still have the yast2-4.1.48-1.1.x86_64 version. 666473 State:review By:dimstar_suse When:2019-01-16T13:46:59
submit: YaST:Head/yast2@851 -> openSUSE:Factory
Review by Group is accepted: legal-auto(licensedigger)
Review by Group is accepted: factory-auto(factory-auto)
Review by Group is accepted: factory-staging(dimstar_suse)
Review by Group is accepted: opensuse-review-team(dimstar)
Review by User is new: repo-checker(factory-auto)
Review by Project is new: openSUSE:Factory:Staging:G(dimstar_suse)
Descr: submit new version 4.1.51
Comment: Being evaluated by staging project "openSUSE:Factory:Staging:G"
Last checked in version was 4.1.48 - since then, yast2 keep on being superseded/updated too frequent to get a checkin done
(In reply to Dominique Leuenberger from comment #16) > 666473 State:review By:dimstar_suse When:2019-01-16T13:46:59 > submit: YaST:Head/yast2@851 -> > openSUSE:Factory > Review by Group is accepted: legal-auto(licensedigger) > > Review by Group is accepted: factory-auto(factory-auto) > > Review by Group is accepted: factory-staging(dimstar_suse) > > Review by Group is accepted: opensuse-review-team(dimstar) > > Review by User is new: repo-checker(factory-auto) > > Review by Project is new: > openSUSE:Factory:Staging:G(dimstar_suse) > Descr: submit new version 4.1.51 > Comment: Being evaluated by staging project > "openSUSE:Factory:Staging:G" > > > Last checked in version was 4.1.48 - since then, yast2 keep on being > superseded/updated too frequent to get a checkin done Yes, I didn't figured it. Just after answer here I checked the available versions in the repositories and the last one is yast2-4.1.48-1.1, so I don't know how Joseph has the version 4.1.49. (In reply to Néstor Acevedo from comment #17) > (In reply to Dominique Leuenberger from comment #16) > > 666473 State:review By:dimstar_suse When:2019-01-16T13:46:59 > > submit: YaST:Head/yast2@851 -> > > openSUSE:Factory > > Review by Group is accepted: legal-auto(licensedigger) > > > > Review by Group is accepted: factory-auto(factory-auto) > > > > Review by Group is accepted: factory-staging(dimstar_suse) > > > > Review by Group is accepted: opensuse-review-team(dimstar) > > > > Review by User is new: repo-checker(factory-auto) > > > > Review by Project is new: > > openSUSE:Factory:Staging:G(dimstar_suse) > > Descr: submit new version 4.1.51 > > Comment: Being evaluated by staging project > > "openSUSE:Factory:Staging:G" > > > > > > Last checked in version was 4.1.48 - since then, yast2 keep on being > > superseded/updated too frequent to get a checkin done > > Yes, I didn't figured it. Just after answer here I checked the available > versions in the repositories and the last one is yast2-4.1.48-1.1, so I > don't know how Joseph has the version 4.1.49. I used our devel project YaST:Head where is always the latest version, but I do not recommend it, as it is not tested by openQA, so useful mainly for YaST developers. So closing again. Thanks yast2 is still 4.1.48-1.1 is there any possibility to get 4.1.49 out? I just got hit by the bug on RPi3. (In reply to Matthias Brugger from comment #19) > yast2 is still 4.1.48-1.1 is there any possibility to get 4.1.49 out? I just > got hit by the bug on RPi3. As soon as Staging:G is green - since all modules can be started directly, there is, for the time being, a workaround in place (not the most comfortable, but still) |
On Tumbleweed Snapshot 20190108, when using yast in ncurses mode, opening many of its modules make Yast actually just return to the main view of all modules and an error is printed on the terminal: Warning: unable to close filehandle __ANONIO__ properly: Bad file descriptor, <STDIN> line 2 during global destruction (#1) (S io) There were errors during the implicit close() done on a filehandle when its reference count reached zero while it was still open, e.g.: { open my $fh, '>', $file or die "open: '$file': $!\n"; print $fh $data or die "print: $!"; } # implicit close here Because various errors may only be detected by close() (e.g. buffering could allow the print in this example to return true even when the disk is full), it is dangerous to ignore its result. So when it happens implicitly, perl will signal errors by warning. Prior to version 5.22.0, perl ignored such errors, so the common idiom shown above was liable to cause silent data loss. This happens for example with: Online update, Software repositories, Boot Loader, /etc/sysconfig Editor, Date and Time, Hardware Information, Release Notes, etc. At least the following modules are opened fine: Software Management, Partitioner, System-Wide Fonts. Also, note that this only happens in ncurses mode. When using the qt interface, all modules work fine.