Re: Need help installing Grub2

[Andrey Borzenkov]

В Mon, 12 May 2014 17:15:53 -0700
"Ronald F. Guilmette" <address@hidden> пишет:

> 
> 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?
> 

*By default* grub2 stores its components on file system. You do not
need to install operating system on the same drive where grub files are
located, but you need operating system to install grub.

Depending on your needs it is possible to build standalone grub binary
that will contain necessary drivers and configuration and will not
require access to "external" filesystem.

> If so, then please educate me.  Why is this even necessary?

Bootloader must store its configuration somewhere. User needs to edit
configuration. Bootloader must be able to read filesystem to load
kernel and other files during boot. This makes filesystem a natural
place to store data that bootloader needs. Bootloader has support to
read its data already, and user can use standard OS tools to edit
configuration.

grub is flexible enough to behave differently, but it needs some
defaults, and this was chosen as default behavior. 

>                                                              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?

As was already mentioned, you can tell grub to store its data somewhere
else. E.g. on dedicated partition.

>                                   (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.)
> 

Full set of grub modules already exceeds 1MiB. So you would need to
artificially restrict its functionality by not installing some of them.

> >...
> >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?
> 

Yes, that's correct. Default grub installation consists of two parts -
stage0 (core.img) which normally has just enough drivers to access
partition and filesystem where all other grub files are located. And
everything else, which is loaded as needed by core.img. Wiping out grub
files will leave you in core.img with very limited functionality.

> 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.
> 

It's hard to make any comment without knowing what those bootloaders
can do. From your further comments it appears they are limited to
chainloading partition boot blocks, which really does not need much
space.

> 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.)
> 

Yes, grub can read NTFS; the challenge is to write to it from within
Linux or other OS. And it can also read FreeBSD UFS.

Current grub 2.02beta2 provides native support for Windows which means
you can install grub on NTFS from within Windows. Prebuilt Windows
binaries are available from download site.

> 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.
> 

grub comes with utility grub-mkconfig that generates grub.cfg for
current operating system (i.e. where grub-mkconfig is executed). with
menu that lists all kernels. Coupled with another utility - os-prober -
it can also generate menu entries for other operating systems found on a
system.

Unfortunately grub-mkconfig is shell based so limited to Unix like OS
and os-prober likely is Linux-only.

> 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?
> 

Sure, that is exactly what "appropriate grub.cfg" means. It is possible
to build grub core.img that would do exactly it and won't require
access to any external filesystem.