Bug 984415 - fedup fails to mount upgrade media
fedup fails to mount upgrade media
Product: Fedora
Classification: Fedora
Component: fedup (Show other bugs)
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2013-07-15 04:06 EDT by udo
Modified: 2014-12-08 13:59 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-06 14:15:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description udo 2013-07-15 04:06:13 EDT
Description of problem:
fedup fails to mount upgrade media

Version-Release number of selected component (if applicable):

How reproducible:
mount /dev/cdrom /mnt
fedup --device /mnt
(wait for it to ask you to reboot)
edit grub.conf so that the raid array is activated
choose to boot from disk via F12 BIOS menu
choose fedup menu item
boot that one

Actual results:
Fedup kernel, ramdisk etc start but in a dazzling stream of messages I can discern one line flashing by (in red!) saying something about unability to mount upgrade media.
The rubbish of errors after that are no pretty sight.

Copying the DVD contents to someplace on the hardisk does not work as fedup does not recognise this as installation media.

Expected results:
Flawless upgrade

Additional info:
DVD drive is a plain plextor 12x device that reads the DVD fine.
Comment 1 Fedora End Of Life 2013-08-01 09:21:43 EDT
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.
Comment 2 udo 2013-08-04 10:29:47 EDT
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.
Comment 3 udo 2013-08-05 10:27:48 EDT
What can I do to help fix this issue?
Comment 4 udo 2013-10-06 11:07:35 EDT
What can I do to help fix this issue?
Comment 5 Will Woods 2013-10-07 14:17:04 EDT
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)
Comment 6 udo 2013-10-07 22:35:24 EDT
How to do that figuring out on a system that shuts down after the failure?
Comment 7 Will Woods 2013-10-08 14:03:42 EDT
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.
Comment 8 udo 2013-10-15 10:09:48 EDT
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.
Comment 9 udo 2013-10-15 12:10:15 EDT
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.
Comment 10 udo 2013-10-18 14:42:01 EDT
- 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)
Comment 11 Will Woods 2013-12-06 14:15:53 EST
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.
Comment 12 udo 2014-12-08 08:03:09 EST
(426 days old) and still bugzilla bugs me with this.
I do hope that an upgrade to FC 21 will not show this behaviour.
Comment 13 Will Woods 2014-12-08 13:59:48 EST
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.

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