From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1U7fLM-0002rU-Jq for mharc-grub-devel@gnu.org; Tue, 19 Feb 2013 00:02:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7fLJ-0002rE-V4 for grub-devel@gnu.org; Tue, 19 Feb 2013 00:02:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7fLI-0004fW-HH for grub-devel@gnu.org; Tue, 19 Feb 2013 00:02:13 -0500 Received: from mail-lb0-f174.google.com ([209.85.217.174]:49657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7fLI-0004fC-8O for grub-devel@gnu.org; Tue, 19 Feb 2013 00:02:12 -0500 Received: by mail-lb0-f174.google.com with SMTP id l12so4720766lbo.5 for ; Mon, 18 Feb 2013 21:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=DZFtTprk0eHWgFSdCj4+xru445UhnseN9lb0JyblcfE=; b=SCJj/TFcBbL9rSjuwkMP/mDlnZbAUuwHLF/eQr5oaTLqyCJcwcT1bqrrRB+16ClBLm esSvFS+A0uCxnVui1PLmw3xHxjPSq0J4zGWlT6f8txnn/Nq7FTHhoPt3ZxGqwonR6kem b1YVnXMys0nvxUAEyc6j7/L9E0kWnpCHbJlbR9XOtaRoXBMFlJCURRfeVPjTzXPmLVnB bb/8qHSeH7mY7fxo4hJ+2MY6onefA6Mv0ZVV6mwyMdTD2w7WSotLHPUwAea07Y5I8PTl diY4OAjG+JvCWB6LnOZSjZwOFt7fZFvubjCQNRtv6dmRBI3wxG9T0JU4/WvDkOaQt6zK WdjA== MIME-Version: 1.0 X-Received: by 10.112.43.38 with SMTP id t6mr6192649lbl.69.1361250130365; Mon, 18 Feb 2013 21:02:10 -0800 (PST) Received: by 10.112.43.230 with HTTP; Mon, 18 Feb 2013 21:02:10 -0800 (PST) In-Reply-To: References: <51138645.4050405@ts.fujitsu.com> <51153345.2020509@ts.fujitsu.com> <0088990F-66E5-4F51-A9C4-3BD8963A6DA0@colorremedies.com> <512261FE.2090604@ts.fujitsu.com> Date: Tue, 19 Feb 2013 09:02:10 +0400 Message-ID: Subject: Re: GRUB and the risk of block list corruption in extX From: Andrey Borzenkov To: The development of GNU GRUB Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.217.174 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 05:02:15 -0000 On Tue, Feb 19, 2013 at 1:07 AM, Chris Murphy wrote: > > Chainloading was never a good idea, it was the only idea for supporting multiboot on hardware with a brain dead BIOS that was never designed with multiboot in mind. > Chainloading is actually the only sane way to do multiboot. While it may have started due to BIOS limitations, today chainloading is simply passing control to another bootloader. If you want to have "master" bootloader that loads everything else, you have to ensure that when "something else" changes, it is reflected in master bootloader configuration. That's unrealistic. You do not go and run os-prober in chroot on every other Linux you may have when you install additional kernel. I have test VM with Windows/Fedora/openSUSE. I installed openSUSE after Fedora. Wanna guess if openSUSE kerenls are present in Fedora grub.cfg? > Name something you can only do via chainloading that you cannot do by keeping a singular > primary boot loader up-to-date. This requires close cooperation between *all* installed OSes that is simply not going to happen. Oh, and how to you add options for Windows loader to you primary grub2 bootloader? > Chainloading is a relic of BIOS limitations. It's a relic of boot sectors. That's not how things > work with UEFI. The way forward is precisely the end to chainloading. Huh? EFI has master bootloader which *chainloads* other bootladers. If anything, this is "chainloading made right".