Red Hat Bugzilla – Bug 344221
grub boot mbr on sdb1 fails, no /root/dev again
Last modified: 2008-08-06 16:21:40 EDT
Description of problem:
Installed of rawhide-20071019-i686 on sdb
/boot1 /boot ext3 on sdb1
LVM on sdb2 (/root,/home/swap, emtryspace)
On bootup of system nothing would boot from grub.
Checked /boot - looks good
checked /boot/grub - look good
checked /boot/grub/grub.conf - looks good.
Booted int sda1 grub, changed exiting titile lines
hd(o,0) to hd1,0)
changed root vg-lv name
system strated to boot and then it hung on the old
can't find /root/dev
I have booted other Linuxs and other system from the second hd.
I have installed other system from live cd's and only fedora keeps getting these
to bugs. Please make sure the final installed and boots from a separate hard
drive and that the /root/dev is fixed for good.
Version-Release number of selected component (if applicable):
This has been going on since last year.
Steps to Reproduce:
Can you please provide exactly what you changed your grub config to be?
The install created a boot and grub for the sdb1
But firstboot came up in grub sda1 and I tired many chainload formats to get to
the sdb1 grub but nothing worked.
So I edited an older grub line in sda1 as it bootted to use the new install kerenl
kernel /vmlinuz-x.y.z.fc8 ro root=/dev/VG/LV
The first time I tied this I missing chaning the LV so it was not booint cand
hung. I saw what I did and corrected the LV name
That is when it started booting a normal but got the /rrot/dev/ not found
The only thing I can even guess at is that I unchecked the first drive from the
install and thus anaconda thinks it is using a one drive system and installs the
boot mbr on the sdb mbr rather than the first sector of the sdb1 but somehow
fails at booth. (Thats the only think I did on the installer other than click on
advanced boot option and indicate to put the boot sector on the fist sector of sdb1.
OK, I installed the dvd F8 20071024 and got the same grub results.
I may not have ever installed a dvd on a second drive as that is usually the
I used the fisrt part of anaaconda (remove all partitions, only sdb disk checked
for install, seleceted sdb disk to boot from.
Install ran fine and fisrtboot was into sda grub (no sign of sdb)
Tried all forms of chainloader + (no go)
edited a title in grub for sda to point to
edited the VG-LV to default of 00
edit version and initrd version to dvd kernel 31
The new install boot up perfect.
I look a /boot - ok
grub - ok
grub.conf - NOT ok
the for boot is commited out
Below is the title showing
root (hdo,o) <<--- This is the problem, it should be root (hd1,0)
I never thoht of looking there before since it boots with the grub sda edit, but
then trying to figure out how it could boot at all without a boot sector lead me
there, because it can't.
So the root (hdn,0 must be changed to match the sdx (where x=n+1)
It would be good if it worked on install be at least the notes need to be changed.
The leaves only the /root/dev/ not found problem with the live install.
I will try that later and on use the same anaconda screens and see if it is
related to the root (hd0,0) problem.
OK, chainloader +1 just does NOT work even with the correct sdb grub.conf
then press b
I get error 13 - non exicutable format.
There is simply NOT a boot sector on sdb1.
I can confirm this. There is no boot sector being installed on (sdb1) when
directed to do so. It's being located on the MBR of sdb no matter what options
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.
If this bug still exists in rawhide, please change the version back to
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)
Thanks for your help and we apologize for the interruption.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Have you encountered this problem in F9?