Bug 62410 - grub-install doesn't run from within rescue mode
Summary: grub-install doesn't run from within rescue mode
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: grub   
(Show other bugs)
Version: skipjack-beta1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
Blocks: 61901
TreeView+ depends on / blocked
Reported: 2002-03-31 09:40 UTC by Nathan G. Grennan
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-02 06:43:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
This is a patch to grub-install in the package grub-0.91-3 to fix the bugs mentioned in bug report #62410 (338 bytes, patch)
2002-03-31 09:57 UTC, Nathan G. Grennan
no flags Details | Diff
Patch to remove the requirement of df (286 bytes, patch)
2002-04-02 06:43 UTC, Nathan G. Grennan
no flags Details | Diff

Description Nathan G. Grennan 2002-03-31 09:40:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314

Description of problem:
grub-install doesn't run from within rescue mode for a number of reasons. First,
you can't run it directly after going into rescue mode because of missing files.
You can try creating symlinks to work around this, but you get to a point where
you need to create a symlink in /usr and under rescue mode /usr is read-only. So
naturally it makes sense to then use "chroot /mnt/sysimage". Again it doesn't
work, but for different reasons. grub-install is a bash shell script. It expects
the output of df ${rootdir}/  to be correct, but in rescue mode with "chroot
/mnt/sysimage"  df ${rootdir}/   gives the wrong output. There is even a comment
over the section using df which questions how portable the use of df is. I found
a what seems to be to be a much more elegant solution to determining the root
filesystem information. Pulling it right out of menu.lst/grub.conf, which seems
100% portable.

There is also another problem with grub-install in rescue mode. There is a if
statement which checks if the filename in $1 exists and if not  exits
grub-install. It also outputs an error message. In rescue mode the quotes around
$1 cause the script to think always fail at that if statement because it seems
to take the "$1" literally. The solution to this is to remove the qoutes. This
doesn't break grub-install in a normal environment either.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install RedHat Linux 7.2.92
2. Boot off RedHat Linux 7.2.92 CD1
3. Enter  linux rescue   at the boot prompt
4. Select Skip when it asks if you want to check the cd
5. Select the right language and locale
6. Select Continue to mount your filesystems under /mnt/sysimage
7. Press Enter once you read about chroot /mnt/sysimage
8. At the Busybox prompt run  chroot /mnt/sysimage
9. Run  su - root
10. Run  /sbin/grub-install /dev/?d?  where ?d? is hd[a-z] or sd[a-z]

Actual Results:  Error message:

: Not found or not a block device.

Expected Results:  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
(hd0)     /dev/hde

Additional info:

This is also a problem with RedHat 7.2, but it gives a different error message.
I haven't looked into grub-install for exact details about RedHat 7.2.

I will attach a patch that fixes grub-install under RedHat 7.2.92's rescue mode
shortly to this bug report for review.

Comment 1 Nathan G. Grennan 2002-03-31 09:57:25 UTC
Created attachment 51545 [details]
This is a patch to grub-install in the package grub-0.91-3 to fix the bugs mentioned in bug report  #62410

Comment 2 Nathan G. Grennan 2002-03-31 10:15:59 UTC
A workaround for this bug is to have lilo installed and make a valid
/etc/lilo.conf. Then use lilo in rescue mode to allow you to boot normally. Once
booted normally you can restore grub.

Comment 3 Nathan G. Grennan 2002-03-31 10:43:27 UTC
Another workaround using grub is to totally bypass grub-install and do what it
is trying to do manually.


/sbin/grub --batch --device-map=/boot/grub/device.map

That should drop you at the grub prompt.

Next declare the filesystem that contains /boot. This could either be / or /boot
itself. Grub starts counting with 0 instead of 1. So hd0 stands for your first
hard drive, no matter if it is hd[a-z], as long as it is first. hd1 is the
second, and so on.  hd0,0  is the first partition of the first drive, hd1,5 is
the fifth partition of the second drive , and so on.  My root filesystem which
contains /boot instead of /boot being it's own partition, hde5

root (hd0,4)

Finally you run the setup command which writes grub to the boot sector of your
first hard drive.

setup --stage2=/boot/grub/stage2 --prefix=/boot/grub (hd0)

If that was successful, you should have a working grub on reboot.

Comment 4 Nathan G. Grennan 2002-03-31 11:01:12 UTC
Yet another workaround is to use a boot disk created during installation or
using mkbootdisk from within rescue mode or on another machine. If on another
machine you will need to use rdev to set the root filesystem the floppy will try
to mount on boot.

I couldn't use this method since my machine doesn't have a floppy drive, by choice.

Comment 5 Jeremy Katz 2002-04-01 04:23:52 UTC
Hrmm... I thought I had beaten rescue mode into creating a valid /etc/mtab so
that you can just run grub-install as-is.  I'll have to double check this
tomorrow when I'm at the office and have test machines to look at it with.

Comment 6 Jeremy Katz 2002-04-01 22:38:22 UTC
Fixed by fixing rescue mode to write out a valid /etc/mtab instead

Comment 7 Nathan G. Grennan 2002-04-01 23:49:28 UTC
I hope you will reconsider using my patch. I seems like a better solution than
mtab. Did you also fix the quotes problem? I don't see how mtab would help that.
But if you don't use my patch, it's all good. I have already submitted it to the
grub bug mailing list.

Comment 8 Jeremy Katz 2002-04-02 00:06:03 UTC
The quotes are perfectly fine to be there they just escape the device name for
any special characters it may contain (it shouldn't but being safe never hurts
with shell scripting).

As to your solution, it depends on the fact that you only ever have one root
filesystem being mounted by the grub.conf in question.  Although true for many
cases, there are enough people who have asked me questions about booting
multiple installations directly from grub.  Making the mtab show the correct
view keeps both camps happy.

