jonesbr@sbcglobal.net wrote:
>
> The /MBR was wiped via fdisk (DOS version) and then Windows was
> reinstalled. I don't have a boot floppy (dumb, I know) and my
> attempts to use grub or grub-install from the RH 9 install DVD
> have been unsuccessful. I either get the same "GRUB" message
> followed by the hung system, or an "ERROR 15: File not Found".
> Keep in mind that when using the DVD in rescue mode, all the
> other drives are mounted under /mnt/sysimage. Thus, the system
> /boot location and the hard-coded paths in grub-install are
> incorrect.
>
>
> The exact grub commands that I tried were (after grub-install
> failed) were:
>
> grub> root (hd1,0)
> grub> setup (hd0)
> grub> quit
>
> So what did I miss, and what do I need to do differently since I
> am working from the RH 9 install CD's/DVD in rescue mode instead
> of a true boot floppy?
>
> Many thanks for any pointers!

Did you chroot into /mnt/sysimage before trying to install grub
to the MBR again?

--
Confucius: He who play in root, eventually kill tree.
Registered with The Linux Counter. http://counter.li.org/
Slackware 9.1.0 Kernel 2.4.24 SMP i686 (GCC) 3.3.2
Uptime: 42 days, 11:17, 1 user, load average: 0.00, 0.00, 0.00

David wrote:
> jonesbr@sbcglobal.net wrote:
>
>>
>> The /MBR was wiped via fdisk (DOS version) and then Windows was
>> reinstalled. I don't have a boot floppy (dumb, I know) and my
>> attempts to use grub or grub-install from the RH 9 install DVD
>> have been unsuccessful. I either get the same "GRUB" message
>> followed by the hung system, or an "ERROR 15: File not Found".
>> Keep in mind that when using the DVD in rescue mode, all the
>> other drives are mounted under /mnt/sysimage. Thus, the system
>> /boot location and the hard-coded paths in grub-install are
>> incorrect.
>>
>>
>> The exact grub commands that I tried were (after grub-install
>> failed) were:
>>
>> grub> root (hd1,0)
>> grub> setup (hd0)
>> grub> quit
>>
>> So what did I miss, and what do I need to do differently since I
>> am working from the RH 9 install CD's/DVD in rescue mode instead
>> of a true boot floppy?
>>
>> Many thanks for any pointers!
>
>
> Did you chroot into /mnt/sysimage before trying to install grub to the
> MBR again?

Yep, did that. Good thought though - thanks!

-Brian

jonesbr@sbcglobal.net wrote:
> David wrote:
>>
>> Did you chroot into /mnt/sysimage before trying to install grub to the
>> MBR again?
>
> Yep, did that. Good thought though - thanks!

Ok I think I see what may be the problem. Boot with the rescue CD
and edit the grub config file the section shown below.

grub> root (hd1,0) <<< This would be /dev/sdb1
I think you need (hd0,1) if root is /dev/sda2
grub> setup (hd0)
grub> quit

--
Confucius: He who play in root, eventually kill tree.
Registered with The Linux Counter. http://counter.li.org/
Slackware 9.1.0 Kernel 2.4.24 SMP i686 (GCC) 3.3.2
Uptime: 42 days, 12:32, 1 user, load average: 0.21, 0.13, 0.12

jonesbr@sbcglobal.net wrote:

>> Did you chroot into /mnt/sysimage before trying to install grub to the
>> MBR again?
>
> Yep, did that. Good thought though - thanks!

Make sure you chroot correctly. After a correct chroot a 'ls /boot' will
give you your original boot file system. For original file systems mounted
under /mnt/sysimage (e. g. /mnt/sysimage/etc) the command is
'cd /mnt/sysimage' followed by 'chroot .'

On a correctly chrooted system grub-install should *not* fail.

Also, make sure the entry in the grub.conf on the mounted file system points
to the correct disk, (hd1,0) in your case.

Joerg

--
OpenPGP: D14F 2782 1276 EBB4 E4E3 0BF1 838D DD4C EB56 1C99

David wrote:
> jonesbr@sbcglobal.net wrote:
>
>> David wrote:
>>
>>> Did you chroot into /mnt/sysimage before trying to install grub to
>>> the MBR again?
>>
>> Yep, did that. Good thought though - thanks!
>
>
> Ok I think I see what may be the problem. Boot with the rescue CD and
> edit the grub config file the section shown below.
>
> grub> root (hd1,0) <<< This would be /dev/sdb1
> I think you need (hd0,1) if root is /dev/sda2

But in my case, the first (and only) IDE drive at /dev/hda
would be (hd0), correct? The first SCSI drive, /dev/sda,
would be (hd1).

