From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1U7avk-00061f-Bk for mharc-grub-devel@gnu.org; Mon, 18 Feb 2013 19:19:32 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7avg-0005r2-Fl for grub-devel@gnu.org; Mon, 18 Feb 2013 19:19:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7ave-0004oR-Hy for grub-devel@gnu.org; Mon, 18 Feb 2013 19:19:28 -0500 Received: from [50.115.112.57] (port=31950 helo=slmp-550-94.slc.westdc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7ave-0004mx-8E for grub-devel@gnu.org; Mon, 18 Feb 2013 19:19:26 -0500 Received: from c-24-9-205-42.hsd1.co.comcast.net ([24.9.205.42]:62876 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 1U7Xvd-000Pa9-2g for grub-devel@gnu.org; Mon, 18 Feb 2013 14:07:13 -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: <512261FE.2090604@ts.fujitsu.com> Date: Mon, 18 Feb 2013 14:07:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51138645.4050405@ts.fujitsu.com> <51153345.2020509@ts.fujitsu.com> <0088990F-66E5-4F51-A9C4-3BD8963A6DA0@colorremedies.com> <512261FE.2090604@ts.fujitsu.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 00:19:30 -0000 On Feb 18, 2013, at 10:16 AM, Martin Wilck = wrote: > Using chainloading has the advantage that the primary bootloader (it's > indeed GRUB 0.9x in my case) doesn't have to understand the more > advanced filesystems of newer distros. Updating your boot loader has the advantage that you don't need two boot = loaders to do what one can do. You haven't explained why GRUB2 can't be = your primary boot loader. > It's no problem to boot a btrfs > distro in this way, and when Fedora 31 comes out with KlingonFS as > default filesystem, my stupid Grub 0.9X will still be able to = chainload > it, as long as KlingonFS supports embedding a boot loader in its > partition header. Effectively you're asking for indefinitely supporting GRUB 0.9, by = requiring other dependencies so that can happen. If GRUB 0.91 hadn't added XFS support explicitly, it would be impossible = to boot from XFS using chainloading because XFS doesn't have a boot = sector. There's no place to put the blocklist. The way to support = booting from new file systems isn't to require those file systems have = specific features to enable chainloading, but to keep the boot loader up = to date so it knows how to traverse that file system natively. 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. > Fedora 18's GRUB2 will not be able to do that using a > secondary "grub.cfg", unless someone backports a KlingonFS module for = it > (fortunately, GRUB2 would be able to chainload, too). This is such a nonsense, red herring argument. There aren't new file = systems popping up every 6-12 months. And who cares about Fedora 18's = GRUB2 in another 6 years when there is yet another new file system? It = should have been upgraded or replaced well before then. 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. Not making it easier to do. >=20 > I like the fact that GRUB2 is able to detect foreign installations and > offer auto-generated boot menu entries for them. But there are some > scenarios for which the primitive chainloading mechanism is better = suited. Name something you can only do via chainloading that you cannot do by = keeping a singular primary boot loader up-to-date. And then state why 'grub2-install --force' on your own is inadequate. = Why should GUI installers literally encourage users to not upgrade their = primary boot loader? That objectively seems like a bad idea to me, bad = advice. If people want to enable a fundamentally flawed workflow like = chainloading, nothing prevents it. The tools are there, right now, to = let you do what you want. But to make it easy for the typical user who = has no idea what a bad idea it is to be using a 6 year old unmaintained, = unsupport boot loader, is like giving them razor blades and telling them = to go play on the free way. It's cruel. And it's bad advice. >=20 >> If the enhancement in bug 886502 were to happen, would this enable = your primary boot loader to find either Fedora's grub.cfg, or core.img = instead of depending on a blocklist? >>=20 >> https://bugzilla.redhat.com/show_bug.cgi?id=3D886502 >=20 > As long as I install F18 on extX, yes. But as explained above, it > wouldn't be my preferred solution. I find the explanation uncompelling. If you find GRUB2 overly bloated = and complicated, then maybe you shouldn't expect your boot loader to = boot from new file systems; this isn't a required workflow. There's = nothing wrong with bootfs on FAT32 or ext[234] with syslinux or = extlinux, i.e. the kernel and initramfs go there, and then placing = rootfs on the more advanced file system. Chris Murphy