Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 127557
Summary: | kickstart install asked to write boot loader on raid boot partition overwrites mbr | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> |
Component: | anaconda | Assignee: | Peter Jones <pjones> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | bill, triage |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | bzcl34nup | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-06 23:59:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 133260, 150221 |
Description
Alexandre Oliva
2004-07-09 17:39:15 UTC
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 |