Again, my device.map, after some marking up (i.e. all :

# this device map was generated by anaconda
(fd0) /dev/fd0
(hd0) /dev/hda --> Windows 2000 disk
(hd1) /dev/sda --> RH 9 system disk
(hd2) /dev/sdb --> RH 9 user disk 1
(hd3) /dev/sdc --> RH 9 user disk 2


Also remember that I have /dev/sda divided up like so
(per default Redhat 9 install):

/dev/sda1 --> /boot
/dev/sda2 --> /


> grub> setup (hd0)
> grub> quit

Grub is the only bootloader on the machine (no lilo, no
Windows bootloader). Thus, grub's root (hd1,0) command
should put the grub files in /boot, and the setup (hd0)
command should install grub in the MBR, correct?

I thought I had that much figured out...

Thanks for the help!

-Brian

Joerg Sauer wrote:
> jonesbr@sbcglobal.net wrote:
>
>
>>>Did you chroot into /mnt/sysimage before trying to install grub to the
>>>MBR again?
>>
>>Yep, did that. Good thought though - thanks!
>
>
> Make sure you chroot correctly. After a correct chroot a 'ls /boot' will
> give you your original boot file system. For original file systems mounted
> under /mnt/sysimage (e. g. /mnt/sysimage/etc) the command is
> 'cd /mnt/sysimage' followed by 'chroot .'
>
> On a correctly chrooted system grub-install should *not* fail.

I thought so too! I did exit out of chroot session once when
I was typing too fast, but the other times I made sure that I
issued the "chroot /mnt/sysimage" as soon as I got the command
line and worked from there.

I haven't messed with grub-install much (compared to the grub
commandline), so I guess I need to verify how it works. i.e.
"grub-install --root-directory=/boot /dev/hda" would be the
proper command in this case, since the /dev/hda is the first
drive seen by the BIOS, and I have /boot on a separate partition
on the first SCSI drive, correct?


> Also, make sure the entry in the grub.conf on the mounted file system points
> to the correct disk, (hd1,0) in your case.

Another good check... I thought I verified this, but I'll double
check. (I'm not at the machine at the moment.)


> Joerg

Thanks for the suggestions!

-Brian

jonesbr@sbcglobal.net wrote:

> I haven't messed with grub-install much (compared to the grub
> commandline), so I guess I need to verify how it works.

Using the GRUB command line is perfectly OK and the commands you gave seem
correct to me. I just thought that the problem might be related to file
system references (possibly resulting from lack of chroot) since you
mentioned that grub-install had failed.

A useful GRUB command you might try if you haven't already is 'find
' which tells you on which drive and partition a particular file
resides, in GRUB nomenclature.

Anyway, if GRUB is configured correctly and the system still does not boot,
there might be a drive enumeration issue. I have seen reports of cases
where drives were enumerated by the BIOS differently than by the OS after
it had loaded.

Since you have many drives on more than one controller something like that
might be happening. I'm going way out on a limb there, though...

But just to make sure... I think that standard DOS or Windows FDISK will
always show drives in the same order that they are referenced by the BIOS,
so that might be a way to check if any drives are enumerated differently by
the BIOS than after booting from the Red Hat recovery DVD.

Joerg

--
OpenPGP: D14F 2782 1276 EBB4 E4E3 0BF1 838D DD4C EB56 1C99

On Tue, 17 Feb 2004 05:03:01 +0000, jonesbr wrote:

> Hello everyone!
>
> I had a hard drive die on me last week, and during the recovery
> process the MBR got wiped. During system boot, I now get the
> infamous "GRUB" message immediately before the system hangs.
>
>
>
> The /MBR was wiped via fdisk (DOS version) and then Windows was
> reinstalled. I don't have a boot floppy (dumb, I know) and my
> attempts to use grub or grub-install from the RH 9 install DVD
> have been unsuccessful. I either get the same "GRUB" message
> followed by the hung system, or an "ERROR 15: File not Found".
> Keep in mind that when using the DVD in rescue mode, all the
> other drives are mounted under /mnt/sysimage. Thus, the system
> /boot location and the hard-coded paths in grub-install are
> incorrect.
>
>
> The exact grub commands that I tried were (after grub-install
> failed) were:
>
> grub> root (hd1,0)
> grub> setup (hd0)
> grub> quit
>
> So what did I miss, and what do I need to do differently since I
> am working from the RH 9 install CD's/DVD in rescue mode instead
> of a true boot floppy?
>
> Many thanks for any pointers!
>
> -Brian
>
> BTW, does anyone know of a place to download various boot floppies?
I don't think there is any such thing for linux (too many variables).
> I didn't find anything after several google attempts...
>
Good things...
1. Partition table not damaged. DOS's fdisk just changes loader code.
2. Rescue mode on CD available.
3. Grub command shell working.

