From: Pavel Roskin <proski@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: boot.img Fix
Date: Tue, 07 Jul 2009 18:17:07 -0400 [thread overview]
Message-ID: <1247005027.3393.82.camel@mj> (raw)
In-Reply-To: <15498-60872@sneakemail.com>
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
next prev parent reply other threads:[~2009-07-07 22:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 8:08 boot.img Fix Yves BLUSSEAU
2009-07-07 22:17 ` Pavel Roskin [this message]
2009-07-08 5:06 ` Pavel Roskin
2009-07-08 8:13 ` Yves BLUSSEAU
2009-07-08 23:09 ` Vladimir 'phcoder' Serbinenko
2009-07-10 17:15 ` Robert Millan
2009-07-12 13:30 ` Pavel Roskin
2009-07-14 17:34 ` Robert Millan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1247005027.3393.82.camel@mj \
--to=proski@gnu.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.