Bug 504826

Summary: preupgrade and /boot on raid
Product: [Fedora] Fedora Reporter: Mike McGrath <mmcgrath>
Component: preupgradeAssignee: Seth Vidal <skvidal>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: urgent    
Version: 15CC: alauschke, atorkhov, brovvnout+rh, dan, falchimarco1979, fc-bugzilla, fredericg_99, fuzz, gregor, jk, lars, matt_domsch, norisdata, pat, pcfe, peher80, raytodd, redhat-bugzilla, robin.bowes, sergio.pasra, tadej.j, tristan.santore, udovdh, vedran, wd, wwoods
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.1.3-1.fc11 Doc Type: Bug Fix
Doc Text:
preupgrade-1.1.9-1.fc14.noarch gives the error again
Story Points: ---
Clone Of:
: 608193 (view as bug list) Environment:
Last Closed: 2011-11-11 10:01:07 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 494832    

Description Mike McGrath 2009-06-09 12:40:17 EDT
While doing a preupgrade today I got:

Checking for new repos for mirrors
 * preupgrade-rpmfusion-nonfree: astromirror.uchicago.edu
Fetched treeinfo from http://mirrors.kernel.org/fedora/releases/11/Fedora/x86_64/os//.treeinfo
treeinfo timestamp: Tue Jun  2 17:15:53 2009
Traceback (most recent call last):
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 238, in on_assistant_apply
    self._do_main()
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 257, in _do_main
    self.main_preupgrade()
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 473, in main_preupgrade
    bootdevpath = bootpath_to_anacondapath(stage2_abs,UUID=True)
  File "/usr/lib/python2.5/site-packages/preupgrade/dev.py", line 86, in bootpath_to_anacondapath
    raise PUError, "/boot is on RAID device %s" % bootdev
NameError: global name 'PUError' is not defined



Now the window just kind of stuck at "Downloading installer stage 2..."
Comment 1 Will Woods 2009-06-09 13:47:26 EDT
/boot on RAID is not supported by preupgrade-1.1.x (see bug 500004), but this is supposed to give you a dialog box instead of a traceback.
Comment 2 Patrick C. F. Ernzer 2009-06-15 05:55:12 EDT
Will,
preupgrade-1.1.0-1.fc10.noarch having this bug, can we expect a version that shows a dialog? If yes I can hold off upgrading this box for a week or two, grab a newer preupgrade from updates-testing and then report back.
If not I'll just update this box via normal boot to anaconda.
Comment 3 Will Woods 2009-06-15 11:08:45 EDT
Try preupgrade-1.1.0-2, appearing in koji Real Soon Now:

http://koji.fedoraproject.org/koji/packageinfo?packageID=6045
Comment 4 Will Woods 2009-06-15 14:23:36 EDT
*** Bug 505954 has been marked as a duplicate of this bug. ***
Comment 5 Patrick C. F. Ernzer 2009-06-15 18:57:29 EDT
with preupgrade-1.1.0-2.fc10 I get:
  - in GUI mode I get the dialog as expected. clicked Quit to try text mode too.
  - in text mode I get:
# preupgrade-cli "Fedora 11 (Leonidas)" & echo $?
[...]
Error: /boot is on RAID device md0

The installer can download this file once it starts, but this requires a wired network connection during installation.

If you do not have a wired network connection available, you should quit now.
Traceback (most recent call last):
  File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in <module>
    pu.main(myrelease)
  File "/usr/share/preupgrade/preupgrade-cli.py", line 219, in main
    extra_args += " ks=%s" % self.generate_kickstart(extra_cmds=self.kickstart_cmds)
  File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 578, in generate_kickstart
    return dev.bootpath_to_anacondapath(targetfile,UUID=True)
  File "/usr/lib/python2.5/site-packages/preupgrade/dev.py", line 87, in bootpath_to_anacondapath
    raise PUError, "/boot is on RAID device %s" % bootdev
preupgrade.error.PUError: /boot is on RAID device md0
 
[1]+  Exit 1                  preupgrade-cli "Fedora 11 (Leonidas)"

