From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1M15TY-00079c-4k for mharc-grub-devel@gnu.org; Mon, 04 May 2009 17:13:24 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M15TW-00078K-3y for grub-devel@gnu.org; Mon, 04 May 2009 17:13:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M15TR-00075H-NJ for grub-devel@gnu.org; Mon, 04 May 2009 17:13:21 -0400 Received: from [199.232.76.173] (port=59265 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M15TR-00075A-D2 for grub-devel@gnu.org; Mon, 04 May 2009 17:13:17 -0400 Received: from c60.cesmail.net ([216.154.195.49]:50713) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1M15TR-0002xF-0o for grub-devel@gnu.org; Mon, 04 May 2009 17:13:17 -0400 Received: from unknown (HELO smtprelay2.cesmail.net) ([192.168.1.112]) by c60.cesmail.net with ESMTP; 04 May 2009 17:13:11 -0400 Received: from [192.168.0.22] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by smtprelay2.cesmail.net (Postfix) with ESMTPSA id D275E34C6D for ; Mon, 4 May 2009 17:12:06 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <49FF1BBE.4090001@googlemail.com> References: <49FB60BE.7090806@googlemail.com> <1241411539.26483.42.camel@mj> <49FF1BBE.4090001@googlemail.com> Content-Type: text/plain Date: Mon, 04 May 2009 17:13:14 -0400 Message-Id: <1241471594.9047.28.camel@mj> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 (2.26.1-2.fc11) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] prevent duplicated entries due to symlinks X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:13:22 -0000 On Mon, 2009-05-04 at 18:45 +0200, Andreas wrote: > Pavel Roskin schrieb: > > 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. I see, you want to support loading the "default" kernel, i.e. the one pointed to by the symlink. This way, re-running grub-mkconfig won't be necessary if a new kernel is installed. > /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. 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. 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. > > 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. > > 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? It's quite strange that some distro would use the initrd functionality purely for eye candy. But if that's true, I'm fine with using initrd.splash as the last resort if no other initrd image is found. -- Regards, Pavel Roskin