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.
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?
+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! :)
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.
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!
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.
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.
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.
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.
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.