(pressed enter after message was displayed a few seconds)
Comment 6 Lars E. Pettersson 2009-06-19 12:51:23 EDT
OK, I installed preupgrade-1.1.0-2.fc10 and started it, and got a window saying 

"/boot is on RAID device md0

The installer can download this file once it starts, but this requires a wired network connection during installation.

If you do not have a wired network connection available, you should quit now"

With two buttons, "Continue", and "Quit".

OK, I will have a wired network connection during the installation, so I press "Continue", and nothing happens, it just hangs. Should it not just continue, and let me do an upgrade when pressing "Continue"?

If I cancel it, and start it again, and chose to resume the install, it will show the window mentioned above, and when I press "Continue" this time, the program will exit by itself, showing the traceback mentioned above.
Comment 7 Will Woods 2009-06-19 12:56:31 EDT
Alas. This will need a second look - as will the failure in preupgrade-cli.

In the meantime, you can still upgrade by using a DVD or boot.iso.
Comment 8 Will Woods 2009-06-22 10:23:58 EDT
*** Bug 507229 has been marked as a duplicate of this bug. ***
Comment 9 Ken Yap 2009-06-30 01:46:54 EDT
Unfortunately booting with a F11 DVD doesn't work on this Mac PPC G5 because of this Yaboot bug where it doesn't detect the hard disks.

https://bugzilla.redhat.com/show_bug.cgi?id=504040

So I'm going to have to wait for a fix to preupgrade.
Comment 10 Will Woods 2009-07-01 15:12:32 EDT
*** Bug 509209 has been marked as a duplicate of this bug. ***
Comment 11 Will Woods 2009-07-10 12:12:20 EDT
*** Bug 510627 has been marked as a duplicate of this bug. ***
Comment 12 Will Woods 2009-07-10 12:16:37 EDT
For the record, this is the bug for the *traceback* when /boot is on RAID. You're supposed to get a dialog box that warns you that it will need to fetch install.img by other means, since anaconda can't use install.img on a RAID device.

Bug 500004 is the bug about the fact that preupgrade won't allow you to try to save install.img on a RAID device.
Comment 13 Will Woods 2009-07-13 13:11:01 EDT
*** Bug 510934 has been marked as a duplicate of this bug. ***
Comment 14 Tristan Santore 2009-07-19 22:57:14 EDT
Hi Seth,
Problem still persists. I hope this helps.


Traceback (most recent call last):
  File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in <module>
    pu.main(myrelease)
  File "/usr/share/preupgrade/preupgrade-cli.py", line 219, in main
    extra_args += " ks=%s" % self.generate_kickstart(extra_cmds=self.kickstart_cmds)
  File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 578, in generate_kickstart
    return dev.bootpath_to_anacondapath(targetfile,UUID=True)
  File "/usr/lib/python2.5/site-packages/preupgrade/dev.py", line 87, in bootpath_to_anacondapath
    raise PUError, "/boot is on RAID device %s" % bootdev
preupgrade.error.PUError: /boot is on RAID device md0

rpm -qa|grep preupgrade
preupgrade-1.1.0-2.fc10.noarch

Regards,
Tristan
Comment 15 Tristan Santore 2009-07-19 22:57:54 EDT
Oops, Forgot to mention. I get no pop-up window.
Comment 16 Kevin R. Page 2009-08-19 14:05:31 EDT
Just to confirm, the idea is that the installer will be setup to retrieve install.img from network (or an install DVD / net.iso? [1]) if /boot is found to be on RAID? Automatically configured for this? Or would there need to be manual configuration?

[1] It's definitely desirable to use preupgrade over an install DVD, even if it means burning that DVD anyway to get around this RAID issue. I had to fall back on an upgrade using an install DVD because of this bug and, well, that ended in pain (bug #506685 ). On a remote machine too, unfortunately. Ironically preupgrade would have avoided bug #506685 in the first place, I think. Sigh.
Comment 17 Wolfgang Denk 2009-09-18 17:05:25 EDT
So what is the proposed upgrade path? I have several systems sitting here running Fedora 10 (i386 and x86_64), and all of them have /boot on a RAID (1) partition. I cannot install or update from DVD or from the netinst image, because these crash during storage detection, and I cannot use preupgrade because of this "/boot is on RAID device" issue. I tried preupgrade-1.1.0-2.fc10.noarch, but it shows the same issue.