Okay...
When you run the grub shell,
grub> setup (hd0)

are any errors issued about missing files? You must be able to
find all the necessary files in this environment. Otherwise, they won't
be correctly linked and written as part of the setup. This step must
succeed before boot will work from the hard disk.

You could make a boot floppy in the rescue environment. Then fix your
loader once your system is booted normally from the floppy.

--
Wonderful what we can do nowadays.
http://us.imdb.com/title/tt0085959/quotes

jonesbr@sbcglobal.net wrote:
>
> I thought I had that much figured out...

I hadn't noticed you had a system with mixed IDE and SCSI drives.
I find lilo much easier to deal with than grub.

--
Confucius: He who play in root, eventually kill tree.
Registered with The Linux Counter. http://counter.li.org/
Slackware 9.1.0 Kernel 2.4.24 SMP i686 (GCC) 3.3.3
Uptime: 42 days, 22:02, 2 users, load average: 0.46, 0.24, 0.1

Joerg Sauer wrote in message news:...
> jonesbr@sbcglobal.net wrote:
[snip]
>
> Anyway, if GRUB is configured correctly and the system still does not boot,
> there might be a drive enumeration issue. I have seen reports of cases
> where drives were enumerated by the BIOS differently than by the OS after
> it had loaded.

Especially with some BIOSes re: a mix of scsi and ide drives. Some
BIOSes will let you set this order or at least inform you of the order
they are imposing -- others not.

> Since you have many drives on more than one controller something like that
> might be happening. I'm going way out on a limb there, though...
>
> But just to make sure... I think that standard DOS or Windows FDISK will
> always show drives in the same order that they are referenced by the BIOS,

Win/DOS are not very reliable for this as they will (especially Win)
report drives (ie., partitions) in order they are encountered in
partition tables -- with the "active" partition/drive always listed as
C:

> so that might be a way to check if any drives are enumerated differently by
> the BIOS than after booting from the Red Hat recovery DVD.
>
> Joerg

First thing: nothing has changed with your setup except the replaced
hd and reloading of Win OS. Correct? Drives map now the way they did
before. Correct?

Is grub hanging (ie., failing to load stage2 properly) or is it not
loading the kernel? You do get an active prompt, don't you? Eg.,
grub>

Either way, this means grub (stage1) is installed into the MBR. If
you get GRUB with a blinking "block" then grub stage1 can't find
stage1.5 &/or stage2.

If you do have an active grub prompt you can load the kernel by trial
& errror or use tab completion feature to see what grub thinks of your
system. Also the suggested find command can be useful. You can cat
the grub.conf file from this prompt also. Review the grub info manual
for the details/examples of loading the kernel by hand.

With an active prompt that is not loading the system properly, I
always suspect the grub.conf file is at fault. Here are the similar
lines (from my grub.conf) that I would double-check closely:

# grub.conf generated by anaconda
# kernel /vmlinuz-version ro root=/dev/hda3
#++ note the root= that is passed to kernel - is it correct?
# initrd /initrd-version.img
#boot=/dev/hda
#++ this is the drive we're booting from. Is it correct?

default=0
timeout=10
splashimage=(hd0,1)/grub/splash.xpm.gz
#++ this will tell you what drive/partition grub sees
#++ as the location of /grub -> (hd0,1)

title Red Hat Linux (2.4.20-13.8)
root (hd0,1)
#++ this is grub's root. Is it correct?

kernel /vmlinuz-2.4.20-13.8 ro root=LABEL=/ hdc=ide-scsi
#++ note the root= that is passed to kernel.
#++ This is the real one and must match what's in
#++ /etc/fstab - is it correct?

initrd /initrd-2.4.20-13.8.img
#++ the initrd to load ie., the init process

