Pavel Roskin schrieb:
Suppose I have Linux 2.6.29 and 2.6.28. Your script makes entries for
"Linux default" and "Linux 2.6.28". Then I install Linux 2.6.30 and
don't run grub-mkconfig. Then I can boot Linux 2.6.30 and 2.6.28 form
the menu, but not 2.6.29.
Even if I run grub-mkconfig, there is still something I lose. By
selecting "Linux default" I still don't know it it's Linux 2.6.30 or
something else.
For me, the convenience of not having to rerun grub-mkconfig doesn't
outweigh the convenience of knowing what I'm loading.
I know, it's have to argue about preferences, but if you want you
changes to be accepted, you need to present a good case.
It's also that kind of discussion which eventually separates the wheat
from the chaff. Thus I welcome it.
I would consider placing the kernel pointed to by the vmlinuz link to
the first position of the Linux kernels. Another approach would be to
have an entry for the link without suppressing any versioned entries.
Ok, I understand and if it is a preference why don't make it a
preference. :)
You can find attached a new version of the patch, which per default
will read the symlink and create an entry for the target, not the
symlink. You can change this behaviour with
"GRUB_USE_LINUX_SYMLINK=yes". If you define this environment variable
with that value, it will use the behaviour I implemented before. This
means it uses the symlink and ignores the kernel the symlink is
currently pointing at.
I think this is the best solution, because it prevents duplicated
entries (only one entry for symlink or symlink target) and it gives
the user the choice which behaviour he wants (rerun of grub-mkconfig
needed or not needed).
Is that solution all right?
Please specify where those names are used. Can you give the
distribution name and version where such names are used?
Zenwalk, Slackware for example. I think more Slackware derivates are
using it too.
Let's add support for more versioned names first. That should be rather
non-controversial.
I see no more versioned names which could be added for the existing
extension(s). There is initrd-<version>.<ext> and
initrd.<ext>-<version>. Whereas <version> can either be $version or
$alt_version and <ext> can be "img" or "gz" ("gz" is new) and at the
very end as a last resort initrd.img initrd.gz and initrd.splash are
tried in that order (that's also new). Roughly speaking only new
fallback options.
Do you see a problem there or do you have a concrete versioned name to
add?
Andreas