The better solution is to break grub-install's dependence on using df to
determine partitions, but that's quite a bit larger task.

Comment 9 Nathan G. Grennan 2002-04-02 04:24:58 UTC
I suggest you test with quotes in rescue mode. It just flat didn't work with
quotes in rescue mode, but does in normal mode.

I thought about what you mention when I created the patch. I don't see a problem
with multiple installations of Linux. I haven't tried it myself, but I would
think since each entry declares it's own root it should be just fine. You just
need a valid root statement so it knows where to read the grub.conf. So from
either Linux distribution they install grub to in the boot sector, they should
have a correct grub.conf.

Comment 10 Nathan G. Grennan 2002-04-02 04:41:25 UTC
Ahhh, just thought about it some more. The root (hd?,?) statement in each entry
is to declare where it will find grub.conf. Where the problem would occur would
be if they had two different grub.conf files in two different /boot directories.
I don't see how declaring different root (hd?,?) in different kernel entries
would work. You are just defining kernel entries. Is it going to load the both
grub.conf files and combine the two, so you can write the kernel entries for
each seperately. This would make some sense, but why do I think grub doesn't
handle it like this. Otherwise is it going to load the first one it finds and
use that, or is it going to load both and use the last one it finds? It also
seems somewhat impractial to use two boot directories in that case. You could
just make it isn't own partition and mount the same /boot for both. I do see
some potential for conflict if both try to write to a genetic name like
/boot/vmlinuz or /boot/vmlinuz-2.4.18, unlike redhat and mandrake which would be
something like /boot/vmlinuz-2.4.18-0.8 and /boot/vmlinuz-2.4.18-2mdk
respectively. You would probably get the most conflict over /boot/System.map. So
maybe it is practial to have seperate /boot directories, but only if grub has
support for reading more than one grub.conf and combining the contents.

Comment 11 Nathan G. Grennan 2002-04-02 04:55:34 UTC
Hmmmm, if grub does have support for reading more than one grub.conf  It still
requires only one during the boot sector install. So it would write one to the
boot sector from which ever linux partition it was installed. Then at boot it
would read it from that partition, and then read both. But to even know about
the other linux partition it would still require a dummy entry in the the
grub.conf on the linux partition you are installing it from, or it wouldn't know
about the other grub.conf in the first place. You might be able to get away with
two /boot directories, but having two grub.conf files seems like it just
wouldn't work. You need entries in grub.conf for both, so only have one. Unless
they really have gone so far as dummy entries to read two or more.

Comment 12 Nathan G. Grennan 2002-04-02 04:59:58 UTC
To really do multiple copies of linux right you would need to allow for multiple
partitions to be written to the boot sector to be checked for grub.conf files to
combine. It is very obvious with the current df setup, this isn't true.

Comment 13 Jeremy Katz 2002-04-02 05:05:43 UTC
I did try it this afternoon and grub-install works fine with my changes to have
a valid mtab.

And although multiple grub configs is impractical (doable with a bit of work and
use of some of the alternate config file stuff, just not common), having kernels
scattered across multiple partitions is perfectly reasonable.  Consider the

hda1  /boot of linux install 1, has main grub.conf, kernels for main install
hda2  /  of linux install 1
hda3  swap  for all installs
hda4  / of linux install 2 (has /boot on it, thus with kernels as well)

So, you have a grub.conf with something like the following

title Install 1
  root (hd0,0)
  kernel /vmlinuz root=/dev/hda2 ro
title Install 2
  root (hd0,3)
  kernel /boot/vmlinuz root=/dev/hda4 ro

Now, this is obviously ordered in the order that will work right with your fix.
 But, if instead, I have Install 2 first (which is perfectly valid), your patch
will try to install using (hd0,3) as the root device which is not the correct

Comment 14 Nathan G. Grennan 2002-04-02 05:12:30 UTC
Hmm, thinking this through on bugzilla, heheh.

Actually, now I think about it more, the root statements in grub.conf are not to
for knowing where to read grub.conf, but to know where to read the kernel images
from, so they are needed. My way could select the wrong one if you had two
installations of linux each had their own /boot and grub.conf was on the second.
So the correct answer in that cause would be to define the correct root
statement either as a comment(easy way out) or rewrite grub with a new global
variable in grub.conf called something liked grubconf (hd?,0). To use the
comment way you would just need to change anaconda to write it in like it
already does #boot=/dev/?d?

Comment 15 Nathan G. Grennan 2002-04-02 05:15:12 UTC
I think I will work on a patch to make grub use my grubconf idea after I think
of a better name for it.

Comment 16 Nathan G. Grennan 2002-04-02 06:41:31 UTC
My programming skills aren't up to the easy task of doing my grubconf idea, and
overall this seems the better of the two ideas. Especially since either way a
option has to be written to menu.lst and this requires no C code changes.  So I
used my comment idea. Here is a simple patch to add a commented out option
called bootpar. Add this to menu.lst:

#bootpar (hd?,?)

where the ?s are the right numbers for the drive and partition that contain the
grub.conf. It uses to turn bootpar into a root command for grub during
grub-install. Sed was the natural choice and is already used in other functions
in grub-install, so it doesn't add a new dependecy.

I am going to also submit this to the grub bug mailing list.

Comment 17 Nathan G. Grennan 2002-04-02 06:43:36 UTC
Created attachment 51765 [details]
Patch to remove the requirement of df

Comment 18 Jay Turner 2002-04-10 20:23:35 UTC
katz solution tested and verified with 0408.1.  Closing out.

Note You need to log in before you can comment on or make changes to this bug.