From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: I had the following line in my kickstart file: bootloader --location=partition --md5pass=wontpastehere:-) Nevertheless, anaconda installed the boot loader in the mbr. This *might* have to do with the fact that I had: raid /boot --useexisting --fstype ext3 --device=md6 but if it couldn't figure out where to install the boot record, it had better ask me, instead of overwriting the mbr and not installing it where I told it to. It left me with a bootable system, but I could no longer boot into the previously-installed OS, that was supposed to have been preserved and remained as the default. Version-Release number of selected component (if applicable): anaconda-10.0.1-2
Do you get "MBR not suitable as boot device; installing to partition" output on tty3 (or in /tmp/anaconda.log) during the install?
Nope, and I'd be surprised if I did, since the problem is actually the converse: I tell it to preserve the MBR and install the boot info in the partition, but it goes ahead and overwrites the MBR (and doesn't set up boot info in the raid device).
My test here was ending up with grub being installed in the right place. Will keep looking.
Can you look at the first 512 bytes of the first disk in the RAID device and see if it has "GRUB" in it? Are you sure that what happened isn't just that the active partition was changed to be your new boot?
It has GRUB in it, but that's because I put it there myself. The way I had things set up here, I had one /boot raid1 device for FC2, and one for FC3test. The FC2 grub.conf has an entry to chain-load the FC3test one, and vice-versa. The FC2 boot device was the one that booted first. To my surprise, after I installed FC3test1, it became the default on all of the boxes that had RAID1 devices for /boot, but remained correct for those that didn't. Since GRUB is installed in the MBR, just pointing to a different partition, I don't think the active partition should make any difference. And, if it does, why did the active partition change, and only when /boot was on raid?
Confirmed with a fresh install of yesterday's rel-eng compose tree. In VT5, before the reboot, I see: Unknown partition table signature Unknown partition table signature and then a GRUB session log that shows it selected the correct root device for the first raid 1 member partition and then installed grub in the MBR: root (hd0,5) install /grub/stage1 d (hd0) ... Could it be that it only happens with pre-existing raid 1 devices? Maybe it's trying to read a partition table from the raid device itself?
Has this ever actually worked (installing to the partition when /boot is RAID1)? I'm rereading the code and I don't think that it ever has...
I don't know. I started using --location=partition quite recently.
Okay. Will be fixed in booty-0.44-1
It does install the boot loader in the first member of a raid 1 device, indeed. But it does so even if I specify --location=mbr. That's wrong.
Still broken in FC4test1. Is this now a dupe of bug 151204, fixed post-FC4test1?
The MBR is rewritten in FC4test2 although anaconda was asked to install the boot loader in the boot partition only. Tested with both raid and regular /boot partitions.
*** This bug has been marked as a duplicate of 151204 ***
Still broken if /boot is a RAID device.
Still no way to get anaconda to install the boot loader on raid partitions, not on MBRs. In fact, the interactive installer doesn't even offer such an option, although kickstart doesn't error out if you request such allegedly impossible feat.
See https://www.redhat.com/archives/fedora-list/2005-August/msg04002.html for how I get GRUB to work on RAID1.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
The installer still thinks it knows better, and claims perfectly reasonable options to be impossible. Should we make this a WONTFIX?
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp