Grub boots from command line but not menu
andrew....@gmail.com
When I try to boot one my slackware partition with grub from the menu,
it fails -- I get a "can't mount root filesystem" error. If the same
commands are typed into the command line, it works like a champ.
Commands are:
root (hd1,0)
kernel /boot/vmlinuz root=/dev/hdb1 ro
I've got a puppy linux partition on (hd0,1) which boots fine.
Any ideas appreciated.
-- Andrew Bell
andrew.bell.ia@gmail
Douglas Mayne
One possible answer: A syntax error in menu.lst (or grub.conf).
Because you are using two different distro's also check that they expect
the same configuration file. Some distros use grub.conf, some use menu.lst.
Another possible answer:
grub is actually installed on the distro with puppy, but not for
slackware. This error might be generated if your configuration marks
_its_ root partition to a partition where it has never been installed.
Post your configuration file.
--
Douglas Mayne
andrew....@gmail.com
I don't have grub installed on the slackware distro. Does grub need to
be installed on each OS that it boots? I *thought* that it went to one
location to get its config file and the stage<n> stuff that was needed
to boot. I guess that I assumed once the kernel started loading, grub
was out of the picture. No?
Cheers,
Douglas Mayne
Yes, once grub shows its menu it has enough info to load any file on _its_
root partition. There will be no problems if all of the files necessary
for booting every linux distribution on your machine are also located on
that partition. But, assuming your slackware kernel is on another
partition (with the slackware distro), then grub might not be able to
load it. This is because grub has the ability to read filesystems, but
only as setup. For example, if one distro is using ext2 and another is
using reiserFS, then they need separate grub stage2 files.
BTW, you didn't post your configuration file. I am trying to help you, but
I can't guess every possible mistake you might have made.
BTW, you need to improve your posting style. Apparently, you are
posting from google groups, and their default setting does not include any
context of the thread. This is bad form. Remember, this is Usenet not
Google Groups.
--
Douglas Mayne
andrew....@gmail.com
> On Thu, 23 Feb 2006 14:20:54 -0800, andrew.bell.ia wrote:
>
> > Thanks for your reply.
> >
> > I don't have grub installed on the slackware distro. Does grub need to
> > be installed on each OS that it boots? I *thought* that it went to one
> > location to get its config file and the stage<n> stuff that was needed
> > to boot. I guess that I assumed once the kernel started loading, grub
> > was out of the picture. No?
> >
> > Cheers,
> >
> Yes, once grub shows its menu it has enough info to load any file on _its_
> root partition. There will be no problems if all of the files necessary
> for booting every linux distribution on your machine are also located on
> that partition. But, assuming your slackware kernel is on another
> partition (with the slackware distro), then grub might not be able to
> load it. This is because grub has the ability to read filesystems, but
> only as setup. For example, if one distro is using ext2 and another is
> using reiserFS, then they need separate grub stage2 files.
In this case, they are using different filesystems, so this could be
the culprit, but I still don't understand why the IDENTICAL commands
typed from the command line would work and the commands coming from the
menu on the puppy filesystem wouldn't work.
> BTW, you didn't post your configuration file. I am trying to help you, but
> I can't guess every possible mistake you might have made.
Thanks again for your insight. I don't think I was at home and had the
file available when I wrote. I'm still not at home. If the above idea
doesn't fix things, I'll try to grab the file and post it.
> BTW, you need to improve your posting style. Apparently, you are
> posting from google groups, and their default setting does not include any
> context of the thread. This is bad form. Remember, this is Usenet not
> Google Groups.
I have been using Usenet for a long time, but the Google interface
makes it really easy not to pay attention to such things.
-- Andrew Bell
andrew....@gmail.com
Douglas Mayne
> Douglas Mayne wrote:
>> On Thu, 23 Feb 2006 14:20:54 -0800, andrew.bell.ia wrote:
>>
>> > Thanks for your reply.
>> >
>> > I don't have grub installed on the slackware distro. Does grub need to
>> > be installed on each OS that it boots? I *thought* that it went to one
>> > location to get its config file and the stage<n> stuff that was needed
>> > to boot. I guess that I assumed once the kernel started loading, grub
>> > was out of the picture. No?
>> >
>> > Cheers,
>> >
>> Yes, once grub shows its menu it has enough info to load any file on _its_
>> root partition. There will be no problems if all of the files necessary
>> for booting every linux distribution on your machine are also located on
>> that partition. But, assuming your slackware kernel is on another
>> partition (with the slackware distro), then grub might not be able to
>> load it. This is because grub has the ability to read filesystems, but
>> only as setup. For example, if one distro is using ext2 and another is
>> using reiserFS, then they need separate grub stage2 files.
>
> In this case, they are using different filesystems, so this could be
> the culprit, but I still don't understand why the IDENTICAL commands
> typed from the command line would work and the commands coming from the
> menu on the puppy filesystem wouldn't work.
>
<snip>
>
Here's why I think it could work from the command line, and not the
menu. Note: entering WAG mode.
Assume your Puppy linux has one boot/root partition formatted ext2. The
grub loader is setup properly on that partition. When you boot it
proceeds as it should to display the grub menu. As part of the boot to
the menu, grub obtains the ability to read ext2 filesystems. It can boot
straight away into Puppy, because it's setup properly.
Assume your Slackware linux has one boot/root partition formatted ext2.
The grub loader has never been setup on the partition, partly because lilo
is the default loader for Slackware. When you try to select it from
grub's menu, grub assumes it will need to reload the stage2 file
necessary to read the type of filesystem on the partition. It
fails with the error you are seeing because that partition's BPB has never
been initialized with grub's loader (stage2). As soon as you install grub
properly on the target partition, the problem disappears.
But grub's command line works...
When you drop to grub's command line, it doesn't "forget" how to access
ext2. It tries to read the disc using whatever tools it has at that
moment
I wrote about grub and an idea for the layout of multibooting with more
than one Linux distribution here:
http://groups.google.com/group/comp.os.linux.setup/msg/17d3cfcff0cf2d0f
Notice: That link is the start of the thread.
--
Douglas Mayne
imotgm
> I wrote about grub and an idea for the layout of multibooting with more
> than one Linux distribution here:
> http://groups.google.com/group/comp.os.linux.setup/msg/17d3cfcff0cf2d0f
>
> Notice: That link is the start of the thread.
I guess that this will have to stop working then, because there is no
grub, or lilo installed in the Slackware partition. It's really a shame,
as it's worked so well up until now.
title Slackware 9.1 - slack partition
kernel (hd0,8)/boot/vmlinuz root=/dev/hda9 vga=788 hdb=ide-scsi hdd=ide-scsi
title Slackware 9.1 - slack partition 2.4.22
kernel (hd0,8)/boot/vmlinuz-adaptec.s-2.4.22 root=/dev/hda9 vga=788 hdb=ide-scsi hdd=ide-scsi
[root@fatman boot]# ls -l
total 2752
-rw-r--r-- 1 root root 1404802 Jan 15 2004 vmlinuz
-rw-r--r-- 1 root root 1404802 Jan 15 2004 vmlinuz-adaptec.s-2.4.22
[root@fatman boot]#
You will note a complete lack of a grub directory, and, obviously, any
files therein. No initrd either, as that's the Slack way.
title PCLinuxOS
kernel (hd0,11)/boot/vmlinuz root=/dev/hda12 devfs=mount hdb=ide-scsi hdd=ide-scsi vga=788 splash=verbose show0pts
initrd (hd0,11)/boot/initrd.img
If the above had installed a boot loader, it would have been lilo, but
this grub stanza does the job instead. Contents of the /boot directory
below.
[root@fatman boot]# ls -l
total 2668
-rw-r--r-- 1 root root 512 Dec 9 2003 boot.0300
-rw-r--r-- 1 root root 512 Dec 13 2003 boot.0800
lrwxrwxrwx 1 root root 24 Dec 18 03:17 config -> config-2.4.23-2.tmb.2mdk
-rw-r--r-- 1 root root 53039 Dec 18 2003 config-2.4.23-2.tmb.2mdk
-rw-r--r-- 1 root root 5032 Jan 4 2004 diag1.img
-rw-r--r-- 1 root root 16796 Jan 4 2004 diag2.img
-rw-r--r-- 1 root root 180641 Dec 20 2003 initrd-2.4.23-2.tmb.2mdk.img
lrwxrwxrwx 1 root root 28 Apr 22 2004 initrd.img -> initrd-2.4.23-2.tmb.2mdk.img
lrwxrwxrwx 1 root root 32 Dec 18 03:17 kernel.h -> /boot/kernel.h-2.4.23-2.tmb.2mdk
-rw-r--r-- 1 root root 537 Dec 20 2003 kernel.h-2.4.23-2.tmb.2mdk
drwx------ 2 root root 4096 Dec 12 2003 lost+found/
-rw------- 1 root root 251904 Jan 15 2004 map
lrwxrwxrwx 1 root root 15 Apr 22 2004 message -> message-graphic
-rw-r--r-- 1 root root 183517 Jan 22 2004 message-graphic
-rw-r--r-- 1 root root 132 Dec 9 2003 message-text
lrwxrwxrwx 1 root root 28 Apr 22 2004 System.map -> System.map-2.4.23-2.tmb.2mdk
-rw-r--r-- 1 root root 617975 Dec 18 2003 System.map-2.4.23-2.tmb.2mdk
-rw-r--r-- 1 root root 256 Dec 9 2003 us.klt
lrwxrwxrwx 1 root root 25 Apr 22 2004 vmlinuz -> vmlinuz-2.4.23-2.tmb.2mdk
-rw-r--r-- 1 root root 1358399 Dec 18 2003 vmlinuz-2.4.23-2.tmb.2mdk
[root@fatman boot]#
Lots of extra junk it there, but again no grub directory.
Grub needs to be installed exactly once, by one OS. All other additional
OS need only have a stanza added to the single menu.lst used by that
single installation of grub. If there is a separate boot partition, it
will be found in /grub/menu.lst. If there is no boot partition, it will be
found in /boot/grub/menu.lst on the partition of the OS from which grub
was installed.
For Red Hat/Fedora menu.lst will be renamed grub.conf.
As you choose to chainload multiple grub installations, I can see why
you'd be confused about how grub actually works. I have one grub, on a
boot partition, with multiple stanzas for the various OSs, seven at
present, and all boot just fine. If OP has the problem that he states,
there is most probably a syntax error in the Slackware stanza in his
menu.lst.
--
imotgm
"Lost? Lost? I've never been lost... Been a tad confused for a
month or two, but never lost."
Douglas Mayne
> On Fri, 24 Feb 2006 08:01:16 -0700, Douglas Mayne wrote:
>
>
>> I wrote about grub and an idea for the layout of multibooting with more
>> than one Linux distribution here:
>> http://groups.google.com/group/comp.os.linux.setup/msg/17d3cfcff0cf2d0f
>>
>> Notice: That link is the start of the thread.
>
>
> I guess that this will have to stop working then, because there is no
> grub, or lilo installed in the Slackware partition. It's really a shame,
> as it's worked so well up until now.
>
> title Slackware 9.1 - slack partition
> kernel (hd0,8)/boot/vmlinuz root=/dev/hda9 vga=788 hdb=ide-scsi hdd=ide-scsi
>
> title Slackware 9.1 - slack partition 2.4.22
> kernel (hd0,8)/boot/vmlinuz-adaptec.s-2.4.22 root=/dev/hda9 vga=788 hdb=ide-scsi hdd=ide-scsi
>
> [root@fatman boot]# ls -l
>
<snip>
> Grub needs to be installed exactly once, by one OS. All other additional
> OS need only have a stanza added to the single menu.lst used by that
Yes. That's one way to do it!
> single installation of grub. If there is a separate boot partition, it
> will be found in /grub/menu.lst. If there is no boot partition, it will be
> found in /boot/grub/menu.lst on the partition of the OS from which grub
> was installed.
>
> For Red Hat/Fedora menu.lst will be renamed grub.conf.
>
> As you choose to chainload multiple grub installations, I can see why
> you'd be confused about how grub actually works. I have one grub, on a
> boot partition, with multiple stanzas for the various OSs, seven at
> present, and all boot just fine. If OP has the problem that he states,
> there is most probably a syntax error in the Slackware stanza in his
> menu.lst.
>
Note: comment inline.
Here we go again. _You_ still want me to diagnose why _your_ system
is not broken:
http://groups.google.com/group/comp.os.linux.misc/browse_frm/thread/a9862aca6be39f5c/27dbc9715f086943?lnk=st&q=%22douglas+mayne%22+diagnose&rnum=5&hl=en#27dbc9715f086943
Your system boots because your kernels are being read from the same boot
partition where grub is installed. Re-read this thread and tell me that
your system would boot if one kernel was on (hd0,6) formatted XFS and
another kernel was to be read from (hd0,7) formatted ext2.
Note: I did telegraph that I was entering WAG to the OP due to lack of
specific information from him. You have provided more than him, hence,
I believe your system is not broken ;-) and should boot.
--
Douglas Mayne
imotgm
Smartass, I remember that. ;)
> Your system boots because your kernels are being read from the same boot
> partition where grub is installed. Re-read this thread and tell me that
> your system would boot if one kernel was on (hd0,6) formatted XFS and
> another kernel was to be read from (hd0,7) formatted ext2.
You didn't look closely enough. None of the stanzas I posted are booting
from kernels on the boot partition. At the moment, I'm doing housekeeping
on the boot partition, and no kernels reside there, at all, only the grub
directory, and the files therein. Each kernel is in the /boot directory of
the OS's / partition. look again.
title Slackware 9.1 - slack partition
kernel (hd0,8)/boot/vmlinuz root=/dev/hda9 vga=788 hdb=ide-scsi hdd=ide-scsi
title Slackware 9.1 - slack partition 2.4.22
kernel (hd0,8)/boot/vmlinuz-adaptec.s-2.4.22 root=/dev/hda9 vga=788 hdb=ide-scsi hdd=ide-scsi
title PCLinuxOS
kernel (hd0,11)/boot/vmlinuz root=/dev/hda12 devfs=mount hdb=ide-scsi hdd=ide-scsi vga=788 splash=verbose show0pts
initrd (hd0,11)/boot/initrd.img
Here are some more.
title SUSE LINUX 10.0
root (hd0,5)
kernel /boot/vmlinuz root=/dev/hda6 vga=0x317 selinux=0 resume=/dev/hda2 splash=verbose showopts
initrd /boot/initrd
title SUSE LINUX 9.3 (/dev/hda5)
kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 vga=0x317 selinux=0 splash=verbose console=tty0 resume=/dev/hda2 showopts
initrd (hd0,4)/boot/initrd
title Mandriva 2006 Current
kernel (hd1,2)/boot/vmlinuz root=/dev/hdc3 vga=791 resume=/dev/hdc2 splash=verbose
initrd (hd1,2)/boot/initrd.img
title Mandrake 10.1 -26 ###
kernel (hd1,4)/boot/vmlinuz root=/dev/hdc5 resume=/dev/hdc2 splash=verbose vga=788
initrd (hd1,4)/boot/initrd.img
I don't use XFS, but having read the stanzas on menu.lst, grub doesn't
seem to mind whether the kernels are on ext3, or reiserfs partitions. Try
this yourself. I think you'll find that grub is even more flexible than
you think.
> Note: I did telegraph that I was entering WAG to the OP due to lack of
> specific information from him.
Always a safe policy. ;) I've been known to use that, as well as request
additional information, or post the "smartquestions" link. I may have even
resorted to, "WTF are you talking about?" a time or two, for a truly
obnoxious, and totally clueless poster, but I try to keep that to a
minimum. There are already too many posters that use the latter as their
standard reply, to every gnubie poster. I'd rather try to be helpful, if I
can, or at least add a little humor, when things get stressed a might.
> You have provided more than him, hence, I believe your system is not
> broken ;-) and should boot.
It's not, and it does. ;-)
If you have further comments to this, please don't think me rude if it
takes a while to get back. I just bought a 160GB Seagate drive, for
$69.95, then ran into a sale that got me a 200GB Seagate for $29.95, so
I'm going to be busy moving some OSs over to the bigger drives,
deleting some of the older OSs, and installing the 32bit versions of
Mandriva 2006, and SUSE 10.0, to run comparisons against the 64bit
versions already installed.
I'm also building an AMD 64 based computer for a friend, or rather
supervising him, while he does the actual building. He's never owned a
computer before, and wants it to run Linux, as he likes what he sees on
mine, so I'm going to start him on a dual boot Mandriva, SUSE. This should
be a trip, and keep me AWOL from the NGs for a while. ;-D
Douglas, I do enjoy talking with you, doing a little needling, receiving a
little needling back, but always in good humor. Much more pleasant than
with some of the more froggy folks one runs into in the NGs. 'Til later.
Cheers. ;-)
andrew....@gmail.com
> On Fri, 24 Feb 2006 14:53:28 -0700, Douglas Mayne wrote:
>
> You didn't look closely enough. None of the stanzas I posted are booting
> from kernels on the boot partition. At the moment, I'm doing housekeeping
> on the boot partition, and no kernels reside there, at all, only the grub
> directory, and the files therein. Each kernel is in the /boot directory of
> the OS's / partition. look again.
>
> title Slackware 9.1 - slack partition
> kernel (hd0,8)/boot/vmlinuz root=/dev/hda9 vga=788 hdb=ide-scsi hdd=ide-scsi
>
> title Slackware 9.1 - slack partition 2.4.22
> kernel (hd0,8)/boot/vmlinuz-adaptec.s-2.4.22 root=/dev/hda9 vga=788 hdb=ide-scsi hdd=ide-scsi
This gave me something to try which worked. Putting the root info on
the kernel line as shown above works, but splitting the root and kernel
command, as I posted originally, doesn't work.
#
# Doesn't work
#
root (hd1,0)
kernel /boot/vmlinuz root=/dev/hdb1 ro
#
# Works
#
kernel (hd1,0)/boot/vmlinuz root=/dev/hdb1 ro
This syntax is not clear from the grub manual. If anyone has any
explanation, I'd love to hear it.
Thanks!
-- Andrew Bell
andrew....@gmail.com
Douglas Mayne
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.
--
Douglas Mayne
iforone
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?)
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.
Douglas Mayne
>
> 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
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.
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.
1. A Basic boot test: this is what grub should do as a
minimum.
Grub's
stage files were present (when grub was setup)
at /boot/grubI tested the
basic setup of grub at the MBR linking to . In
all cases, once the menu is displayed, grub can read files on any
partition on the disctesteperformed several tests (independantly with
ext2, XFS, ReiserFS, JFS). I
I setup a test platform with grub booting to stage2 on hda3 using xfs. I
tested with this menu.lst:
title Slackware 10.2+ xfs
root (hd0,2)
kernel /boot/vmlinuz ro root=/dev/hda3
initrd /boot/initrd
title Slackware 10.2+ ext2 w-root
root (hd0,0)
kernel /boot/vmlinuz ro root=/dev/hda1
title Slackware 10.2+ ext2 direct
kernel (hd0,0)/boot/vmlinuz ro root=/dev/hda1
All three entries boot, and there is no difference for me with the
second and third menu options. grub was not installed at all on hda1
(either in /boot/grub nor the boot sector.)
Thanks for your input. Your "reported working" experience was helpful for
me to investigate further and learn more about grub.
--
Douglas Mayne
Douglas Mayne
>
> 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
>
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
imotgm
Oops! I get to give you another little needle. ;-)
You seem to be responding to me, imotgm, as determined by the context of
this, and your other parallel post, and I got the message, but your
response is actually to iforone, who is not me, and asks about WAGs, of
which I have been a master, for years. ;)
I left his post intact, above, so you could verify that, without leaving
this post.
> Note: Try again with post. My adjacent response was incomplete. There is
> some sort of "hair trigger" on Pan's send button ;-)
I've noticed that myself. It must be Pan's fault. It could never be my
own. Certainly not yours. ;-P
> 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.
As I understand it, (in a fuzzy logic sort of answer) stage1 can only find
it's root, and, in effect, ask which stage1_5 can read the file system of
the "grub root" partition, then attaches itself to that one which can.
Then it locates, and joins, the stage2, which gives grub the ability to
read files on the partition, which allows it to not only read, and use the
menu.lst, but also the remaining stage1_5 files present in the /grub
directory, which then makes grub complete.
> 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.
For what it's worth, both I, and PTB, have had problems with grub 0.97. I
don't know if they have been fixed yet, but grub 0.96, as delivered with
SUSE 10.0 seems to be working fully.
You might want to repeat your tests with 0.96, to see if the problems with
XFS, JFS, and chainloader are peculiar to 0.97, or common with grub in
general.
<snip>
> 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.
I've chainloaded to lilo, somewhere back between 0.92-0.94, not sure
which, when I still had a multiboot disk, with lilo in the MBR of that
disk, as well as on one of the partitions. I started with the grub menu,
chose the lilo drive, or partition, and got the lilo menu, then chose the
OS to boot. It worked fine, either way, but seemed to be an unnecessary
step, as I could also boot direct to each OS, with a menu.lst stanza.
That's also when I finally dropped lilo, and it's need to be run after
each kernel update. ;-)
> But, this procedure _does not_ work with the more complex journaled
> filesystems, XFS, JFS, ReiserFS.
With grub 0.9x, with x being less than 7, I've never experienced a problem
doing this, with ReiserFS, as that is the default for SUSE, and has been
since the 7.x versions, I believe. I think it was the default on 7.2, but
may have been an option. I had it, and grub, on 7.2, and used that as my
initial grub test bed. By 8.0 it was definitely default.
> 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.
Check a fresh XFS partition's first sector with a hex editor to see if
there's anything there, that grub is overwriting.
> 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.
As stated above, hex editor, and try with 0.96.
> 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.
Excellent idea, but wait until you've tried 0.96 also.
> imotgm, thanks for your input. Your "reported working" experience was
> helpful for me to investigate further and to learn more about grub.
BTDTGTTS ;-D
You're welcome. I'm getting something out of this as well. I've never used
XFS, or JFS, so your findings, from direct testing, mirror mine, but
include extras that I haven't done first hand. I've always trusted that
which I have personally observed, more than someone's personal pet theory
of how something should, or should not, work. Your method of testing
really is, almost exactly, my own, so I trust your observations, and
conclusions, (or at least I will, after you test with 0.96). Did I mention
that before? I thought I did. ;-D
'Til later,
Cheers.
P.S.
Like I don't already have enough to do, now I've got to go d/l your
v.0.0.2.8 10.2-live CD. Actually it's being done as I write this. ;)
imotgm
Of course you have a real kernel image; it's vmlinuz-2.6.8-2-386, and it's
in your /boot directory, where it's supposed to be. Why do you suppose the
grub stanzas would lie about it?
What you don't have is the kernel source installed in /usr/src, which
you'll need, if you want to compile your own kernel, or any special
drivers/modules.
> ~$ dmesg | grep -i cram
> RAMDISK: cramfs filesystem found at block 0
> VFS: Mounted root (cramfs filesystem) readonly.
--
Douglas Mayne
> On Tue, 28 Feb 2006 11:12:58 -0700, Douglas Mayne wrote:
>
<snip>
>
> Oops! I get to give you another little needle. ;-)
>
> You seem to be responding to me, imotgm, as determined by the context of
> this, and your other parallel post, and I got the message, but your
> response is actually to iforone, who is not me, and asks about WAGs, of
> which I have been a master, for years. ;)
>
> I left his post intact, above, so you could verify that, without leaving
> this post.
>
Yes, I noticed that, too- after I sent the post ;) There's no retrieving
mail once it's in the box.
>> Note: Try again with post. My adjacent response was incomplete. There is
>> some sort of "hair trigger" on Pan's send button ;-)
>
> I've noticed that myself. It must be Pan's fault. It could never be my
> own. Certainly not yours. ;-P
I started writing this answer when I had some preliminary results. I
had to rethink what was going on when chainloader tests didn't work as I
thought.
I assumed 0.97 would be incrementally better than previous versions, not
newly broken. I'll repeat the tests with Grub, version 0.96. Thanks for
the idea.
I'll check exactly what changes. It is obviously damaging the sector
because mount fails. The mount commands below fail, the first asks which
filesystem to use. (Normally, mount can automatically determine which
filesystem to use, with no entry in fstab.)
mount /dev/hda5 /mnt/hda5
mount -t xfs /dev/hda5 /mnt/hda5
Note: comments inline.
Thanks for downloading my project. The 149M download expands to a 344M
iso image for a bootable CD. The resulting bootable CD gives an
environment similar to Slackware 10.0 disc 2, but updated for a 2.6.x
kernel and with newer packages. Slackware 10.0 disc 2 had a lot of
kernels, to match the target platform. This project uses one modular
kernel, and no special initrd is required to match the user's hardware.
The user sets the modules to be modprobe'd from an initial "pre-start"
shell. The difference between this project and other live CDs is that
other live CDs are designed to identify/guess which hardware the user
intends to use. My project makes no assumptions and leaves it to the user
to load the necessary modules for his hardware. My project is also
different in that it is designed to use a Read/Write device, if avaiable
(that RW device is combined with a RO device). If no RW device is
available, then the fallback mode is similar to a standard live CD. Using
my project as a live CD is the simplest option.
Scan through the README before you bootup,
http://www.xmission.com/~ddmayne2/10.2-live/v.0.0.2.8/10.2-live/README
This file can also displayed at bootup, too.
Thanks again. I don't think I'll be able to repeat my tests with
version 0.96 until next week. It should be a pretty simple change though.
The test platform is otherwise setup and ready to go.
--
Douglas Mayne
iforone
> On Sat, 25 Feb 2006 21:43:58 -0800, iforone wrote:
> > 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
> >
> > 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);
>
> Of course you have a real kernel image; it's vmlinuz-2.6.8-2-386, and it's
> in your /boot directory, where it's supposed to be. Why do you suppose the
> grub stanzas would lie about it?
>
> What you don't have is the kernel source installed in /usr/src, which
> you'll need, if you want to compile your own kernel, or any special
> drivers/modules.
>
It's just my silly terminology misunderstanding I guess...
I'm just starting to learn about initrd, hotplug, udev, etc. I suppose
I'd like to compile my own kernel but it's a bit beyond my
knowledge/abilities at the moment.
I have many empty 4.0KB files and DIRs in my '/' partition's subDirs
and even in /sys DIR (this bothers me) - since I created separate
(hda7-11) partitions of /, swap, /home, /usr, /var, in that order, it
seems hda11 (/var) is the most "active" (with /usr/shared/apps - and
other subDirs) containing many things I'd expect to find in / -- which
stinks ;-), ....being so close to the spindle and so far from others.
What happens is, I'll read in NG threads, discussion about certain
locations of certain Items, then I'll go investigate on my system and
"it's" not there :-( (poof!).
Also - I have some odd permission issues (I'm always logged in as my
self-made restricted User). I am locked out of some(many) folders (some
have lock icons on them) - I Cannot view "Hidden" files (ones that
start with . ) in a GUI...on and on and on (very annoying).
Granted I know (finally) how to access these elements/items in a Shell
(sudo) or as root in a VT, but that's not pleasant viewing to me all
the time (distasteful terminal screens and such) - though whenever I
need to do some mild Admin, I have no problem dropping to either VT or
as 'su' and editing using nano, pico, vim, (emacs?) etc...
I created many (some) different partitions in the expectation I'd
easily be able to save, move, adjust, swap items around (even if I
needed a reinstall)..I'm at the point where;
A. I need to learn howto and perform compiling my own kernel
B. I atleast want to blast/wipe out this /var partition and merge(?)
whatever data is necessary for saved settings over into / (or wherever,
but closer to /)..I hear my HDD heads thrashing away too much for my
liking.
Obviously I had no clue as to 'which' partitions and/or DIRs would
require constant access (reads/writes) when I created them - but
never-you-mind...this is deserved of atleast another separate thread
(or three ;-))
Thanks to you and Doug (and many others across these linux groups, as
well as my own research) I am slowly learning/grasping...
As you were ;)
iforone
Douglas Mayne wrote:
> On Fri, 03 Mar 2006 13:12:03 +0000, imotgm wrote:
> > You seem to be responding to me, imotgm, as determined by the context of
> > this, and your other parallel post, and I got the message, but your
> > response is actually to iforone, who is not me, and asks about WAGs, of
> > which I have been a master, for years. ;)
> >
> > I left his post intact, above, so you could verify that, without leaving
> > this post.
> >
> Yes, I noticed that, too- after I sent the post ;) There's no retrieving
> mail once it's in the box.
>
That's one reason I haven't responded (not that I had anything
important to add anyway). I knew from the "context", it was meant for
imotgtm (and not moi ;-))
Douglas Mayne
The issue of root vs. regular user is ongoing. A regular user is safer,
but root throws up a lot less obstacles for the end user when using
devices- being able to mount, use camera's, make CDs, etc. I have made
the following recommendation to those using Linux as a desktop (this is
what I do):
1. Start a virtual terminal as a regular user. Start X. Use for
all normal and network applications: pan, mozilla, office, etc.
2. Start another virtual terminal as root. Start X (startx -- :1) and
use for special applications which require root access. Don't run any
network appplications. Also, be careful, _root_ can destroy your system
with a misplaced rm.
Then use <CTL>-<ALT>-<F7> and <CTL>-<ALT>-<F8> to switch between the
users. Also, by using a different Windows manager, there will be a clear
difference which "user" is which. I use gnome for my normal user, and
XFCE for root. XFCE is a very light windows manager which can run
simultaneously along side gnome without overtaxing the system. I don't
know if it is a good solution from a security standpoint, but it is a
compromise which works for me.
BTW, I think you might consider reinstalling with a simpler partitioning
scheme.
--
Douglas Mayne
imotgm
> On Fri, 03 Mar 2006 13:12:03 +0000, imotgm wrote:
>
>> On Tue, 28 Feb 2006 11:12:58 -0700, Douglas Mayne wrote:
>>
> <snip>
<snip>
>> I left his post intact, above, so you could verify that, without leaving
>> this post.
>>
> Yes, I noticed that, too- after I sent the post ;) There's no retrieving
> mail once it's in the box.
It's Usenet, shit happens.
<snip>
> I started writing this answer when I had some preliminary results. I
> had to rethink what was going on when chainloader tests didn't work as I
> thought.
One of those, "Just when I thought I had it all figured out, it threw me a
curve," moments.
<snip>
>> For what it's worth, both I, and PTB, have had problems with grub 0.97.
>> I don't know if they have been fixed yet, but grub 0.96, as delivered
>> with SUSE 10.0 seems to be working fully.
>
> I assumed 0.97 would be incrementally better than previous versions, not
> newly broken. I'll repeat the tests with Grub, version 0.96. Thanks for
> the idea.
It's worth a shot.
< more snip, this is getting too long. ;) >
>> Check a fresh XFS partition's first sector with a hex editor to see if
>> there's anything there, that grub is overwriting.
>
> I'll check exactly what changes. It is obviously damaging the sector
> because mount fails. The mount commands below fail, the first asks which
> filesystem to use. (Normally, mount can automatically determine which
> filesystem to use, with no entry in fstab.)
>
> mount /dev/hda5 /mnt/hda5
> mount -t xfs /dev/hda5 /mnt/hda5
I did this recently with a vfat partition, which had a mess of shit there,
and a ext3, which was blank, so nothing to overwrite.
<snip>
>> Like I don't already have enough to do, now I've got to go d/l your
>> v.0.0.2.8 10.2-live CD. Actually it's being done as I write this. ;)
>
> Thanks for downloading my project. The 149M download expands to a 344M
> iso image for a bootable CD. The resulting bootable CD gives an
> environment similar to Slackware 10.0 disc 2, but updated for a 2.6.x
> kernel and with newer packages.
That was the first thing I checked. I like 2.6.x. My Slack 9.1 is the only
2.4.x I have left, and I need to do a fresh Slack installation, it's
getting long in the tooth. This way I can play with 10.2, before
installing. ;-)
> Slackware 10.0 disc 2 had a lot of kernels, to match the target
> platform. This project uses one modular kernel, and no special initrd is
> required to match the user's hardware. The user sets the modules to be
> modprobe'd from an initial "pre-start" shell. The difference between
> this project and other live CDs is that other live CDs are designed to
> identify/guess which hardware the user intends to use. My project makes
> no assumptions and leaves it to the user to load the necessary modules
> for his hardware.
Thanks for warning me. I did a # lsmod > /home/imotgm/modules.txt so I can
print it before I boot the CD.
> My project is also different in that it is designed to
> use a Read/Write device, if available (that RW device is combined with a
> RO device). If no RW device is available, then the fallback mode is
> similar to a standard live CD. Using my project as a live CD is the
> simplest option.
I removed my CD-R/W when I rebuilt this machine, as I had a DL-DVD-R/W
also, and had never done a straight disk to disk copy. I always make an
image first, so I opted for an extra rack/caddy for another hard drive.
Maybe an external USB 5.5" housing might not be too bad of an idea. ;-)
> Scan through the README before you bootup,
> http://www.xmission.com/~ddmayne2/10.2-live/v.0.0.2.8/10.2-live/README
I always read README and INSTALL files first. Saves many headaches. As
long as you posted the link, I saved the README to disk, so I can read it
while burning the CD.
> This file can also displayed at bootup, too.
>
> Thanks again. I don't think I'll be able to repeat my tests with
> version 0.96 until next week. It should be a pretty simple change though.
> The test platform is otherwise setup and ready to go.
Not a problem by me. I'm still playing with my hard drives, and my friends
new 'puter. I just took some time to check if you'd answered my last post
from the 25th. Glad I did. Post the results, whenever you get them.
Remember to re-format the XFS partition. ;)
Later.
Douglas Mayne
> On Fri, 03 Mar 2006 08:11:51 -0700, Douglas Mayne wrote:
>
>> On Fri, 03 Mar 2006 13:12:03 +0000, imotgm wrote:
<snip>
>>
>> Thanks for downloading my project. The 149M download expands to a 344M
>> iso image for a bootable CD. The resulting bootable CD gives an
>> environment similar to Slackware 10.0 disc 2, but updated for a 2.6.x
>> kernel and with newer packages.
>
> That was the first thing I checked. I like 2.6.x. My Slack 9.1 is the only
> 2.4.x I have left, and I need to do a fresh Slack installation, it's
> getting long in the tooth. This way I can play with 10.2, before
> installing. ;-)
>
>
>> Slackware 10.0 disc 2 had a lot of kernels, to match the target
>> platform. This project uses one modular kernel, and no special initrd is
>> required to match the user's hardware. The user sets the modules to be
>> modprobe'd from an initial "pre-start" shell. The difference between
>> this project and other live CDs is that other live CDs are designed to
>> identify/guess which hardware the user intends to use. My project makes
>> no assumptions and leaves it to the user to load the necessary modules
>> for his hardware.
>
> Thanks for warning me. I did a # lsmod > /home/imotgm/modules.txt so I can
> print it before I boot the CD.
The only important modules those necessary to get access to the devices
you intend to use as part of the root filesystem. The 2.6.15.3
kernel uses P.V.'s configuration for his 2.6.x generic kernel, which means
IDE devices are supported with no changes. Other devices will need a
module, such as, ata_piix for the common Intel SATA chipset.
Because this project is based on updating the rescue disc, alsa sound is
not included. It's a cut down, bare bones system. It can work also work
with an "as setup" full install, though. That approach gives an
"unmodifiable" base layer (RO), with layers on top for changes. I have
used it as an alternative to slacktrack. It also seems like a good
platform for a firewall where quick resets to a known good state is a
desirable feature.
>
<snip>
>
> Not a problem by me. I'm still playing with my hard drives, and my
> friends new 'puter. I just took some time to check if you'd answered my
> last post from the 25th. Glad I did. Post the results, whenever you get
> them.
>
> Remember to re-format the XFS partition. ;)
Already ready to go.
>
> Later.
>
Note: comments inline.
Thanks!
--
Douglas Mayne