Red Hat Bugzilla – Bug 496532
When doing a fresh install grub is not set up properly on raid
Last modified: 2015-05-18 17:55:29 EDT
Description of problem:
After doing an install where /boot is a software raid device, the system was not able to boot off the first element of the array. The bios when then boot off the second element. I was able to fix this in rescue mode by running grub and doing a setup on both devices in the array.
Version-Release number of selected component (if applicable):
This was with the April 19th boot.iso which uses anaconda 184.108.40.206-1. Though depending how anaconda does things the real problem might be elsewhere (grub-install?).
It happened a couple of times, so it doesn't appear to be just a one time glitch.
Steps to Reproduce:
Is this still a problem for you? I just did a quick test with /boot on MD0 and / on sda3. It was able to boot off the RAID device no problem and got me to a login prompt. If you're still seeing problems, could you attach program.log and storage.log to this bug report? Thanks.
I no longer have machines available for fresh installs at this particular time.
However I have also seen the problems when rebooting machines after updates. But since I don't normally reboot right away I am not sure which updates are causing problems. There have been some grub updates and my first thought is those are causing a problem. This may or may not be related to what I saw when I was trying to get F11 installed on some machines I scrounged.
There is a good chance I'll be trying another install using a live dvd Thursday night created by livecd-creator before then. I can report back on Friday if I see the problem again.
Do those log files end up in someplace obvious (e.g. /var/log or /root)?
Is a live dvd based install going to properly test this? I was using network installs when I saw the problem because I have a local mirror at home. I won't have one this Thursday.
After a successful install, they're copied into /var/log. So you'd be looking for /var/log/storage.log, /var/log/program.log, and /var/log/anaconda.log.
If you can set up /boot on a RAID volume with the livecd installer, then you should be able to test this. Is the problem that only one of the members gets a boot record written to it, so it then depends on which device gets selected for boot?
My guess would be that some setup is only done on one drive.
For the machine(s) I will be playing with on Thursday, they have 3 drives, one of which has windows and two are available for the install. So I can set up raid. The machines are setup to boot from the mbr of the windows drive, but last week when I did an install on one of them, the mbr was change to point to /boot on another drive and that all seemed to work at some point. I don't remember whether or not I had to futz with grub or not.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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:
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
I am just closing out the needinfo. Anaconda has changed a lot since f11, so there isn't any point in reopening this bug again even if the problem were to occur in a current release.
I should be trying a fresh install with software raid of f22 in the near future and will file a new bug if the bios can't boot off of both drives after an install.