Re: Towards a customized Grub2

[adrian15 adrian15]

2017-05-30 12:40 GMT+02:00 Richard Owlett <address@hidden>:

> 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?}?
>
There is not an unadulterated canonical Grub2 (as you understand it in a
binary form that you can just download and install) unless maybe the
Windows release which it's built previous to its release. The rest of the
canonical Grub2 releases only exists as 'source code' and you are supposed
to build them.

>
> 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"?
>
What you can do is what you can find on my Super Grub2 Disk project that
is... using scripts that emulates 'OS prober' or 'Update grub' because it
provides a dynamic boot menu based on what you have installed. Super Grub2
Disk is meant to be run from an external usb or cdrom though.

Once you have an installed working custom Grub2 installation you can borrow
some of the Super Grub2 Disk scripts and, if needed, adapt them to your
needs. I try to build Super Grub2 Disk as similar to default upstream Grub2
but, well, when building it, you always have to decide which bits to turn
on or not. It's like the Linux kernel, when building desktop distributions,
some devices from the kernel are being choosen, other ones kept apart on
modules and other ones not used at all, but no so complex.

Note: 'OS Prober' checks partition starts for determining if an Operating
system is Windows 7, 8, 8.1, 10 and so on. That it's not currently doable
with current Grub2 scripts. Given a partition you can get the device name,
partition number, uuid or label though (some of that it's done on Super
Grub2 Disk).

I also do not find quite viable your quest of installing many OSes on one
physical machine while avoiding them to overwrite the default grub which
you pretend to install on sda2 (if I'm not mistaken).
I mean, don't get me wrong, it can be done, of course, but you might forget
to untick the Grub installation in one distro installation (or maybe the
installation media forces grub to be installed without asking the final
user) and then you lose your custom Grub2 installation and you need to
reinstall it manually from a live cd.

If you finally use Super Grub2 Disk your feedback will be welcomed (
https://github.com/supergrub/supergrub/issues ). Its main audience is for
people that want to regain access to their computers even if UEFI or MBR is
wrecked. But there's a secondary audience for powerusers that install many
OSes in a single system (not so common nowadays because of virtualisation).


>
> 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
>>
>>
>
>
> _______________________________________________
> Help-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-grub
>



-- 
Support free software. Donate to Super Grub Disk. Apoya el software libre.
Dona a Super Grub Disk. http://www.supergrubdisk.org/index.php?pid=10