Grub2 svn2059

Grub2 svn2059

[BandiPat]

Hi guys,
Help a Grub2 novice out please.  I try to keep up with most of the 
changes you guys make, but I've either missed something or there is a 
problem with the latest svn release, listed in the subject.

Upon building the package for Zenwalk, installing, then running 
grub-install, I rebooted the machine to test.  I got the "Welcome to 
Grub2" then an error!
error:  the symbol 'grub_command_list not found
Entering Rescue mode...

What happened?  Did I fail to build it correctly?  Is this an actual 
error or failing with Grub2 svn2059?  Do I need to change something in 
the grub.cfg?  I await your instructions.

TIA
Pat

-- 
        ---Zenwalk v6.0--Linux 2.6.28---
         Registered Linux User #225206
"Ever tried Zen computing?"  http://www.zenwalk.org

Re: Grub2 svn2059

[Pavel Roskin]

On Thu, 2009-04-02 at 17:00 -0400, BandiPat wrote:
> Hi guys,
> Help a Grub2 novice out please.  I try to keep up with most of the 
> changes you guys make, but I've either missed something or there is a 
> problem with the latest svn release, listed in the subject.

Why are you writing that?  Did any previous revision work for you?

> Upon building the package for Zenwalk, installing, then running 
> grub-install, I rebooted the machine to test.  I got the "Welcome to 
> Grub2" then an error!
> error:  the symbol 'grub_command_list not found
> Entering Rescue mode...

I cannot reproduce that problem with revision 2059.  Please give details
how exactly you built and installed GRUB.

> What happened?

GRUB cannot find some module, probably "minicmd".  Please post the
output of "ls" and "set".  Perhaps "prefix" points to an undetected
device.

>   Did I fail to build it correctly?

I don't know.  You message doesn't indicate any build failures.

>   Is this an actual 
> error or failing with Grub2 svn2059?

I don't understand your question.

>   Do I need to change something in 
> the grub.cfg?  I await your instructions.

It looks like the failure happens before grub.cfg is loaded, so the
contents of grub.cfg is irrelevant at that stage.

-- 
Regards,
Pavel Roskin

Re: Grub2 svn2059

[BandiPat]

Pavel Roskin wrote:
> On Thu, 2009-04-02 at 17:00 -0400, BandiPat wrote:
>> Hi guys,
>> Help a Grub2 novice out please.  I try to keep up with most of the 
>> changes you guys make, but I've either missed something or there is a 
>> problem with the latest svn release, listed in the subject.
> 
> Why are you writing that?  Did any previous revision work for you?
-------
Sure, presently using svn2031 and have had no problems like this with
any other previous build.

> 
>> Upon building the package for Zenwalk, installing, then running 
>> grub-install, I rebooted the machine to test.  I got the "Welcome to 
>> Grub2" then an error!
>> error:  the symbol 'grub_command_list not found
>> Entering Rescue mode...
> 
> I cannot reproduce that problem with revision 2059.  Please give details
> how exactly you built and installed GRUB.
> -----------
I can include my build script, if that will help you determine the
problem.  I can assure you though the only changes I made in the script
from 2031 to 2059 was the version number though.  Installation was
standard "upgradepkg", then I ran grub-install (device).  Could it be
that something didn't copy over?  I'm using ext3 filesystem, where I was
using xfs, but again 2031 works fine.

>> What happened?
> 
> GRUB cannot find some module, probably "minicmd".  Please post the
> output of "ls" and "set".  Perhaps "prefix" points to an undetected
> device.
> --------
I didn't write that down when testing 2059 and cannot remember the
output of either, sorry.

>>   Did I fail to build it correctly?
> 
> I don't know.  You message doesn't indicate any build failures.
> ========
I ask this in case there was something else I needed to include in the
./configure I may have left out.  One thing I'll mention, but I don't
believe it plays a part, is that we just started using the latest gcc 4.3.3?

> It looks like the failure happens before grub.cfg is loaded, so the
> contents of grub.cfg is irrelevant at that stage.
> 
--------
Ok, so either something failed to compile or I built it incorrectly.
Included find the build text, which may be of help.  I did not see any
errors.  The mail list wouldn't take the large text file, so I'll post 
it on my download site for you to grab with the build script.
http://zenwalk.pinguix.com/user-accounts/BandiPat/files,etc/build-grub2.sh
http://zenwalk.pinguix.com/user-accounts/BandiPat/files,etc/grub2-svn2059-build.txt

thanks again,
Pat

Re: Grub2 svn2059

[BandiPat]

Pavel Roskin wrote:

>> What happened?
> 
> GRUB cannot find some module, probably "minicmd".  Please post the
> output of "ls" and "set".  Perhaps "prefix" points to an undetected
> device.
=======
Just recompiled Grub2-svn2059 with some changes, I thought might have 
been causing my particular problem, but it still will not work.  Here 
are the results of the above question.

ls
(hd0) (hd0,1) (hd0,2) (hd0,3) (hd0,4) (fd0)

set
root=hd0,2

lsmod
pc   1
ext2  1        fshelp
fshelp 2
biosdisk  1

Hope that helps.  Need any further info, hardware, etc. please let me know.

Pat

Re: Grub2 svn2059

[step21]

Hey, just a wild guess, but I think boot.mod got dropped and the boot
command is now included in minicmd.mod
So maybe your build script needs to be adjusted for that, to copy that
one to the right place? Not familiar with grub2 booting on i386/bios
though anymore, so just a guess.

On Fri, Apr 3, 2009 at 6:50 AM, BandiPat <magicpage91@earthlink.net> wrote:
> Pavel Roskin wrote:
>
>>> What happened?
>>
>> GRUB cannot find some module, probably "minicmd".  Please post the
>> output of "ls" and "set".  Perhaps "prefix" points to an undetected
>> device.
>
> =======
> Just recompiled Grub2-svn2059 with some changes, I thought might have been
> causing my particular problem, but it still will not work.  Here are the
> results of the above question.
>
> ls
> (hd0) (hd0,1) (hd0,2) (hd0,3) (hd0,4) (fd0)
>
> set
> root=hd0,2
>
> lsmod
> pc   1
> ext2  1        fshelp
> fshelp 2
> biosdisk  1
>
> Hope that helps.  Need any further info, hardware, etc. please let me know.
>
> Pat
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Grub2 svn2059

[BandiPat]

step21 wrote:
> Hey, just a wild guess, but I think boot.mod got dropped and the boot
> command is now included in minicmd.mod
> So maybe your build script needs to be adjusted for that, to copy that
> one to the right place? Not familiar with grub2 booting on i386/bios
> though anymore, so just a guess.
------------
This could be a very good guess on your part!  Looking at the 2031 
build, I see the boot.mod, but do not see that in the 2059 build.  So 
how should this be handled in the build?  Add a symlink to minicmd.mod 
with a boot.mod or something else.  Shouldn't the new Grub2 know to look 
at minicmd.mod instead of boot.mod?

I'll try with the symlink to test your theory, but this seems like a bug 
to me, if that is the case?

...still testing
Pat

Re: Grub2 svn2059

[step21]

yes, it probably should. i know that when creating an efi image for an
efi based system with grub-mkimage you specify the modules, so it gets
specified there, on a bios system I'm not sure. I don't think a
symlink is the right solution.Did you run autogen.sh after updating?
What might also work is to re-check out grub to a seperate directory,
and try if that works.

On Fri, Apr 3, 2009 at 2:19 PM, BandiPat <magicpage91@earthlink.net> wrote:
> step21 wrote:
>>
>> Hey, just a wild guess, but I think boot.mod got dropped and the boot
>> command is now included in minicmd.mod
>> So maybe your build script needs to be adjusted for that, to copy that
>> one to the right place? Not familiar with grub2 booting on i386/bios
>> though anymore, so just a guess.
>
> ------------
> This could be a very good guess on your part!  Looking at the 2031 build, I
> see the boot.mod, but do not see that in the 2059 build.  So how should this
> be handled in the build?  Add a symlink to minicmd.mod with a boot.mod or
> something else.  Shouldn't the new Grub2 know to look at minicmd.mod instead
> of boot.mod?
>
> I'll try with the symlink to test your theory, but this seems like a bug to
> me, if that is the case?
>
> ...still testing
> Pat
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Grub2 svn2059

[BandiPat]

