Description of problem: WARNING: problems were encountered during transaction test: broken dependencies mod_auth_ntlm_winbind-0.0.0-0.16.20070129svn713.fc20.x86_64 requires httpd-2.4.9-2.fc20.x86_64 Continue with the upgrade at your own risk. How reproducible: Every time. Steps to Reproduce: 1. Have mod_auth_ntlm_winbind installed on F20 2. sudo fedup --network rawhide --nogpgcheck --instrepo http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/ Actual results: Upgrade fails. Expected results: Upgrade proceeds.
I've seen it too, with different packages: WARNING: problems were encountered during transaction test: broken dependencies async-http-client-1.7.22-1.fc20.noarch requires netty-3.6.6-2.fc20.noarch xorg-x11-drv-r128-6.9.2-1.fc20.x86_64 requires xorg-x11-server-Xorg-1.14.4-11.fc20.x86_64 Continue with the upgrade at your own risk. fedup doesn't say _how_ to "upgrade at your own risk". The workaround for now is to uninstall the packages with unresolved requirements, using "rpm --nodeps" if needed, then restart fedup. Instead of exiting and wasting minutes of hard CPU work, fedup should ask permission to uninstall packages if their dependencies cannot be satisfied after the upgrade. For unattended usage, there should be options allowing and disallowing uninstallation without asking.
No, you can just reboot and the upgrade will start just fine. If you look *above* those warning messages, it says: Finished. Reboot to start upgrade. The warning messages are just there to inform you that certain packages might not work after the upgrade. The upgrade will proceed either way. Clearly I should move the "Finished..." message to the end...
Yes, please! I didn't notice it. It would have saved me some time.
The next fedup release should have improved warnings/error messages in these case. To be specific, https://github.com/wgwoods/fedup/commit/33e2f0b changes the messages to read: WARNING: problems were encountered during transaction test: broken dependencies [warning messages here] These packages may have problems after the upgrade. Finished. Reboot to start the upgrade, or 'fedup --resetbootloader' to abort.
*** Bug 1176793 has been marked as a duplicate of this bug. ***
I'm not sure that marking 1176793 as a solution was a good idea, since 1176793 and 1098886 may require different solutions. However working on the basis that the solution to 1098886 should now also solve 1176793, please let me explain why the proposed solution is not enough. 1176793 describes a problem where the proposed warning would be clearly inadequate (xorg-x11-drv-r128 fails to be installed. If it's on a system, it's presumably there because the hardware requires an r128 driver, so that upgrading will lead to a system that cannot boot to a desktop, as happened in my case). For these cases, the proposed warning is likely to lull users into a false sense of security. If they do go ahead with the upgrade, they will end up with a system that is likely not to be recoverable. To cover these cases as well, the warning needs to: 1. If possible, distinguish critical cases like xorg-x11-drv-r128 from less critical ones like async (which I guess would require correctly identifying which packages are essential to normal operation) 2. Advise users how to get themselves out of a situation where any unattended reboot will lead to a catastrophic upgrade (i.e. how to reset the boot configuration so that a default reboot will not boot the upgrade)
Sorry Will, I missed that you had added "or 'fedup --resetbootloader' to abort." I think that's enough for point 2, but it would be good to also address point 1: as I understand it, fedup is intended to be safe for most users, so probably a bit more advice on how to decide whether an upgrade is safe to proceed with would be desirable. Maybe something like: These packages may have problems after the upgrade. If you are not sure whether it is OK, please use 'yum info' to check what each package does. If the problem packages affect core system components, you should not upgrade unless you are sure it is safe. Finished. Reboot to start the upgrade, or 'fedup --resetbootloader' to abort.
(In reply to bob mckay from comment #6) You are making good points, but the example is not quite good. A default Fedora install includes many Xorg drivers. The r128 driver may have been one of them. Maybe it was a dependency of a metapackage. Maybe r128 was merged with another driver or obsoleted by one. Even if not, there are still drivers for VESA and fbdev that would provide some desktop experience. If Fedora removes some functionality, we would need a more specific example to decide how to handle it. We may want to warn the user in the beginning before downloading packages and preparing upgrade on reboot.
Hi Pavel; I agree that the warning would be better given before rather than after download. However I don't agree that it's a poor example. It may well result in a system that is fixable. That is not really the point. It's still a case where fedup should be warning users that they probably shouldn't go ahead. Of course more detailed advice would be even more desirable: ideally, for each possible such break, the system would advise users what to do and how to fix the problem. But that's probably a pipe-dream, I doubt there are ever going to be the resources to pre-diagnose every possible problem. In the meantime, before a perfect system is designed, some better warnings are essential. I have no idea what happened to the r128 driver (this relates to a previous RFE of mine, that _when_ packages are obsoleted, 'yum info' should inform about the obsoletion, and about the intended replacement). The result was that when I upgraded the system, I got a system that was only able to give me a black screen (bug 1176791). Fixing this problem requires a level of expertise on xorg that I don't have, and that it's not in general reasonable to expect users to have. If that level of expertise (knowing which xorg drivers can substitute for which other ones on specific hardware) is going to be required, fedup needs to warn users, so that they can decide for themselves what to do. Apart from anything else, if they do decide to do the exploration, they are very likely to prefer to do so on their F20 system (where they actually can google, because they can run a browser in their desktop) rather than their broken F21 system using command line. It is exactly the kind of case where warning is needed. The issue is not whether fedup works and is safe for users with your level of expertise; it's whether it works and is safe for the ordinary users (even those who have only one computer). To summarise: there are two kinds of cases that will result in broken upgrades: 1. Those where Fedora has stopped supporting specific hardware. For those systems, users need to not upgrade the system ever. However this will be the rarer case. 2. Those where the upgrade will break the system in fixable, but perhaps complex, ways - ways that the very break may make hard to repair. An installation with a broken windowing system is going to be hard to fix if it's your only system, and you need to google to better understand xorg drivers. One with a broken networking system is going to be even harder, and similar remarks apply to other core systems. The two cases may require different warnings, but they both need warnings.
Great ideas, guys, but this bug isn't the place for them. High-level pre-upgrade checks (e.g. unsupported hardware) are outside the scope of fedup. In RHEL/CentOS this is handled by a separate tool, the Preupgrade Assistant. See http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool for details on that. If someone wants to port a similar tool to Fedora, I'll be happy to help integrate it with fedup. But this will require new tools, and data about the differences between Fedora releases, and project policy about how we create that data/what data is important, and so on. And we just don't have that. This bug report concerns the "Finished ..." message not being visible after the warnings (See comment #1 and comment #2). Policy discussions and ideas for future development should be taken to the mailing lists.
Hi Will; it sounds like Preupgrade Assistant is exactly what we need - but for the reasons you mention, it also sounds like it would be a nightmare to build and maintain for Fedora, with its much shorter upgrade cycle. So I understand why it hasn't been ported (and I'm not putting my hand up to try - you're very convincing). You're right that this bug is about "Finished ..." message not being visible after the warnings", but please don't beat me about the head with it. I didn't think 1176793 was a duplicate at the time, and based on your comment, neither do you now. If you could un-merge it, we could separate the issues again (sorry, I don't know how to do that) - or would it be better to start a new bug? If a Preupgrade Assistant for Fedora is probably infeasible, the enhancement originally requested in 1176793 isn't going to get up. But the issue remains that the warning message at the end of the fedup process, when packages cannot be upgraded, is too benign. This isn't a policy issue, it is very simply an issue about what fedup should tell users. To users who don't have your level of expertise, the current warning suggests that if they go ahead, they might have a few broken packages - but that's all. It doesn't even hint that they might have a broken system that might be difficult to recover, and it doesn't tell them how to go about figuring out whether a broken system is likely. A more detailed warning would be highly desirable, whether along the lines suggested in comment 7, or some other way.
fedup-0.9.2-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/fedup-0.9.2-1.fc21
fedup-0.9.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedup-0.9.2-1.fc20
fedup-0.9.2-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/fedup-0.9.2-1.fc22
Package fedup-0.9.2-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fedup-0.9.2-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-6467/fedup-0.9.2-1.fc20 then log in and leave karma (feedback).
fedup-0.9.2-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
fedup-0.9.2-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.