RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1855203 - [Lenovo 8.4 FEAT] gnome-setting-damon - hitting the power button makes the machine interactive by default.
Summary: [Lenovo 8.4 FEAT] gnome-setting-damon - hitting the power button makes the m...
Keywords:
Status: CLOSED DUPLICATE of bug 1895394
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: gnome-settings-daemon
Version: 8.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: alpha
: 8.4
Assignee: Carlos Garnacho
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1848158 1916350 1916352
TreeView+ depends on / blocked
 
Reported: 2020-07-09 08:33 UTC by Rick
Modified: 2022-07-14 09:15 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-09 07:26:56 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Rick 2020-07-09 08:33:08 UTC
1. Feature Overview:

A system running RHEL may hang when using either power actions ("Restart server normally" or "power off server normally") in Lenovo XClarity Controller (XCC). 

While the XCC power action function is supposed to have the same effect as a short press of the power button, due to the system default setting in RHEL8, a short press of the power button actually puts the system in a suspended state. However, system suspension (S3, S4) are not supported on some server processors.

2. Feature Details
a. Architectures: 64-bit Intel EM64T/AMD64
    b. Bugzilla dependencies:
    c. Drivers or hardware dependencies, including a specific platform or CPU:
    d. Library or other software dependencies:
    e. Upstream acceptance information, including Linus's kernel version in which the feature appears and the date on which this feature was accepted or is targeted for acceptance into Linus's kernel.
    f. External links:  
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/customizing-gnome-desktop-features_using-the-desktop-environment-in-rhel-8#changing-behavior-when-pressing-the-powerbutton_customizing-gnome-desktop-features

    g. Severity (H,M,L): High
    h. Feature required by date (for example, the date on which hardware requiring this feature is planned for launch): RHEL8.4 alpha version
       
3. Business Justification
    a. Why is this feature needed?
       Power button actually puts the system and Lenovo XClarity Controller (XCC) may cause system hang.  
    b. What hardware or software does this enable?
       
    c. If hardware, is it on-board in a system (eg, LOM) or an add-on card?
    d. Business impact?
       Customers need to change the default setting when they install RHEL on Lenovo systems. 
    e. What market problems / audience does it address?
       Short press of the power button actually puts the system in a suspended state and system suspension (S3, S4) are not supported on some server 
        processors. The systems will hang. 

4. QE Test Plan

5. Primary contact at Red Hat, email, phone (chat)
    a. Monte Knutson
    b. mknutson
    c. office: 919-890-8413

6. Primary contact at Partner, email, phone (chat)
    a. Rick Hsu
    b. rhsu5
    c. +886281707648

Comment 3 Benjamin Berg 2021-01-11 16:05:19 UTC
That seems kind of expected, but I can see how the 60s delay that this causes (or the suspend) may not be desirable.

I don't really see how we can fix this though. Changing the behaviour of the power button on normal workstations will not be acceptable. And I doubt we can easily define a "server" machine type to base this decision on.

And, then we are only left with automatically changing the default value for server installations somehow. Not sure if we even have a mechanism we can use here (e.g. a package that is specific to servers and can drop-in the file for dconf).

Comment 4 Matthias Clasen 2021-05-17 17:45:14 UTC
Benjamin, do we have reliable information (or any information, really) from the kernel on whether suspend is supported?

Comment 5 Benjamin Berg 2021-05-19 09:16:09 UTC
So, my take is pretty much "no", which is the problem here.

We do special case VMs, and my first thought was to check the "chassis" information from DMI in order to make a decision. But ultimately the information in DMI is extremely unreliable and it is not clear whether we would just break other scenarios.

I think technically we want to base such a decision based on the primary use of the machine. If you have a server with a graphical interface, then it shouldn't take over any functionality like power button handling (and systemd should do all this for us). On a workstation however, the graphical desktop is the primary use case and we should take over.

Comment 6 Tomas Popela 2021-06-09 12:39:35 UTC
If I'm not mistaken then this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1895394 as mentioned by Ray in https://bugzilla.redhat.com/show_bug.cgi?id=1869978#c10. Ray is that right?

Comment 8 RHEL Program Management 2022-01-09 07:26:56 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 9 Tomas Popela 2022-07-14 09:15:25 UTC

*** This bug has been marked as a duplicate of bug 1895394 ***


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