step21 wrote:
> yes, it probably should. i know that when creating an efi image for an
> efi based system with grub-mkimage you specify the modules, so it gets
> specified there, on a bios system I'm not sure. I don't think a
> symlink is the right solution.Did you run autogen.sh after updating?
> What might also work is to re-check out grub to a seperate directory,
> and try if that works.
-----------

Shouldn't the autogen.sh be run during the build?  How do you mean 
re-check out grub to a separate directory?  Just drop it in another 
unrelated directory and use the commands to run it testing the setup. 
Sorry don't remember exactly the commands right now, but I've got that 
somewhere in notes.  :-)

I guess when it goes into rescue mode, I could "insmod minicmd.mod" to 
test as well?

Thanks for your patience & help.

Pat

Re: Grub2 svn2059

[Yoshinori K. Okuji]

On Friday 03 April 2009 14:17:04 step21 wrote:
> Hey, just a wild guess, but I think boot.mod got dropped and the boot
> command is now included in minicmd.mod

Yes, it seems so. And, it is a mistake that boot and some other commands are 
not built into the kernel. We must reduce modules, and let them back to the 
kernel.

Regards,
Okuji

Re: Grub2 svn2059

[BandiPat]

Yoshinori K. Okuji wrote:
> On Friday 03 April 2009 14:17:04 step21 wrote:
>> Hey, just a wild guess, but I think boot.mod got dropped and the boot
>> command is now included in minicmd.mod
> 
> Yes, it seems so. And, it is a mistake that boot and some other commands are 
> not built into the kernel. We must reduce modules, and let them back to the 
> kernel.
> 
> Regards,
> Okuji
-----------
In the meantime, how do we get the new svn to work then?  Is there some 
trick or something in the compile we need to do?  Presently I'm using 
svn2031 successfully.

Thanks
Pat

Re: Grub2 svn2059

[Yoshinori K. Okuji]

On Saturday 04 April 2009 04:02:18 BandiPat wrote:
> Yoshinori K. Okuji wrote:
> > On Friday 03 April 2009 14:17:04 step21 wrote:
> >> Hey, just a wild guess, but I think boot.mod got dropped and the boot
> >> command is now included in minicmd.mod
> >
> > Yes, it seems so. And, it is a mistake that boot and some other commands
> > are not built into the kernel. We must reduce modules, and let them back
> > to the kernel.
> >
> > Regards,
> > Okuji
>
> -----------
> In the meantime, how do we get the new svn to work then?  Is there some
> trick or something in the compile we need to do?  Presently I'm using
> svn2031 successfully.

I guess you just have some outdated files. As "make" depends on timestamps, 
checking out from any kind of version control system can confuse "make". 
Try "make clean all".

Regards,
Okuji

Re: Grub2 svn2059

[BandiPat]

Yoshinori K. Okuji wrote:
> On Saturday 04 April 2009 04:02:18 BandiPat wrote:
>> Yoshinori K. Okuji wrote:
>>> On Friday 03 April 2009 14:17:04 step21 wrote:
>>>> Hey, just a wild guess, but I think boot.mod got dropped and the boot
>>>> command is now included in minicmd.mod
>>> Yes, it seems so. And, it is a mistake that boot and some other commands
>>> are not built into the kernel. We must reduce modules, and let them back
>>> to the kernel.
>>>
>>> Regards,
>>> Okuji
>> -----------
>> In the meantime, how do we get the new svn to work then?  Is there some
>> trick or something in the compile we need to do?  Presently I'm using
>> svn2031 successfully.
> 
> I guess you just have some outdated files. As "make" depends on timestamps, 
> checking out from any kind of version control system can confuse "make". 
> Try "make clean all".
> 
> Regards,
> Okuji
-------------
No, no outdated files.  I download svn fresh and build from the fresh 
download.  I build a package for Zenwalk, so it's easily installed or 
removed.  There is never any need to "make clean all" due to the fact 
I'm not using the same unarchived directory.

I normally remove grub from the system before installing the new, so 
that no old files are left behind.  From what I can see from testing, 
there is a bug in 2059.  What that is, I'm afraid I don't know, but am 
hoping you guys will clear it up soon.

thanks,
Pat

