Creating purpose-built TinyCoreLinux Images(fabianstumpf.de) |
Creating purpose-built TinyCoreLinux Images(fabianstumpf.de) |
A nice buildroot tutorial: http://free-electrons.com/doc/training/buildroot/
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.
It's a clever hack, but I don't know of any practical application. Did you have one in mind? Or is it just for the hack value?
you can check a small benchmark here: https://github.com/s-macke/jor1k/wiki/Benchmark-with-other-e...
I d like to describe the vm configuration similar to chef or ansible in js and run some dev/test code.
http://www.gnu.org/software/grub/manual/multiboot/multiboot....
Are there any bootloader specs that are standard across architectures? UEFI comes to mind, and I'm sure you could boot an x86 board via u-boot.
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.
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.
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?
Also, PSA: this project has a program that can read and write Windows registry hives.
https://github.com/libguestfs/supermin/commits/master
Having said that, it's not relevant to what the OP wants to do. libguestfs, however, is very relevant.