Bug 848136 - Holding 'alt' on the user menu does not offer a Suspend option
Holding 'alt' on the user menu does not offer a Suspend option
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
18
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-14 14:07 EDT by Adam Williamson
Modified: 2012-09-14 14:42 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-14 14:42:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2012-08-14 14:07:40 EDT
In F18 / GNOME 3.6, apparently, instead of having a Suspend option in the user menu that turns to Power Off when you hold down <alt>, it's supposed to be a Power Off entry that turns to Suspend when you hold down <alt> (say aday and rtcm in #fedora-desktop). Well, it doesn't work: I have a Power Off entry, but nothing happens when I hold <alt>. In F17 it worked as intended - I had a Suspend entry, it turned to Power Off when I held <alt>.

The problem isn't upower not believing the system can suspend, viz:

[adamw@adam live]$ gdbus introspect --system --dest org.freedesktop.UPower --object-path /org/freedesktop/UPower | grep CanSuspend
      readonly b CanSuspend = true;

So the issue must lie elsewhere. Not sure where, though. Suspending does actually work fine, if I run pm-suspend from a shell as root. So the issue definitely seems to lie with GNOME not exposing the capability, not the system being incapable of exercising it.

[adamw@adam live]$ rpm -q gnome-shell gnome-settings-daemon upower
gnome-shell-3.5.4-5.fc18.x86_64
gnome-settings-daemon-3.5.5-4.fc18.x86_64
upower-0.9.17-2.fc18.x86_64
Comment 1 Adam Williamson 2012-08-16 01:51:56 EDT
Still valid with gnome-shell-3.5.5-2.fc18.x86_64 .
Comment 2 Adam Williamson 2012-08-31 14:43:49 EDT
So, more information. This is *something* specific to my system, but I can't figure out what.

Ever since I updated to F18 via yum, I've had trouble with booting and logging in normally. gdm almost always refuses to work for me: it tries to start, but X just hangs, with whatever was in the display buffer from the last boot on the screen.

So I've been booting to runlevel 3 and doing 'startx'. I discovered that if I boot to runlevel 3, run 'startx', wait for 60 seconds, log out, then do 'systemctl start gdm.service', gdm works fine.

I've just realized that this bug and one other I've seen - the lock screen not working right - are actually all parts of this same problem.

When I'm running GNOME from startx, I see this problem, and the lock screen doesn't work (when I drag it upwards there's just a blank grey screen, no unlock dialog).

If I do the 'startx, logout, start gdm' dodge, then I have a Suspend option, and the lock screen works.

So all of this is tied into this weird issue I'm having with gdm, I just can't figure out what the hell that problem is.
Comment 3 Adam Williamson 2012-09-14 14:42:49 EDT
Per comment #2 this is basically invalid, it's a result of using startx (though really that ought to work, but eh). let's close it.

Note You need to log in before you can comment on or make changes to this bug.