-- 
        ---Zenwalk v6.0--Linux 2.6.28---
         Registered Linux User #225206
"Ever tried Zen computing?"  http://www.zenwalk.org

Re: Grub2 svn2059

[phcoder]

BandiPat wrote:
> Yoshinori K. Okuji wrote:
>> On Saturday 04 April 2009 04:02:18 BandiPat wrote:
>>> Yoshinori K. Okuji wrote:
>>>> On Friday 03 April 2009 14:17:04 step21 wrote:
>>>>> Hey, just a wild guess, but I think boot.mod got dropped and the boot
>>>>> command is now included in minicmd.mod
>>>> Yes, it seems so. And, it is a mistake that boot and some other 
>>>> commands
>>>> are not built into the kernel. We must reduce modules, and let them 
>>>> back
>>>> to the kernel.
>>>>
>>>> Regards,
>>>> Okuji
>>> -----------
>>> In the meantime, how do we get the new svn to work then?  Is there some
>>> trick or something in the compile we need to do?  Presently I'm using
>>> svn2031 successfully.
>>
>> I guess you just have some outdated files. As "make" depends on 
>> timestamps, checking out from any kind of version control system can 
>> confuse "make". Try "make clean all".
>>
>> Regards,
>> Okuji
> -------------
> No, no outdated files.  I download svn fresh and build from the fresh 
> download.  I build a package for Zenwalk, so it's easily installed or 
> removed.  There is never any need to "make clean all" due to the fact 
> I'm not using the same unarchived directory.
> 
> I normally remove grub from the system before installing the new, so 
> that no old files are left behind.  From what I can see from testing, 
> there is a bug in 2059.  What that is, I'm afraid I don't know, but am 
> hoping you guys will clear it up soon.
> 
> thanks,
> Pat
> 
Have you re-run grub-setup?

-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Grub2 svn2059

[BandiPat]

phcoder wrote:

> Have you re-run grub-setup?
> 
------
No, I've never run grub-setup after an install, only grub-install & 
grub-mkconfig.  What will that program do?  I tried to read the man 
page, but it gave me an error.

Pat

-- 
        ---Zenwalk v6.0--Linux 2.6.28---
         Registered Linux User #225206
"Ever tried Zen computing?"  http://www.zenwalk.org

Re: Grub2 svn2059

[Andreas Born]

BandiPat wrote:
> phcoder wrote:
>
>     Have you re-run grub-setup?
>
>
> ------
> No, I've never run grub-setup after an install, only grub-install & 
> grub-mkconfig. What will that program do? I tried to read the man 
> page, but it gave me an error.
It's invoked by grub-install to do the actual installation of the
bootloader. Basically it installs an image generated by grub-mkimage.
grub-install just tries to automate all this stuff.
So in fact you run grub-setup.

Andreas

Re: Grub2 svn2059

[BandiPat]

Andreas Born wrote:
> BandiPat wrote:
>> phcoder wrote:
>>
>>     Have you re-run grub-setup?
>>
>>
>> ------
>> No, I've never run grub-setup after an install, only grub-install & 
>> grub-mkconfig. What will that program do? I tried to read the man 
>> page, but it gave me an error.
> It's invoked by grub-install to do the actual installation of the
> bootloader. Basically it installs an image generated by grub-mkimage.
> grub-install just tries to automate all this stuff.
> So in fact you run grub-setup.
> 
> Andreas
=======
Thanks Andreas, I just figured that out as well when testing on another 
machine just now.  If you still have the file I sent you for svn2059, 
would you mind testing it on your machine as well.  I'm tempted to send 
you the svn2059 or 2065 to compile on your current machine, to see if it 
behaves differently than the one I built.  Be prepared though, as I'm 
sure you'll need to re-install svn2031 back after 2059 fails to boot. 
Keep your LiveCD available to reboot!  :-)

I just tested 2059 on another machine here, which resulted in the same 
error, non-boot situation as it did on my main machine.  There is a bug 
somewhere since 2031.  I guess at this point someone needs to research 
what changed between 2031 and 2059.

Thanks for everyone's help!
Pat

Re: Grub2 svn2059

[Andreas Born]

