Re: Grub2 almost does what I want

[Felix Miata]

On 2013-02-03 12:28 (GMT+0400) Andrey Borzenkov composed:

> 02 Feb 2013 16:04:18 -0500 Felix Miata composed:

> > On 2013-02-02 23:50 (GMT+0400) Andrey Borzenkov composed:

> > > If you have ideas how to improve generation of grub.cfg that are generic
> > > enough, it is always possible to submit patch (or attract someone to
> > > write patch to implement them :) )

> > 1-Get rid of the vga= is deprecated message. It has nothing to do with Grub2
> > function.

> No quite. From Documentation/kernel-parameters.txt:

>                          This is actually a boot loader parameter; the value is
>                          passed to the kernel using a special protocol.

Either that doc is wrong, or it serves more than one purpose....

> >            Some installations still require it, it's still a valid kernel
> > cmdline option, and it still functions as always when KMS is not enabled.

> Do you mean it does not work?

Which "it"? Some old video chips have no KMS support, so vga= is required to 
not have 80x25 login prompts on the ttys.

Even with KMS supported video, KMS initialization is anything but instant, 
while vga= is quickly responded to by the kernel. In nearly every boot menu 
stanza on all my hundred plus installations post-KMS I have both vga= and 
video=. In most they are not equivalent modes, and I see the vga= mode used 
for well over a screenful of boot messages before a KMS switch to the video= 
mode is made. Typically I use vga=794 with video=1152x864, so on switch the 
text gets larger than it just had been.

> > 2-This is the initial  Mageia (3) Cauldron (grub-2.00-16.mga3;
> > os-prober-1.57-3.mga3) grub.cfg file generated yesterday:
> > http://fm.no-ip.com/Tmp/Linux/Mdv/grub.cfg.gx27b-cauldron3-1.txt

> > Note the default stanza's vmlinuz-prv & initrd-prv, which are symlinks to the
> > previously installed kernel. One set of the current kernel's symlinks are way
> > down the list in the submenu, vmlinuz-cur & initrd-cur,

> Are those links created by default in Mageia? I do not remember them in
> Mandrake^H^H^Hiva. Or did you create them manually?

Like in openSUSE, new kernel installation only symlinks to the latest 
installed kernel/initrd, though Ma*a creates two different symlinks for each 
of kernel & initrd. I create the other symlinks so that I can use them 
directly by my master bootloader or at a Grub prompt and not need to change 
the master bootloader menu every time a new kernel gets installed or remember 
the name of the latest or older kernels when I want to use one at a Grub 
prompt. On many I have also vmlinuz-prv2, initrd-prv2, vmlinuz-prv3, 
initrd-prv3, etc.

> >                                                        while the default
> > set, vmlinuz and initrd also pointing to the latest installed, are not
> > present in any stanza, and other sets are in duplicate stanzas without even
> > considering recovery stanzas.

> Well, that's exactly the problem of "generic enough". Every
> distribution has own ways of managing kernel updates, own ways of
> naming them or creating symlinks for them.

I spend the most time with openSUSE, less with Ma*a, and still less with 
Fedora. OS and Ma*a are as I say above, but Fedora creates no kernel/initrd 
symlinks at all, so I must do all of its manually.

> I would tentatively suggest to raise this issue on Mageia list/bugzilla
> first. Only Mageia knows which kernel is current and which kernel is
> not and how to sort them. It would take a single line patch to call
> distribution script to sort kernel entries correctly.

> > How mkconfig decided what to create and where to locate are unfathomable.

> It takes list of /boot/vmlinuz-* and lexicographically sorts them.

It probably needs to find the one on the target partition with the biggest 
numeric component to make default/top of list when all others are to go in a 
submenu as Mageia does it.

> > Consequently, I have no idea anything specific about how to improve it, only
> > that it needs improvement, with one exception:

> > GRUB_MASTER_LOADER=[true,false]

> > If true:
> > 1:assume GRUB_DISABLE_OS_PROBER=false
> > 2:MBR installation.

> This two are unrelated. grub-install just takes device where to install
> as argument and does not care whether this MBR or not. And it does not
> call grub-mkconfig.

And I have yet to call grub2-mkconfig. Mageia is the first non-*buntu I've 
installed Grub2 into, which I only did after discovering Grub2 and Grub 
Legacy can coexist there, and what core.img is and does. For reasons besides 
lack of need for Grub2 and aversion to mixing old Grub and new Grub on the 
same systems I use *buntu very very little.

> > If false:
> > 1:assume GRUB_DISABLE_OS_PROBER=true (only provide stanzas for kernels on the
> > installation target partition; override if not GRUB_DISABLE_OS_PROBER=true)
> > 2:do not write to MBR track.

> > Linux installation programs could provide a checkbox so that the big mess and
> > the suspiciously long installation delay on account of mkconfig/os-prober's
> > sloth can be readily avoided from the outset.

> What prevents Linux distribution programs from providing this checkbox
> now?

I have no idea beyond the fact that Grub2 is a quickly moving target that 
seems hard for distro packagers to keep up with for purposes of 
distro-specific configurators like MCC and YaST.

>  Or simply not installing os-prober in the first place?

On Mageia I did 'urpmi --no-suggests grub2', which pulled os-prober in with 
it, after aborting 'urpmi grub2', which proposed to install something like 9 
packages total.

> > Annotated partitioning of subject system:
> > http://fm.no-ip.com/Tmp/Dfsee/gx27bL07.txt
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/