Red Hat Bugzilla – Bug 53677
Embedded e2fs_stage1_5 won't boot on CHS=119150/16/63
Last modified: 2008-05-01 11:38:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010809
Description of problem:
Since I lost the contents of my disks, I decided to go ahead and get the
geometry of the disk changed to the one detected on a clean disk, instead
of the geometry recored in the MBR by the installation of Windows 98 done
by the computer supplier.
The disks used to have CHS=7476/255/63. After wiping out the MBR, they
were detected as CHS=119150/16/63, which lets me not waste half a megabyte
and gives me more flexibility in choosing the partition boundaries.
I had to force the kernel to recognize this geometry for hda, though
(hda=...); it would do the right thing for hdc, hde and hdg. hdb is a
CD-RW. Also, I have to tell the kernel it's ok to use UDMA5 for the two
native IDE controllers of this , so my kernel command-line looks likeAsus
A7V133 motherboard; the two additional on-board Promise IDE controllers are
already detected as supporting UDMA5. My kernel command-line looks like:
ide0=ata66 ide1=ata66 hda=119150,16,63 hdb=ide-scsi
Installation proceeded fine. I created a RAID1 /boot on the first 32 MB of
every disk. The installer correctly installed grub on hda, and I was happy
for a moment.
Then, I decided to restore the ability to boot from all other disks (the
idea is that, if any of the 4 disks fail, the system can keep running, by
using a combination of RAID1 and RAID5 filesystems over the 4 disks).
So, I did just like I had done before. I set up the /boot/grub/device.map
so that hd0 mapped to hda, hd1 to hdc, hd2 to hde and hd3 to hdg. Then, I
proceeded to installing the boot loader on each disk, with `root (hd#,0)'
and `setup (hd0)'.
To my dismay, none of the disks were bootable after this (stupid me! I
should have tested some other disk before overwriting the working hda MBR).
Just after loading the boot sector, GRUB would start printing GRUB GRUB
GRUB GRUB GRUB etc until I rebooted the machine.
After a number of rescue-mode boots, having even considered going back to
lilo, I decided to have a look at the code in Anaconda, that had succeeded
in installing the boot loader with the new geometry. The difference was
that, unlike setup, that ran:
install /grub/stage1 d (hd3) (hd3)1+22 p (hd3,0)/grub/stage2 /grub/grub.conf
Anaconda would run something like:
install /grub/stage1 d (hd3) /grub/e2fs_stage1_5 p /grub/stage2 /grub/grub.conf
After I ran install like Anaconda, I was able to boot with Grub again.
If I were to guess, I'd say the problem has to do with the embedding of
stage1.5 given the smaller number of logical heads. It doesn't make much
sense to me, but it was the only difference between the working
configuration and the failing one.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install the system on an IBM Deskstar 60GXP 61.5GB with geometry
2.Boot the system.
3.Start grub, and run `root (hd0,0)' and `setup (hd0)'.
5.Go find the rescue disk. :-)
Actual Results: Grub prints GRUB GRUB GRUB GRUB GRUB and doesn't boot.
Expected Results: I'd hope it would just boot.
What do you get if from the grub shell you type
drive 0x80: C/H/S = 53614/16/63, The number of sectors = 120103200, /dev/hda
looks reasonable, as far as the 32GB limit on CHS access goes. It shouldn't
affect access to the /boot partition, though. Or should it? Or should I force
LBA mode enabled or disabled?
If you use lilo with lba32 in /etc/lilo.conf, do you have any problems?
Please rephrase the question bearing in mind that the problem showed up in grub,
i.e., without using lilo.
Right, if you install lilo on the system and have the lba32 keyword in
/etc/lilo.conf, are you able to boot? Basically, I'm trying to determine if
it's the LBA32 stuff causing breakage (as I suspect) as GRUB and LILO both do it
Ok, I've set up lilo with lba32, and indeed it failed to boot too. It would
print an infinite sequence of `2 '.
"Great". another broken bios... guess I'll be implementing a --disable-lba32
flag for grub soon
*** This bug has been marked as a duplicate of 55168 ***