From: Cory Smelosky <b4 at gewt.net> The disk is 1048778 blocks. I created a 512M image and copied it bit-for-bit to the disk. So you're saying the image *did* work under emulation and only broke when you copied it to the first 512 MB of a disk that you then moved to a controller with an unknown private partitioning scheme? If I'm understanding you right then it sounds as if the controller may indeed be storing its own stuff in the first block(s) and the partition for DU1: isn't supposed to start until a few blocks into the drive. I would experiment with that by zeroing the disk, and then partitioning it on the PDP-11 (I assume this is done with the SCSI controller's firmware), move it to the PC and pull off the first few blocks, then repeat the process with different partitioning (assuming that's possible -- or do you mean the firmware is hard-coded to split drives into chunks .LE. 512 MB?), and see what changes in those first few blocks. It might be very obvious... Another thing to do is generate a bunch of different boot blocks that look like this: .word 240 ;NOP (required by some boot PROMs) .word 0 ;HALT (unless the PROM also requires a BR ...) .word blkno ;block # you'll be writing this one to .blkw 253. ;(junk for the rest of the block) ... and copy them to the first N blocks of the SCSI disk. Then when you move it to the PDP-11 and boot from it, it'll halt, and if you examine the word at 000004, you'll know which actual block was read in as block 0. Then next time write your image starting at that block instead of 0, and it might work. If you wanted to get *really* fancy, maybe you could set up a Linux (etc.) box as a SCSI target, and log the actual block #s accessed by the PDP-11? Seems kind of ridiculous... John Wilson D Bit