I wouldn't bother with this. There is an excellent project named Buildroot for the exact purpose. There is also Yocto but it generates bigger images in their recommended configuration but you can always tweak it.
Supermin solves a narrow case: how to distribute an appliance [Linux-based OS disk image] as a very small download (typically 100K - 1MB). It works by observing that the end user already has the files they need as part of their host Linux OS (eg. /bin/bash, /lib/libc.so), and the distribution is just a skeleton of the disk image, which is "filled in" on the end user's machine by copying the host files in at the last second.
So it's not really applicable here, although I understand people use supermin to build chroots for Docker (as the author of supermin, I wouldn't necessarily recommend doing that unless you understand the limitations).
What is actually needed here is libguestfs, which is a pure userspace tool for building disk images that doesn't require root access and is built for scripting/automation and security. We have a tool built on top of libguestfs called virt-builder which specifically churns out minimal Linux distros very quickly.
Sadly virt-builder can't build TinyCore Linux yet, although it probably should be extended to do that. It would be a lot simpler to use virt-builder, than to go through the tedious and dangerous steps outlined in the article.
Unrelated(ish), but thanks for mentioning libguestfs! I've been passively looking for the solution to the non-root filesystem access problem for a while.
Also, PSA: this project has a program that can read and write Windows registry hives.
These kinds of tools are very relevant when creating Docker base images - not all of us can afford to download 1.6GB just for Ruby. See the official Ruby baseimage vs Alpine + ruby package for example
As I get some pleasure out of writing scripts to build finely tuned minimal images like this, I found the article interesting. However, I think manipulating a qcow2 image directly via nbd is over-complicating it. I think it would be better to create a sparse file, mount that via a loopback device, work with that, and then convert it to a qcow2 image (or vmdk or whatever) at the end.
.qcow2 files have two main advantages when building system images compared to a loopback device.
First, when building a system image with make, it works best to have each step result in a separate image file so that make can rebuild your image when a dependency changes without having to completely start over. Using .qcow2 images means that only the diffs are stored in each image file, instead of having a dozen 4GB .bin files.
Second, because the loopback device requires root by default, you end up running "sudo make" as part of your build process. But with .vmdk or .qcow2 files, tools like libguestfs can mount the filesystem for manipulation without root. If you're planning to distribute your work, then "git clone && cd project && make" is more accessible directing your users to modify their user permissions or elevating to root.
When I've done this sort of thing in the past, the ability to work with a set of staged partial images was a very mixed blessing. It ended up being over-complicated and rarely taken advantage of. I've settled on local package repositories and a single image build step which compiles everything together.
The latter problem you describe, that of needing to be root, goes away if you don't use a loopback device but instead use a mountable filesystem image. `truncate -d1G os.img && mkfs.ext3 os.img && mount os.img mountpoint/` doesn't need root at any point.
Aren't these images typically built on designated build machines anyway? Sure you've got to develop it locally. But the majority of developer-consumers will get it from some distributor fed from a build machine.
The diffing is still a great point. I did not know that about qcow2 images. Do you have any articles then on incremental builds with .qcow2 images?
I'm not convinced that you're saving anything by avoiding nbd. You need to modprobe nbd and start qemu-nbd. Both single commands that you can cut and paste. What you gain is not having to convert an image at the end.
I am with mwcampbell. There's something to say for the minimalism/lack of dependencies - even if it is not much more complex to use nbd. You don't need qemu to create a sparse file, mount it as a loopback device and manipulate it as a new device from there. If someone needs a qcow2 file afterward, fine. But that doesn't /need/ to be involved in the build step.
Thank you guys for all the links to related projects. I need to create embedded Linux image for a project in the near future, so your links are quite handy.
Does anyone have an idea how a minimal base Linux image can run inside a browser? Like can we create a small virtual Linux server right inside a browser?
You need just the Linux kernel and Busybox in order to run Linux with a working shell. 2-4 MB all together I would say. My first Internet router ran a Linux from a 1.44MB disk 15 years ago.
You're in the right ballpark. I ported a network monitoring app to Linux and helped bring Linux up on a custom board a long time ago, and that device had 4MB for the kernel, shell/utilities and the application itself. It fit nicely.
Actually UEFI was very Intel-centric when it started out. It worked only on Itanium and x86. We (Red Hat) spent a great deal of time of a very talented colleague of mine porting it to Aarch64.
