Bug 1295213
Summary: | dnf system-upgrade download --releasever=23 reboots but stalls on 'starting system upgrade' | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | reescf |
Component: | dnf-plugin-system-upgrade | Assignee: | Will Woods <wwoods> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | jhenner, wwoods, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-12-20 17:34:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
reescf
2016-01-03 16:47:28 UTC
It seems that the root of the problem probably lies in a lack of disk space. This did not occur to me because when I upgraded the first machine, it told me I had too little space and ensured that I had sufficient space before I ever got to the point of triggering the upgrade by rebooting. In the case of the second machine, not only did it fail to check for sufficient space prior to preparing the machine for upgrade on reboot, the putative upgrade failed silently with no useful error message or information at all. May I suggest that dnf should ideally check for sufficient space prior to preparing the system for upgrade? Failing that, the system-upgrade process itself should fail with a meaningful error in the case that it finds insufficient space to proceed on reboot. Enough space is a pretty basic check and I'm very surprised that the software neither checked for this nor provided any information about the problem. Or perhaps the process is supposed to check this and somehow that check gave a false 'OK' in this case? As I say, it did refuse to proceed due to lack of space on the first machine, so it seems odd that it behaved so badly on the second. I'm not yet clear whether the upgrade will proceed correctly from here, but it has got beyond the point of merely starting the process, at least. (In reply to reescf from comment #1) > May I suggest that dnf should ideally check for sufficient space prior to > preparing the system for upgrade? It does - RPM does a disk space check as part of the test transaction. > Or perhaps the process is supposed to check this and somehow that check gave > a false 'OK' in this case? As I say, it did refuse to proceed due to lack of > space on the first machine, so it seems odd that it behaved so badly on the > second. Correct, you got a false positive. The disk space check is necessarily inaccurate because of RPM scriptlets; RPM can't predict how much data any given %pre or %post scriptlet will write to the disk, or how much temporary space they might use. So while it checks for sufficient disk space (and pads the check a bit to be sure), if you're close to the boundary you can still get false positives. There's not a lot the plugin can do about that problem. It *could* implement its own extra disk check, which pads the required disk space a little more than RPM does. This would lead to people who are near the borderline getting false *negatives* instead of false positives. That's arguably safer, but we'll definitely get bug reports from people who are *sure* they have enough disk space but fail the extra check. So: it would also need a config option to control how much padding the extra diskspace check adds (and/or disable the check entirely). Probably it'd also need a CLI flag to control it, plus documentation. I added https://github.com/rpm-software-management/dnf-plugin-system-upgrade/issues/48 to keep track of that idea. Pull Requests welcome! Would it be possible to at least give some sort of useful error when it fails? Or at least an error, even if not a useless one? It just stalled on 'Starting upgrade'. It never even printed the first installation/upgrade message. So 'got part way through and ran out of space' did not seem an obvious diagnosis. Had it appeared to install some packages and then got stuck, even that would have been a clue. But I got nothing after the 'starting' message. Also, I'm not entirely convinced that it was even close to having enough space. Shouldn't it have shown some visible progress in that case? Why didn't it upgrade/install a bunch of stuff and only then stall? Why stall at the very start of the process? I managed to upgrade using # rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-$(uname -i) # dnf upgrade # dnf clean all # dnf --releasever=23 --setopt=deltarpm=false distro-sync from the https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager?rd=Upgrading_Fedora_using_yum This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |