In message <CAHh2SOR-1OQOQrTLbQzGexO9bjbJ-jeOxq=isglp68g1xyj...@mail.gmail.com> Jordan Uggla <[email protected]> wrote:
>On Sun, May 11, 2014 at 2:50 PM, Ronald F. Guilmette >> Must I first find a whole 'nother drive, install some flavor of Linux on >> that other drive, boot that other drive, and then use Linux to install >> Grub2? > >Definitely not needed. But I gather from your other comments that I *must* have installed on the drive... at the very least... *some* operating system which is using *some* type of filesystem which grub2 understands, *and* into which some little bits of pieces of stuff relating to grub2 must get installed. Is that correct? If so, then please educate me. Why is this even necessary? Doesn't a boot loader such a grub/grub2 have a whole entire track0 (63 * 512 byte sectors) to play with, at a very minimum? Why does it need to store *anything* into *my* filesystems? (I say "at a very minimum" because it appears to me that most modern partitioning tools... including but not limited to Gparted, FreeBSD's gpart, and even the Windows7 built-in partitioning tools... all seem to try hard to cater to the unique foibles associated with modern SSD drives by placing partitions, by default, after the first 1 MiB of the drive. Obviously, a lot could be done, software-wise, given nearly a whole megabyte to work with.) >... >You do however need a /boot/, >so you'll need to decide which partition should contain grub's >/boot/grub/, mount that partition somewhere, and pass the path to the >/boot/ directory on this partition to grub-install's --boot-directory >option and create an appropriate grub.cfg in. This is the part I'm still confused about. Why? Why does grub2 find it necessary to obtain anything at all from some particular place in one of *my* partitions? This is a concern for me, because I copy partitions around a lot. I'll have a "known good" OS installation on one drive, and then use either Gparted or Clonezilla to copy that to a different "woking copy" drive. If that get's hosed, e.g. by a virus or by fumble fingers... like, you know, the proverbial "rm -fr *"... then no worries. I just go back and re-copy the partition again from the "master" drive. But if my master doesn't already have this "grub.cfg" already all setup, installed into the Right Place, and configured properly for my *target* drive, then it appears that you are telling me that my simple partition copies won't work anymore... or at least grub2 won't be able to boot them. Correct? Also, and perhaps more to the point, I have used various other "unaffiliated" boot managers in the past (i.e. ones not specifically affiliated with one specific operating system) and also FreeBSD's boot manager and none of them seem to have any need or desire to have critical components of themselves embedded into any of my partitions. All of them seem perfectly happy to live just within track 0, including any & all of their associated config data. So there it is. I have tried to be clear about the various specific points of my ignorance. Now, if you be so kind, please enlighten me. Regards, rfg P.S. Is NTFS one of the supported file system types, you know, with respect to the --boot-directory option? How about FreeBSD UFS? (I'm guessing that both must be, but I'd just like to get solid confirmation.) P.P.S. In the context of your comments, what exactly is an "appropriate" grub.cfg file? Having never worked with grub before... or at least not consciously... I have no idea what needs to be in there. The other alternative boot managers I've worked with in the past just automagically came up showing me a list of possible partitions I might be able to boot from and then asking me to select one. No special pre-configuration needed. Does grub have a mode like this? _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
