Yast qt version seg faults

English Applications
1

running “kdesu yast --qt” opens the request for password window but nothing happens

running just “yast2” in Konsole produces

/usr/sbin/yast2: line 440: 7556 Segmentation fault $y2ccbin $Y2UI_ARGS “$@”

running a specific module produces

>yast2 --qt sw_single
YaST got signal 11 at file /usr/share/YaST2/modules/Wizard.rb:836
/usr/sbin/yast2: line 440: 8430 Segmentation fault $ybindir/y2base $module “$@” “$SELECTED_GUI” $Y2_GEOMETRY $Y2UI_ARGS

running “yast2 --qt” as root in Konsole works fine, the gtk version works fine

This happened after my system got borked after an update and I fixed it by doing an upgrade from the 13.2 dvd. I had no choice as the system booted into a black screen and whatever msgs displayed couldn’t be read, the grub screen did not display either

Tried reinstalling all Yast and QT packages, running it as a different user and un-installing librpoxy1-config-kde4 (it was mentioned in a search result)

running 13.2, KDE 4.14.3

thanks,

2

addendum - the section of Yast2 that ends on line 440

 elif test $module != "menu" && other_tools_are_conflicting "$@" ; then    exit_code=1
else
    # In case YaST has to be restarted, create this file
    # and exit. Script that creates the file should also
    # remove it itself.
    case "$module" in
    # special cases
    menu) REDO_FILE=/var/lib/YaST2/restart_menu ;;
    online_update) REDO_FILE=/var/lib/YaST2/selected_patches.ycp ;;
    # all other cases when YaST has to be restarted
    *) REDO_FILE=/var/lib/YaST2/restart_yast ;;
    esac
    snapshot_pre $module
    #  break out on errors, #343258
    while  $exit_code = 0 ]; do
    $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS
    exit_code=$?
    if  -z "$REDO_FILE" -o ! -f "$REDO_FILE" ]; then
        break
    fi
3

On 2015-01-08 02:46, google01103 wrote:
>
> running “kdesu yast --qt” opens the request for password window but
> nothing happens
>
> running just “yast2” in Konsole produces
>> /usr/sbin/yast2: line 440: 7556 Segmentation fault $y2ccbin
>> $Y2UI_ARGS “$@”

As plain user? It should not work.

> running “yast2 --qt” as root in Konsole works fine, the gtk version
> works fine

Then I see no problem >:-)

> This happened after my system got borked after an update and I fixed it
> by doing an upgrade from the 13.2 dvd. I had no choice as the system
> booted into a black screen and whatever msgs displayed couldn’t be read,
> the grub screen did not display either
>
> Tried reinstalling all Yast and QT packages, running it as a different
> user and un-installing librpoxy1-config-kde4 (it was mentioned in a
> search result)

Run this:


rpm -q -a --queryformat "%{INSTALLTIME}	%{INSTALLTIME:day} \
%{BUILDTIME:day} %-30{NAME}	%15{VERSION}-%-7{RELEASE}	%{arch} \
%25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}
" \
| sort | cut --fields="2-" | tee rpmlist \
| egrep -v "openSUSE.13\.2" | less -S

And examine the results. Any entry is suspect of not belonging to 13.2.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

4

Yes, it should.
But it should show a warning that it will not show all entries when run as normal user, and then only show a few.

It definitely shouldn’t segfault… :wink:

Regarding the problem:
Try running “xauth -b” (as user) and then just quit by entering ‘q’.

If that doesn’t help, please post the last lines of /var/log/YaST2/y2log after it segfaults:

sudo tail /var/log/YaST2/y2log

Strange though that it would work as root (I suppose you mean you log in to the GUI as root, right?). This should rule out an installation problem.
Maybe some graphics driver issue? (insufficient permissions perhaps)
What does “glxinfo | grep render” say when running it as user? (you might have to install Mesa-demo-x to get output)

5 
 xauth -b
Attempting to break locks on authority file /home/smiley/.Xauthority
Using authority file /home/smiley/.Xauthority

The tail is not from the “yast2” command based on time stamp

No, I was running it in a root Konsole session and it works fine, BUT logging in as root and it also seg faults -

