Bug 1462423 - Update on shutdown broken on encrypted devices.
Update on shutdown broken on encrypted devices.
Status: NEW
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
25
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-17 09:12 EDT by Frank Büttner
Modified: 2017-06-18 10:16 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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 Frank Büttner 2017-06-17 09:12:10 EDT
Description of problem:
When shutdown  the system an updates are available, than gnome ask to install it on shutdown. But it automatic only works on none encrypted file systems, because it do it this order:
1. reboot
2. boot to update stage
3. install the updates
4. shutdown.

But on encrypted devices the automatic update fails at part 2, because the system needs an password.

An better solution can be:
1. switch to the update stage without reboot/unmount
2. install the updates
3. shutdown the system.

Version-Release number of selected component (if applicable):
gnome-shell-3.22.3-1.fc25.x86_64


How reproducible:
Every time updates are available on system shutdown. 

Steps to Reproduce:
1. mark "Install update on shutdown"

Actual results:
The automatic process fails, because at the reboot phase it will wait for the password.


Expected results:
That the updates can be installed on shutdown without unlock the encrypted device.

Additional info:
I think at the bug, there are more components involved.
Gnome, systemd, dnf etc.
Comment 1 Florian Müllner 2017-06-18 10:16:15 EDT
gnome-shell only exposes an option of the underlying system, it's not involved at all in the actual update => reassigning to PackageKit.

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