From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KEa7i-0001oE-54 for mharc-grub-devel@gnu.org; Thu, 03 Jul 2008 21:30:06 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KEa7g-0001mg-La for grub-devel@gnu.org; Thu, 03 Jul 2008 21:30:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KEa7g-0001lz-2L for grub-devel@gnu.org; Thu, 03 Jul 2008 21:30:04 -0400 Received: from [199.232.76.173] (port=60120 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KEa7f-0001lr-U4 for grub-devel@gnu.org; Thu, 03 Jul 2008 21:30:03 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]:19776) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KEa7f-0006J0-Mr for grub-devel@gnu.org; Thu, 03 Jul 2008 21:30:04 -0400 Received: by ug-out-1314.google.com with SMTP id l31so1048502ugc.48 for ; Thu, 03 Jul 2008 18:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer; bh=SoSx4/i9aIE6BLqggktGeZIgv9jGfO7NJ09kSlGmQBo=; b=CeEGLAX9sB4dkjWXT2YsKihaF85pP0zMc8wOCc9Ejc3szSqvOO/8ggevwh7NBNSDf8 ugaz2gfH+zJWZY2XD8i2HS1v8rLkYwSyYGEUG/Hl+uCEYWzMbP9hixQLo0eD6q/xgWTT qUUlhi3sb343WODbeHpJj0pFq+MNRvjPl571A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer; b=QcYc+aEkoT9BDp2TrVXjXneaEj8GcVv0bM4WeP8iGSDa3KueG2+2xqMPSSvD1Mrul9 AmimvawQfPkef3nmyzt3/hPk27TbPR1KwOs7UATApzO1CD0PEBm887mQj9gTcGAf4tnM e943VW3ngQyozTBVU146gXnDPV+m3F12k2H2k= Received: by 10.66.218.15 with SMTP id q15mr2134862ugg.77.1215135002318; Thu, 03 Jul 2008 18:30:02 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id j33sm1282126ugc.32.2008.07.03.18.30.00 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Jul 2008 18:30:01 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <20080704000829.GE4074@thorin> References: <20080701160827.GF6985@thorin> <1214929545.13432.19.camel@dv> <1214937759.9353.64.camel@localhost> <20080701204816.GA31206@thorin> <1214954927.9353.91.camel@localhost> <20080702142245.GA21064@thorin> <1215027160.9353.125.camel@localhost> <20080703140211.GA19341@thorin> <1215104875.8123.23.camel@localhost> <20080704000829.GE4074@thorin> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yy7YFgu0ubS/N85tHMh+" Date: Fri, 04 Jul 2008 03:20:32 +0200 Message-Id: <1215134432.26019.42.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Subject: Re: grub-probe detects ext4 wronly as ext2 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2008 01:30:04 -0000 --=-yy7YFgu0ubS/N85tHMh+ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El vie, 04-07-2008 a las 02:08 +0200, Robert Millan escribi=C3=B3: > On Thu, Jul 03, 2008 at 07:07:55PM +0200, Javier Mart=C3=ADn wrote: > > > The question here is whether we should increase complexity with inter= faces > > > that don't provide any usefulness to the user, just to make it easier= to > > > do potentially dangerous things. If a user understands the implicati= ons > > > and really doesn't mind making her system bootability unreliable, the= n she > > > should have no problem modifiing the source to do it. > > The system bootability is already unreliable with the current code, >=20 > You mean because grub-probe is not conservative enough when determining w= hether > a filesystem can be accessed? I think we agreed that this needs fixing. Indeed, grub-probe should adopt the most conservative stance possible so that real GRUB works on minimum assurances. However, I meant reliability was compromised because grub-probe, as currently used by grub-install on i386-pc, only checks the availability of the filesystem GRUB will boot from. Thus, if GRUB is installed on a normal ext2/fat/whatever partition and the OS kernel we will boot (or another file we want to use) is stored in an ext4 partition, the most likely output of our current scheme is an error from the ext2 driver (ranging from an error message to a crash), because in its current best-effort policy it ignored the "forbidden" signs in the superblock and tried to read the ext4 partition as ext2. >=20 > > and > > as I already explained, it will be unreliable as long as the filesystem > > drivers use the "best-effort" politics you support. >=20 > If grub-probe says "you can't rely on this filesystem being readable by > GRUB", then we're bound to that. You don't make it any more reliable by > adding user input into the equation. As I said, there are setups in which (the current use of) grub-probe does not add any reliability, because it just checks the GRUB boot partition, not those with the kernels we might load (and I'm not proposing instituting such checks). >=20 > When I talk about real GRUB being "best-effort", it's not reliability tha= t > is at stake here; we already got that from grub-probe. This is a minor > problem IMHO; it's just about having read access to as many filesystems > as possible (other than the one we need for booting) vs not risking > corruption during data read. I seriously think we're wasting our time > here. Really, it's not worth it. This whole discussion is not about how > we engineer a new feature or solve a bug, but about how we deal with a > _temporary_ limitation in our code. It is both a temporary limitation and a permanent one: the limitation of not being able to read ext4 extents and such is temporary indeed, but I already said why we cannot just ignore the "incompat" field. Today is ext4, tomorrow it will be something else. As I mentioned above, such flags are huge warning signs telling us not to dare enter the partition if we don't know what to do with them. >=20 > > I'm just proposing > > that we change the default politics in the bootloader to "nearly > > conservative" and then having an user-controllable option to enable > > "best-effort" behaviour. I've had GRUB since at least 2004, and I've > > done a few nasty things in its command line from the start; but only no= w > > I feel comfortable enough to modify its source, so don't assume that a > > knowledgeable/advanced user will be brave enough to modify the source o= f > > his _bootloader_ just like that. I don't understand why you're so > > adamant against sensible defaults AND the possibility of a rational, > > free choice. >=20 > Because it's a gratuitous increase in complexity of the user interface. = It's > a choice about a bug, which is due to be fixed, and for which an informed > answer will always be the same. As I said before, we can fix the "ext4 compatibility not implemented" bug, we WILL eventually encounter _another_ "incompatible" feature, and then another... We can't be in par with the evolution of extN filesystems! >=20 > > > This looks like a more general problem. I wonder if we should really= address > > > it at the filesystem level. e.g. the filesystem could be perfectly f= ine but > > > the files in it went corrupt; if the data you're reading is corrupt,= does it > > > matter at which point it was corrupted? > > It does, if the data on disk is not corrupted and our filesystem driver > > reads wrong data because in its "best-effort" trials to read the data i= t > > forfeits the "specification"-mandated behaviour of aborting on finding > > incompatible feature flags. We would be INTRODUCING errors in the data, > > instead of just reading erroneous data because of a crash or something > > like that. >=20 > When the problem is you've read corrupt data, and you have to handle this > gracefuly, it doesn't make any difference that it was your fault because > you violated a spec, it's still the same problem. Fine, then. Let's _not_ worry about automatically trying to read what we cannot, violating standards and such. After all, GRUB _is_ better than Internet Explorer. It _does_ make a difference because we can avoid it being our fault if we just obey the huge warning signs in the superblock! If the user specifically requests us to try and read the partition even though the superblock tells us not to, then we proceed and whatever happens is, at least in part, his fault, even though this does not completely exonerate us for not having a completely up-to-date filesystem driver. > > I'm finding this discussion increasingly unproductive >=20 > Hey, at least we agree on something :-) >=20 As I threatened in my last post, here is the full patch, with the incompatible features detection and the user override option, for a total of +168 bytes in i386. It works like this (test was on a QEMU VM, with GRUB booting from floppy and hda1 being an ext2 part turned ext4): grub> ls (hd0,1)/ error: unknown filesystem grub> set ext2_options=3Dignore_incompatible grub> ls (hd0,1)/ lost+found/ grub/ Godfather.wav vmlinuz-2.6.24-16-server (&more) grub> linux (hd0,1)/vmlinuz-2.6.24-16-server [Linux-bzImage, setup=3D0x2a00, size=3D0x1e26d8] grub> hexdump (hd0,1)/Godfather.wav (shows 256 bytes of zeros instead of the actual contents) Of course, the new file (with extents) was the Godfather tune, while the kernel was an old extentless file. Trying to "play" the file crashed QEMU (I suspect that meant a triple fault happened in the simulation?) That was it. I will post no more in this thread. Do whatever you please with the patch - I'll just request some more people from the GRUB dev team to review the thing, instead of the tennis match we've had here (and I appreciate all matches, even the ones I lose). --=-yy7YFgu0ubS/N85tHMh+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUASG164KSl+Fbdeo72AQKd3BAAh4jFsLpNCtUPLopm4uX5CY4vH2aBQbmt /dAzL4vQykcwMT7SosjfaGUPip8AMbtmvYNe/vEgAPG9qsL+zEJCZBd4u7jMCgcJ Kk316RAoslBpOmaLHROQVGwfr5XF+RYdmFuSSkjx33CuFruSeRrY9fqBSmT9+WLx 26sJgsI7LR4pzbC52cN2xi6rN0alrmCx291tpHsGqi+RSYsa1t1NnC2jGYbQCfEG /Nfaqxz1Bglta6T88BjCjuDRAvOTpyNtPNgcmaa7SVwrg9pwEZPSMvF1a6XAG8QA kjf94rhAzCFnKv+Xv5g7XwnbWLouTNsqesim2Nw7Smt4kJSVltxS5ddMUIkVGr8n V6Qb0+K7PGD76uQSjg+HA84D6eHZFW2Q20N0Vh1+ZP1XALNzC+xYztcu0IYbg+pg 8AFXm0uPzE4/wZ4FfIXgQVyCwHxiy7jdfiw5U6AEslTAOHaVIoeqpQeN5nuPRIBC dBknS5+yz5IAVoK/0vchS86nmH7IuXGvo6nB/YvJp33K9qtM/zD+JQMgQ6xym0Z8 X1eUVdjCKz75izCTqQvrYGiIQO1SVmIkpzyFYSgrHlv5olcGyTBNOOS060z33tJq PwIPT9luztVmxvMUZk36JDF31kZVMpX1ql/w2hUnts6uGGt5HBDtmhZ/sBHDWC0h 03EiXj6dHlQ= =g7zu -----END PGP SIGNATURE----- --=-yy7YFgu0ubS/N85tHMh+--