From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7) Gecko/20040614 Firefox/0.9
Description of problem:
Sorry if this is incorrectly filed under grub; it's a boot issue in
general. Not sure if it has anything to do with grub or not.
With Fedora Core2 release. My hardware is:
- Intel D865GBF, P4 2.8, 2GB DDR266
- 3Ware Escalade 7508-12 (w/10 x Maxtor 200GB and one WD 200GB (2TB))
Ive installed FC2 several times on this setup to no avail.
Including redoing partitions to make sure everything gets
re-initialized, etc.. The install works flawlessly (thank you, works
even better than the RH9 installer).
After the cdrom is ejected and system rebooted, I get a blank screen
with a blinking "_" in the upper left corner. It almost seems as if
it's getting hung up reading the MBR.
Ive installed grub both on the MBR and on the first sectors of the
boot partition (sda3) to no avail.
It's not an obvious problem with the 3ware card or the disk config,
as I am able to install FreeBSD both 4.9 and 5.2.1-pre on the array
with no problems whatsoever (except for the 1TB limitation on mount
point size, which apparently is also true with FC2).
Any other places I could look? A separate disk for booting is not
an option; defeats the point of having a RAID array. :)
Version-Release number of selected component (if applicable):
stock core2 rel
Steps to Reproduce:
1. Install FC2.
3. Go "argh." :-)
Actual Results: A blinky "_" appears. And stays. Ive left it for
hours, same thing. Thought maybe something was timing out.
Expected Results: "Welcome to Fedora." etc
Ive done this both with the 3ware being the first device in the boot
order and second, no difference.
Other OSes (FreeBSD 4.9, 5.2.1) installed to the same array work fine.
The array is recognized by the system upon install.
Have earlier releases worked? I know that there are a few hardware
RAID arrays that count on specific bits of the boot block being usable
for their scratch space (and it's just that those bits aren't used for
the windows chainloader, not that they're actually guaranteed to be
If you start the install with 'linux lilo' and then switch to using
lilo instead of grub, does it work?
OK. Executive summary: I figured it out. I did find some quirks tho
you might be interested in passing along to the appropriate person(s).
Oh, and wow, thank you for the fast reply. I dont get replies this
fast even from some vendors I have support contracts with. :-p
Here's how I did it and here's what I determined..
First time I installed, something failed in some sort, but it wasnt
really important to me.. turned out there was a media error.. it was
The problem that caught me has to do with the behavior of the installer,
If any part of the install fails and you "restart" the install (i.e.
do an "upgrade"), regardless of whether or not you change grub
options, the installer does not (re)write the MBR/boot block. Even if
you specifically set a new grub config, etc.
In my case, since my *first* install failed half way, and from what I
gather, the MBR/boot block writing doesn't happen until after a
completely successful install, it just plain never happened. Or, it
wrote it but corrupt.
So, I zeroed out the drive (dd) starting with sector 0, and went about
a new install. That worked.
I figured, force a clearing or the disk, MBR et al. Reboot with
$generic_rescue_cd and "dd if=/dev/zero bs=512 of=/dev/sda
count=1000". (1000 was probably overkill, but it didnt matter to me at
Bullet pointing this:
- First install. Install failed on media error, reboot
- Second install.
-> Installer saw things on the fs, determined (incorrectly) that I
could just "upgrade" to refresh everything, also determined
(incorrectly) that it didn't need to (re)write the boot record info.
- Reboot. Nothing boots up.
- Repartition, in an attempt to force the MBR rewrite. Didnt work.
- Wash, rinse, repeat.
- Bug opened.
- Turn server off, watch bad VH1 80's shows, etc. to clear head.
- Zeroed out drive.
- Burn new media, verify it
- Reinstall FC2 again. Success.
So, errata I've learned:
1. Installer is too assumptive during "upgrade" that prior
installation was completely successful / system boots.
Perhaps some sort of flag should be created at the end of the install
process that indicates success.. I dont write OSes but if I had to do
this on an Ops level I might create perhaps an immutable /etc/.install
with 'success=1' 'installdate=502345251215' etc.. that perhaps the
installer can verify and acct accordingly ("I show a valid OS but I
can't be sure it is complete.. did the last install finish completely
with no errors?"), or maybe better, a reading and parsing of MBR info
(a lint of sorts)? An MBR "verification tool" that's automatically run
Regardless, at your discretion it's okay to close this ticket as the
issue has been mitigated. If you think the errata I found is worth
looking into, feel free to do whatever, but I thought a reply was the
least I could do. I found one other installer issue, which I'll open
a separate ticket for.
Thanks again, seriously..
This is working as designed. Upgrade assumes that your system is sane
and correct before the upgrade begins. Otherwise, it's nearly
impossible to be sure that every thing is "correct".