From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V8oq1-0001tX-O8 for mharc-grub-devel@gnu.org; Mon, 12 Aug 2013 05:54:57 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8opy-0001tM-K7 for grub-devel@gnu.org; Mon, 12 Aug 2013 05:54:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V8opw-0008Lp-Ll for grub-devel@gnu.org; Mon, 12 Aug 2013 05:54:54 -0400 Received: from mail-ee0-x22b.google.com ([2a00:1450:4013:c00::22b]:37323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8opw-0008LV-F2 for grub-devel@gnu.org; Mon, 12 Aug 2013 05:54:52 -0400 Received: by mail-ee0-f43.google.com with SMTP id e52so3348585eek.16 for ; Mon, 12 Aug 2013 02:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FxsxsnoLySIrdyIX0ddR1Tnjv5FXervlPKMP7qHVKo4=; b=j0ms53Tm5m/x0DyodE+IVStBxSu8yI6Tmmq/iRL0qMmzzaqG74QXVCjZAEC1zazx6M klCcvVW9qCRbBQipOPOAD/53qAGdxb3YJrYvXFfmfH2J/usNA/L1YtD4mVLnxFnkKJpD coys22wrBOmQrkQfXe82G0vT4+QhYd7XdhHRaMn5emgSRskLXR5TMFRbRqrtFDDrAv1T SwTShqkRGCJyfrCOtrJ59SeK22OdSFqh+ZF9+AYBeDY2UFB3VI+g9NOo3ghyGc1I7rwT rM1JkabiSLG6kZUc9Ok11gf2CazjnKRgK4eYQDWaBAhJNOlqcHsDcT88f7JLx13krR8L aaDw== X-Received: by 10.14.246.11 with SMTP id p11mr25166029eer.9.1376301291122; Mon, 12 Aug 2013 02:54:51 -0700 (PDT) Received: from ?IPv6:2001:67c:10ec:3f42:8000::1340? ([2001:67c:10ec:3f42:8000::1340]) by mx.google.com with ESMTPSA id j2sm55950693eep.6.2013.08.12.02.54.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 02:54:50 -0700 (PDT) Message-ID: <5208B0E4.8000304@gmail.com> Date: Mon, 12 Aug 2013 11:54:44 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Bug#709097: grub-pc: Boot failure after updating to 2.00-14 - cannot find normal.mod, grub-rescue reports /boot empty References: <20130520185519.5798.65190.reportbug@wormtail.bear-cave.org.uk> <20130811135306.GL27110@riva.ucam.org> In-Reply-To: <20130811135306.GL27110@riva.ucam.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22b 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: Mon, 12 Aug 2013 09:54:56 -0000 On 11.08.2013 15:53, Colin Watson wrote: > Control: retitle -1 misdetects FAT-overwritten-with-ext2 as FAT > Control: severity -1 important > This is a pretty specialised (hence the severity downgrade), but > interesting, corner case. It appears that the partition in question > used to be a FAT filesystem (specifically, a Dell Utility partition). > It has been overwritten sufficiently that the fstype magic has been > overwritten: > > 00000000 eb 54 90 00 65 6c 6c 20 38 2e 30 00 02 08 01 00 |.T..ell 8.0.....| > 00000010 02 00 02 00 00 f8 86 00 3f 00 ff 00 3f 00 00 00 |........?...?...| > 00000020 92 2a 04 00 80 00 29 1c 0a d9 07 44 65 6c 6c 55 |.*....)....DellU| > 00000030 74 69 6c 69 74 79 00 41 54 31 36 20 20 20 10 00 |tility.AT16 ..| > How does something like that come into existence? Why would only part of BPB overwritten? The tools that I know either overwrite whole sector or don't touch BPB. > Vladimir, could you elaborate on this? Which mkfs implementations were > involved here? > AFAIR it was some FAT images that are commercially distributed. AFAIR neither Windows nor Linux check this field. > It seems questionable to me for GRUB to be quite this liberal. Perhaps > we can restore its previous strictness somehow without breaking the > filesystems that Vladimir ran into? > > Thanks, >