> Yes, unfortnately it states that it starts at cyl 0, head 1, sector > 1. can't mount it as a loop. Have been looking for a list of magic > numbers to try and manually locate and chop out the partition, but no > luck yet.
Converting disk geometries to block numbers is a pain and a half. Some numbers may be 0-based, others are 1-based, and it's not always a power of 2. What is the geometry (ie heads, sec/track)? 0/1/1 however should be block 63, 63 sectors/track is a fairly safe bet. mount ro,loop,offset=$((63 * 512)) diskimagefile emptydir Some partitions start 63 blocks (the S number) into the disk from where you expect, this includes the first extended partition (as that needs another partition table at relative 0!). What partitions do you expect? If you get stuck, let the silicon do the work and make a mount attempt every block. Log the result and let run in the background. Expect a big syslog. Extra points if you manage to work out the geometry thing and only attempt to mount on blocks which can theoretically carry a partition start (eg every 63rd, but it's not that simple and off-by-one errors will be biting you everywhere). Use the difference between fdisk -l and fdisk -lu to work it out... Stop after 4GB worth of blocks because offset= wraps around. If the first partition is bigger than 4GB, too bad... (Theoretically you could hack the kernel to interpret offset= as a block number.) That's assuming gpart has failed you, if 0/1/1 is all it managed to come up with it's not looking good (everyone knows this is always the start of the first partition on all PC hard disks, see fdisk -lu). That's a pretty detailed recipe now. If you make a script to work out the partition starts from a given geometry, do post it please... Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
