svn commit: r197608 - head/sys/geom/part

[John Baldwin]

On Tuesday 29 September 2009 12:18:11 pm Marcel Moolenaar wrote:
> 
> On Sep 29, 2009, at 4:49 AM, John Baldwin wrote:
> 
> > On Monday 28 September 2009 7:52:47 pm Marcel Moolenaar wrote:
> >> Author: marcel
> >> Date: Mon Sep 28 23:52:47 2009
> >> New Revision: 197608
> >> URL: http://svn.freebsd.org/changeset/base/197608
> >>
> >> Log:
> >>  The first 96 bytes may not be zeroes. It can contain trivial boot
> >>  code that merely emits an error and waits for a key press before
> >>  rebooting. The error being that extended partitions are not
> >>  bootable. The origin is presumed to be Windows 2000; Windows XP
> >>  does not do this...
> >>
> >>  For now, ignore the first 96 bytes when checking that the EBR is
> >>  (for the most part) all zeroes.
> >>
> >>  Tested by:	Mario Lobo <mlobo at digiart.art.br>
> >>  MFC after:	1 week
> >>
> >> Modified:
> >>  head/sys/geom/part/g_part_ebr.c
> >
> > Why do you check for zeros at all?  AFAIK, the only real check is  
> > for AA55 at
> > the end of the sector (and having an MBR or other Extended MBR  
> > partition
> > entry point at the sector in question).  The '96' thing seems rather
> > arbitrary in the code, and I think the zero's check is overly  
> > restrictive.
> 
> Only checking for a signature that 99% of the boot blocks
> have isn't enough. The msdos file system has that signature
> and the check for all-zeroes is to prevent false positives
> there.

The signature is only half of what I said.  The more important point is that a 
slice we have already enumerated points to this sector and has the type of 
the slice set to 'extended MBR'.  That is actually the most reliable bit of 
information we have and the AA55 check at that point is just a sanity check 
against a zero'd sector.  However, the slice type of 'extended MBR' in the 
parent partition table should be authoritative.

Much of the PC world (esp. disk labelling crap in DOS-land) is far less 
standardized than GPART seems to expect and using standards that no one else 
expects or adheres to is only going to limit our interoperability.

-- 
John Baldwin