Re: boot.img Fix

[Vladimir 'phcoder' Serbinenko]

Sorry for posting some not very-related ideas in one mail and
top-posting but I want to go to bed ASAP now. FAT install is
important. A friend asked me on RMLL to install GRUB on his
partionless SD card. This card was formatted with Symbian and
contained no "FAT32" string. I actually see no reason to keep the
check for this string. Originally it was added to ignore some recovery
partitions from the list. But there is no reason to do so even if they
normally contain no useful data. It's user's freedom to read even
useless data in GRUB.
Current grub-setup may have a bug to accidently detect FAT* as
pc_partition_map (they share signature) and try to embed with
potentially bad results
For FAT booting I would prefer to have 3 separate sectors able to
parse FAT32/FAT16/FAT12. I would prefer it to be able to go into
subdirectories but in worst case grub-install can copy core.img to the
root. Or we can use so-called "reserved sectors" on FAT to either
store second part of parser or embed core. For the latter the obstacle
is that it's typically only around 32 reserved sectors.

On Wed, Jul 8, 2009 at 12:17 AM, Pavel Roskin<address@hidden> wrote:
> On Tue, 2009-07-07 at 10:08 +0200, Yves BLUSSEAU wrote:
>> Hi,
>>
>> there is a "bug" in boot.img: if you install the boot.img into the
>> volume boot sector of a FAT32 partition instead of MBR (i know it's a
>> bad idea), you "destroyed" the partition (even grub will not recognize it).
>
> I think a much bigger issue is that installing on FAT32 it was allowed
> at all!  I assume that even with your patch, installing the GRUB
> bootsector into some filesystems would still break them.  We need a
> check that the bootsector is compatible with the filesystem.
>
>> The problem is that the FAT32 FileSystem need a 87 bytes long BPB
>> instead of the 59 bytes long for FAT16
>> (http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector).
>> So the boot.img need to preverse the first 90 bytes of the first sectors
>> of a FAT32 partition.
>> I made this patch to fix it and it work perfectly.
>>
>> What i have done is:
>>     * change the offset of the end of BPB
>>     * change the offsets of the data inside the region of Extended BPB
>>     * remove 2 constants that are never used
>
> Removing unused constants is better done in a separate patch.  And they
> should be specified by name.
>
>>     * change the minor version of the GRUB_BOOT_VERSION 4.0 => 4.1
>
> I don't see where it's checked.  What's the effect of the change?
>
>>     * change the string of hd_probe_error_string from "Hard Drive" to "HD"
>>        because i needed 2 extras bytes and do not want to change the working
>>        code of the boot.
>
> It means the code is very tight.  We would not able to add any
> workarounds or features in the future.
>
> When is the ability to install on FAT32 important?  If it's just a way
> to fix a missing check in grub-setup, then I'll rather have some extra
> space.
>
> The same boot.S has a hole for the partition table.  I think we should
> need either one hole or another.  That would allow us to have two
> versions of boot.img, one for FAT bootsector and another for MBR.
>
>> -notification_string: .asciz "GRUB "
>
> It's better not to mix formatting and essential changes.  Besides, the
> use of tabs is justified for alignment.
>
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git