[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grub2 almost does what I want

From: Felix Miata
Subject: Re: Grub2 almost does what I want
Date: Sun, 03 Feb 2013 04:24:49 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 SeaMonkey/2.15

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

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:

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:


If true:
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

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:
"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  ***

reply via email to

[Prev in Thread] Current Thread [Next in Thread]