Red Hat Bugzilla – Bug 129113
fail to boot after install
Last modified: 2007-11-30 17:10:46 EST
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: Hi, 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). However.. 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 How reproducible: Always Steps to Reproduce: 1. Install FC2. 2. Reboot. 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 Additional info: 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 usable) 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 subtle tho. 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 that point). 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 during install. 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.. jamie rishaw
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".