Red Hat Bugzilla – Full Text Bug Listing
|Summary:||preupgrade fails if /boot is on raid device|
|Product:||[Fedora] Fedora||Reporter:||Matthias Adler <macedigital>|
|Component:||preupgrade||Assignee:||Richard Hughes <richard>|
|Status:||ASSIGNED ---||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||23||CC:||bugzilla, dwreski, fcbugz, Florian.P.Nierhaus, fredericg_99, igeorgex, kas, patrick.pichon, rhughes, richard, udovdh|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-07 15:14:56 EDT||Type:||---|
|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