Re: Bug#709097: grub-pc: Boot failure after updating to 2.00-14 - cannot find normal.mod, grub-rescue reports /boot empty

[Colin Watson <cjwatson@debian.org>]

Control: retitle -1 misdetects FAT-overwritten-with-ext2 as FAT
Control: severity -1 important

On Mon, May 20, 2013 at 07:55:19PM +0100, Jim Hague wrote:
> Package: grub-pc
> Version: 2.00-14
> Severity: critical
> Justification: breaks the whole system
> 
> After update from 1.99-27 on my i386 laptop, it failed to boot, stopping at the
> grub-rescue prompt.
> 
> grub-rescue could see (hd0), (hd0,msdos1) and (hd0,msdos2). (hd0,msdos2) is a
> LVM partition containing the root filesystem. (hd0,msdos1) is the boot
> partition containing an ext2 filesystem. All prefixes were correct, but grub
> reported it could not find /grub/i386-pc/normal.mod. This was apparently
> because Grub could not find any files on the partition.
> 
> grub-rescue>ls (hd0,msdos1)
> 
> grub-rescue>
> 
> I used boot-repair to fsck the boot partition (clean), and to purge and re-
> install grub, configuring as before boot sda, boot partition sda1. On
> rebooting, no change.
> 
> I then tried saving the content of the boot partition, re-creating the boot
> partition filesystem (using mkfs.ext3), copying the files back and re-running
> update-grub and grub-install. The machine booted correctly, so I therefore
> infer something about my /boot ext2 filesystem was causing it to be misread by
> 2.00-14.
> 
> A copy of the offening boot partition (saved with 'dd if=/dev/sda1 of=<file>
> bs=1M') is at http://www.lunch.org.uk/grub2-empty-partition.bz2.

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   ..|

This means that blkid no longer detects it as FAT, but unfortunately
GRUB does ever since this commit:

  revno: 1855.125.850
  committer: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
  branch nick: grub
  timestamp: Tue 2012-01-31 23:26:07 +0100
  message:
          * grub-core/fs/fat.c (grub_fat_mount) [!MODE_EXFAT]: Remove fstype
          check as some mkfs implementations omit it.

Vladimir, could you elaborate on this?  Which mkfs implementations were
involved here?

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,

-- 
Colin Watson                                       [cjwatson@debian.org]