On Fri, 03 Feb 2006 14:50:21 +1300 Volker Kuhlmann wrote: > > No no , grub.conf is read on the fly on bootup. > > You're talking about menu.lst, and you'd be editing menu.lst to change > kernel boot options or boot targets. > > How does grub find out which partition to find menu.lst on?
it is embedded in the mbr. Specifically the mbr has embedded in it that grub's is on partition X and therefore knows that menu.lst is X/boot/grub/menu.lst grub.conf is the same file as menu.lst, they are symlinked. > > True, you don't need a grub.conf, you can enter the data manually into > grub-install if you feel so inclined. > > Do a test Nick: copy your /boot onto /, then do a > cat /dev/zero >/dev/hda1 (the 32M hdaX which used to contain /boot) > and see if it still boots... it won't unless you rerun grub's setup routine with an instruction that tells it that grub's root is now /dev/hda3 (hd0,2) instead of /dev/hda1 (hd0,0) Oh and it pays to remember that grub's root is not the same thing as your filesystem's root. > > Actually not a conclusive test, grub might have a fallback and keeps > looking on other filesystems until it finds a /boot/menu.lst. What if > you have multiple partitions/filesystems all containing a valid (but > different) /boot/menu.lst? > > > > [1] The list of actual disk blocks taken up by the kernel image file is > > > hardcoded (ok around 2 corners) into the boot loader. > > > > not in grub it isn't. You are thinking of lilo. > > Correct, the [1] was in the lilo part of the sentence... > OK sorry, yes thats correct, lilo maintains a list of the physical blocks where the kernel is stored. I misunderstood your post and thought you were claiming that about grub. -- Nick Rout <[EMAIL PROTECTED]>