BandiPat schrieb:
> Thanks Andreas, I just figured that out as well when testing on 
> another machine just now.  If you still have the file I sent you for 
> svn2059, would you mind testing it on your machine as well.  I'm 
> tempted to send you the svn2059 or 2065 to compile on your current 
> machine, to see if it behaves differently than the one I built.  Be 
> prepared though, as I'm sure you'll need to re-install svn2031 back 
> after 2059 fails to boot. Keep your LiveCD available to reboot!  :-)
I tested the svn2059-60.1 build on my current Zenwalk installation. It 
would boot here, but I have it installed to superblock of my ext3 
partition, so that might be the difference. Therefore I installed grub2 
to the MBR, but like that it would work too.
But I noticed two other problems:

    * If I drop to console with 'c' from the menu and then reload the
      menu with 'configfile (hd0,3)/boot/grub/grub.cfg', 'prefix' is
      unset and I can't boot. If I drop then back to console I can set
      'prefix' properly to '(hd0,3)/boot/grub' and boot from console,
      but configfile won't work.
    * With the 'linux' loader as opposed to the 'linux16' loader, I
      would always get a verbose splash, although I force a silent one
      with 'splash=silent'. My assumption was that the kernel parameters
      are ignored at all, but passing a wrong root resulted in a error.
      So either only 'splash=silent' is ignored or its something
      completely different. I think the problem is related to the one
      described in "New linux loader doesn't like vga=1".


Andreas

Re: Grub2 svn2059

[BandiPat]

Andreas Born wrote:
> BandiPat schrieb:
>> Thanks Andreas, I just figured that out as well when testing on 
>> another machine just now.  If you still have the file I sent you for 
>> svn2059, would you mind testing it on your machine as well.  I'm 
>> tempted to send you the svn2059 or 2065 to compile on your current 
>> machine, to see if it behaves differently than the one I built.  Be 
>> prepared though, as I'm sure you'll need to re-install svn2031 back 
>> after 2059 fails to boot. Keep your LiveCD available to reboot!  :-)
> I tested the svn2059-60.1 build on my current Zenwalk installation. It 
> would boot here, but I have it installed to superblock of my ext3 
> partition, so that might be the difference. Therefore I installed grub2 
> to the MBR, but like that it would work too.
> But I noticed two other problems:
> 
>    * If I drop to console with 'c' from the menu and then reload the
>      menu with 'configfile (hd0,3)/boot/grub/grub.cfg', 'prefix' is
>      unset and I can't boot. If I drop then back to console I can set
>      'prefix' properly to '(hd0,3)/boot/grub' and boot from console,
>      but configfile won't work.
>    * With the 'linux' loader as opposed to the 'linux16' loader, I
>      would always get a verbose splash, although I force a silent one
>      with 'splash=silent'. My assumption was that the kernel parameters
>      are ignored at all, but passing a wrong root resulted in a error.
>      So either only 'splash=silent' is ignored or its something
>      completely different. I think the problem is related to the one
>      described in "New linux loader doesn't like vga=1".
> 
> 
> Andreas
>=============
Ok, I'm not sure I understand what all of this means, except the part 
that you mentioned it worked for you.  That at least tells me the build 
is not bad.  Since I don't presently have a current 6.0 setup, I can't 
test that right now, but will do a new install so I can.

I've never installed to the superblock, just the mbr, but I'll assume 
that's not the problem, since you seem to have gotten both to work.  As 
I mentioned, I have tried this on two snapshot systems, where both have 
failed using 2059 or above.  Since you haven't tried it on your 
snapshot, and this file will work there as well because the only 
difference is I compiled one as 686 the other 486.  I would be 
interested to know your results there as well.

I've got an idea I'm going to try, but not sure it will make a 
difference.  Thus far, I've been using the previous grub.cfg created by 
2031, so I think I'll try to let 2059 create a new one.  Again not sure 
it would make a difference because it appears the loader is not getting 
to the grub.cfg before it fails.

Thanks,
Pat

Re: Grub2 svn2059

[BandiPat]

