On Sun, 2007-11-18 at 14:37 +0000, Timothy Murphy wrote: > John Austin wrote: > > >> > >> Notice f8 has already got a new kernel and it was properly added to > >> > >> grub. This would not happen if the above was just added to the main > >> > >> grub.conf. > > >> > > Why not? > >> > > I don't see anything special about your setup. > >> > > Most people just have one grub.conf and this seems to work fine. > > >> > It works fine if you are not getting upgraded kernel's. I prefer to > >> > use this method because it is open ended. I can add more systems easy. > > > It is neater to use chainloader +1 if you have several different installs > > > > When you update the "chained" kernel the "chained" grub.conf is updated > > automatically. On one machine I have a "production" F7 and "development" > > F7 and F8s > > Nobody has explained why it is "neater". > I have F7 on sda and F8 on sdb, > with a common /boot on sda2. > > > I do not have to play with grub.conf on /dev/sda1 > > I don't have to "play" with grub.conf either. > > I can imagine there might be a problem if there were two kernels > for different OS's with the same name, > but very few people are likely to meet this situation. > It is just that I prefer to have a new installations completely isolated from previous ones, with the installation not writing to the MBR and following blocks ie /dev/sda. The only reason is in case things go wrong - when installing F9T1 say. As it happens, in the example I gave, I put the whole installation in one partition /dev/sda6 (/ and /boot) complete with the "secondary" grub written at the front ie /dev/sda6 F8 picks up an existing swap partition. If required I can over write /dev/sda6 with something else without touching /dev/sda. Whether its desirable that F8 should be booted from an F8 version of grub rather than an older version I don't know, but this approach avoids that possibility. The assume the story must be completely different if using LVM and/or RAID. John
