On Wed, 16 Aug 2000, Bob Nestor wrote:

> Bill Studenmund wrote:
> 
> >What else is wrong?
> >
> The APM created by NetBSD/macppc has the wrong value in the pmPartBlkCnt 
> and pmDataCnt fields for the Apple Partition Map Entry. Both should 
> reflect the number of blocks allocated to the Partition Map.  The 
> pmPartStatus flags don't appear to be correct for the NetBSD parition 
> itself, and the pmPartBlkCnt/pmDataCnt values are totally bogus too.

From the docs I had, I thought pmDataCnt and pmLgDataStart are for certain
OS's (A/UX) which use only a subsection of the PartMap partition. So I
don't _think_ getting them wrong is a problem.

I think the idea is that the fake map has a partition map in blocks 1 & 2,
and the boot code starting at block 4. The size of the driver block is
definitly wrong, and will be fixable if we know stats on the disk.

> Oh, you might want to make sure you get the right values from the 
> disklabel for the size of the disk.  One of the fields contains the 
> actual number of blocks on the physical volume. This might not be the 
> same as the value you get by computing it from the cylinder, sector and 
> head count.  If you don't use the actual disk block count it will appear 
> to many disk formatters that there is unused/unallocated space at the end 
> of the disk.  If you want everything to come out on whole cylinder counts 
> you might consider allocated the slop to an "Unused" partition.

Right. c*h*s is totally broken today. :-)

> Every disk formatter I've played with seems to add to the list of 
> partition types.  I've come to the conclusion that anything that starts 
> with "Maci" or "Appl" is Apple defined and reserved, everything else up 
> for grabs.

And we're adding some too. :-)

> >> The Partition Entry usually starts in block 1, but you can't count on 
> >> this!  There are many disk formatters that scramble the blocks in the 
> >> Partition Map and I've found that I always had to hunt for the entry that 
> >> mapped the Partition Table itself.  Some disk formatters and disk setup 
> >> routines improperly initialize the size of the Partition Table to be just 
> >> the number of blocks used rather than the number allocated as the 
> >> documentation calls for.  Mkhybrid is guilty of this error.  I've found 

Oh, what I was saying is that the partition map starts at block 1, but
that the partition map entry doesn't have to be the first. The current
code searches the partition map for the entry which covers the map itself.

> >Well, since the partition map mkhybrid uses won't grow, that's not too
> >bad.. We might want a partition editor which will fix these errors.
> >
> Unless one considers writing something like mksunbootcd for the Mac to 
> add the boot code to a new partition at the end of the ISO image before 
> burning it.  I was actually working on this and have some code already 
> written which is how I found the problem with mkhybrid.  One of my 
> routines does in fact fix up the errors in the APM.  When I get the code 
> finished I'll send the updates to Jim Pearson.  He's been real responsive 
> about updatding mkhybrid and in the past included some of the things I 
> sent him.

Another option is that I think he has the ability to add drivers to the
image. We could just have mkhybrid add a dummy (well incorrect) bootxx
image, and then use installboot to fix things later.

Note: this version of installboot doesn't do the right thing for
non-512-byte blocks!

> >What are these blocks allocated to???
> >
> They aren't! And that's the problem.  The block are technically allocated 
> to the Partition Map, but since the pmPartBlkCnt/pmDataCnt values dont' 
> correctly map the entire space allocated they appear to be unallocated.  
> However if one tries to re-partition the disk most disk formatters will 
> correctly assume the space should be allocated to the Partition Map and 
> use it.

?? If they aren't in the partition map, they aren't allocated. :-)

Weird...

> >I thought about Apple_Scratch, but decided against it for now.
> >
> No problem, just wanted to make sure you were aware that it exists with 
> some formatters.

Right. I just wasn't sure if it was really "free" space. :-)

Take care,

Bill