Bill Studenmund wrote:

>On Wed, 16 Aug 2000, Bob Nestor wrote:
>
>> Bill Studenmund wrote:
>> There are some errors in the way the fake APM is configured right now.  
>> The disk size isn't correct and the APM has some minor errors in it.  I 
>> don't know if you want to fix these along the way or if it's even 
>> important to do so at this time.  The only reason I found them is that I 
>> relied on some of these fields in sysinst/mac68k.
>
>Yes, I'd like to actually store the right number of blocks in there. I
>haven't added that yet, as it means grabbing the disklabel to get disk
>info.
>
>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.

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.

>> I noticed the #define's for the most common partition types.  The list 
>> isn't completely defined in NetBSD at the moment. There are driver 
>> partition types defined for ATA, ATAPI, and CDROM drivers that I've found 
>> looking at a number of disks and CDs.  Also these names are all 
>> case-insensitive although one gets the impression from reading Apple's 
>> docs that they are all upper-case.  This was a problem for Mkfs on the 
>> 68k port a few years ago.
>
>I got the impression they were mixed-case. Hmm... If you have more, that'd
>be great!
>
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.

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

>> that it's best to scan for the lowest allocated partition which is 
>> adjacent to the Map to determine the actual size of the Partition Map. 
>> (Apple docs indicate that all blocks on a disk are mapped by the 
>> Parititon Map except for Block0.) The other thing that many disk 
>> formatters do, which is incorrect, is to hide boot code in blocks in the 
>> Partition Map that are allocated but unused.  Apple even does this on 
>> some of their CDs in violation of their documentation.  Its not a problem 
>> on CDRs since the CD can't be modifed, but on a disk it can be a 
>> disaster.  It makes disk partitioning a real headache since the process 
>> can end up destroying disk boot code!
>
>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 we find an "Apple_Free" partition, we found freespace. If it is big
>> >enough to hold the boot blocks and either we haven't found a free space
>> >partition yet, or this one is smaller than the one we already found, we
>> >use it.
>> >
>> Other partition types that might also qualify are "Apple_Scratch" and 
>> "Apple_Unused".  Both are present in some disk formatters.
>
>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.

>> >Then we get the freespace partition we're using. We strip space out of it,
>> >and save it. We then itterate over all partitions increasing the count of
>> >active partitions.
>> >
>> I haven't looked real close at the code yet, but I assume by "strip 
>> space" you mean allocating a part of the free space.  Do you create a new 
>> partition map entry to place the rest of the space in, i.e. do you 
>> "split" the original partition into two entries?
>
>Actually I remove space from the front of the existing Apple_Free
>partition, and I use that space in the NetBSD/macppc partition I add at
>the end of the map.

Cool!

-bob