Re: Towards a customized Grub2

[Richard Owlett]

On 05/29/2017 07:17 PM, John Little wrote:
> Richard Owlett asked for a grub2 customized to his wishes.
>
> > How to obtain and install?
>
> (This from memory before I got an UEFI computer.  Please, anyone,
> criticize the following.)

I approve of trimming, BUT ;/
You trimmed one {perhaps poorly worded} sentence too much.
I had said:
  > I am assuming a Grub2 executable conforming exactly to the
  > official documentation.
In your first paragraph you alluded to a "can of worms" I'm trying to 
avoid when you said:
  > A lot of what people see as part of Grub, like the "OS prober",
  > "update-grub", and custom entries in /etc/grub.d belong to
  > debian, and grub is agnostic about them.

What I want "to obtain and install" is an "unadulterated canonical 
Grub2". Does what I want even exist in the "www.gnu.org/software/grub/" 
universe of discourse? Or is Grub2 itself only a set of building blocks 
and intentionally not a complete entity {right word?}?

You also said:
  > ... running several installs, reinstalling occasionally,...
and
  > ... implies you haven't installed it yet.

That points out something I did not explicitly state in this thread.
My underlying motivation for the question is that I'm experimenting with 
releases and configurations. I have a machine physically set aside for 
my experiments. I have done as many as 15 installs from scratch in one 
week. I've had as many as 5 fully functioning installs at one time.

I suppose the critical question is "does the Grub2 project have 
functional equivalents of "OS prober" and "update-grub"?

I've not digested the remainder of your post yet.
Thank you for your time.








> I think you're headed for a hand-coded grub.cfg.  There's a learning
> curve, but in the long run, say the life of a PC, if you're running
> several installs, reinstalling occasionally, IMO it's easier that way.
>   A lot of what people see as part of Grub, like the "OS prober",
> "update-grub", and custom entries in /etc/grub.d belong to debian, and
> grub is agnostic about them.
>
> The main trouble with the generated grub.cfg was that it would change
> unpredictably, and not work sometimes; grub 2 was arriving during
> those years.  Or, I'd move a partition, add a disk, or do an install
> and get the grub rescue prompt.
>
> 1) I imagine the default gap to the first partition (1 MiB less 1
> sector) will be enough, as I'm not suggesting you add any modules to
> what goes there.  However, in 2017, perhaps more is needed now.
> /boot/grub is 8.9 MiB on my system, but if you want background images
> and fonts they'll need space.  I suggest 100 MiB for /dev/sda1.
>
> 2) "will contain the default OS" implies you haven't installed it yet.
> When you install it, if possible tell the installer to put grub on
> /dev/sda3.  (My installer is Ubuntu's one, ubiquity, and it asked that
> question.)  The grub code in the MBR and the gap will point to
> /dev/sda3/boot.  When your debian updates with a new kernel, you don't
> want debian updating grub on /dev/sda1. When you install other OS's,
> don't let them install grub to /dev/sda.
>
> 2) Boot that OS, then (as root) mount /dev/sda1, say on /mnt/grub,
> mkdir /mnt/grun/boot, then run grub-install /dev/sda
> --boot-directory=/mnt/grub/boot.  The grub in the MBR and the gap will
> now point to /dev/sda1/boot.  Have bootable media handy, in case
> something goes wrong.
>
> 3) Edit /dev/sda1/boot/grub.cfg.  At the least change the first entry,
> for your default OS, to search for the label you give it, not the
> UUID, and to load /vmlinuz and /init.rd, some thing like:
>
> search --no-floppy --label <your-label>
> linux /vmlinuz
> initrd /init.img
>
> Those are symbolic links to the latest kernel and initrd; debian
> updates them when getting a new kernel.  Now, no need for grub.cfg to
> be updated when a new kernel arrives.
>
> 4) I used to add an "others" menu entry:
>
> menuentry "others" {
>     search --no-floppy --label --set=root <my-label>
>         configfile /boot/grub/grub.cfg
> }
>
> This just gets to debian's updated grub, with all it's bells and
> whistles, memdisk, older kernels, and whatever annoying change would
> arrive.  I would also rip out most of the beginning of grub.cfg, and
> refactor the insmod statements that appeared in every menuentry,
>
> 5) Every year or so, I'd have a look at where the debian grub.cfg had
> got to, and see if I wanted the changes.
>
> Regards, John Little
>
> _______________________________________________
> Help-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-grub