I kinda wish some of the FS utilities were better. Despite FUSE, mounting a block device (like, disk image) as a non-root user is tough, so writing to an image with actual partitions/FS on it is difficult, especially to script, especially if you don't want to sudo in a build script. losetup on a disk image doesn't (to my knowledge) detect partitions… for reasons unknown to me.<p>Bootsectors are similar. You can't just install grub to a disk image. (You have to losetup it, at the very least, which implies root. Why can't I just install to a file?)<p>You want a script/build system that allows you, at the very least, to:<p>1. Code.
2. Run build system/script.
3. Fire up qemu or similar.<p>You can't be rebooting. Ideally, it'd be great to do this in userspace.<p>That said, if you're starting out, just do [boot sector] + [kernel] = tada image until you need to do otherwise. (Really, do whatever works and is easy.)<p>That said, I've found a few somewhat helpful tools.<p>fuseloop[1] takes a file and offset/size, and exposes a single file. If you have a partitioned disk image, then you can feed it the partition offset, and it gives you back something you can format as an FS. (e.g., you can run ext2fs on.)<p>Then there's fuse.ext2[2], which mounts an ext2 FS on FUSE, so non-root usable again. Note that I'm linking to my fork of it, since the original didn't build for me, but I didn't write it. (Which I fixed, and sent a pull request, but never heard back.)<p>Finally — and sorry to peddle my own stuff again — I wrote a Python library for dealing with the MBR.[3] I use it to figure out offsets and sizes in a disk image.<p>I've had a bit of fun writing a boot loader, and I've managed to get it to load up its stage 2 and switch to 32-bit pmode. Had a fun error where a division instruction was throwing things into a triple fault; see [4] if you want to see how a division instruction can fail <i>without</i> dividing by zero (which was the first thing I checked). The disk layout is currently:<p><pre><code> [boot sector] [stage 2] [kernel] [ partitions, FS, real data, etc. ]
</code></pre>
stage2's size is hard coded into the first sector of stage 2 (into itself), and the kernel's location and size will be similarly hard coded into it as well. (When I get there. Disks in pmode are different, as you can't just have the BIOS do all the work for you, sadly!) And by hard-coded, a build script calculates and just re-writes a few bytes.<p>[1]: <a href="https://github.com/jmattsson/fuseloop" rel="nofollow">https://github.com/jmattsson/fuseloop</a><p>[2]: <a href="https://github.com/thanatos/fuse-ext2-fakeFS" rel="nofollow">https://github.com/thanatos/fuse-ext2-fakeFS</a><p>[3]: <a href="https://github.com/thanatos/pymbr" rel="nofollow">https://github.com/thanatos/pymbr</a><p>[4]: <a href="http://stackoverflow.com/questions/21212174/why-cant-i-step-over-this-div-instruction" rel="nofollow">http://stackoverflow.com/questions/21212174/why-cant-i-step-...</a>