Bug 708548

Summary: preupgrade fails if /boot is on raid device
Product: [Fedora] Fedora Reporter: Matthias Adler <macedigital>
Component: preupgradeAssignee: Richard Hughes <richard>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 23CC: bugzilla, dwreski, fcbugz, Florian.P.Nierhaus, fredericg_99, igeorgex, kas, patrick.pichon, rhughes, richard, udovdh
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 15:14:56 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Matthias Adler 2011-05-27 19:07:17 EDT
Description of problem:

preupgrade throws exception if /boot is on a raid device with message like 'preupgrade.error.PUError: /boot is on RAID device md1' instead of just notifying : 
<quote>
Error: /boot is on RAID device md0

The main installer image could not be saved to your hard drive. The installer can download this file once it starts, but this requires a wired network connection during installation.
</quote>

When I did an upgrade from Fedora 13 -> 14 the method described in http://www.wombattechnology.com.au/pages/articles/fedora-preupgrade-raid-workaround.php worked like a charm (Short of it: Loading kickstart file from external source). 

But because preupgrade will quit prematurely now, there is no way to upgrade remotely if /boot is on a raid device. 


Version-Release number of selected component (if applicable):
preupgrade-1.1.9.noarch

How reproducible:

Steps to Reproduce:
1. # preupgrade-cli --vnc=password --dhcp "Fedora 15 (Lovelock)"
2. --- wait for it --- 

  
Actual results:
exception thrown

Expected results:
Error message is shown, kickstart file can be loaded from external source on reboot, upgrade finished successfully

Additional info:
Comment 1 udo 2011-06-10 09:10:06 EDT
See https://bugzilla.redhat.com/show_bug.cgi?id=504826
Blocks upgrade, even now that I am ready for it.
Comment 2 udo 2011-06-10 09:29:28 EDT
This is an old issue.
It is disappointing that new versions of Fedora get released without fixing the important stuff.
And yes, people can vary in opinions about important but I think upgrading is one of the basics that must be working great.

Now:

What can I do to workaround this issue to still use preupgrade?
Comment 3 Dave 2011-06-19 22:57:16 EDT
Worse yet, at least to me, is that they knew full well when they released f15 that it had this problem, since it existed since at least f10, and provided no ability for us to work around it during the initial install, and now no way to deal with it after the install.

At least an acknowledgement that it is being worked on, or it is not being worked on and we're on our own? wtf?
Comment 4 Richard Hughes 2011-06-20 04:35:15 EDT
(In reply to comment #3)
> At least an acknowledgement that it is being worked on, or it is not being
> worked on and we're on our own? wtf?

It's not being worked on. /boot on RAID for upgrade has never really been supported, there's too much that can go wrong. I'll happily take patches if anyone has fixed this, but it's not something I'm going to be working on myself. Apologies.
Comment 5 udo 2011-06-20 09:41:29 EDT
Sigh.
We have working system with all devices reachable and working etc.
So why do we need to boot some redhat-built kernel that doesn't handle raid with it's setup environment?


Why can't I do an `init 1`, start the anaconda upgrader manually and get a working upgraded system?
What is blocking this?
Comment 6 Dave 2011-06-20 09:51:45 EDT
Thanks for the follow-up. I don't have physical access so can't boot from a DVD. I did manage to do a successful upgrade using yum and distro-sync, but had to use IPMI to reboot it, as it had a problem calling shutdown or init to reboot.
Comment 7 Need Real Name 2011-07-19 20:16:58 EDT
Sorry to hear that this is broken permanently - after all it did work for a while and was great. Thought that /boot on RAID 1 is pretty standard, or is there now some other hard disk setup recommended to replace /boot on RAID 1?
Comment 8 Patrick Pichon 2011-08-06 16:27:39 EDT
This is very annoying since the upgrade from F14 to F15 doesn't work with yum distro-update due to the new systemd system. So when we have only remote access to system, it is key to have the preupgrade working and even on a RAID1 system
Comment 9 Christian Jose 2011-11-12 15:04:15 EST
This bug still remains in Fedora 15, attempting update to Fedora 16.

The preupgrade log shows:
"
  File "/usr/lib/python2.7/site-packages/preupgrade/dev.py", line 91, in bootpath_to_anacondapath
    raise PUError, "/boot is on RAID device %s" % bootdev
preupgrade.error.PUError: /boot is on RAID device dm-1
"

But the GUI still states everything is ready for upgrade and presents the "Reboot Now" button. Of course, after a reboot, the relevant entries are missing from grub.conf and the system boots as before.

This is very frustrating, since attempting an upgrade from the x86_64 Install DVD also does not offer an upgrade option. So my upgrade path is a fresh install!
Comment 10 udo 2011-11-13 01:15:14 EST
Can someone confirm the final line of Comment #9? (DVD also does not offer an upgrade option. So my upgrade path is a fresh
install!)

Because this would be quite disastrous w.r.t. the problem presented in this bug.
Comment 11 Frederic Grelot 2011-11-13 14:35:57 EST
#9 may be related to the following bug :
https://bugzilla.redhat.com/show_bug.cgi?id=748119

In my case, I had this problem, and since I didn't manage to make my installation being recognized by anaconda, I was left with one option : yum upgrade... It's not the best, not supported, but fortunately it worked for me.

Still, those 2 bugs together were a real pain for me!

Frédéric.
Comment 12 Christian Jose 2011-11-13 14:52:34 EST
Frederic, Thank you!
I have /var and /usr on separate filesystems - maybe now is the time to move with the wheels of progress and do away with some of the filesystems!
Comment 13 Fedora End Of Life 2012-08-07 15:14:59 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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 to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Jan Kurik 2015-07-15 11:15:40 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23