Hide Forgot
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..."
/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.
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.
Try preupgrade-1.1.0-2, appearing in koji Real Soon Now: http://koji.fedoraproject.org/koji/packageinfo?packageID=6045
*** Bug 505954 has been marked as a duplicate of this bug. ***
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)
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.
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.
*** Bug 507229 has been marked as a duplicate of this bug. ***
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.
*** Bug 509209 has been marked as a duplicate of this bug. ***
*** Bug 510627 has been marked as a duplicate of this bug. ***
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.
*** Bug 510934 has been marked as a duplicate of this bug. ***
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
Oops, Forgot to mention. I get no pop-up window.
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.
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?
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.
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
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.
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.
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.
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.
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
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
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
(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).
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
(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.
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.
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.
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.
I'm seeing the same issue with preupgrade-1.1.9-1.fc14.noarch in F14 (upgrading to F15)
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 :-(
Same issue for me trying to upgrade from F14 to F15
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!
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
This one is closed so is being ignored. Of course the whole issue also seems to be being ignored.
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
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
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)
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.
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
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?
I have to wonder why this is not actually the default configuration for an install when there are two drives?
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 ) .
Why do we need a reboot? Can't we simply init 1 and kill the remaining unnecessary processes? Then manually start a suitable upgrade?
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
*** This bug has been marked as a duplicate of bug 500004 ***