[NCLUG] Bootable HDD image generation

[Stephen Warren]

I'm creating (for work) a tiny Linux "distro" to drive an embedded 
device. This system uses a DOM (Disk-On-Module) - essentially an IDE 
hard disk implemented using flash chips. We need to create disk images 
from a regular x86 PC.

We're using genext2fs and mkcramfs to generate images of the partitions 
themselves. This is working fine.

So far, generating complete disk images (i.e. including partitioning and 
boot-loader installation) has been something like:

# hook a physical DOM into a USB<->IDE device
# that gets detected as /dev/sda
# DOM is assumed to be pre-partitioned, manually
dd if=root_fs.ext2.img of=/dev/sda1
resize2fs /dev/sda1
dd if=var_fs.ext2.img of=/dev/sda2
resize2fs /dev/sda2
dd if=app_fs.cramfs.img of=/dev/sda3
mount /dev/sda1 ./mnt
./mnt/sbin/lilo -r ./mnt -b /dev/sda
umount ./mnt
dd if=/dev/sda of=hdd.img

This has a number of disadvantages:

1) requires root - our automated build systems don't run stuff as root
2) requires a physical HDD

I've seen patches to extend the loop device to support partitions, which 
I think would allow us to remove problem 2.

However, loop still requires root, and I'm not sure our build team is 
going to want to setup all kinds of sudo stuff for us.

Building an auto-install CD isn't an option, because the target device 
doesn't have a CD/DVD drive, and we can't attach one using e.g. USB.

So, does anyone know any interesting tools that'll help out? Something 
like genext2fs, but for entire partitioned hdd images *and* supporting 
lilo install!

Humm. I guess if I kept the kernel/initrd in a raw partition with no 
filesystem, then the sectors would be guaranteed contiguous, and I 
wouldn't need lilo to boot - something much simpler would work...

Right now, the hdd image we're generating is for a standard x86 
BIOS-driven PC. However, this could change in the future.

-- 
Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO
swarren at wwwdotorg.org     http://www.wwwdotorg.org/pgp.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nclug.org/pipermail/nclug/attachments/20050819/a81d035e/attachment.pgp>