Grub install broken after kernel update

Guy Fraser guy at incentre.net
Fri Feb 11 18:27:49 UTC 2005


On Wed, 2005-09-02 at 13:00 -0500, Phil Schaffner wrote:
> On Fri, 2005-01-28 at 18:21 +0100, Pierrette Barbaresco wrote:
> > Hello,
> > 
> > We updated smp kernel on a Sun V20Z AMD Opteron Scsi device.
> > After installation we tried grub-install /dev/sda and we got
> > 
> > /sbin/grub-install: line 475: 4041 Segmentation fault 
> > 
> > 
> > 
> > [root at cict-009 ~]# uname -a
> > Linux cict-009.toulouse.grid5000.fr 2.6.10-1.741_FC3smp #1 SMP Thu Jan 13 16:58:29 EST 2005 x86_64 x86_64 x86_64 GNU/Linux
> > [root at cict-009 ~]# grub-install /dev/sda
> > /sbin/grub-install: line 475:  4041 Segmentation fault      $grub_shell --batch $no_floppy --device-map=$device_map  >$log_file <<EOF
> > root $root_drive
> > setup $force_lba --stage2=$grubdir/stage2 --prefix=$grub_prefix $install_drive
> > quit
> > EOF
> > 
> > Installation finished. No error reported.
> > This is the contents of the device map /boot/grub/device.map.
> > Check if this is correct or not. If any of the lines is incorrect,
> > fix it and re-run the script `grub-install'.
> > 
> > # this device map was generated by anaconda
> > (fd0)     /dev/fd0
> > (hd0)     /dev/sda
> > 
> > Any idea.
> 
> Ran into the same problem. Installed a new SATA disk on an x86_64
> system, copied/configured/booted FC3 installation, and attempted to
> reconfigure grub to use the new /boot partition.  Attempting to run grub
> or grub-install to update boot record results in "Segmentation fault".
> The old MBR is not changed.  Not sure what kernel update may have to do
> with it.  Behavior is the same for at least the last 3 kernels tried.
> 
> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147600
> 
> Phil
> 
Yup, Grub sucks.

I just installed a third SATA drive and can now only get into my 
machine with a rescue disk.

I have read and tried a dozen 'fixes', but now the best I can get 
is "Read Error".

Every time a new PATA or SATA drive is changed, grub breaks and 
the only way I have ever been able to get it going again is to 
reinstall, changing the drive order in the advanced section of 
boot setup.

Many variations of these methods have been tried :

###Initial device.map ###
(fd0) /dev/fd0
(hd0) /dev/hde
(hd1) /dev/hdg
(hd2) /dev/hdh
(hd3) /dev/sda
(hd4) /dev/sdb
(hd5) /dev/sdc
###

Change device.map :
###
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc
(hd3) /dev/hde
(hd4) /dev/hdg
(hd5) /dev/hdh
###

Now /boot/grub/grub.conf matches the device list again.

--
# grub-install /dev/sda

Result = Grub all over the screen until crash.

--
# grub-install --recheck /dev/sda

Result = Resets device map to initial map, and machine 
does not even enter grub after reboot.

--
Edit /boot/grub/grub.conf to match device map.

# grub-install /dev/sda

Result = Read Error

--
Once in rescue mode, enter grub:

# root (hd3,0)
# setup (hd3)
# quit

Result = Read Error

--

I tried many different variants of editing device.map 
and grub.conf, using grub-install and grub console 
without success. I have made sure (hd3) was the correct 
by using the auto completion feature of the device 
command to see the partition list of the device.

What is the install wizard doing to make the system 
work in the first place?

I have already backed up my up2date, etc and data 
directories and will probably just reinstall wiping out 
the base system and redo the updates.

Syslinux and LILO may be feature poor, but they were 
easy to use and reliable.

Any chance FC4 will reinstate LILO as an optional boot 
loader?

If I can't figure it out, this will be the third time 
I will have had to reinstall after changing drives in 
FC3.





More information about the fedora-list mailing list