[PATCH] Workaround for usb boot failure on some mainboards

[PATCH] Workaround for usb boot failure on some mainboards

[Thomas Frauendorfer | Miray Software]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Hi,

On some boards, like the AsRock K7S41GX, Grub fails to boot from 
superfloppy fat32 formated usb sticks.

The reason for the boot failure is that  the bios of the  mentioned 
board  replaces byte 0x24 of the bpb with the value 0x00 when it's read 
through the bios function.
In fat16 this byte contains the Disc unit number, so this causes no real 
harm there.
In fat32 this byte is part of the sectors per FAT information, so by 
modifying this value the bios makes Grub unable to read the fat system.

The attached workaround reads the backup bpb information from the  fat32 
filesystem and uses the sectors per fat information stored there.



[-- Attachment #2: fat.patch --]
[-- Type: text/plain, Size: 1507 bytes --]

--- ../grub2-upstream/grub2-upstream/grub-core/fs/fat.c	2010-09-21 12:13:17.154835710 +0200
+++ grub2-merge/grub-core/fs/fat.c	2010-09-22 10:23:27.935482451 +0200
@@ -214,6 +214,29 @@ grub_fat_mount (grub_disk_t disk)
 			    ? grub_le_to_cpu16 (bpb.sectors_per_fat_16)
 			    : grub_le_to_cpu32 (bpb.version_specific.fat32.sectors_per_fat_32))
 			   << data->logical_sector_bits);
+  if (bpb.sectors_per_fat_16)
+    data->sectors_per_fat = grub_le_to_cpu16 (bpb.sectors_per_fat_16) << data->logical_sector_bits;
+  else
+    {
+      /* Workaround for buggy BIOSes which replace offset 0x24 in the bpb 
+         with the drive number. This offset is part of sectors_per_fat_32 in
+         the fat32 structure. 
+         We read the backup bpb (if available) and use the value there */
+      struct grub_fat_bpb backup_bpb;
+      grub_uint32_t backup_bpb_address = grub_le_to_cpu16 (bpb.version_specific.fat32.backup_boot_sector) << data->logical_sector_bits;
+      if (bpb.version_specific.fat32.backup_boot_sector && 
+	  (! grub_disk_read (disk,
+			     backup_bpb_address,
+			     0,
+			     sizeof (backup_bpb),
+			     &backup_bpb)))
+	data->sectors_per_fat = grub_le_to_cpu32 (backup_bpb.version_specific.fat32.sectors_per_fat_32) << data->logical_sector_bits;
+
+      if (data->sectors_per_fat == 0)
+	data->sectors_per_fat = grub_le_to_cpu32 (bpb.version_specific.fat32.sectors_per_fat_32) << data->logical_sector_bits;
+    }
+
+
   if (data->sectors_per_fat == 0)
     goto fail;
 

[PATCH] Workaround for usb boot failure on some mainboards

[Thomas Frauendorfer | Miray Software]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

Hi,

On some boards, like the AsRock K7S41GX, Grub fails to boot from 
superfloppy fat32 formated usb sticks.

The reason for the boot failure is that  the bios of the  mentioned 
board  replaces byte 0x24 of the bpb with the value 0x00 when it's read 
through the bios function.
In fat16 this byte contains the Disc unit number, so this causes no real 
harm there.
In fat32 this byte is part of the sectors per FAT information, so by 
modifying this value the bios makes Grub unable to read the fat system.

The attached workaround reads the backup bpb information on fat32 
filesystems and uses the sectors per fat information stored there.

PS: I'm sorry if this mail is a duplicate, but I sent it before but I 
wasn't subscribed so it might have been blocked/dropped before



[-- Attachment #2: fat.patch --]
[-- Type: text/plain, Size: 1508 bytes --]

--- ../grub2-upstream/grub2-upstream/grub-core/fs/fat.c	2010-09-21 12:13:17.154835710 +0200
+++ grub2-merge/grub-core/fs/fat.c	2010-09-22 10:23:27.935482451 +0200
@@ -214,6 +214,29 @@ grub_fat_mount (grub_disk_t disk)
 			    ? grub_le_to_cpu16 (bpb.sectors_per_fat_16)
 			    : grub_le_to_cpu32 (bpb.version_specific.fat32.sectors_per_fat_32))
 			   << data->logical_sector_bits);
+  if (bpb.sectors_per_fat_16)
+    data->sectors_per_fat = grub_le_to_cpu16 (bpb.sectors_per_fat_16) << data->logical_sector_bits;
+  else
+    {
+      /* Workaround for buggy BIOSes which replace offset 0x24 in the bpb 
+         with the drive number. This offset is part of sectors_per_fat_32 in
+         the fat32 structure. 
+         We read the backup bpb (if available) and use the value there */
+      struct grub_fat_bpb backup_bpb;
+      grub_uint32_t backup_bpb_address = grub_le_to_cpu16 (bpb.version_specific.fat32.backup_boot_sector) << data->logical_sector_bits;
+      if (bpb.version_specific.fat32.backup_boot_sector && 
+	  (! grub_disk_read (disk,
+			     backup_bpb_address,
+			     0,
+			     sizeof (backup_bpb),
+			     &backup_bpb)))
+	data->sectors_per_fat = grub_le_to_cpu32 (backup_bpb.version_specific.fat32.sectors_per_fat_32) << data->logical_sector_bits;
+
+      if (data->sectors_per_fat == 0)
+	data->sectors_per_fat = grub_le_to_cpu32 (bpb.version_specific.fat32.sectors_per_fat_32) << data->logical_sector_bits;
+    }
+
+
   if (data->sectors_per_fat == 0)
     goto fail;
 