Is there _any_ way left to install or upgrade Fedora on a system with /boot on a RAID partition?
Comment 18 Ray Todd Stevens 2009-09-18 18:25:21 EDT
It appears that very little testing of RAID configurations are done prior to releases.   I am not sure what you can do.

I was able to do upgrades by using a cd (not dvd) iso and then doing a net install.   On several of my systems I had to do a copy off of all of the data, and then a complete fresh reinstall.   To get that to work and avoid the problem you are mentioning I had to first use a fc9 cdrom iso imaged cdrom to boot into rescue mode and then to modify the partition tables to contain no partitions.   That allowed me to then do a fresh install.

I have filed bug reports on this problem, but they have been closed as "won't fix".   The problem appears to be that older implementations of software RAID partions are not compatible with the current RAID drivers.   RAID 1 and RAID 5 partitions created under fc10 seem to actually work, but if you created them under fc9 or earilier you frequently have problems during the upgrade process, and the only real option is to do a fresh install.

I know that is not much help, but it all that I can offer.
Comment 19 Noris Datum 2009-09-19 00:12:59 EDT
I've managed to upgrade F10 to F11 using yum. Beforehand tried all --somehow more plausible-- methods of upgrade (which failed) than went on with a yum upgrade over a fresh (raid 1) install of F10. All but yum turned out to be fruitful.

So I encourage everyone to use yum for distro upgrade purposes (not on mission critical servers for sure). Upgrade was performed on i386/686 arch.

I happen to carry another heartache; raid configuration via anaconda text installer is omitted for some reason. This is --totally-- outrageous, many administrators NEED to set up RAID via text installer and I (and many of my colleagues) comprehend this as a bug! Fedora stands as a basis for future RHEL distros, where the hell is it goin' for gods sake.

