Re: [PATCH] Fix when installing on pationless but partionable medium

[Vladimir 'phcoder' Serbinenko]

On Sat, Jul 18, 2009 at 8:45 PM, Robert Millan<address@hidden> wrote:
> On Fri, Jul 17, 2009 at 05:51:40PM +0100, Colin Watson wrote:
>> On Fri, Jul 17, 2009 at 06:41:59PM +0200, Vladimir 'phcoder' Serbinenko 
>> wrote:
>> > Sometimes a media that can be partioned isn't really partioned. E.g.
>> > usb sticks. This is a patch to handle this situation. Unfortunately
>> > such medium is often formated with a flavour of FAT which shares its
>> > signature with MBR so it may be easily misidentified as
>> > pc_partition_table. Furthermore the same signature is shared with
>> > bootsectors including grub. One possibility is to try interpret disk
>> > as known filesystems and see if we succeed. But the problem is that
>> > the check for FAT are light and may result in false positives too. The
>> > only more or less advanced check there is a check for FATXX string.
>> > But I was about to propose to eliminate this check since I encountered
>> > a FAT filesystem without this string on friend's SD card formatted
>> > with symbian which he wanted to use as liveusb. Does anyone has a
>> > better idea?
>>
>> When checking for an MBR filesystem label, parted checks whether each of
>> partitions 1-4 has a boot indicator that's either 0 or 0x80, since as
>> you point out checking for the FAT signature suffers false positives; I
>> believe this algorithm matches that in the Linux kernel. Look at
>> libparted/labels/dos.c:msdos_probe(), which is already FSF-copyrighted
>> and GPLv3+. GRUB should use the same algorithm, and then the worst case
>> is that things will fail consistently.
>
> I might be missing something about this check, but GRUB doesn't require that
> the boot flag is present.  Therefore, its non presence doesn't imply this is
> not a real msdos label.
>
He refers to boot flag as a byte in msdos structure which can only be
0x00 (not set) or 0x80 (set)
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> 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