From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1N0CJe-0007BJ-JA for mharc-grub-devel@gnu.org; Tue, 20 Oct 2009 06:51:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N0CJa-0007AC-Nl for grub-devel@gnu.org; Tue, 20 Oct 2009 06:51:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N0CJV-00079X-NP for grub-devel@gnu.org; Tue, 20 Oct 2009 06:51:41 -0400 Received: from [199.232.76.173] (port=51472 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0CJV-00079U-IS for grub-devel@gnu.org; Tue, 20 Oct 2009 06:51:37 -0400 Received: from fg-out-1718.google.com ([72.14.220.156]:44931) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N0CJV-0004LF-6P for grub-devel@gnu.org; Tue, 20 Oct 2009 06:51:37 -0400 Received: by fg-out-1718.google.com with SMTP id e21so1674869fga.12 for ; Tue, 20 Oct 2009 03:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=quuvTq2Qldo/37rqb/XmAO7drfyArgqcvSlF/hKUzh4=; b=f4D7RT9z1sQ/RyHUNCwXxWf0PKDyQxc3i6gOkOuRX2uL9jmqySxxGW7Hb/GAUJj+AQ GoMuy2iLRmEDvbvi6rjdJNfkgu0tfUCF5nJJrIYPUuc/eKWRHappgnv0GRqthEvMN1eT D23jF6wlz0PA9buDY9iXn7DbtwOA3xnLQGAhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=fNihwe1mm66cYUwoKozPt6bU0lZTVLreNCU+uVB9MdoO5jK23Ge9+avbUhi6RQrT4N Qnxt2/0iAdEzBN9m1MNbNvcD/2DmidPq93OGD56kT4IUjtqekD83L0M+PQv64gDGnoBS Mb9tn0ZKBjkX1PXkq1Lc0A+eBoZ5NUNbd2zCo= Received: by 10.86.229.18 with SMTP id b18mr3649762fgh.34.1256035896207; Tue, 20 Oct 2009 03:51:36 -0700 (PDT) Received: from debian.bg45.phnet (hg-public-dock-140-dhcp.ethz.ch [82.130.80.140]) by mx.google.com with ESMTPS id l12sm1400430fgb.22.2009.10.20.03.51.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Oct 2009 03:51:35 -0700 (PDT) Message-ID: <4ADD9636.5050102@gmail.com> Date: Tue, 20 Oct 2009 12:51:34 +0200 From: Vladimir 'phcoder' Serbinenko User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: The development of GRUB 2 References: <20091016205258.GA8496@thorin> <4AD8E0CF.9080509@gmail.com> <20091016215343.GA9378@thorin> <4AD8F11D.1030007@gmail.com> <20091017112545.GA3556@thorin> <4AD9ADE9.3020004@gmail.com> <20091017120013.GA4040@thorin> <4AD9B3FB.9000904@gmail.com> <20091018154608.GA27494@thorin> <4ADB4293.6070703@gmail.com> <20091020101810.GA3952@thorin> In-Reply-To: <20091020101810.GA3952@thorin> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] Refuse to install on XFS destroying its superblock 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: Tue, 20 Oct 2009 10:51:42 -0000 Robert Millan wrote: > On Sun, Oct 18, 2009 at 06:30:11PM +0200, Vladimir 'phcoder' Serbinenko wrote: > >> Robert Millan wrote: >> >>> On Sat, Oct 17, 2009 at 02:09:31PM +0200, Vladimir 'phcoder' Serbinenko wrote: >>> >>> >>>>>> The danger is that fs_probe may reject filesystem as valid just because >>>>>> it's newer than expected. >>>>>> >>>>>> >>>>>> >>>>> What do you mean with "reject filesystem as valid"? >>>>> >>>>> >>>>> >>>>> >>>> Sorry for being unclear. I just meant that if some XFS structures are >>>> updated then our xfs driver won't recognise it as xfs >>>> >>>> >>> What do you mean with "updated"? You mean a new implementation of XFS? Or >>> the same instance of XFS that has been modified after use? >>> >>> >>> >> I mean next version on XFS >> > > Sorry, but what did you expect? You want to prevent PEBCAK using > heuristic. There's no way we can tell if those 512 bytes are valuable > data, only the user can. And even if you try to err on the safest side, > there's no garantee that newer versions of XFS, or other filesystems that > don't even exist yet will be detectable by us no matter what we do. > > I think best way is to have whitelist of OS which have first sector free and possible manual override like it was suggested. > Why don't we just take a backup like someone suggested a while ago? I > think there was even a patch. This way if valuable data is lost, user can > restore it (and while at it, learnt his lesson that filesystems and embedded > code aren't really supposed to be mixed in the same place). > > The backup is inevitably stored on the filesystem itself which becomes inaccessible once superblock is destroyed. -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git