21–30 of 33 posts
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.
A nice buildroot tutorial: http://free-electrons.com/doc/training/buildroot/
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[0] is another really cool tool that might be interesting. Though I still can't exactly tell if it's relevant. [0] http://people.redhat.com/~rjones/supermin
Earlier quoted context omitted.
Supermin[0] is another really cool tool that might be interesting. Though I still can't exactly tell if it's relevant. [0] http://people.redhat.com/~rjones/supermin
Supermin seems quite old. Perhaps an idea that has passed?
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.
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 .b…
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.
Can anyone tell what are the differences between a TinyCoreLinux image and a Rumpkernel, and the practical implications of those differences?
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[0] is another really cool tool that might be interesting. Though I still can't exactly tell if it's relevant. [0] http://people.redhat.com/~rjones/supermin
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.
Earlier quoted context omitted.
The grub multiboot specification is short-sighted, x86 specific, and generally useless.
Not useless , it's a useful thing to have when you're trying to learn how to write Hello World as an OS - http://wiki.osdev.org/Bare_Bones 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.
Earlier quoted context omitted.
Supermin[0] is another really cool tool that might be interesting. Though I still can't exactly tell if it's relevant. [0] http://people.redhat.com/~rjones/supermin
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…
Also, PSA: this project has a program that can read and write Windows registry hives.