From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1U7sMd-0007z7-1A for mharc-grub-devel@gnu.org; Tue, 19 Feb 2013 13:56:27 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7sMU-0007wa-Bb for grub-devel@gnu.org; Tue, 19 Feb 2013 13:56:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7sMO-0001VQ-2t for grub-devel@gnu.org; Tue, 19 Feb 2013 13:56:18 -0500 Received: from [50.115.112.57] (port=12237 helo=slmp-550-94.slc.westdc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7sMN-0001V3-Pt for grub-devel@gnu.org; Tue, 19 Feb 2013 13:56:12 -0500 Received: from c-24-9-205-42.hsd1.co.comcast.net ([24.9.205.42]:49589 helo=mingisapsycho.hsd1.co.comcast.net) by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U7sML-0034kE-0c; Tue, 19 Feb 2013 11:56:09 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: GRUB and the risk of block list corruption in extX From: Chris Murphy In-Reply-To: <51233C23.1040602@ts.fujitsu.com> Date: Tue, 19 Feb 2013 11:56:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E67E80F-8B05-4465-B70C-5FF1BB9FEEC0@colorremedies.com> References: <51138645.4050405@ts.fujitsu.com> <51153345.2020509@ts.fujitsu.com> <0088990F-66E5-4F51-A9C4-3BD8963A6DA0@colorremedies.com> <512261FE.2090604@ts.fujitsu.com> <51233C23.1040602@ts.fujitsu.com> To: The development of GNU GRUB , Martin Wilck X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - colorremedies.com X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id: whatever@colorremedies.com X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 50.115.112.57 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 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: Tue, 19 Feb 2013 18:56:25 -0000 On Feb 19, 2013, at 1:47 AM, Martin Wilck = wrote: > Chris, >=20 >> Effectively you're asking for indefinitely supporting GRUB 0.9, by = requiring other dependencies so that can happen. >=20 > The only other dependency I am asking for is the ability for the = distro > boot loader to be installed in the root or boot partition. That's not = much. You're asking for more than you apparently realize. You said you wanted = to be able to support KlingonFS, but your idea can't do this alone. I = already used XFS as a real example file system that will not be bootable = using your idea, and I see it as conclusive proof of a fundamentally = broken concept. If you want new file systems to support booting, then the primary boot = loader needs to be able to understand that file system.=20 Next, your idea requires the installer UI code to check the target file = system before installing the boot loader. Every file system has a = different location for this blocklist or boot loader code, there is no = standardization. And in the case of XFS, this test fails and now you = need extra UI code to indicate to the user that installing to an XFS = partition isn't supported. And you need code that warns the user that = even though a boot loader is being installed, that the installed system = won't be bootable out of the box because the 1st boot loader doesn't = know about the 2nd. And all of this needs to be tested. Instantly you're talking about *dozens* of people, dozens of hours of = coding and testing. And this is because you don't want to type = grub2-install --force. I don't understand how you think a GUI installer = enabled to install in root/boot is "not much" and yet for you to type = --force is too much? > The biggest argument for Fedora not being able to do this has been the > claimed danger of block list corruption. The biggest argument is: https://bugzilla.redhat.com/show_bug.cgi?id=3D872826#c10 > That's the only aspect of this discussion that is worth bothering the > GRUB developers with. The validity of my use case should be discussed > elsewhere. anaconda-devel-list@redhat.com Chris Murphy=