Re: Grub boots from command line but not menu

On Sat, 25 Feb 2006 21:43:58 -0800, iforone wrote:


Douglas Mayne wrote:

WAG: root is the magic word which causes the grub to "forget"
anything it knows about filesystems, and also reinitialize where it looks
for _its_ files. This is what I was speculating about before.

BTW, I am planning on doing some more tests with grub. I'd like to know
what exactly is required for it to be able to read from different types of
filesystems on different partitions. I think that an appropriate stage2
needs to be pre-installed on the BPB of a target partition before it can
read it (unless the target partition and last specified root partition
are using the same filesystem type.) I am not sure, but some simple tests
will tell.

I'm going to add some info that may or may not help....
(BTW - what does WAG mean ? Wagers A Guess?)

That's a nice variant, kind of like, "read the _fine_ manual."
WAG and SWAG:
http://www.ceri.com/q_v6n5q4.htm


Ok..here's distro/kernel info;
$ uname -a
Linux 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux
Debian 3.1r1

Here's my relevant /boot/grub/menu.lst info
~$ sudo cat /boot/grub/menu.lst

title Debian GNU/Linux, kernel 2.6.8-2-386
root (hd0,6)
kernel /boot/vmlinuz-2.6.8-2-386 root=/dev/hda7 ro acpi=force
apm=force
initrd /boot/initrd.img-2.6.8-2-386
savedefault
boot

title Debian GNU/Linux, kernel 2.6.8-2-386 (recovery mode)
root (hd0,6)
kernel /boot/vmlinuz-2.6.8-2-386 root=/dev/hda7 ro single
initrd /boot/initrd.img-2.6.8-2-386
savedefault
boot

# This entry automatically added by the Debian installer for a
non-linux OS
# on /dev/hda1
title Windows 95/98/Me
root (hd0,0)
savedefault
makeactive
chainloader +1

Notes;
I have no kernel image or "real" Kernel .....Nothing in /usr/src DIR --
not even a /linux Directory present. I think I'm booting from a
mini-kernel - I notice 'cramfs' in dmesg at boot time (whatever that's
worth);

~$ dmesg | grep -i cram
RAMDISK: cramfs filesystem found at block 0
VFS: Mounted root (cramfs filesystem) readonly.

Note: Try again with post. My adjacent response was incomplete. There is
some sort of "hair trigger" on pan's send button ;-)

Note: comment inline.

I did some testing, with results which confirm your experience. Grub
could read all of the known filesystems on the disc as soon as stage2 was
loaded. The results of my tests show that if grub menu is displayed, then
it doesn't require anything else to read the filesystems for which it has
been compiled. Also, it doesn't appear to reload stage2 when root
is issued within a grub menu.lst stanza. It appears that stage2 is the
superset of all the filesystems it knows how to read, established when
stage2 is compiled. As you thought, grub proved to be even more flexible
than I had guessed. But it was also more limited with chainloader than I
thought.

More Information

I could not duplicate the experience of the OP. grub would not
"forget" how to load a filesystem once stage2 is loaded. I tested
grub, version 0.97. The only error I could generate was if stage2
could not be loaded at all. That is, if I removed stage2 from the
grub directory, "grub error 15" is reported. I also found some problems
with grub installed at the partition are detailed below.

Specific Test Information

Several tests were performed separately using separate filesystems and
modes of operation. I tested ext2, XFS, JFS, and ReiserFS with Grub being
loaded directly from a hard disk and from a CD-R with the grub loader. I
used my project, a Slackware-based LiveCD as the base platform for
testing:
http://www.xmission.com/~ddmayne2/10.2-live/

I was using a VMWare virtual machine as the "hardware" platform.

1. A Basic boot test: this is what grub should do as a minimum.
Grub is installed on the partition, so that the loader can be setup:

# grub
grub> root (hd0,4)
grub> setup (hd0)
grub> quit

All of my tests were successful, with the exception of JFS.

Again, at this point grub can read all of the other partition types that
it knows about without extra help. Therefore, commands like these succeed
(either from menu.lst or the boot shell):

grub> kernel (hd0,4)/boot/vmlinuz ro root=/dev/hda5

grub> kernel (hd0,5)/boot/vmlinuz ro root=/dev/hda5

Weird result with JFS

JFS/Grub would hang before showing the menu when loaded directly from the
hard disk. But, this is strange, when booting from CD-R, and using
chainloader from the boot shell (as shown below) works fine- the menu
loads, and bootup proceeds normally:

grub> root (hd0)
grub> chainloader +1
grub> boot

This error could have been due to a mistake I made, but I tried it
twice with the same results.

2. Tests with chainloader. (And a big word of caution.)

Some of the ways I had envisioned the chainloader command do not work.
For example, it is possible to link to a Windows NTFS partition with this
syntax:

grub> rootnoverify (hd0,0)
grub> makeactive
grub> chainloader +1
grub> boot

I didn't test the above example, nor chainloading to lilo on the
partition. Chainloading to lilo may be tested at a later date.

This syntax also works with a GNU/Linux partitions which are
formatted using _ext2_. This assumes grub has been setup properly at the
target partition, using syntax similar to this:

grub> root (hd0,4)
grub> setup (hd0,4)

Then, from the grub boot shell, issue these command:

grub> rootnoverify (hd0,4)
grub> chainloader +1
grub> boot

This causes grub's menu to be displayed, at least with ext2.

Other filesystems

But, this procedure _does not_ work with the more complex journaled
filesystems, XFS, JFS, ReiserFS. In fact, if the "setup" commands are
issued on an XFS partition, the partition is destroyed. Grub reports no
errors when installing on XFS, but the partition will fail to mount.
Also, grub "setup" on ReiserFS report an error. To emphasize, this is the
case where grub is installed on the partition, not loading through the
MBR. That generally works- as shown in my test 1 (above.) When I checked
grub's documentation, it reports that it can be installed on the
partitions using FFS (?) or ReiserFS:
http://www.gnu.org/software/grub/manual/html_node/Bootstrap-tricks.html#Bootstrap-tricks

That is not what I see in reality with ReiserFS, however. Perhaps,
grub is not intended to be installed on the partition (BPB) of advanced
filesystems. The least it could do is to "do no harm." It should really
identify XFS, and refuse to modify the BPB. But for consistency sake, it
should be possible to install the loader this way.

Conclusion

Test, don't assume something works by extrapolation. The failure of XFS
and grub really surprised me.

I took some screenshots of my tests. Perhaps, I'll try to organize and
post them.

imotgm, thanks for your input. Your "reported working" experience was
helpful for me to investigate further and to learn more about grub.

--
Douglas Mayne
.

Quantcast