Re: [PATCH] Workaround for usb boot failure on some mainboards

[Lennart Sorensen]

On Wed, Sep 22, 2010 at 05:45:34PM +0200, Thomas Frauendorfer | Miray Software wrote:
> On some boards, like the AsRock K7S41GX, Grub fails to boot from  
> superfloppy fat32 formated usb sticks.
>
> The reason for the boot failure is that  the bios of the  mentioned  
> board  replaces byte 0x24 of the bpb with the value 0x00 when it's read  
> through the bios function.
> In fat16 this byte contains the Disc unit number, so this causes no real  
> harm there.
> In fat32 this byte is part of the sectors per FAT information, so by  
> modifying this value the bios makes Grub unable to read the fat system.
>
> The attached workaround reads the backup bpb information on fat32  
> filesystems and uses the sectors per fat information stored there.
>
> PS: I'm sorry if this mail is a duplicate, but I sent it before but I  
> wasn't subscribed so it might have been blocked/dropped before

Wouldn't that be a bug in the BIOS?  Don't go writing to a drive you
don't know what contains.  It could be something other tahn fat16 after
all (what if it was a linux kernel with a bootheader on it and not a
filesystem at all?)

Sounds like the BIOS needs fixing badly.  Nothing wrong with making
grub more robust against corrupt filesystems, but it doesn't actually
fix the bug in the BIOS.

-- 
Len Sorensen

Re: [PATCH] Workaround for usb boot failure on some mainboards

[Thomas Frauendorfer]

On Wed, Sep 22, 2010 at 6:14 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:

> Wouldn't that be a bug in the BIOS?  Don't go writing to a drive you
> don't know what contains.  It could be something other tahn fat16 after
> all (what if it was a linux kernel with a bootheader on it and not a
> filesystem at all?)
>
> Sounds like the BIOS needs fixing badly.  Nothing wrong with making
> grub more robust against corrupt filesystems, but it doesn't actually
> fix the bug in the BIOS.

Well, I think I didn't state the problem clearly enough:
The bios doesn't write to the disk, it just changes the value on the
fly when the bootloader is reading the bpb through a bios method.
The workaroud also doesn't change the disk, it only reads the
necessary information from a region the bios doesn't mess up on the
fly...

Re: [PATCH] Workaround for usb boot failure on some mainboards

[Lennart Sorensen]

On Wed, Sep 22, 2010 at 06:52:46PM +0200, Thomas Frauendorfer wrote:
> Well, I think I didn't state the problem clearly enough:
> The bios doesn't write to the disk, it just changes the value on the
> fly when the bootloader is reading the bpb through a bios method.
> The workaroud also doesn't change the disk, it only reads the
> necessary information from a region the bios doesn't mess up on the
> fly...

Still a bug.  It can NOT assume things about what is being booted.
Don't assume FAT16 unless you checked explicitly that it is FAT16.

-- 
Len Sorensen

Re: [PATCH] Workaround for usb boot failure on some mainboards

[Thomas Frauendorfer]

On Wed, Sep 22, 2010 at 7:45 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Wed, Sep 22, 2010 at 06:52:46PM +0200, Thomas Frauendorfer wrote:
>> Well, I think I didn't state the problem clearly enough:
>> The bios doesn't write to the disk, it just changes the value on the
>> fly when the bootloader is reading the bpb through a bios method.
>> The workaroud also doesn't change the disk, it only reads the
>> necessary information from a region the bios doesn't mess up on the
>> fly...
>
> Still a bug.  It can NOT assume things about what is being booted.
> Don't assume FAT16 unless you checked explicitly that it is FAT16.

I know, that a bios must not assume anything about a file system it
hasn't checked. But it does and I can't change that and because of
that bug booting from an usb-stick fails on that mainboard (and most
likely a few others at well).

Re: [PATCH] Workaround for usb boot failure on some mainboards

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

On 09/22/2010 05:45 PM, Thomas Frauendorfer | Miray Software wrote:
> Hi,
>
> On some boards, like the AsRock K7S41GX, Grub fails to boot from
> superfloppy fat32 formated usb sticks.
>
This config isn't recommended in first place. You should really create
partitions on the USB disk and leave some space between MBR and
partition, then there will be no problem with this on-the-fly
replacement. As an alternative you can use grub-mkrescue.
As for your patch it may break in case when only backup is damaged. The
correct algorithm would be sth like

if (!consistent (bpb))
{
   err = read_backup_bpb (bpb);
   if (err)
      return err;
   if (!consistent (bpb))
      return grub_error (...);
}

Function consistent would contain all current checks (minus perhaps
"FAT" string checking) plus the checks that e.g. number of fat entries
and fat sectors is consistent.

> The reason for the boot failure is that  the bios of the  mentioned
> board  replaces byte 0x24 of the bpb with the value 0x00 when it's
> read through the bios function.
> In fat16 this byte contains the Disc unit number, so this causes no
> real harm there.
> In fat32 this byte is part of the sectors per FAT information, so by
> modifying this value the bios makes Grub unable to read the fat system.
>
> The attached workaround reads the backup bpb information on fat32
> filesystems and uses the sectors per fat information stored there.
>
> PS: I'm sorry if this mail is a duplicate, but I sent it before but I
> wasn't subscribed so it might have been blocked/dropped before
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]