Bug 62410

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

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.

Another workaround using grub is to totally bypass grub-install and do what it
is trying to do manually.

Run

/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.

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.

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.

Fixed by fixing rescue mode to write out a valid /etc/mtab instead

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.

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.

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.

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.

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.

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.

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
following

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
answer.

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?

I think I will work on a patch to make grub use my grubconf idea after I think
of a better name for it.

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.

Created attachment 51765 [details]
Patch to remove the requirement of df

katz solution tested and verified with 0408.1.  Closing out.