Excuse me but I did in fact read the documentation. Iwasn't being serious
bout the microsoft comment. Please calm down. With an attitude like that
no one will use grub. (I am the only person I know who does).
I think its great but you need to realize that most grub users are ex-lilo
people. I have read your documentation and did not see any special
provisions for people who have boot partitions.
Sorry if your almight program had a bug. Try not to be so touchy in the
future. I was merely trying to help and was told to make a bug report by
somone on kernelnewbies on irc.openprojects.net.
I will continue to use GRUB as I am planning to work with the HURD project
and it is their official kernel loader. I even like GRUB better than lilo
due to the simple menu interface.
As for your comments and overexplanation you are speaking to someone who
is VERY knowledgeable on OS's. This is my first experience with GRUB and
I wasn't sure of the functionality.
That is why I went into the source code to find why I couldn't get a menu.
Dave
On Wed, 26 Jul 2000, Khimenko Victor
wrote:
> 26-Jul-00 07:48 you wrote:
> > If that's a feature.... I am going to put my resume in with Microsoft!
> > :)
>
> Go full speed. It IS feature. It's VERY simple in fact. GRUB is NOT linux
> loader. It can load ANY number of different OSes from different partitions.
> Thus it DOES NOT have ANY knowleadge about what's mounted where.
> GRUB just do not care. GRUB knows that it can found menu.lst on partition
> where it's installed in subdirectory /boot/grub/menu.lst and that's all.
> It does not care if this partition is mounted as / (in this case file will
> be /boot/grub/menu.lst in your system as well), /boot (then it'll be
> /boot/boot/grub/menu.lst), /dos/c (then it'll be /dos/c/boot/grub/menu.lst),
> /mnt/somewhere/deep/in/there (in this case you'll need to put file
> in /mnt/somewhere/deep/in/there/boot/grub/menu.lst) or even on on some
> partition nt present in /etc/fstab (in this case you STILL can mount it
> somewhere and edit this menu.lst even if this partition is not even visible
> in system most of time). It's chicken-egg problem in fact: till OS is not
> loaded there are NO mount-points at all and even more: then same partition
> can be visible in different pathes in different systems. Thus you can not use
> "full path" /boot/grub/menu.lst: there are NO "full path" concept till
> at least / is mounted. And GRUB is searching it's menu.lst WAY before
> anything is mounted ! Even before system kernel is loaded !
>
> P.S. Pehaps you STILL can not understood simple fact with all implications:
> GRUB DOES NOT look on files when you install it: it'll install itself on HDD
> where you'll ask it to install itself and that's all. menu.lst, vmlinuz and
> other files are read in BOOT PROCESS, not in INSTALLATION PROCESS. This
> mean that:
> 1. You should not reinstall GRUB after moving files around/editing files
> (you can install new kernel and reboot - no need to rerun /usr/sbin/grub
> like /sbin/lilo)
> 2. GRUB can not use "full path" concept: this concept just do not present
> in system when menu.lst (and other files) are read parsed. So you are whinig
> about GRUB inability to predict future and guess where partitions will be
> mounted when OS will be loaded. Hmm. When you'll invent time-machine in
> software and give use copy we'll be able to fix this "bug".
>
> P.P.S. In fact it's all explained quite well in GRUB documentation. Of course
> users who think it's bug and not feature will not read GRUB documentation
> anyway...
>
> > Dave
>
> > On Wed, 26 Jul 2000, Khimenko Victor wrote:
>
> >> 26-Jul-00 01:33 you wrote:
> >>
> >> > It's not a fatal bug but very annoying.
> >>
> >> Of course it's not fatal bug, it's not even bug at all if you'll think about it:
> >> GRUB knows NOTHING about what's mounted where. And that's good, that's how GRUB
> >> was designed and how it should work. So it's feature, not bug. Still perhaps
> >> somewhere in documentation it should be mentioned - for users not familiar with
> >> GRUB it looks like a bug.
> >>
> >> > The menu.lst file cannot be processed as usual for every user who has a
> >> > boot partition mounted as /boot under linux because of the hard coded path
> >> > for menu.lst in asmtub.c on line 89 in grub 0.5.95.
> >>
> >> > Because of this I had to make another directory and move everything.
> >>
> >> > Instead of /boot/grub/menu.lst I have /boot/boot/grub/menu.lst.
> >>
> >> > It should work with a symbolic link
> >> > ln -s /boot /boot/boot
> >>
> >> > This bug doesn't affect anyone who doesn't have a separate boot partition
> >> > mounted under the name /boot.
> >>
> >> > here is my partition table info.
> >>
> >> > /dev/hda1 /dos vfat user,exec,conv=binary 0 0
> >> > /dev/hdc2 /dos2 vfat user,exec,conv=binary 0 0
> >> > /dev/hdc1 /boot ext2 defaults 1 2
> >> > /dev/hdc3 swap swap defaults 0 0
> >> > /dev/hdc4 / ext2 defaults 1 1
> >>
> >> > as you can see /boot is not on the same partition as / and that is where
> >> > your problem lies.
> >>
> >> > I hope I didn't repeat myself too much. It was very confusing for me and
> >> > it took over an hour to fix.
> >>
> >> > If you have any questions please email me.
> >>
> >> > Dave
> >>
> >>
> >>
> >>
> >>
>
>
>
>
>
