Try it like this:
sfdisk --force -C $cylindernum -S $sectors -H $heads $device0

Isn't a loop device already equivalent to a partition? And if so, isn't it a non-sequitur that a partition table can be written to it? I think you need something that is more like a block device, not a partition. I don't know of any such thing, but I won't say it doesn't exist.
And, doesn't the device driver for the block device abstract the physical geometry of the device into just 'blocks', so you don't have to worry about all of the OP's concerns? As I understand it, you should just have to write blocks to the device, and the geometry will look after itself.

--- rod.

I was wondering some of the same things. I think geometry is relevant with actual hardware, which is the ultimate target, so the image should probably have the same geometry as the drive. On the other hand, I'm not sure how you access the partitions of the loop device, unless you somehow deduce the minor numbers and then mknod them.
Kevin Barry

if you look at my OP it has the how to of how to mount partitions out of a loop device, you can either do it with a mount or a losetup offset. you need to calculate the offset, which is the point of trying to specify geometry.. i know.... PITA

The first sector of a disk image is the MBR -the partition table is in the last part of that. But the partitions start after that. The offset used in the OP's link is used when the partitions are being formated and/or written to -the filesystem there.

To create and/or edit the partition table, the image needs to associated to a loop device without any offset. To loop-mount to any particual partition on the image, then you need to use the proper offset, although on some systems you may get a single block device with pasrttions showing just like with a normal hard disk.

Since the OP wants to eventually dd the image to a raw device, the size and geometry can matter -especially if the raw device is not the same size as the image. Plus, assuming he wants to create a bootable device, the size, geometry and partition scheme makes a big difference as those are the things that different BIOS's look at to decide if a device looks bootable. A good example is the old zip disks -they could one of two different sizes, but what really makes them get recognized is that there is a 4th partition marked bootable.

ISO images using eltoro look like fat floppies to the BIOS. There is a tool which comes with syslinux which lets you write the first sector in a way that it can be seen as an ISO or as hard-disk. makebootfat has some other tools which make a boot-sector look bootable to many machines.

ive also posted this on another site, but nobody seems to know! mebbe ill go ask the people who make sfdisk if i can... thanks anyway for all the answers!

Okay, so I'm now trying to figure out whether the problem is how to create an image file with the accordant partition table, how to script that process, or how to mount partitions from an existing image file on loop devices.

I tried the example recipe from the link in article #1, and it seems to work fine, and made good sense to me. So if that is the hangup, I cannot contribute any solution there. If the objective is to mount partitions from an image of a block device (or 'raw device' as described by gnashley), then I think you should look at the tool kpartx (an unfortunate choice of name). Google will point you to some help on kpartx.

So that leaves the scripting issue, and that one is probably the most difficult to overcome. I would suggest considering a couple of different approaches to that problem. First, the expect tool, which is made for just the purpose you have, which is to supply input to a console-mode program, as if it were being typed by a human. I would consider expect to be the definitive solution in this case. There is also the possibility of of running a process insode of a Gnu screen session, and using its stuff command to provide a scripted form of input. This is conceptually similar to the expect method, and I would consider it a poor substitute. Without having looked deeply into the problem, I suspect it boils down to tools like fdisk not using stdin for its input, but instead using direct tty input, which is not readily subjected to redirection.

---- rod.

loving your quote ive been fixing this for days now, and i have successfully broken everything

im sure its trivial to partition a loop image manually via fdisk or some such, but my problem is in scripting it. i want to know how to script putting a bunch of partitions onto a loop device in a way where i can mount the partition easily (and using this howto in the OP, which says i need to set geometry in order to accurately mount the partition) and then to be able to dd that image direct to eg /dev/sdx...

im aware of kpartx and expect but i havent tried either although ive done a lot of expect stuff with other things. with fdisk, i feel like its a little bit of a large tool for the small job.. and also ive seen a bunch of people on the web who seem to have successfully scripted fdisk and sfdisk with the here document thinger (EOF)... im sure im just not doing something right here in terms of setting the geometry. i shall look at kpartx as suggested and report back, thanks again for the help guys, i shall release this script to the community once im done, which allows you to extract, chroot and customise linux and *will* be able to write loop images for usb and cd and then write them to the preferred media, including encrypted partitions, which ive completed but this bit is basically the last step

You might look into dmsetup, although that seems like it could be a world of hurt. I've really only used it for encrypted block devices.
Kevin Barry

Okay, I think I know something about at least part of the problem. Your script didn't include the final newline, following the 'q' command. I used the example recipe from the posted link as a test to create a disk image (junktest.img), with no partition table. Then, I crafted the following recipe file (recipe.fdisk):
Note the blank line at the end of the file. This is what results from a newline following the 'q'. When I feed the recipe file to fdisk stdin, it successfully creates a partition on the image file.
I test the result:
My image file is much smaller than the example, but the principle still seems to work.

--- rod.

hey rod, i just tried that, no joy here, same stuff, edited with vi so im sure the newline is there, same old thing though fdisk hangs there, waiting for something no idea what
then hangage again... looking through the strace there are lots of cuda and nvidia calls in there, dunno why.... i installed cuda a while back but nothing is running...
ill investigate this further...

im assuming that dmsetup is for encryption stuff ? i already have the encrypted stuff working fine with lvm, its just this geometry thing...

It's more general than that. As far as I know, you can arbitrarily map sections of block devices so that literally any part of a disk can be treated as an independent block device. You can also combine different disks into one device. Anyway, it might make mounting the individual partitions easier.
Kevin Barry

thankyou kevin, ill try that as well and report back...

You aren't trying to modify the partition table while there are mounted partitions, are you?

--- rod.