Although it might sound odd, creating your own distro from scratch makes sense in certain situations:
- you want to create a small self-contained (eventually read-only) system that delivers only those components that you want
- it might be, for instance, a rescue disk, a diagnosis toolkit, whatever
- you want to create the base of a system that you are going to deploy on your entire organization and, of course, to control and to maintain it by yourself; you want also that every component being installed to be tuned for that particular hardware and for that particular user usage.
- you design an embedded system and you need a basic OS to help you to control the hardware.
- you only want to have some fun and, being wired like me, you haven't found anything more exciting than spending few hours/days building step by step the entire GNU/Linux system.
To get a grasp of this idea it would worth mentioning that you could, with little effort, create a self-contained system just enough to run the Apache web server, and this in only 5-8MB of disk space!
When I'm saying "create your own GNU/Linux system" I mean exactly that, a GNU/Linux system and not a system developed from scratch by yourself (including the kernel, system tools, etc). That would not be wired but a tremendous effort which, despite the fact that it will pay off eventually, it would require more than a 100-lines post on my blog.
The whole idea is to start with a working (HOST) system, an empty hard drive (or a raw disk image) and by downloading, compiling and installing some applications/libraries from the Internet on that new disk, to end with a self-contained working GNU/Linux system assembled step by step by yourself.
Linux system From Scratch (LFS)
Unlike the other GNU/Linux distributions out there (Gentoo, Sorcerer,etc) the LFS is a type of an online book that will guide you step-by-step how to install a Linux From Scratch (thus LFS). It's very well detailed (like a install Linux From Scratch for dummies) and the team that maintain this project are willing to help you on their IRC channel. Of course, if you work by the book the chances to fail are minimal.
I did it, it was fun, I've ended with a 600M disk image (a SMP x86_64 GNU/Linux tested on a qemu emulator; user=root, pwd=lfs) that contains the base of a working Linux system (no X11, of course). In a nutshell, the steps I've done are the the following:
- create a raw disk image file (dd if=/dev/zero of=image.raw bs=X count=Y)
- create partition and filesystems for your disk (fdisk/mkfs.ext*)
- create a filsystem hierarchy based on the standards set for UNIX-like operating systems (/bin,/boot,/dev,/etc,/home,/lib,/media,/opt,/root,/sbin,/tmp,etc).
- create a compiler toolchain for your new system:
- step1: download/unpack/configure/install the Binutils,GCC,Linux API Headers,GLibC using the HOST GLibC library (dependency by the HOST system)
- step 2: configure/install the Binutils,GCC using the newly create GLibC at step 1 (now it's an independent/self contained toolchin)
- download/unpack/configure/test/install the libraries/applications for a temporary system (like ncurses,diffutils,coreutils,findutils,grep,sed,perl,tar,bzip2,xz,gzip,etc)
- download/unpack/configure/test/install the libraries/applications that will be self-contained, independent base of the new system (like Linux API headers,GlibC,Binutils,GCC,Util-linux, E2fsprogs, Shadow, Coreutils, Inetutils, Perl, Autoconf, Automake, IPRoute, SysVInit, Udev, GRUB, etc)
- create/configure the system bootscripts (like /etc/hosts,/etc/sysconfig,/etc/resolv.conf,/etc/sysconfig/network,/etc/sysconfig/clock,/etc/rc.d/*,etc/init.d/*,/etc/inittab,/etc/fstab,etc)
- download/unpack/configure/install the Linux kernel
- install the GRUB boot loader on the disk, configure the boot menu, reboot the new system
If you would stick to the English localization and if you are willing to discard the Linux documentation/manuals, you could easily lower the disk footprint to 300MB. If you would discard the GCC compiler toolkit and its libraries you could shrink the whole thing to 100MB. If you want something more extreme, like the 5-8MB Apache web server in the example above, you would need more time to test and to shrink every bit of it but the bottom line is that "it's possible!".
Now, if you think that this article was interesting don't forget to rate it. It shows me that you care and thus I will continue write about these things.
Eugen Mihailescu
Latest posts by Eugen Mihailescu (see all)
- Dual monitor setup in Xfce - January 9, 2019
- Gentoo AMD Ryzen stabilizator - April 29, 2018
- Symfony Compile Error Failed opening required Proxies - January 22, 2018
Thank you very much for this interesting article! Can you please write down the command line used for the qemu? I tried your image but the qemu freezed...
It is a SMP x86_64 GNU/Linux disk image that I run via libvirt (Virtual Machine Manager). Anyway, libvirt or not, it is a process that has a command line after all. That command looks like :
/usr/bin/qemu-kvm -name LFS -S -M pc-1.2 -enable-kvm -m 512 -smp 2,sockets=2,cores=1,threads=1 -uuid 11e4b4d3-917d-fd21-213e-7e73da65194a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/LFS.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/eugen/Dev/rpi/lfs.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=19,id=hostnet0,vhost=on,vhostfd=20 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:86:89:be,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
Of course, these settings have something to do with the drivers/devices that I wanted to enable for my virtual machine. You can discard easily many options shown here and just run the the whole thing like:
/usr/bin/qemu-kvm -name LFS -m 512 -smp 2 -enable-kvm /lfs.img
Thank you for your response almost a year ago...
I'm trying to automate the build process for LFS 7.3 with a bash script. I almost finished but the last point 'install the GRUB boot loader on the disk'. I call grub-install from the chrooted environment, it finished without an error. But if I run the image afterwards with qemu the grub rescue prompt appears (UUID error). If I install grub from outside the chrooted env. then it works. How did you call grub-install? I use a loop device not a physical disk.
Thanks in advance.
Although it happened one year ago I remember that I encountered the same problem.
I don't remember exactly what was the solution but you can easily find a solution on web: http://bit.ly/1cDO14T
I forgot to add the --modules switch with part_msdos in grub-install. So I got finally a script which creates an image file, resizes the fs and partition and truncates the image file to its minimum size and at the end (after a couple of hours) runs under qemu...