glxinfo | grep renderdirect rendering: Yes
OpenGL renderer string: GeForce GT 430/PCIe/SSE2
    GL_KHR_debug, GL_KTX_buffer_region, GL_NVX_conditional_render, 
    GL_NV_blend_square, GL_NV_compute_program5, GL_NV_conditional_render, 
    GL_NV_parameter_buffer_object2, GL_NV_path_rendering, 
    GL_KHR_debug, GL_KTX_buffer_region, GL_NVX_conditional_render, 
    GL_NV_blend_square, GL_NV_compute_program5, GL_NV_conditional_render, 
    GL_NV_parameter_buffer_object2, GL_NV_path_rendering, 
    GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
6

So it crashes before it is even opening the log.

No, I was running it in a root Konsole session and it works fine, BUT logging in as root and it also seg faults -

So it works inside the user’s X session if you run it via “su -”, but not with kdesu, right?

glxinfo | grep renderdirect rendering: Yes

Looks ok. But if it doesn’t work inside an X session running as root either, it’s definitely not permissions related.

One question: when it works, what widget style does it have? (you can best see that inside some module, how the checkboxes look like)

This crash could be caused by a mismatch of Qt5 and libKF5Style5 versions, which would make each Qt5 application crash when trying to use KDE’s styles (breeze, oxygen). Running it via “su -” might imply different settings (because of the different environment), and cause it to use the built-in “Fusion” style instead (and therefore not crash).

Does uninstalling libKF5Style5 (and ignoring the dependencies) help?
The main negative side-effect of this would just be that all Qt5/KF5 apps would use Fusion instead of Breeze or Oxygen, you don’t have to fear breaking your system by trying that. :wink:

7

correct

I run Oxygen

Confused - I’m running KDE4 not 5

8

In YaST?
I mean the widget style btw, not the window decorations.

Confused - I’m running KDE4 not 5

But YaST is using Qt5. And if libKF5Style5 is installed, it will try to use Breeze by default even when running on KDE4.

If you don’t have libKF5Style5 installed at all, this is probably not the problem, of course.

9

https://forums.opensuse.org/images/misc/quote_icon.pngOriginally Posted by wolfi323
This crash could be caused by a mismatch of Qt5 and libKF5Style5 versions, which would make each Qt5 application crash when trying to use KDE’s styles (breeze, oxygen). Running it via “su -” might imply different settings (because of the different environment), and cause it to use the built-in “Fusion” style instead (and therefore not crash).

Does uninstalling libKF5Style5 (and ignoring the dependencies) help?
The main negative side-effect of this would just be that all Qt5/KF5 apps would use Fusion instead of Breeze or Oxygen, you don’t have to fear breaking your system by trying that. :wink:

Yup - that’s the issue, so I should lock libKF5Style5 ? strange didn’t have this until I un-borked the system, of course this isn’t my only new issue from the un-borking (you might find a new post on the KDE5 thread if I can’t figure it out :embarrassed: )

thanks (a bunch)

10

No, just install the correct one that is built against the Qt5 you have installed.

IOW, if you have Qt5 5.4.0 from the KDE:Qt5 repo, you need libKF5Style5 from KDE:Frameworks5.
If you have Qt5 5.3.2 from the standard 13.2 repos, you also need the libKF5Style5 from the standard 13.2 repos.

libKF5Style5 (i.e. KDE’s Qt5 platform plugin) uses some private internal Qt APIs that have changed between 5.3 and 5.4.
Other desktop plugins (lxqt-libqtplugin e.g.) have the same “issue”.

The reason why YaST crashed when running via kdesu or in root’s KDE session, but not when run via “su -”, is that Qt5 checks via a certain environment variable on which desktop it is running and loads the corresponding plugin then. If you run it in KDE (doesn’t matter whether it’s KDE4 or Plasma5) this variable is set to “KDE” and so the KDE platform plugin (libKF5Style5) is loaded to get KDE’s settings etc.
If you run “su -” (this is done by the root Konsole session, have a look at the profile…), the environment gets reset completely, so Qt5 cannot detect that it is running inside KDE and doesn’t load that plugin.

strange didn’t have this until I un-borked the system, of course this isn’t my only new issue from the un-borking (you might find a new post on the KDE5 thread if I can’t figure it out :embarrassed: )

If another issue was Plasma5 or all other KF5 applications crashing, then it was most likely caused by the same problem, and should be fixed now… :wink:

11

yes it was the QT libs, but it was my using the QT54 repo which caused this and my other issue - at one point using QT 5.4 was the correct thing to do I recall but obviously that’s changed. The other problem (now fixed) was that trying to log into Plasma 5 showed a black screen then I was brought back to my KDE 4 session lock screen (I had switched users)

thanks,

12

PS: For KF5’s platform plugin, this issue has been solved recently:

