From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1U7sLY-0007Ux-Gl for mharc-grub-devel@gnu.org; Tue, 19 Feb 2013 13:55:20 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7sLO-0007MU-KQ for grub-devel@gnu.org; Tue, 19 Feb 2013 13:55:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7sLD-0000om-Mm for grub-devel@gnu.org; Tue, 19 Feb 2013 13:55:10 -0500 Received: from [50.115.112.57] (port=27334 helo=slmp-550-94.slc.westdc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7sLD-0000oH-D7 for grub-devel@gnu.org; Tue, 19 Feb 2013 13:54:59 -0500 Received: from c-24-9-205-42.hsd1.co.comcast.net ([24.9.205.42]:49586 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 1U7sLB-0034DL-Jw for grub-devel@gnu.org; Tue, 19 Feb 2013 11:54:57 -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: Date: Tue, 19 Feb 2013 11:54:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54D468CC-529B-4D23-A6AB-32756030F63A@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> <6F446F2C-5CEE-4516-8F03-5B6F16AEA251@colorremedies.com> To: The development of GNU GRUB 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:55:18 -0000 On Feb 19, 2013, at 1:43 AM, Michael Chang wrote: > 2013/2/19 Chris Murphy : >>=20 >> It's also untrue. GRUB can first load a grub.cfg pointing to the = grub.cfg of each distribution; those distribution specific grub.cfg's = are updated by those distributions. The first grub.cfg only needs = updating when a distribution is added/subtracted - which is no different = than what you'd have to do with the first boot loaders config if you = were chain loading to a 2nd bootloader rather than to merely a = configuration file. >=20 > This is based on assumption that all foreign distribution must > maintain a grub.cfg which is not true. The context was GRUB, so yes I'm assuming GRUB configuration files in = this case. But GRUB2 can still do what most other boot loaders can't = which is read pretty much any common file system out there, and even = find boot files on md raid and lvm. It can chain load the distribution's = unique boot loader by reading the file system its on. Blocklists, VBR = boot sectors, are still not needed. > If they offer options of other > bootloader than grub2 why bother them to maintain grub.cfg ? I'm not suggesting that distributions be required to play nice in the = multiboot sandbox. But if they want to be cooperative, they might = actually have to cooperate somehow. Doesn't seem totally surprising to = me. >> Name something you can only do via chainloading that you cannot do by = keeping a singular >> primary boot loader up-to-date. > Some people who use standard mbr boot code to manage their booting,. > The reason they would like to keep that old practice is they don't > want to bet their destiny on any primary bootloader of any > distribution as it fails for whatever reasons would render your entire > system un-bootable. They could still booting to other distribution via > togging the active flag and perform the rescue of data. It meets my vague and loose requirements, but the failure is an edge = case. And it's fine there are tools that help people with their edge = cases. But this work around to regain bootability requires esoteric = knowledge on the part of the user (in addition to being an edge case for = it to occur). The probability of both happening at the same time, is = low. I don't think this is a case of good design. There's also still a = single point of failure, LBA0. It's not as if the risk of rewriting = those 512 bytes is zero, just to change the active flag. I don't see how = the probability of boot loader failure is meaningfully reduced. Chris Murphy=