On Sat, May 30, 2009 at 9:58 AM, Jason Dixon <ja...@dixongroup.net> wrote: > On Sat, May 30, 2009 at 09:10:58AM -0400, Donald Allen wrote: >> >> So, I'd like to ask why grub is apparently unsupported on the amd64 >> architecture? And I would suggest that grub provides a simple solution >> to dual-booting OpenBSD on a system that had been previously >> dual-booted with Windows and something else and where the Windows >> version of the mbr is no longer present. I'd be happy to provide the >> documentation for the procedure to add to the install guide, if the >> developers are interested. > > Save yourself some headaches. Use GAG. > > http://gag.sourceforge.net/
I looked over the documentation. Yes, for dual-booting OpenBSD with Windows, this looks fine, very nice. And I'll concede that it's a bit easier to configure than grub (it guides you through the configuration, rather than your having to make up a menu.lst), but when there's a grub package available, as there is with i386 OpenBSD, the difference isn't great, especially for someone like me with years of experience with grub, or if good documentation is available explaining how to do it. Though it isn't important in the Windows/OpenBSD case, it appears that GAG is less general than grub, in the sense that it is assuming there's a loader in the partition boot record of every partition you want to boot and appears to always use the grub chainloader technique. This is not a problem for OpenBSD, which installs its bootloader in its partition boot record when you tell it during installation that you aren't going to use the whole disk. But it is a problem if you want to, say, triple-boot Windows, OpenBSD, and Linux. Linux will require installing grub in its partition boot record, as the GAG author notes in his document. In that situation, it would make more sense, I think, to skip GAG and let the Linux installer install grub in the mbr for booting all three. In that setup, Linux would be booted by grub directly, not via a secondary loader. /Don > > -- > Jason Dixon > DixonGroup Consulting > http://www.dixongroup.net/
