All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas <futur.andy@googlemail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] prevent duplicated entries due to symlinks
Date: Mon, 04 May 2009 18:45:50 +0200	[thread overview]
Message-ID: <49FF1BBE.4090001@googlemail.com> (raw)
In-Reply-To: <1241411539.26483.42.camel@mj>

Pavel Roskin schrieb:
> On Fri, 2009-05-01 at 22:51 +0200, Andreas Born wrote:
>   
>> If there's both a symlink and a kernel at which the symlink is pointing 
>> in the list of detected kernels of 10_linux, two entries are created for 
>> actually the same kernel. This patch checks for this condition and only 
>> uses the symlink (usually the wanted behaviour), in case the target of 
>> the symlink doesn't exist, it uses neither.
>>
>> Furthermore there may be kernel images named e.g. /boot/vmlinuz, so to 
>> detect those the patch doesn't require a hyphen in the kernel name.
>> In this case the sed used to determine the kernel version, won't return 
>> as expected an empty string. Therefore I replaced it by another one with 
>> the wanted behaviour.
>> If the kernel version can be empty we don't want to have a "GNU/Linux, 
>> linux " menuentry. Accordingly this patch adds a check for empty kernel 
>> version, so that only "GNU/Linux" will be displayed.
>>     
>
> The result will be that we would have an entry without version instead
> of an entry with a version.  That's hardly an improvement.  Can you give
> an example where it would be useful?
>   
You have a symlink named /boot/vmlinuz which points at the current 
kernel version. Now you could of course find out which kernel version 
it's pointing at but that version could change anytime. /boot/vmlinu[zx] 
and /vmlinu[zx] (there should only exist one of them) are the only cases 
I can think of which have no version in their name. So you always know 
that the version-free entry always boots the kernel pointed at by 
/boot/vmlinuz, which is always the current kernel if your distro 
maintains the symlink. I see no regression there.
This is for example my Zenwalk boot entry:
'menuentry "Zenwalk GNU/Linux" {
    set root=(hd0,3)
    search --fs-uuid --set 408e3e53-d766-4592-bb12-31233bd415c0
    linux16    /boot/vmlinuz root=/dev/sda3 ro  splash=silent 
resume=/dev/sda7 vga=794
    initrd16    /boot/initrd.splash
}'
That's the symlink: /boot/vmlinuz -> vmlinuz-2.6.29.2


>   
>> Finally there's quite a bunch of other names for initrds. This patch 
>> adds support for initrd.gz and initrd.splash. Both initrd.img and 
>> initrd.gz become or were yet supported with two different version 
>> positions and without version at all. For initrd.splash this isn't 
>> needed because it's not kernel version dependent.
>>     
>
> 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.
> What is initrd.splash?  Why does it need to be handled like initrd and
> why is it always version independent?  Again, where is it used?
>
>   
initrd.splash is used by Zenwalk (others too) it contains only the data 
of one or multiple bootsplashes as returned by the "splash" command. 
It's used by bootsplash and doesn't contain any files, modules, etc.
The version independence is quite self-explaining now, I think. Unless 
bootsplash support was removed it works for any kernel version. And even 
if bootsplash support is removed it does no harm to load it.

Is it understandable now?

Andreas




  reply	other threads:[~2009-05-04 16:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-01 20:51 [PATCH] prevent duplicated entries due to symlinks Andreas Born
2009-05-04  4:32 ` Pavel Roskin
2009-05-04 16:45   ` Andreas [this message]
2009-05-04 21:13     ` Pavel Roskin
2009-05-05 21:11       ` Andreas Born
2009-05-09 22:20         ` Andreas
2009-08-18 18:01           ` Pavel Roskin
2009-08-18 19:19     ` Michal Suchanek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49FF1BBE.4090001@googlemail.com \
    --to=futur.andy@googlemail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.