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
>>
>>
>>
>>
>>
