From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OlsaN-0005WE-Sr for mharc-grub-devel@gnu.org; Wed, 18 Aug 2010 20:02:23 -0400 Received: from [140.186.70.92] (port=55010 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OlsaK-0005W0-5m for grub-devel@gnu.org; Wed, 18 Aug 2010 20:02:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OlsaI-0003Bj-U3 for grub-devel@gnu.org; Wed, 18 Aug 2010 20:02:20 -0400 Received: from mail-gx0-f169.google.com ([209.85.161.169]:42680) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OlsaI-0003BW-Rm for grub-devel@gnu.org; Wed, 18 Aug 2010 20:02:18 -0400 Received: by gxk9 with SMTP id 9so546071gxk.0 for ; Wed, 18 Aug 2010 17:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QfhyPpzDVqVjOKA6NSh5/xtE6CFdODQiwZJFGChlnTc=; b=PssMdu1udIJgNY6gEgPcnD7ZwvU2tiGqTGFH2yGI7BUFQGso7dt4LYqdSTYWmY49I3 cxLkQ7fVkIMK1CON8P10LRC5zzu67C61A7e98mz8iFzCqRix2rYCGjVSDlTIOl/hwNUn L5QgZ2FtF/a0QTZ7/c/8mwgT59ESDi2n9MiQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=LoP+CKm0fLY330SC8wb8YTv9BUVVU6PJMJDfHuRLmwAFiP5Gtb9M3MwyA+uNtGbhVw gBcQxk6igVD7kUvHBLsxPOSf/mis3klIoL9VzgCImSuAlEh/VK4DqSLfZ28zDrdSMBvi 0rRLihX2CJjsjZY64q1Kors2Zx/iSYomIu4no= Received: by 10.100.124.4 with SMTP id w4mr10311561anc.140.1282176137816; Wed, 18 Aug 2010 17:02:17 -0700 (PDT) Received: from [192.168.0.75] (cpe-24-174-180-111.satx.res.rr.com [24.174.180.111]) by mx.google.com with ESMTPS id t30sm1237143ann.27.2010.08.18.17.02.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 17:02:16 -0700 (PDT) Message-ID: <4C6C7487.9010802@gmail.com> Date: Wed, 18 Aug 2010 19:02:15 -0500 From: Bruce Dubbs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080722 SeaMonkey/1.1.11 MIME-Version: 1.0 To: The development of GNU GRUB References: <4C698F9F.1080609@post.cz> <20100818144402.GD2632@caffeine.csclub.uwaterloo.ca> In-Reply-To: <20100818144402.GD2632@caffeine.csclub.uwaterloo.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: my thoughts about grub 2 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 00:02:21 -0000 Lennart Sorensen wrote: > grub2 is multi architecture, modular, extendible, and much more robust > than grub1. The fact it no longer depends on any block maps to work is > a great thing. The fact it uses modules to build the required features > in and loads any others needed on demand means it can support a lot more > filesystems than grub1 since grub1 would have gotten too big adding all > those features. I agree with your general comments, but at the same time think grub2 is suffering form a severe case of feature-itis. Just because something can be done, doesn't mean is should be done. For example, I've never seen a real need for a boot loader to work with software raid. Users can very easily create a separate non-raid partition in a reasonably common format and boot from that. Is there a real need for the boot partition to be encrypted? In the effort to be complete, the whole thing has become very complicated. > Sure grub1's config was simple and the syntax had a lot less in it, but it > was also limiting the ability to add new features. Now for debian users, > they already had an update-grub command that generated the grub config > file for them, so going to grub2 really doesn't change anything from the > users point of view, unless they happen to want to custize something. And if you have some non-debian kernels, that are not recognized either grub.cfg or an intermediate shell script needs to be edited manually. I'd rather edit grub.cfg myself and have the distros keep away from grub.cfg. > Now those customizations happen in /etc not /boot/grub/menu.lst. That's > actually a good thing, since all config SHOULD be in /etc, not /boot. > So grub1 was actually the one that was doing the wrong thing before. Using /etc only applies to Unix-like operating systems. If you *are* in a Unix-like OS, just put a symbolic link into /etc. > Isn't native mdraid, lvm, dmraid, piles of filesystems and multi > architecture support worth it? How about multiple partition table types > (disks or raids over 2GB don't work with msdos partition tables after all, > and grub2 supports EFI style GPT partition tables.) I'm afraid I don't agree. Too many options leads to complications. A boot partition does not need all those specialized partition types. Even a graphical interface is overkill when the vast majority of users will only be in the boot screen 10 seconds or less waiting for a timeout for the default boot. For really novice users, just set the timeout to zero and skip the boot screen completely. > So how does installing a new kernel update the boot loader then if it > is only configured by itself? That's why they invented emacs and vi (or ed). For me to add a new kernel means that I need to add basically two lines to grub.cfg. For many users though that's way too much. However, once a user has a working configuration, the only thing that should happen is for the distro to add a file to a directory with a menuentry entry. I don't need or want a customized boot screen for Debian, or Ubuntu, or Red Hat, or SuSE. -- Bruce