grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert Millan
Subject: Re: [PATCH] Fix when installing on pationless but partionable medium
Date: Sat, 18 Jul 2009 21:17:41 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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<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)

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."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]