[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: Wed, 06 Feb 2013 02:27:23 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 SeaMonkey/2.15.2

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 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=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 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  ***

reply via email to

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