On Sat, Jul 18, 2009 at 09:01:38PM +0200, Vladimir 'phcoder' Serbinenko wrote: > On Sat, Jul 18, 2009 at 8:45 PM, Robert Millan<r...@aybabtu.com> 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)
Yes. GRUB's boot.img doesn't do anything with it AFAICT. -- 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 Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
