Bug 1297984 - DNF system upgrade on docked laptop with closed lid fails
Summary: DNF system upgrade on docked laptop with closed lid fails
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-12 23:51 UTC by Jan Vlug
Modified: 2016-02-19 12:18 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-19 12:18:29 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1109927 None None None Never
Red Hat Bugzilla 1301371 None None None Never

Internal Links: 1109927 1301371

Description Jan Vlug 2016-01-12 23:51:00 UTC
We encountered problems with upgrading the system with DNF on laptops that were on a docking station with a closed lid. When rebooting to finalize the upgrade, the systems went into hibernate (probably because the lid of the laptop was closed), which resulted in a corrupted upgrade.

We actually encountered this during an upgrade from Fedora 21 to 22, so I'm not sure whether this is still an issue when upgrading from Fedora 22 to 23.

Comment 1 Zbigniew Jędrzejewski-Szmek 2016-01-13 00:33:05 UTC
In principle this should be solved by rpm-plugin-systemd-inhibit. 
Do you have rpm-plugin-systemd-inhibit installed?
What version of dnf was installed?
Do you have logs (journalctl) from the interrupted installation?

Comment 2 Eric Curtin 2016-01-21 00:08:33 UTC
+1 for reporting this bug

I was on fedora 22 and it seemed to get unstable. So I thought it's about time to upgrade to fedora 23. I was on MATE desktop environment prior to this and had set "When laptop lid is closed:" Do nothing in the Power Management Preferences. So when this upgrade started after the reboot, I said I'd grab a coffee while I'm waiting and close the laptop lid. This screwed the upgrade of course.

A user should not have to know whether rpm-plugin-systemd-inhibit is installed or what this does, I use Linux everyday and did not even know about this tool rpm-plugin-systemd-inhibit until now. How would you know? It's not a commonly used tool.

The thing is I shouldn't have to know, a laptop should not go into hibernation during an upgrade regardless if the laptop lid is closed or not. Or if they have rpm-plugin-systemd-inhibit installed or not.

Because this is more or less guaranteed to break an upgrade and hibernate does not work great with Linux on many devices.

Heck I'd make this contribution to turn this "feature" off if you pointed me in the right direction! :)

Comment 3 Zbigniew Jędrzejewski-Szmek 2016-01-21 00:15:05 UTC
Reporting a bug is the first step. Answering a simple question is the next step.

rpm-plugin-systemd-inhibit is (indirectly) required by dnf. So it should be always installed. But I wanted to verify that it is indeed true, and I never got the answer to that question.

Comment 4 Eric Curtin 2016-01-22 01:36:42 UTC
I fired up a quick fedora 22 docker in the interests of speed as I am not running fedora on this machine at the moment.

Did this:

[root@5398c58dff45 /]# find / -name "rpm-*"
/etc/pki/rpm-gpg
/usr/lib64/rpm-plugins
/var/lib/rpm-state

I thought this might be a binary that's why I did the find.

[root@5398c58dff45 /]# dnf -v
cachedir: /var/cache/dnf/x86_64/22
DNF version: 1.0.0

I noticed when I did a yum update it did an update to:

rpm-plugin-systemd-inhibit.x86_64 4.12.0.1-14.fc22

And dnf is on

[root@5398c58dff45 /]# dnf -v
cachedir: /var/cache/dnf
DNF version: 1.1.5

So I assume it was installed on my fedora 22 at the time. But who knows I guess!

After yum update

[root@5398c58dff45 /]# dnf -v
cachedir: /var/cache/dnf
DNF version: 1.1.5

I don't know if this information is very useful for you.

Unfortunately I don't have logs, I wiped my machine and installed another Linux distro on this as it's my main personal pc at home and I wanted it working.

But if you want I'm sure I can try to reproduce and send you the logs. It might take me a while though, I'd have to backup everything just in case first.

Let me know anyway Zbigniew, thanks for responding so fast!

It should be easy enough to reproduce anyway (hopefully) if you follow the steps:

Install fedora 22
Start upgrade to fedora 23
After reboot, during upgrade close laptop lid
Upgrade screwed!

Comment 5 Jan Vlug 2016-01-22 13:54:52 UTC
Sorry Zbigniew for not replying to your question. Unfortunately the log files are not available any more, and due to the update I cannot answer what version of dnf we were using at the time of update.

If you have more questions, please let me know, and I will try to answer more promptly.

Comment 6 Zbigniew Jędrzejewski-Szmek 2016-01-24 15:41:41 UTC
OK, thank you both for the replies.

Unfortunately it seems that it's not possible to simulate laptop close events under Qemu, so testing this will require actual hardware. F22→F23 upgrades are still officially supported, and F22→F24 upgrades will be supported when F24 comes out, so we'll have to resolve this somehow.

Comment 7 Zbigniew Jędrzejewski-Szmek 2016-01-24 15:53:06 UTC
Nevermind. It's easy enough to test... it's enough to simply start dnf upgrade and close the lid. rpm-plugin-systemd-inhibit appears to do nothing.

Comment 8 Florian Festi 2016-02-19 08:50:23 UTC
Yeah, that's what the current implementation does: block shutdown but not hibernate. The argument being that you can actually suspend/hibernate during updates and resume later.

While it might be interesting what actually broke the update (my guess would be a hard reboot instead of waking the laptop up to resume with the update). The interesting question here is where the systemd-inhibit plugin should not actually also prevent suspend and hibernate, too.

Comment 9 Florian Festi 2016-02-19 12:18:29 UTC
Changed to block "idle:sleep:shutdown" upstream. This is going to go into rawhide with the next package build.

There is the question whether this is an issue if the system runs out of power and a hibernate would be preferable to a hard loss of power. For now we just pretend that's systemd's problem.


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