Yoshinori K. Okuji wrote:
> On Saturday 04 April 2009 04:02:18 BandiPat wrote:
>> Yoshinori K. Okuji wrote:
>>> On Friday 03 April 2009 14:17:04 step21 wrote:
>>>> Hey, just a wild guess, but I think boot.mod got dropped and the boot
>>>> command is now included in minicmd.mod
>>> Yes, it seems so. And, it is a mistake that boot and some other commands
>>> are not built into the kernel. We must reduce modules, and let them back
>>> to the kernel.
>>>
>>> Regards,
>>> Okuji
>> -----------
>> In the meantime, how do we get the new svn to work then?  Is there some
>> trick or something in the compile we need to do?  Presently I'm using
>> svn2031 successfully.
> 
> I guess you just have some outdated files. As "make" depends on timestamps, 
> checking out from any kind of version control system can confuse "make". 
> Try "make clean all".
> 
> Regards,
> Okuji
______________________________________________

Well, devs, I am making some advancements with the new svn versions.  I 
just did a brand new fresh install to a test computer which had LILO 
installed as default.  I first installed svn2059 for testing, which 
worked!  I then did an upgrade to svn2065 afterwards, ran the 
grub-install command to replace all the files in /boot/grub.

Each time I've run or re-run grub-install though, I get this error.
grub-setup:  error:  cannot read '/boot/grub/core.img' correctly

Someone enlighten me as to what might be causing that?  Otherwise, 
things are looking favorable for Grub2 being okay, but I'm not letting 
you devs off until I do a bit more testing.  :-)

Regards,
Pat

Re: Grub2 svn2059

[BandiPat]

Andreas Born wrote:
> BandiPat schrieb:
>> Thanks Andreas, I just figured that out as well when testing on 
>> another machine just now.  If you still have the file I sent you for 
>> svn2059, would you mind testing it on your machine as well.  I'm 
>> tempted to send you the svn2059 or 2065 to compile on your current 
>> machine, to see if it behaves differently than the one I built.  Be 
>> prepared though, as I'm sure you'll need to re-install svn2031 back 
>> after 2059 fails to boot. Keep your LiveCD available to reboot!  :-)
> I tested the svn2059-60.1 build on my current Zenwalk installation. It 
> would boot here, but I have it installed to superblock of my ext3 
> partition, so that might be the difference. Therefore I installed grub2 
> to the MBR, but like that it would work too.
> But I noticed two other problems:
> 
>    * If I drop to console with 'c' from the menu and then reload the
>      menu with 'configfile (hd0,3)/boot/grub/grub.cfg', 'prefix' is
>      unset and I can't boot. If I drop then back to console I can set
>      'prefix' properly to '(hd0,3)/boot/grub' and boot from console,
>      but configfile won't work.
>    * With the 'linux' loader as opposed to the 'linux16' loader, I
>      would always get a verbose splash, although I force a silent one
>      with 'splash=silent'. My assumption was that the kernel parameters
>      are ignored at all, but passing a wrong root resulted in a error.
>      So either only 'splash=silent' is ignored or its something
>      completely different. I think the problem is related to the one
>      described in "New linux loader doesn't like vga=1".
> 
> 
> Andreas
_______________________________________________

Don't know if anyone is still interested in this problem or not, but I 
believe I have found the problem, as I have svn2070 working now on all 4 
of my machines.  What I found.  Upon testing on my main machine, I found 
during my investigations, that it didn't seem that the newer Grub2 was 
overwriting the info in the MBR.  My drive had the system on hd0,1, but 
listing the root set at the rescue prompt showed hd0,2 for some reason, 
which was from a previous setup.  I manually cleared out the MBR, 
installed the newer version, from svn2031 that had been working, then 
ran grub-install again.  To my delight, it worked without problems, 
after rebooting!

Since I normally get weekly svn files to test, I wondered if doing 
grub-install so often caused this breakdown in overwriting the MBR?  I 
have tested this fix on 4 different machines now and after clearing out 
the MBR, grub-install works correctly.  So my question to you guys is 
this:  is this a bug in Grub2 that causes it not to overwrite the MBR 
with new info or something else?

I also concur with Andreas above about the "vga" problem, which I've 
noticed you guys discussing often here.  Presently if I use 
splash=silent vga=794, the splash will not show.  I get the correct 
resolution set, but still see the scrolling text.  From the emails I've 
read here, this problem still seems to be present in the latest svn?  Is 
there something extra that ./configure needs now to make this work 
correctly?

Thanks,
Pat