Hi Michael,

> My data for my disks comes after my .sig.  The first disk actually has
> 5 partitions; the `aptck' utility drops out after the fourth one.

Yep, aptck aborts at the first error, because it doesn't know if it is
a minor or major error. Continuing after a major error makes no sense,
aptck would then try to evaluate `garbage'. The next version will be
more clever, and hopefully also be able to fix the small bugs in the
partition table. Thanks to the reports send by you and others, I'm
getting quite a good impression of the most frequent errors. Sofar,
all of them are minor errors, which could be fixed automatically.

> Both disks have been partitioned with SCSI-Tools.

A first glance at your disk data was enough to spot the problem, it's
the same one I had with my disks, also formatted with SCSI-tools. Of
course you and I have the advantage that SCSI-tools keeps a backup
of the root and auxilary root sectors. Should you mess up while
fixing the error, you can always restore the original partition
table (make sure you have a copy of SCSI-tools on a floppy).

> While `aptck' had been running, the TOS SCSI driver reported lots of
> "sense code $21"; I think that means "invalid block address"...  I
> guess that's normal, isn't it?

Yes, with HuSHI this is normal. Aptck tries to access many non-existent
sectors before it has found the last existing sector on the disk.

> device     : s00 (SCSI target 0 lun 0) [MAXTOR  LXT-213S        ]
> sector size: 512 bytes
> medium size: 415436 sectors
> 
> root sector data:
>   medium size: 415435

This is typical of SCSI-tools, the medium size stored in the
root sector is one less than the real medium size as reported
above. This doesn't matter to NetBSD, which only looks at the
real medium size.

>   start of bad sector list : 1
>   length of bad sector list: 2
>   entry 0: BGM         4     81920
>   entry 1: GEM     81924     30727
>   entry 2: BGM    112651    112640
>   entry 3: XGM    225291    190137

The size of the extended partition (entry 3) is too short, it
should have been 4 sectors more (190141). Load physical sector 0
in a sector editor, at offset 0x01f2 you should see (in hexadecimal):
00 02 e6 b9. Change the last byte from b9 to bd.

You're probably not ready yet! Because this is SCSI-ID 0, I have
to assume that this is your boot-disk. If it is, you must make sure
that the checksum will be correct. You find the checksum addjustment
value in the last two bytes of the sector (offset 0x01fe). I don't
know what's in there, but whatever it is, just subtract 4 from the
current value, to make for the 4 you added in the partition table.

If you make a mistake and are no longer able to boot from harddisk,
you still have that copy of SCSI-tools on a floppy -- no reason to
panic.

> auxilary root at sector 225291:
>   entry 0: GEM         1     10240
>   entry 1: XGM     10241    179905

Now this is weird, because it is really impossible. Theoretically this
cannot be more than 179900, a difference of 5 sectors!? I suggest you
reduce the size by 5: physical sector 225291 in the sector editor, at
loation 0x01da you see: 00 02 be c1. Change the last byte from c1 to
bc. Save the sector.

Run `aptck s0', and whatever it says, please mail the report. I would
like to see the last auxilary root sector, to make sure that this is
the correct solution.

> device     : s10 (SCSI target 1 lun 0) [QUANTUM LP240S GM240S01X]
> sector size: 512 bytes
> medium size: 479350 sectors
[ ... ]
> NetBSD says: AHDI partition table OK.

Wow, that's what we want to see. :-)


Waldi