6 ms·
Creating purpose-built TinyCoreLinux Images
- mwcampbell 11y agoAs 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.
- vidarh 11y agoI'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.
- eatonphil 11y agoI 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.
- elevation 11y ago.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.
- eatonphil 11y agoAren'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?
- regularfry 11y agoWhen 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.
- thoughtexpt 11y agoIs the Linux kernel compatible with multiboot specification yet? http://www.gnu.org/software/grub/manual/multiboot/multiboot.html http://www.gnu.org/software/grub/manual/multiboot/multiboot....
- stonogo 11y agoThe grub multiboot specification is short-sighted, x86 specific, and generally useless.
- voltagex_ 11y agoNot 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 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.
- rwmj 11y agoActually 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.
- diminish 11y agoDoes 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?
- mwcampbell 11y agohttp://jslinux.org/ http://jslinux.org/ 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?
- diminish 11y agoa test / development environment inside the browser where a server is emulated for testing purposes too, accompanied with a code editor. I d like to describe the vm configuration similar to chef or ansible in js and run some dev/test code.
- homarp 11y agoDepending what you want to do, there is also the OR1K Emulator running Linux - http://jor1k.com http://jor1k.com and a generic x86 emulator - v86 - https://github.com/copy/v86 https://github.com/copy/v86 you can check a small benchmark here: https://github.com/s-macke/jor1k/wiki/Benchmark-with-other-emulators https://github.com/s-macke/jor1k/wiki/Benchmark-with-other-e... via https://news.ycombinator.com/item?id=10498305 https://news.ycombinator.com/item?id=10498305
- s-macke 11y agoYou 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.
- vidarh 11y agoYou'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.
- serguzest 11y agoI 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.
- eatonphil 11y agoSupermin[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 http://people.redhat.com/~rjones/supermin
- voltagex_ 11y agoThese 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
- hoodoof 11y agoSupermin seems quite old. Perhaps an idea that has passed?
- rwmj 11y agoSupermin is actively developed. The last commit was 2 days ago. https://github.com/libguestfs/supermin/commits/master 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.
- rwmj 11y agoSupermin 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. http://libguestfs.org/ http://libguestfs.org/ http://libguestfs.org/virt-builder.1.html http://libguestfs.org/virt-builder.1.html
- jensmittag 11y agoThank 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.
- ilurk 11y agoCan anyone tell what are the differences between a TinyCoreLinux image and a Rumpkernel, and the practical implications of those differences?
- justincormack 11y agoTinyCoreLinux is just a small Linux distro. A rump kernel is a unikernel reusing netbsd code, running in a single address space.