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

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

[Colin Watson]

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]

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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

[Andrey Borzenkov]

В Sun, 11 Aug 2013 14:53:06 +0100
Colin Watson <cjwatson@debian.org> пишет:

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

It still is. Linux kernel silently mounts it as vfat. It looks like an
empty FAT.

bor@opensuse:~> /sbin/losetup  -a
/dev/loop0: []: (/home/bor/tmp/grub2-empty-partition)
bor@opensuse:~> grep loop0 /proc/mounts 
/dev/loop0 /tmp/xx vfat rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
bor@opensuse:~> LC_ALL=C ls -l /tmp/xx
total 0
bor@opensuse:~> dmesg | tail -2
[124630.727150] EXT4-fs (dm-3): re-mounted. Opts: acl,user_xattr,commit=600
[129578.577311] loop: module loaded
bor@opensuse:~> 

blkid does check BPB signature and so it does not detect is as a FAT.

I'm not sure what can be done here.