(And please dont come back with "raid setup is possible via graphical setup" argument, thats totally out of context and of very little help to those in need of a text setup // how come spinners come out with different options for viable installation methods anyway?)

** Please use yum upgrade on your own risk, I just happened to try and came out with success **

regards,
noris.

--

current info on upgraded server is as below, partition table and raid arrays were intact after upgrade, disks were tested for individual boot capability successfully as well;

[root@saboteur ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              110G   20G   85G  19% /
/dev/md0              190M   29M  152M  16% /boot
tmpfs                 313M     0  313M   0% /dev/shm

[root@saboteur ~]# fdisk -l

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x21ba21b9

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          25      200781   fd  Linux raid autodetect
/dev/sda2              26         107      658665   82  Linux swap / Solaris
/dev/sda3             108       14593   116358795   fd  Linux raid autodetect

Disk /dev/sdc: 120.0 GB, 120033041920 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xffff0000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1          25      200781   fd  Linux raid autodetect
/dev/sdc2              26         107      658665   82  Linux swap / Solaris
/dev/sdc3             108       14593   116358795   fd  Linux raid autodetect

Disk /dev/md1: 119.1 GB, 119151329280 bytes
2 heads, 4 sectors/track, 29089680 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

Disk /dev/md0: 205 MB, 205520896 bytes
2 heads, 4 sectors/track, 50176 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

[root@saboteur ~]# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sda1[0] sdc1[1]
      200704 blocks [2/2] [UU]
      
md1 : active raid1 sda3[0] sdc3[1]
      116358720 blocks [2/2] [UU]
      
unused devices: <none>

[root@saboteur ~]# mount
/dev/md1 on / type ext4 (rw)
/dev/md0 on /boot type ext3 (rw)
.
.

root@saboteur ~]# uname -a
Linux saboteur 2.6.30.5-43.fc11.i686.PAE #1 SMP Thu Aug 27 21:34:36 EDT 2009 i686 i686 i386 GNU/Linux
Comment 20 alauschke 2009-11-07 12:52:34 EST
Is there anything I can check beforehand to see if this bug
will affect me? Most of what I read above is "necessary conditions" (aka: "you need this ... for it to work"). Are there "sufficient conditions" (aka: "if this ... works, then you won't be affected")?

I have a F10 server version on a dual 64 bit AMD Opteron server, and I can't
wait until I can install F11. F12 is coming out soon, and I still run F10. And
yes, my two drives are in a virtual RAID, and I want to keep it that way. What
check can I perform to determine if 504826 will still affect me? I am NOT a
Linux expert, I'd rate myself as "average", not more.

Thanks.
Comment 21 Ray Todd Stevens 2009-11-07 15:44:48 EST
It sounds like you have the "necessary conditions".   Basically those conditions are the /boot volume on a RAID partition.   This can be because the /boot volume is a seperately defined partition, or if the /boot is off of the / and the / is on RAID.

You can however do a CDROM image network install/upgrade with no problem.
Comment 22 Wolfgang Denk 2009-11-08 13:51:25 EST
It's not correct that installation from CDROM / DVD works, not even netinstall - see my entry from 2009-09-18 17:05:25 EDT above. At least for me the installer is crashing.

The only way I was able to update such configurations is using yum.

Needless to say that it's pretty disappointing when I have to install an older version first just to upgrade then.
Comment 23 Ray Todd Stevens 2009-11-08 13:55:31 EST
I have upgraded probably about 20 different servers with this configuration issue.    I have a video issue with a couple and had to run a text upgrade.   The rest ran smoothly for an upgrade off of the cdrom.
Comment 24 Fedora Update System 2009-11-13 17:11:47 EST
preupgrade-1.1.3-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/preupgrade-1.1.3-1.fc12
Comment 25 Fedora Update System 2009-11-13 17:13:07 EST
preupgrade-1.1.3-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/preupgrade-1.1.3-1.fc10
Comment 26 Fedora Update System 2009-11-13 17:13:10 EST
preupgrade-1.1.3-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/preupgrade-1.1.3-1.fc11
Comment 27 Kevin R. Page 2009-11-15 16:05:43 EST
(In reply to comment #12)
> For the record, this is the bug for the *traceback* when /boot is on RAID.
> You're supposed to get a dialog box that warns you that it will need to fetch
> install.img by other means, since anaconda can't use install.img on a RAID
> device.

Thanks for the fix, which is presumably just for the traceback issue (as above). So now if /boot is on RAID we should get a warning message, but with the option to continue?

Could you confirm that there are mechanisms implemented to "fetch install.img by other means" - network, USB key, ...? (and any limitations etc.)

I couldn't find this in any documentation (and apologies for not just giving it a try, but things went rather badly wrong last time I went down that path).
Comment 28 Fedora Update System 2009-11-16 02:31:49 EST
preupgrade-1.1.3-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update preupgrade'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-11547
Comment 29 Will Woods 2009-11-16 10:44:00 EST
(In reply to comment #27)
> Thanks for the fix, which is presumably just for the traceback issue (as
> above). So now if /boot is on RAID we should get a warning message, but with
> the option to continue?
> 
> Could you confirm that there are mechanisms implemented to "fetch install.img
> by other means" - network, USB key, ...? (and any limitations etc.)

Yes. install.img can be fetched over the internet - using a wired network connection  - when the installer starts, as described in comment #6.
Comment 30 Fedora Update System 2009-11-20 00:11:15 EST
preupgrade-1.1.3-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 31 Fedora Update System 2009-11-20 00:16:27 EST
preupgrade-1.1.3-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 32 Fedora Update System 2009-11-20 00:32:35 EST
preupgrade-1.1.3-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 33 Robin Bowes 2011-05-24 15:00:04 EDT
I'm seeing the same issue with preupgrade-1.1.9-1.fc14.noarch in F14 (upgrading to F15)
Comment 34 Gregor Hlawacek 2011-05-27 03:02:59 EDT
Cannot upgrade F14 to F15 using preupgrade. No warning on the screen but an error message in the console saying that boot is on raid :-(
Comment 35 Patrick 2011-05-27 14:27:01 EDT
Same issue for me trying to upgrade from F14 to F15
Comment 36 Daniel Scott 2011-06-02 09:59:24 EDT
Same issue for me trying to upgrade from F14 to F15
Comment 37 Tristan Santore 2011-06-02 10:05:58 EDT
Everyone who posted here for other than F11, you must open a new bug report against F14 preupgrade please!

Thank you.


Do not post more comments here, they will be ignored!
Comment 38 Daniel Scott 2011-06-02 10:10:27 EDT
Do we need to make it a duplicate of one of these?

https://bugzilla.redhat.com/show_bug.cgi?id=608193
https://bugzilla.redhat.com/show_bug.cgi?id=500004
Comment 39 Ray Todd Stevens 2011-06-02 10:40:44 EDT
This one is closed so is being ignored.

Of course the whole issue also seems to be being ignored.
Comment 40 udo 2011-06-10 09:33:04 EDT
MEMORY                                                   |  883 B     00:00     
/boot/upgrade/vmlinuz checksum OK
/boot/upgrade/initrd.img checksum OK
Traceback (most recent call last):
  File "/usr/share/preupgrade/preupgrade-cli.py", line 329, in <module>
    pu.main(release)
  File "/usr/share/preupgrade/preupgrade-cli.py", line 219, in main
    extra_args += " ks=%s" % self.generate_kickstart(extra_cmds=self.kickstart_cmds)
  File "/usr/lib/python2.7/site-packages/preupgrade/__init__.py", line 601, in generate_kickstart
    return dev.bootpath_to_anacondapath(targetfile, UUID=True)
  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 md0
[root@surfplank2 boot]# rpm -q preupgrade
preupgrade-1.1.9-1.fc14.noarch
Comment 41 udo 2011-06-10 09:34:21 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
preupgrade-1.1.9-1.fc14.noarch gives the error again
Comment 42 udo 2011-06-12 04:38:48 EDT
As a workaround for this no-longer ENTERPRISE issue:

How hard is it to bring a system into single user mode, have the ISO of the DVD mounted somewhere and start the upgrade process from the DVD or whatever set of files we got ourselves?
This way: No more dependency on the raid issue since the system was already up.
Could be wrapped into the existing DVD. (for upgrades only)
Comment 43 udo 2011-09-30 09:05:53 EDT
You have to see that you have to accept the inevitable.
As technology improves, gets cheaper, more features become available to the common user.
Look at e.g. cars. Disc brakes, airbags, ABS, whatever. At first it was something for race or expensive cars, nowadays every car has disc bakes.

Now look at the computer stuff.
Storage gets cheaper and cheaper.
Motherboards have 4, 6 or more SATA connectors.
And you expect us to not use any form of RAID?

Please be a little bit more creative, a bit more proactive.
At least let us know you understand and accept our point of view but that you lack the resources and/or plan it for fedora N + 1.
Comment 44 Sergio Pascual 2011-10-01 18:22:40 EDT
Same problem with preupgrade-1.1.9-1.fc15.noarch, preupgrade from f15 to f16 not working

preupgrade.error.PUError: /boot is on RAID device md127
Comment 45 udo 2011-10-04 09:41:58 EDT
Please explain why even thinking of a solution to this very basic problem is allowed to take up more time than it currently has?

Why not decide about a solution, schedule an implementation, have it implemented, tested, released and be done with it?
Comment 46 Ray Todd Stevens 2011-10-04 10:51:15 EDT
I have to wonder why this is not actually the default configuration for an install when there are two drives?
Comment 47 Marco Falchi 2011-11-03 07:13:07 EDT
I have recompile preupgrade-1.1.9-1.fc15.noarch for fedora 11. 
I have the same problem , preupgrade from f11 to f15 not working:

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 md0


I have commented the line 91,92, the preupgrade procedure go to end but at the next reboot can't mount /boot partition ( /dev/md0 ) .
Comment 48 udo 2011-11-03 11:12:04 EDT
Why do we need a reboot?
Can't we simply init 1 and kill the remaining unnecessary processes?
Then manually start a suitable upgrade?
Comment 49 Wolfgang Denk 2011-11-10 07:09:21 EST
The problem is still present when trying to upgrade from Fedora 15 to Fedora 16.
See detailled report at https://bugzilla.redhat.com/show_bug.cgi?id=608193#c8
Comment 50 Will Woods 2011-11-11 10:01:07 EST

*** This bug has been marked as a duplicate of bug 500004 ***