Bug 3439

I tossed this out on Google+ and we got a number of good responses from the FS experts. The most promising is make_ext4fs from android:

http://gitorious.org/0xdroid/system_extras/blobs/8642b7fba54727a38f751516bcdc452fb09ef610/ext4_utils/make_ext4fs.c

Other suggestions included libguestfs (Fedora) and qemu, both of which spawn a vm and work with the FS using guest root privilege.

Some good discussion in the Google+ thread:
https://plus.google.com/u/1/101378268367730737515/posts/DoXJXurM8XZ

There are two basic approaches we can take. The first is to deal with each filesystem individually, which is what we do now. This is fraught with partially completed support for root directory pre-population and lacks a common mechanism which makes maintenance harder.

The second approach is to attempt a common infrastructure to use across all filesystems. libguestfs is one way to accomplish this. It connects to the VM FS using libguestfs, and then uses the guest kernel filesystem drivers to populate the image, rather than having separate userspace tools for every fs. Unfortunatley we still need the mkfs* tools in order to initialize each filesystem, so it doesn't save us much build complexity.

The libguestfs works something like this:

$ guestmount -a ext4.img -m /dev/sda mnt
$ echo "Hello world!" > mnt/helloworld
$ fusermount -u mnt

Devices will still require special treatment as indicated by the following failed attempts. This is something we deal with already, I suspect we can reuse that mechanism.

$ mknod ttyS0 c 4 64
mknod: `ttyS0': Operation not permitted

$ fakeroot -- mknod ttyS0 c 4 64
dvhart@envy:~/mnt/dev
$ ls -la ttyS0
-rw-r--r-- 1 dvhart dvhart 0 Nov 15 15:22 ttyS0

                           ^ not a device

I'm looking into how much overhead building libguestfs and guestfstools would add to our build time, something we must consider.

libguestfs is looking very promising, there are a couple pitfalls. One concern in particular is the issue with Ubuntu making their kernels (/boot/vmlinuz*) readable only by root (?!?!?!). This requires users to "chmod a+r /boot/vmlinuz*" which would of course require root permissions.

Some great information here:
http://libguestfs.org/guestfs-faq.1.html

Also note that libguestfs has C, Python, and other bindings which can be used to create partitions among other things. This has the potential to form the underlying infrastructure for our deployment mechanism.

The libguestfs dependencies are a bit scary, but we should be able to cut them down quite a bit, especially by limiting the language bindings. The febootstrap part of the build is... interesting, as it seems to build a different image based on whatever distribution you are running. Making this work within bitbake and host-agnostic might provide to be some tricky recipe writing. Build-time will be an issue. It took over 8 minutes on my dual-core i5 with "make -j4" (Thinkpad x220).

Ted just let me know if we were to send clean patches to support "mke2fs -r" that he would probably take them.

I think this might be the best approach. It would allow us to make incremental progress by removing the one major gap in the existing tooling for populating file-systems without root.

I'm going to have a look at how much effort this would entail and will report back.

To keep people posted I have made some progress on modifying mke2fs to prepopulate a newly created filesystem from an existing directory. I'll share patches as soon as it passes populating from a core-image-minimal rootfs dir.

As this bug was to investigate the options and determine a course of action, it can now be closed. The solution we are working towards initially is adding initial directory support to mke2fs, as described in Bug 3516

Setting to verified as per last comment.