Re: Grub2 almost does what I want

[Felix Miata]

On 2013-02-05 22:28 (GMT+0400) Andrey Borzenkov composed:

> 03 Feb 2013 14:44:18 -0500 Felix Miata composed:

> > Current listing of /boot/vmlinuz-* needs changing to listing of
> > /boot/vmlinuz* so that the stanza containing the preferred kernel "vmlinuz"
> > (or "linux" if that's what the distro uses) when present appears first
> > instead of not at all.

> Hmm ... if /vmlinuz link is managed by distribution, it is usually
> points to the kernel with highest version number (in which case see
> below). If you manage it yourself, you can simply set GRUB_DEFAULT to

There's nothing particularly simple about messing with /etc/default/grub 
unless maybe the only thing you work with is Grub or you are a fine manual 
memorizer. Within the file it's all about Grub, so why does nearly everything 
in it need to contain GRUB_? GFXPAYLOAD is nuts. GFX has a rather well 
established meaning, referring to graphics, while the video mode on ttys and 
during init is about text, however produced. Why not use what the KMS kernel 
uses (other than case), VIDEO?

> menu entry id, which remains the same for a given kernel version on a
> given filesystem (at least, as long as you do not reformat it) even if
> you add or remove kernels.

> So it is not clear what problem using /vmlinuz solves.

On my systems, post-firstboot it's always the default kernel, and the easiest 
to use via tab completion at a prompt.

If you're asking why symlinks at, there are multiple reasons, but one 
non-obvious one I make routine use of is that their timestamps handily and 
conveniently mark the time a particular kernel was installed, a time that 
would otherwise disappear when an update process recreates a previously 
existing initrd.

The most important reason for the symlinks is master bootloader usage. My 
MBRs all have generic boot code, and each HD destined for bootability has at 
least one primary partition (most have 3 pri + ext), with one hosting the 
master bootloader and set "active" in the partition table. I maintain the 
master boot menu 100% manually, never mounting it to /boot. Its maintenance 
is orders of magnitude easier to do when kernel version numbers are made 
irrelevant. The boot menu only needs changing when an installation is added 
or removed, not when yet another update has caused yet another kernel version 
number change.

> >                       (Had that been the case already, I might never have
> > participated in this thread.) Those containing numeric strings should be
> > sorted in descending order.

> That's what happens currently.

> >                            The rest should be sorted in ascending alpha order.

> Why? Because in English "cur" sorts before "prev"? And if other
> language translations sort differently?

-cur and -prv were selected because of how they sort, in English, the only 
language I know and work with. If I wanted reverse sort I might have selected 
-latest and -earlier or something else.

> >       I would prefer all symlink stanzas be grouped before realname stanzas
> > whenever the titles can be made sensible.

> And I prefer to use vmlinuz-$version :)

I have hundreds of kernels sprawled across more hundreds of partitions. The 
particular numeric component is only occasionally useful for comparing to 
something non-local, like to see if a match to the newest on an updates 
mirror. Otherwise, I mostly only care where one ranks in newest to oldest 
sequence, with no regard for the numbers themselves. With the strange way 
numbers are mixed with hyphens and periods in kernel versions, I'd really 
rather never need see those numbers.

> If you want to manage grub.cfg yourself, it is really easy. In
> default case of /boot and /boot/grub(2) being on the same filesystem
> (which likely covers 99% of all use cases) $root is already set
> correctly for you by grub-install and core.ing already incudes
> everything needed to access /boot. Which reduces "unfathomable" grub.cfg
> to trivial

Your use of $root here thwarts my understanding of what I wrote that you are 
responding to.

> menuentry --title ... {
>    kernel /vmlinuz-whatever-name whatever kernel options
>    initrd /initrd-name
> }

> Just disable /etc/boot.d/10_linux and maintain /etc/grub.d/40_custom
> manually. Or add 05_my-symlinks which contains menu entries for your
> vmlinuz-first, vminuz-second ... in order you like them, which will
> always come before standard ones.

Just this, just that, just about everything is diametrically different from 
Grub Legacy. Just keep using Grub Legacy seems simpler than trying to figure 
out why so many files in /etc/grub.d/ and whose job it is to do what with which.

> One think that could be improved in default script set is symlink
> handling. Something like

> GRUB_SYMLINK_HANDLING=(prefer|resolve)

> GRUB_SYMLINK_HANDLING=resolve would complement above nicely without need
> to disable standard scripts. Does it make sense?

I really don't think I understand enough yet to answer. Prefer what? Resolve 
what? And why yet another string starting with GRUB_ in a configuration file 
for Grub named grub? Why not just SYMLINKHANDLING? Is it any wonder comments 
like ending of 
http://lists.opensuse.org/opensuse-factory/2013-02/msg00072.html are common?
--
"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/