Bug 984415
| Summary: | fedup fails to mount upgrade media | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | udo <udovdh> |
| Component: | fedup | Assignee: | Will Woods <wwoods> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | CC: | tflink, udovdh, wwoods |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-12-06 19:15:53 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
udo
2013-07-15 08:06:13 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed. If you automagically close bugs like this, then how am I supposed to upgrade from F17 to 19 in the first place? Please explain. Alan Cox gave F18 a bad reveiw so I stuck with F17. By the time that F19 comes out one may expect that the worst bugs have been ironed out. But so far I could not use a complete fedup upgrade path at all. Not on a simple lvm disk, not on lvm on crypto on raid. What can I do to help fix this issue? What can I do to help fix this issue? Figure out why the DVD isn't being mounted - check journalctl or similar. You might also need to boot with 'rd.upgrade.debugshell' and use the shell on tty2 to examine the system (if the shell seems broken, exit the shell and it will reload, which should fix it) How to do that figuring out on a system that shuts down after the failure? Boot messages from the failed boot should still be in the journal/logs. Please attach the syslog/journalctl logs from a failed boot, if possible. The quicker way would be a yum update/upgrade but that runs in circles for hours (!) during the depsolve. So how can we proceed here? Neither method works. W(In reply to Will Woods from comment #7) > Boot messages from the failed boot should still be in the journal/logs. > > Please attach the syslog/journalctl logs from a failed boot, if possible. The fedup environment shuts down after failing to mount and listing all failed packages. There is no prompt, no console I can open, etc. So how can I provide logs? Please help. This situation could have been prevented by offering the classic 'boot from dvd' option that fixes the upgrade without further issue or by admitting that the whole booting for upgrading thing is obsolete as we can go to single user mode and download all new rpms, install them and only at the end reboot into the new install. Either way means less hassle for users. This situation also emphasizes the dependency hell situation of fedora as that upgrade route appears to be unworkable: doing a `yum --skip-broken update` or `yum --skip-broken upgrade` makes yum run for hours (!) while going in circles declaring what needs to be updated/upgraded. (why list all that stuff and not just when it is all found out?) Even on a `yum --skip-broken update a\*` (or any other leter) the yum update suffers from dependency hell and tries to do the whole system at once. And this is just a small system with about 2100 rpms installed. Of course the fedora powers that be will ignore all wise input; if not, please let me know how to help fix these issues and how to upgrade this box. Recommendations: - Please make the fedup reboot environment so that one can collect logs of failed/succeeded upgrades - Please think again about the need of rebooting as it appears very unnecessary to reboot to install software - Please think about offering the upgrade on the DVD if we have to reboot anyway - Please think about not listing a bunch of errors/problems that are based on a previously occurring problem/error (cannot install XYZ, ABC, DEF, etc because the DVD could not be mounted: skip the install issues as they do not add anything) Your suggestions are noted. As for the original bug, there have been a bunch of fixes for mounting media / .iso images in 0.8.0 - see bug 984415 and 1024223, for example. You may want to retry with 0.8.0. But I can't reproduce your problem and I don't have enough information to diagnose or fix anything here. (426 days old) and still bugzilla bugs me with this. I do hope that an upgrade to FC 21 will not show this behaviour. fedup-0.9.0 handles mdraid config files differently, so if that was the problem then it may work for upgrades to F21. But since I can't reproduce your problem, I can't test it for you. |