On May 13, 2014 2:15:53 AM CEST, "Ronald F. Guilmette" <address@hidden> wrote:
In message <address@hidden>
Jordan Uggla <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/help-grub