Since you are getting no output at all (except err# 15 msg) I suspect
a problem with the root(hdx,x) line or the kernel line.

If you have a hanging grub process then grub is not fully loading
stage2 properly which _almost_ always indicates that grub stage1 is
not pointed to the correct drive/partition. Remember, grub has no
knowledge of the disk layout except what it hears from the BIOS
(together with device.map) or from you.

Your OS output, device.map and previous attempts "look" to be OK --
but something ain't right. This is detective work unless you stumble
on the correction.

It could be the BIOS "lying" to grub about disk drive search/boot
order -- but why now and not before? New ide/scsi/BIOS interactions
as a result of new hd?

What _does_ the BIOS have to say about your hard drives?

Does rescue mode navigation of disks show any surprises? Can you
umount /boot and then mount it again from command line as expected?
If so, this could be clue that OS and BIOS and Grub are not correctly
in sync in device.map.

If you can use grub's tab completion feature, what does it reveal
about grub's notion of your disk layout? Eg.,
grub> root (hd[tab-key]
grub spits back a "candidate" list to choose from
grub> root (hd_1,_[tab-key]
grub spits back a "candidate" list to choose from
and so on. This is the easiest way to trial-and-error into a correct
mapping with trial sequences of:
grub> root (hdX,x)
grub> setup (hdX)
grub> quit
and reboot the box -- though grub can reboot also you need to allow
time for disk write out.

If no help or luck with any of this, about the only way we could help
is with output of:
$ df
$ fdisk -l /dev/sda <- that's elle
$ cat /etc/fstab
$ ls -a /boot
$ ls -a /boot/grub
# cat /boot/grub/grub.conf
and maybe try some parted -p /dev/sda to compare with fdisk

We're missing some little something, but what? Grrrr....

hth,
really,
prg
email above disabled

Hello again!

First of all, thanks to everyone that replied! I received
some very detailed responses (prg, especially) to a question
that gets asked with amazing regularity. Much obliged!

Ok, here's the kicker... the solution ended up being a
previously unneeded change in the BIOS settings. The original
hard drive order in the BIOS (paraphrasing wording from memory):

1) Card bus (can't remember exact description, but
this turns out to be the SCSI adapter)
2) IDE drive
3) SCSI drive 1 (SCSI id 0)
4) SCSI drive 2 (SCSI id 1)
5) SCSI drive 3 (SCSI id 6)

Before the power circuit overloaded last week (the reason the
Windows IDE drive had to be re-imaged in the first place),
the system had worked in the above configuration for about
a year under RH8, and about a month under RH9. (Actually,
SCSI drive 3 is about six weeks old, but was added without
incident.)

The solution? Move the IDE drive ahead of the card bus
entry in the BIOS drive order. Once I did this, I could
dual-boot again without any further changes (GRUB or
otherwise).

Yes, the sudden power loss corrupted the Windows disk...
Yes, the MBR was wiped while re-imaging the Windows drive...
Yes, GRUB was apparently re-installed correctly...
No, I have no idea why the original working BIOS drive order
settings and unchanged physical drive order would suddenly
cause problems!

Thanks for the pointer to check out the BIOS settings, guys.
I'm still puzzled, but back in business!

-Brian


jonesbr@sbcglobal.net wrote:
> Hello everyone!
>
> I had a hard drive die on me last week, and during the recovery
> process the MBR got wiped. During system boot, I now get the
> infamous "GRUB" message immediately before the system hangs.
>
> The system is a dual processor Pentium IV Xeon machine dual
> booting between Redhat 9.0 (fully updated via RHN, including
> kernel 2.4.20-28.9smp) and Windows 2000 Professional. The system
> has a mix of IDE and SCSI drives, as shown by the annotated
> /boot/grub/device.map file shown below:
>
> # this device map was generated by anaconda
> (fd0) /dev/fd0
> (hd0) /dev/hda --> Windows 2000 disk
> (hd1) /dev/sda --> RH 9 system disk
> (hd2) /dev/sdb --> RH 9 user disk 1
> (hd3) /dev/sdc --> RH 9 user disk 2
>
>
> The 1st SCSI disk is divided as follows:
> /dev/sda1 --> /boot
> /dev/sda2 --> /
>
>
> The /MBR was wiped via fdisk (DOS version) and then Windows was
> reinstalled. I don't have a boot floppy (dumb, I know) and my
> attempts to use grub or grub-install from the RH 9 install DVD
> have been unsuccessful. I either get the same "GRUB" message
> followed by the hung system, or an "ERROR 15: File not Found".
> Keep in mind that when using the DVD in rescue mode, all the
> other drives are mounted under /mnt/sysimage. Thus, the system
> /boot location and the hard-coded paths in grub-install are
> incorrect.
>
>
> The exact grub commands that I tried were (after grub-install
> failed) were:
>
> grub> root (hd1,0)
> grub> setup (hd0)
> grub> quit
>
> So what did I miss, and what do I need to do differently since I
> am working from the RH 9 install CD's/DVD in rescue mode instead
> of a true boot floppy?
>
> Many thanks for any pointers!
>
> -Brian
>
> BTW, does anyone know of a place to download various boot floppies?
> I didn't find anything after several google attempts...