From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jn58x-0006Ot-65 for mharc-grub-devel@gnu.org; Sun, 21 Jun 2020 14:56:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48464) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jn58v-0006Ok-3o for grub-devel@gnu.org; Sun, 21 Jun 2020 14:56:37 -0400 Received: from orion.archlinux.org ([2a01:4f8:160:6087::1]:43956) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jn58s-0003mb-C2 for grub-devel@gnu.org; Sun, 21 Jun 2020 14:56:36 -0400 Received: from orion.archlinux.org (localhost [127.0.0.1]) by orion.archlinux.org (Postfix) with ESMTP id 12AE81D0E869F8 for ; Sun, 21 Jun 2020 18:56:26 +0000 (UTC) X-Spam-BL-Results: Received: from [IPv6:2600:1700:57f0:ca20:763a:c795:fcf6:91ea] (unknown [IPv6:2600:1700:57f0:ca20:763a:c795:fcf6:91ea]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: eschwartz) by orion.archlinux.org (Postfix) with ESMTPSA id 711331D0E869D9 for ; Sun, 21 Jun 2020 18:56:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=archlinux.org; s=orion; t=1592765785; bh=muoRhWpGcJDlBMtds9P+nCTsT84hkNQiMht4ZH0crvo=; h=Subject:To:References:From:Date:In-Reply-To; b=tKB51nJQMpEwcQjOhGsVzm8lEh1oC0mg2AUSfzlZgSNkpdCkAcJIGOK0DbvpuX7tm X+VBVv9hz75dD/hKG8BHt+uBAQ80qN0Y68I2LnVwCtzC+G9QSxex/jzaLRER4gntWI GPoe0oWlGh205sOSQ32OYeX1R9a6yg0bEwXxDauIp0Vce8r+DGmcZHQxGne1deGOff mmWc8QUZoRpXOWzseQmoudRIUf5uIJlGABP5DrwO35Zj0ahXhVe60i+k6yVWS5EKaa P95xNkFW9RUDt//NsQ+/8866U7OHgb4mtGJ3v3zY0qjngz1+HE8+CD6SjX2Hr+W8Lq B8AvJBkOB3/+r9Cs+gWwMAh5ZuA5PdfEqOQP4eKfiVaOnjgIM9/kmBGV+AFHFhYiYd JviExt8HH+stN/6rQUt8qWTwgee6lSLXxhe3sDIo4fS1CcX5SxG4JkEivuuMB13/Zc HqjGnBDCRo+Kr2x8AsBMZKqGeTuHL5JaskvEQ4UlJ2J95WrJC+jXpTIu8adyFmZx4H 2+iE994uOb7frmaM6KwQOL0veTsJota6YMuLofFOvxZ6mCs2a6fFwfnM5sotWpfBgJ X6/sH5ygqjbiohKqm9wbQvoFmIvvKbHoovlwdvBO/AGmiU97QLOty1g8ODJZCYm7f+ /u9eGtwbUHmT38u+74CH7jYA= Subject: Re: [PATCH] btrfs: disable zstd support for i386-pc To: grub-devel@gnu.org References: <20191105091949.29559-1-mchang@suse.com> <20191107045504.GA4084@mazu> From: Eli Schwartz X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <6f2be4c8-e90a-d16a-1604-dacb1571cf8a@archlinux.org> Date: Sun, 21 Jun 2020 14:56:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Go9O4GCUtC3QGvK9nnd1HWAJfXPOEcukI" Received-SPF: pass client-ip=2a01:4f8:160:6087::1; envelope-from=eschwartz@archlinux.org; helo=orion.archlinux.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 18:56:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Go9O4GCUtC3QGvK9nnd1HWAJfXPOEcukI Content-Type: multipart/mixed; boundary="46U4Q0dRUoEV3US8YpKNQa0N9N5iQqfmc" --46U4Q0dRUoEV3US8YpKNQa0N9N5iQqfmc Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: quoted-printable On 6/21/20 2:26 PM, Mike Gilbert wrote: > On Thu, Jun 11, 2020 at 6:58 PM Eli Schwartz = wrote: >> >> On 11/7/19 12:08 AM, Vladimir 'phcoder' Serbinenko wrote: >>> On Wed, 6 Nov 2019, 20:55 Michael Chang, wrote: >>> >>>> On Wed, Nov 06, 2019 at 11:15:04AM -0800, Vladimir 'phcoder' Serbine= nko >>>> wrote: >>>>> Please don't do it this way. The right solution is to move it to se= parate >>>>> module and include zstd module when needed. >>>> >>>> I fully agree to work out a proper solution, but before that I think= it >>>> is necessary to stop it from spread out going forward, as the runnin= g >>>> system upgrading to new version could be affected and the consequenc= e is >>>> fatal - an unbootable system, qualified to be show stopper imho. >>>> >>> We don't do a release right now, so I don't think it's justified. Als= o >>> increase in size can easily come from a compiler. If an increase in s= ize >>> can make system unbootable on upgrade, I'd rather be fixing this than= just >>> pepper over it. >> >> Given grub 2.06 is on the horizon, is it time to re-evaluate this and >> disable something known to be badly broken? >=20 > If I have read the thread correctly, this only breaks if you try to > install grub in an undersized embedding area. This would really only > affect new grub installs; existing ones can keep using the currently > installed code. "changing grub only affects people who newly run the grub-install command" therefore it's not worth considering whether to make sure grub-install completes without errors? I don't comprehend this logic. Who ever suggested we care about people who aren't the target audience of new grub versions to begin with? But anyway this isn't true. There are valid reasons to reinstall grub on old systems, in which case you are most likely not benefiting from zstd support one way or another, but in this case, rerunning grub-install destroys the working bootloader code and fails to replace. https://bugs.archlinux.org/task/63656 our infrastructure apparently somehow ended up mismatching core.img and /boot modules, and had to rerun grub-install (it's not clear what happened exactly, possibly grub-install accidentally got rerun in a broken manner?) and then this remote server would not boot, and could not be fixed without hunting for the right old version of grub via the rescue system, reinstalling it, and using it to restore the boring (working) old pre-zstd bootloader code, after a lot of painful debugging. > I think it would be better to hold out for a real fix than to disable > a feature for an entire platform where only a subset of configurations > would not work. I'm astonished that "it's better to hold out for a real fix than to ensure users' systems actually work". Why is the benefit of enabling zstd support in situations where it very often breaks everything, worth more than the disadvantage of, in fact, breaking everything? The feature was broken out of the gate, no proper fix seems imminent, let's bandage the wound before more people get hurt. Better to not have a hot new feature than to have it, but be unable to bo= ot. --=20 Eli Schwartz Bug Wrangler and Trusted User --46U4Q0dRUoEV3US8YpKNQa0N9N5iQqfmc-- --Go9O4GCUtC3QGvK9nnd1HWAJfXPOEcukI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvSewel70XCra9w4EhIGKaBmvSpsFAl7vrVQACgkQhIGKaBmv Sps53RAAgfwV1W/Pun8rZuFJAyo8nSwHjUewdakGSYhIhilugzim0TXUOhHfZx1S 1F6DHp6YrUrI22FpG0RvCOObv/Tp2OBJ3sq4sOOcaU6ZDjBWoO3taMz3sldlJaoQ NRCs2ELXX48zkDso22MBcf6KqVNiYP4vmqk09NAR73QjeaxVejK5sszlGbdTaJfd RUg4GH8ojx+nuBu1MFYI1IN5luK14/DYCgcI5ixWAOOlJF2MUxXKGFNknx0EFw/Y FkWw6ebSzCflgNWejmVCN0wWEm4oUHNLD4ru6mzL9NNJveKNx6byetVGjHkVJiY4 pQu4HsdvCnFJxS02j8BcS15M7GiJwfxNH8oea9cbfku4C8LgM/d7geH/VUE6ZGMI FPIPC3RavMn37C66/jq1Kh/1PHWIjiYMo3G5QuOh9hS93GOSTp3xud7RkNlg+VTh Kz5lOPGFaIRHQVKQtVS/e76J0T2D1UVlvinnqPm5yEExzDNl/0TWhkly+/CSoN4J jAhzS2WgyCh7coFs9EHgs8qo+lNjoEUS+MiW1lFhIj6lIUtCvElAxKwXcetufAdc Ck349YAHJkxHc9yMR6sss9cJ/+yUQTo3G501opNvDjDKM/r28cfxyU9A2lGcpJbO go+t1XUnnpzKX7+ND4bnAfhaHuGE+RWui75H4/cg43h40Y1Y93OJAjMEAQEKAB0W IQRgQRMEwJ02YoNA7v/OsWfvtXIr1gUCXu+tVAAKCRDOsWfvtXIr1uoXD/sGYPEe 01fsluF+ujIykpCi0Az/xGRpL39vQCiBOa4pimrBJBOHoeyJoDGo7aqBHJC3UrWg KLIcWT0Fr5hZ993CAmBXXbhXk2O/vlE3adH7HqYykCT5ZimK2TM6tpVN2TE8rg37 rto4kQVx4DQQF5Tw+2US74wianRLs0n2CFBf4wEH9jC6uZjJojPceqRBL44qd5Op 2vQCtER84p2Hgc+3iVT4c/uKUKYWW+ockZ1hKQ9l2VaNPUAR5hJy9SdieRAnhDLx JXezdqGE5tFOmTNgrF5YOpJUifeDH1RI+EpqkhtEJUw/0ZAP9AGW6FXUDt1xbbPL Yz99TbJoTNllNrveFmmwkxEoLVwHaZXWpBTBV5O6Rr5AZ664umZtK5Ork3avkHNr qh4YW6/zU4VnhP18itoazBmU9MQ0xhDDx+yIeUqIg8YLJYezUIhFwEnNYs78GSDA gcQhW6zIK4BLMXKelrwDkTFZzK8HoqY4jUjS9dxTStaglv1VJvi6/8SL4J/jrGy1 orghPAynhHBlwCJCqslCPmA6leSxRXN8nPF0/O49w8Tw7K3Vqf8cX8Ih4B+2TpV5 f4JR72iYhxEufKx+ItwkKmpZmrP9WeqyXpOQaer/n7/QYxDkroIVGU6NY4CwhPyJ +EL/GhcU3bvogz4grsFuVNrf62ZM9oaI5olGiA== =kEpl -----END PGP SIGNATURE----- --Go9O4GCUtC3QGvK9nnd1HWAJfXPOEcukI--