From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LVVUG-0004eN-M0 for mharc-grub-devel@gnu.org; Fri, 06 Feb 2009 13:31:36 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVVUE-0004dn-94 for grub-devel@gnu.org; Fri, 06 Feb 2009 13:31:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVVUC-0004dW-Qi for grub-devel@gnu.org; Fri, 06 Feb 2009 13:31:33 -0500 Received: from [199.232.76.173] (port=36938 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVVUC-0004dT-LL for grub-devel@gnu.org; Fri, 06 Feb 2009 13:31:32 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]:13508) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LVVUC-0000wf-8Y for grub-devel@gnu.org; Fri, 06 Feb 2009 13:31:32 -0500 Received: by fg-out-1718.google.com with SMTP id l27so633646fgb.30 for ; Fri, 06 Feb 2009 10:31:29 -0800 (PST) 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=TXurqKb9kPkrAwAmu0T0cGKQf0IvhUBOmu1eBXg2NDk=; b=Auv0IG0HPcbMz79cFxHsl1e9Rn2CHrohws1Jt/UqEfqyb6ToF1CzXQ4I2hENjCduR9 v2aCkzeCvK8bJdnBtlXwdFqM5dDTmen6BF1D8B7b2qhw3Xs2nTMLGIMdOTakelep20NI F9sHuudoBZ4JpyquuBjafyxryTt5ers/WzGFc= 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=jrewVOO3lH5Bn/94uBUczrDmj4j3myR/qulYDPbq5lWvoUGyA4TT+AIa/OZPqVXsGA aYgQRKEKQp24B++BVuEW6Fp0WdzHUe7hsuR6H6+F0lAnxVn4P9Bkso5Jkf9i3RVL/bFg h/9BzhkmP6qiaGU08Ix7WseT+3A/OpRjhDbaY= Received: by 10.86.59.18 with SMTP id h18mr965497fga.5.1233945089392; Fri, 06 Feb 2009 10:31:29 -0800 (PST) Received: from ?192.168.1.25? (196-234.62-81.cust.bluewin.ch [81.62.234.196]) by mx.google.com with ESMTPS id e20sm3617973fga.46.2009.02.06.10.31.28 (version=SSLv3 cipher=RC4-MD5); Fri, 06 Feb 2009 10:31:28 -0800 (PST) Message-ID: <498C81FF.9000101@gmail.com> Date: Fri, 06 Feb 2009 19:31:27 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <1233866360.3426.31.camel@fz.local> <498BD389.60902@gmail.com> <1233935204.3420.3.camel@fz.local> In-Reply-To: <1233935204.3420.3.camel@fz.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] try to avoid false positives on FAT filesystem 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, 06 Feb 2009 18:31:34 -0000 Currently GRUB tries first the filesystem which was loaded at last. If you do rmmod ext2 insmod ext2 then ext2 will be probed first. If we want reliable ordering we need priority field. Thanks Vladimir 'phcoder' Serbinenko Felix Zielcke wrote: > Am Freitag, den 06.02.2009, 07:07 +0100 schrieb phcoder: >> If I understood you correctly you propose to use partition table >> information to determine filesystem. I'm personally against it. First of >> all it isn't portable - it probably wouldn't work on GPT. Second if you >> just do mkfs.* the partition type isn't changed. Linux ignores >> partition type and so if your patch is applied there will be many bug >> reports like "hey, *FS isn't detected". Finally sometimes you >> intentionally change partition type in the technics like partition >> hiding. IMO the correct solution to this problem is to make sure that >> fat and ntfs are probed at last. Should we add a priority field for this? > No I don't want to check the partition type. > FAT partitions normally have the string FAT12/FAT16/FAT32 at the > beginning of 512 bytes of the partition. But these DELL FAT partions > have there the string .AT16 so it would be a solution for the Debian bug > report we got. > But yes the best would be to probe for FAT at last but I don't know how > to change the order, in fs.lst FAT is listed after ext2 but it seems > that FAT is checked before ext2. >