Bugzilla Bug 111885

After upgrading from 0.97 to 0.97-r1 and rebooting, Grub could not boot the
kernel. It said it couldn't find it (the kernel) and to provide an absolute path
or blocklist.

After pressing a button to return to the previous menu, all my Grub entries are
garbled, in strange characters.

When bringing up a Grub console and trying to load the kernel manually, I
noticed that whilst I tried to tell it to boot from
(hd0,6)/boot/vmlinuz-2.6.14-gentoo, it would interpret the (hd0,6) as (hdX,Y)
where X and Y were seemingly random large numbers.

My system in x86.

Reproducible: Always
Steps to Reproduce:
1. Emerge sys-boot/grub-0.97-r1
2. Reboot
3. Select kernel from the menu




I had to boot from the Gentoo Install CD and downgrade to sys-boot/grub-0.97.
This fixed the problem. Let me know I can provide more useful information. I
hope this is severe enough to justify the "critical" rating. Apologies if it's not.

hrm i tested on my amd64 systems and they worked ... the 0.97-r1 version
introduced two new patches:
015_all_grub-0.96-unsigned-addresses.patch
400_all_grub-0.97-reiser4-20050808-gentoo.patch

try editing the 0.97-r1 ebuild and change src_unpack to read like this:
src_unpack() {
    unpack ${A}
    rm patch/015_* patch/400_*
    cd "${S}"

and then see if you can reboot ... if you can, change it to read:
    rm patch/015_*
and if that works too, change it to:
    rm patch/400_*

that way we can narrow down the offending patch

Thanks Mike -- it seems 400_all_grub-0.97-reiser4-20050808-gentoo.patch is the
offender. The 
unsigned addresses patch doesn't cause me any problems.

Let me know if you need me to test anything further.

ok, grub-0.97-r2 now in portage without the reiser4 patch, thanks for testing !

*** Bug 112015 has been marked as a duplicate of this bug. ***

I believe the problem is that the reiser4 patch makes reiser4 the default boot
filesystem. There is a note about this. From the Reiser4
http://www.namesys.com/install_v4.html page.

"The reiser4 support is enabled by default, to disable it the the option of the
configure script --disable-reiser4 can be used."

So for persons NOT using reiser4, the system can't boot.

I believe that implementing the use flag USE="reiser4" in the ebuild will
remove this error. This can guide what econf throws out.

Some additional notes: I patched a clean grub 0.97 with the reiser4 patch. Did
a plain configure, make, make install. copied the /usr/local/lib/grub stuff to
/boot/grub. Did the grub install routine, and the system booted fine minus the
graphics. Some things to check.

1) if the root partition is reiserfs (version 3.6), it MUST be mounted with the
notail option. Otherwise grub won't be able to load the right stage properly.
You cannot just copy over the grub stuff.

2) I notice the reiser4 patch has been modified from the default. Perhaps not
correctly so?

In any event, I believe the problem lies elsewhere other than with the reiser4
patch.

Since the patch is forcibly removed, I cannot test it, but any grub update
means that the contents of /usr/lib/grub be copied into /boot/grub first
otherwise the stage1_5/2 loader won't match and may not work.

So, afaik, reiser4 patch is not the culprit here. This needs some more
analysis.

reiser4 has not been modified from the default beyond the splash glue ... if
there is any difference it is because upstream updated and we have not synced

i'm not adding back in reiser4 as default

That's OK if you don't add it back. It's your ebuild. However fwiw, I added the
reiser4 patch back in to your default ebuild for 0.97-r2, copied over the stuff
from /lib/grub to /boot/grub, boot off a cd, reset grub, and voila, it works
fine. I _think_ the problem is improper user installation, not a function of
the reiser4 patch. I don't even use r4, but the patch does not affect me. Once
again, I advise to be sure and copy over all new stage files to /boot/grub
before saying it doesn't work. If using reiserfs3.6 (like I do), be sure to
mount the boot device with notail.

Perhaps get a little more information from the reporter. Like what fs he uses,
whether he copied over the /lib/grub files, etc.

arggh. Also, be sure to run grub
> root (hd0,#)
> setup (0) or setup (0,#)
> quit

Any version upgrade requires this to rewrite the stage files. Perhaps this was
not done. In any event, you should add a friendly reminder to do that in your
next ebuild, don't you think?

look at the tail end of the grub ebuild, it tries to do just that

(In reply to comment #10)
> look at the tail end of the grub ebuild, it tries to do just that
> 

A ha! IF the user has reiserfs3 mounted without using notail, this would cause
an error in the grub files. Remember, they cannot be copied over and packed.
They must be separated and notail forces that. You need to include a message
for reiser users (probably reiser4 too although I don't use that at the
moment). The user would configure grub and not know why everything blew up. It
would be nice to hear from the original reporter and see if this happened or
what filesystem he was using in the first place. I still say it's not the
reiser4 patch. I continue to boot fine.

works fine in a plain r4 partition too. Need a little trickery wrt stage 2 in
the grub shell, but it works. That's all for me. AFAIK the patch is fine and
should stay for the R4 folks.