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

[Robert Millan <rmh@aybabtu.com>]

On Sat, Jul 18, 2009 at 11:28:58PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > I don't understand what you mean here.
> Let's take a common example of cdrom. Most of the users and developers
> are accustomed to a cdrom holding one filesystem. On macs however cds
> are partitioned and not being able to access all the partitions is a
> problem for end user. Such situations are probably common. If we ditch
> has_partitions altogether the only negative side effect will be that
> in some weird configurations unpartitioned media may appear to have
> partitions but whole media is still accessible. Additionally it
> simplifies and makes kernel smaller

I'm not sure they're so weird.  But we could still do it.  Pavel, what do
you think?

> >> > I'm not sure there's much we can do about this.  Using heuristics sounds like
> >> > it will make the solution worse than the problem.  I don't care much about
> >> > Microsoft filesystems, but I'd hate to see GRUB fail on a completely sane
> >> > ext3 inside msdos label because it happened to look like FAT in raw disk at
> >> > the same time.
> >> The approach proposed by Collin avoids such problems since correct
> >> pc_partition_map is always detected as such.
> >
> > I haven't looked at the source code, but what he said is we can determine if
> > an MBR is valid by checking the bootable flag, and this is not always so.
> I don't see any problem. He said: checking that bootable flags of all
> partitions are either set (0x80) or unset (0x0) and not another value

Oh, that's different.  I think it's fine provided that:

  - None of the commonly used free partitioning tools uses an illegal value.

  - We fail gracefully and let the user know why.

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