# rpm -q --changelog libKF5Style5 | head
* Sam Jän 03 2015 hrvoje.senjan@gmail.com
- Update to 5.6.0
  * Fix handling of palette change events (kde#336813)
  * For more details please see:
    https://www.kde.org/announcements/kde-frameworks-5.6.0.php
- Split the integration plugin into separate package
- Make sure that the plugin uses exact libQt5Gui5 version it was
 compiled against, due to usage of private Qt headers

(the plugin has been split-out to a separate package “frameworkintegration-plugin” that requires libQt5Gui5=5.4.0)

You probably had libKF5Style5 from 13.2 installed together with libQt5Gui5-5.4.0 which doesn’t have this strict dependency yet.
An update is pending for KF5 in 13.2 that contains this fix as well though.

So this problem should not be possible any more in the near future.

13

It depends.
If you install the KF5/Plasma5 packages included in 13.2, you have to use Qt5 from 13.2 (5.4 is mostly compatible, but this one problem is a show-stopper), as those packages are of course built against that Qt 5.3.2 included in 13.2.

If you use KDE:Frameworks5 (and maybe also my repo), you need KDE:Qt5 as well for exactly the same reason (those packages are built against Qt 5.4.0 from KDE:Qt5). Also those newer KF5 (and Plasma5) packages might use new features of Qt 5.4 and won’t work with 5.3 therefore.

Again, you need to make sure that you install libKF5Style5 from KDE:Frameworks5 if you install Qt5 from KDE:Qt5.
And soon it will not be possible to install the wrong one any more by mistake.

The other problem (now fixed) was that trying to log into Plasma 5 showed a black screen then I was brought back to my KDE 4 session lock screen (I had switched users)

As I said, that was likely caused by the same problem.
An incompatible platform plugin causes all Qt5 and KF5 (which is based on Qt5 of course) applications to crash on startup.

14

I keep reading that this issue is fixed, but I just run into the same problem with a brand new installation of Leap 42.1 64-bit. The very first time I logged-in to the desktop, launching Yast2 and then trying to access the Software Management feature worked just fine. Subsequent tries to access it again, failed consistently.

The only way I can actually launch these facilities, e.g., Online Update, Software Repositories, or Software Management, is if I first launch the “Terminal - Super User Mode”(red icon under System"), enter the root password as it prompts you automatically, and then launch: yast2 from the command line. It does not work any other way. Mind you that this is NOT an upgrade, it is a brand new installation.

If I just open a Konsole terminal and do an ‘su’ to login as root and then launch yast2 to access the above mentioned facilities, the yast tool will throw a segmentation fault as follows:

Run command: /sbin/yast2 sw_single &
YaST got signal 11 at file /usr/share/YaST2/modules/PackagesUI.rb:312
sender PID: 504
/sbin/yast2: line 440: 31246 Segmentation fault $ybindir/y2base $module “$@” “$SELECTED_GUI” $Y2_GEOMETRY $Y2UI_ARGS

I’ve installed the nvidia-glG03 libraries because the nvidia-glG04 causes more problems with the KD5 Plasma to the extent that I cannot even login, it’s version 340.98.

I found the work-around by coincidence, but obviously it’s not an optimal solution. I’ve tried some of the suggestions here, that apply, but nothing seems to have solved the issue. My friend has basically the same setup, and same type of hardware, and his installation works just fine. The only differences between our set-ups is that he wiped out ‘all partitions’ prior to installing Leap 42.1, and I kept the Windows 8.1 partitions, everything else is very much the same thing. I have no problems, at least no visible/obvious issues, booting up my Leap 42.1 distro, but maybe there’s something to it, I doubt it but you never know.

If any of you has an idea of why this would happen, please drop a note.

Thnx!!

15

But definitely not here.
The problem in this thread was caused by an incompatible mixture of Qt5 packages from different repos.
I.e. no bug, but a very specific user error.
And it has been fixed by bringing the packages in line.

Unlikely that you have the same issue, but please post your repo list:

zypper lr -d

Though if that’s your problem, you should find how to fix it in this thread already.

There was (is?) a general problem with YaST crashing on Multi-Monitor systems, when it is being run on the secondary display.

It may also be a graphics driver issue, so install the package “Mesa-demo-x” and post the output of:

glxinfo | grep render

to show whether your nvidia driver is actually working.

And next time, please do not append a post to a 9 months old thread that was about a very specific, self-inflicted system breakage, but better start your own.