[im on plasma] if i click yast>kernel-settings it starts reading system settings, then the window just closes. I assume i have a malformed config file or such like? I did a start-menu search for ‘kernel settings’ which gives command shortcut xdg-su -c “/sbin/yast2 system_settings”, but run from terminal gives no information. Thanks for any help.
then i engaged my brain and tried again as root (both su and su-)
#su
#/sbin/yast2 system_settings
/usr/share/YaST2/include/hwinfo/routines.rb:43: warning: key "cache" is duplicated and overwritten on line 592
/usr/share/YaST2/include/hwinfo/routines.rb:343: warning: key "vendor_id" is duplicated and overwritten on lin
e 652
/usr/share/YaST2/modules/StorageInit.rb:77: warning: constant ::Fixnum is deprecated
[the window closed again]
i then tried:
#su -
#/sbin/yast2 system_settings
/usr/share/YaST2/include/hwinfo/routines.rb:43: warning: key "cache" is duplicated and overwritten on line 592
/usr/share/YaST2/include/hwinfo/routines.rb:343: warning: key "vendor_id" is duplicated and overwritten on line 652
/usr/share/YaST2/modules/StorageInit.rb:77: warning: constant ::Fixnum is deprecated
but this time the window opened?
to bump my own thread, nobody has any ideas/intuitions?
/var/log/YaST2/y2log should tell more about the crash.
And there may be a signal file too in the same directory, IIRC.
You may want to file a bug report though, see here for the required information:
https://en.opensuse.org/openSUSE:Report_a_YaST_bug
FWIW, it seems to work fine here on Leap 42.3…
Having just read https://forums.opensuse.org/showthread.php/522384-System-freezes-after-some-uptime?p=2833158#post2833158, i thought i’d have a look at that same YaST section. To my shock the identical misbehaviour you described also happens to mine. At that point i had not seen this current thread, so i laughed at the serendipity of me then reading your thread on the same problem. My TW [KDE] is 20170802.
> To my shock the identical misbehaviour you described also happens to mine.
thanks for feedback, so it looks like it might be a systematic rather than individual problem.
Three more data points FYI… TW [KDE] versions 20170806 & 20170808 still / also don’t solve it – the same misbehaviour occurs. Conversely, in one of my older VMs, 20170725 does work properly. So, somewhere between 20170725 & 20170802, the problem arose.
Oh, groan. I found another old VM, also 20170725, & it does not work properly. The YaST2 Kernel Settings window sometimes actually gets to 100%, other times only 50%, but either way then closes abruptly. So, this really only muddies the waters…
Another data point: In TW [KDE] 20170730 it does open correctly, every time.
since you have bisected and investigated the issue more than i, perhaps submit a bug report? (be sure to include (check) it works from terminal “su -” if you do)
I haven’t ignored or forgotten this, but have been too busy to advance this… am still planning on doing it though, once i have time to. In the meantime, more info… every TW snapshot since my previous note, up to & including the current 20170821, continues to bomb out on that YaST module. However tonight when i did try it in said latest snapshot, it gave some new info prior to then aborting:
I had some spare time today, so thought i might give this [bug-reporting] a try. I’ve now read these:
- https://en.opensuse.org/openSUSE:Report_a_YaST_bug
- https://en.opensuse.org/openSUSE:Submitting_bug_reports
- https://bugzilla.opensuse.org/enter_bug.cgi?product=openSUSE+Tumbleweed&format=guided
…& i confess to now feeling quite intimidated about the complex procedure & requirements. Even though i was not the originator of this thread, & despite my sense of personal inadequacy re the onerous requirements, I still feel willing to try to do it, given i remain so very impressed with openSUSE & the helpful community… grateful for such a fine distro.
All that guff said, i noted in the third link that it’s important to avoid duplication by first searching the bugs database – that makes complete sense. However, i feel that i have fallen at the first hurdle. What are the best keywords to search for? Is the search function’s logic fuzzy or exact [ie, if i don’t happen to think of the “right” words for an exact match with any putative existing bug entry, will it still be found, or will it miss?]. For example, i tried searching for “yast kernel-settings” [in the entry field directly below the page-top bugs table, then clicked the green “[i]Search” button], but nothing happened… nothing. The page gives me no visual indication if it did actually search or not. Is that normal? Does it mean that i did something wrong, or the page is broken, or that there were no hits? I also tried “yast kernel settings”, with the same [non] reaction.
Oh – wait – i just discovered that the page does respond if i instead use the top search field, so i shall continue… but why does the other one not also work? Is there a bug reporter for the bug reporter? 
Just tested in Leap 42.2, same or similar problem, stops with this error message:
http://paste.opensuse.org/images/23312320.png
Click on the okay, all just vanishes into thin air.
System is up to date.
Is it worth filing a bug report for 42.2 now that 42.3 is out?
I have not tested in 42.3, but see above that wolfi reports it is not happening in 42.3.
For what it is worth it does not happen here. 42.2 AMD CPU/NVIDIA using GO4
42.2 is still supported until January at least (6 months after the release of 42.3).
I have not tested in 42.3, but see above that wolfi reports it is not happening in 42.3.
Yes, it works fine here.
But the problem may very well be restricted to a certain hardware or system setup.
Augeas (that is mentioned in your error message) is a parser for config files:
rpm -qi augeas
...
Description :An utility for programmatically editing configuration files. Augeas
parses configuration files into a tree structure.
The transformation works very hard to preserve comments and formatting
details. It is controlled by ``lens'' definitions that describe the
file format and the transformation into a tree.
So the problem might be triggered by certain config files, and I find that very likely actually.
Okay, thanks, wolfi. I am running all queries I can think of to be certain it is not already reported, then I will file a bug report. I will report back here with the link to the bug when that is done.
One other thing, I am also not exactly certain how to file it, as this appears to me to be the same bug or very similar with different outputs for different Users.