When running mgaapplet as a normal user, updates can not be installed. I tracked this down to MageiaUpdate being able to install updates, resp. does not even start up correctly. In mgaapplet, when selecting "Install Updates" from the menu (or just clicking the tray-icon), the tray-icon will shortly disappear, then change to the orange "checking for updates" icon and than again to the red "updates available". Please see below for my analysis of the problem. Version-Release number of selected component (if applicable): - mgaonline-3.15-1.mga5 - rpmdrake-6.20 How reproducible: Always. ====================== Steps to Reproduce ========================= Even if the error showed up to me via mgaapplet, you can reproduce this by running MageiaUpdate directly: $ /usr/bin/MageiaUpdate # command-line args do not matter here No protocol specified Cannot be run in console mode. Analysis ============== It looks like somewhere the access to X11 gets lost. This *may* be related to the user's $HOME being on a NFS-share (with root-squash) , since it works fine on other machines. It took me two hours to track this down from mgaapplet to to /usr/lib/libDrakX/common.pm::check_for_xserver() returning `False`. You may want to apply the attached patch (debug-check_for_xserver.patch) to get debugging output. Call-order is approx. this: mgaapplet::installUpdates /usr/bin/MageiaUpdate --no-media-update --no-confirmation --no-splash /usr/bin/pkexec /usr/libexec/drakrpm-update --no-media-update --no-confirmation --no-splash use mygtk3 /usr/lib/libDrakX/mygtk3.pm /usr/lib/libDrakX/mygtk3.pm::init() /usr/lib/libDrakX/common.pm::check_for_xserver() Reproducible: Steps to Reproduce:
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=2210
Created attachment 7223 [details] Patch adding debug output to /usr/lib/libDrakX/common.pm::check_for_xserver()
Created attachment 7224 [details] test-script for check_for_xserver This is a example-script testing only running check_for_xserver. This fails (debug-check_for_xserver.patch is applied to get debug output): $/usr/bin/pkexec perl /tmp/test-xserver.pl Ignore the following Glib::Object::Introspection & Gtk3 warnings >>> check_for_xserverxtest (running in /tmp/test-xserver.pl) >>> $::xtest not yet set, testing >>> : >>> check_for_xserverxtest returns 0 Cannot be run in console mode.
Attachment 7224 is obsolete: 0 => 1
Created attachment 7225 [details] test-script for check_for_xserver This is an updated version of the test-script. It really only calls check_for_xserver(), while the previous version did initialize mygtk3 (which then calls check_for_xserver()).
Comment on attachment 7225 [details] test-script for check_for_xserver Argl, mixed up the upload
Attachment 7225 is obsolete: 0 => 1
Created attachment 7226 [details] test-script for check_for_xserver This is the correct, updated version of the test-script. It really only calls check_for_xserver(), while the previous version did initialize mygtk3 (which then calls check_for_xserver()).
Assignee: bugsquad => thierry.vignaud
CC: (none) => alphonix
Created attachment 7994 [details] lspcidrake -v output
Priority: Normal => HighHardware: i586 => x86_64Target Milestone: --- => Mageia 5Severity: major => critical
@ Rom It would have been OK to change the platform to "All" if you hit the same bug, but on a different platform than the one who reported it. However, please do not set the platform to x86_64 again in a bug report, when the original reporter set it to i586 ;-)
CC: (none) => marja11Hardware: x86_64 => AllTarget Milestone: Mageia 5 => ---
Summary: mgaapplet resp. MageiaUpdate can't install updates. => mgaapplet doesn't start if homedir is on NFS
Attachment 7994 description: rappor du file system => lspcidrake -v output
Attachment 7226 mime type: application/x-perl => text/plain
And? What's the difference for you between a local user and one whose homedir is on NFS? Can you guess something by running both cases with eg: "strace -e file"?
Created attachment 8009 [details] wrong upload :-(
Attachment 8009 is obsolete: 0 => 1 Attachment 8009 description: home on NFS: output of strace -f -e file,process perl test-xserver.pl 2>&1 => wrong upload :-(
Created attachment 8010 [details] Running from dir in NFS: output of strace -f -e file,process perl test-xserver.pl 2>&1
Attachment 8010 filename: home-on-nfs.txt => running-from-dir-on-nfs.txt Attachment 8010 description: home on NFS: output of strace -f -e file,process perl test-xserver.pl 2>&1 => Running from dir in NFS: output of strace -f -e file,process perl test-xserver.pl 2>&1
Created attachment 8011 [details] wrong file (missed -f)
Attachment 8011 is obsolete: 0 => 1 Attachment 8011 description: Running from /tmp: output of strace -f -e file,process perl test-xserver.pl 2>&1 => wrong file (missed -f)
Created attachment 8012 [details] Running from /tmp: output of strace -f -e file,process perl test-xserver.pl 2>&1
Attachments 8010 and 8011 show now relevant difference. But note: I had to kill (Ctrl-C) the processes since they did not stop by themselves. After I created these two logs, I realised that this should have been "strace ⦠/usr/bin/pkexec perl â¦". But when running this, I get the error message "pkexec must be setuid root" -- which I obviously did not get earlier, see comment 2.
I meant Attachments 8010 and 8012 show now relevant difference.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=12799
I assume this issue is still valid for Cauldron and Mageia 6 Please correct me if I'm wrong. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, because we are waiting for a big Plasma5 update in Mageia 6, that'll fix many of the Mageia 5 => 6 upgrade issues.
Version: 5 => CauldronKeywords: (none) => PATCHWhiteboard: (none) => MGA6TOO
Hi, This is High priority bug for a good reason. Making Mageia even better than ever is best direction. In order to do right thing, this bug should be examined and fixed as soon as possible. Packagers, please make the status to Assigned when you are working on this. Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it. On October 1st 2020, we will drop priority to normal.