Description of problem: gsmartcontrol not start in F18. Version-Release number of selected component (if applicable): gsmartcontrol-0.8.7-1.fc18.x86_64 How reproducible: Always. Steps to Reproduce: 1.Run gsmartcontrol 2.Enter root password Actual results: In console No protocol specified <error> [gtk] cannot open display: :0 And application not start. Expected results: Normal start with gpaphical interface. Additional info:
This is caused by some problem with consolehelper; PAM is failing to authenticate the session. Each attempt logs: Jun 12 19:33:18 localhost /etc/gdm/Xsession[2594]: The password you typed is in\ valid. Jun 12 19:33:18 localhost /etc/gdm/Xsession[2594]: Please try again. Probably something needs to be changed in /etc/pam.d/gsmartcontrol, but I haven't yet figured out what. It would probably be even better to convert from using consolehelper to polkit, but I haven't figured out how to do that either.
Quite possibly the same root cause as bug #974334 for mtr-gtk, as both apps have the same behavior including the log messages, and both use consolehelper with identical PAM configuration files.
FWIW, I have tried a fresh F18 install in a VM (F18 KDE live DVD in this case) and both in KDE and GNOME gsmartcontrol started fine; on a different F18 installation xmtr started as well. So I can't reproduce the problem here. One possible way to start debugging this: 1. Change the root password to something safe to publish 2. Start gsmartcontrol, wait for the password prompt, enter the password without pressing Enter 3. Then attach strace to both consolehelper-gtk and userhelper (strace -ff -s 16384 -o log -p $pid_of_the_process) This needs to happen as root, it is easiest to do this from a virtual console or a ssh-attached session because consolehelper grabs the X11 keyboard 4. Press Enter in the password prompt, reproduce the problem. Then review the generated logs for private data (e.g. contents of /etc/shadow), remove it if any, and attach the logs.
I can try strace, but when this happens, the user is not prompted for a password. After the program is selected from the menu, nothing visibly happens. I have not personally attempted to reproduce this (or the same with xmtr) with F18, but both fail for me on F19 beta installed natively on an x86_64 box.
(In reply to Eric Smith from comment #4) > I can try strace, but when this happens, the user is not prompted for a > password. After the program is selected from the menu, nothing visibly > happens. Comment #0 includes "enter root password". So this may not all be the same problem. > I have not personally attempted to reproduce this (or the same with xmtr) > with F18, but both fail for me on F19 beta installed natively on an x86_64 > box. OK, I'll try to test with F19 as well.
I verified that I can start gsmartcontrol after booting the F19 live desktop. Still can't start it from GUI on my native F19 install.
Eric, is there any output when started from a terminal?
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.