logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Building-a-real-Linux-distro.md (6160B)


  1. ---
  2. date: 2017-05-05
  3. layout: post
  4. title: Building a "real" Linux distro
  5. tags: [linux]
  6. ---
  7. I recently saw a post on Hacker News: "[Build yourself a
  8. Linux](https://github.com/MichielDerhaeg/build-linux)", a cool project
  9. that guides you through building a simple Linux system. It's similar to Linux
  10. from Scratch in that it helps you build a simple Linux system for personal use.
  11. I'd like to supplement this with some insight into my experience with a more
  12. difficult task: building a full blown Linux distribution. The result is
  13. [agunix](http://agunix.org), the "silver unix" system.
  14. For many years I've been frustrated with every distribution I've tried. Many of
  15. them have compelling features and design, but there's always a catch. The
  16. popular distros are stable and portable, but cons include bloat, frequent use of
  17. GNU, systemd, and often apt. Some more niche distros generally have good points
  18. but often have some combination of GNU, an init system I don't like, poor docs,
  19. dynamic linking, or an overall amateurish or incomplete design. Many of them are
  20. tolerable, but none have completely aligned with my desires.
  21. I've also looked at not-Linux - I have plenty of beefs with the Linux kernel. I
  22. like the BSD kernels, but I dislike the userspaces (though NetBSD is pretty good)
  23. I like the microkernel design of Minix, but it's too unstable and has shit
  24. hardware support. plan9/9front has the most elegant kernel and userspace design
  25. ever made, but it's not POSIX and has shit hardware support. Though none of
  26. these userspaces are for me, I intend to attempt a port of the agunix userspace
  27. to all of their kernels at some point (a KFreeBSD port is underway).
  28. After trying a great number of distros and coming away with a kind of
  29. dissatisfaction unique to each one, I resolved to make a distro that embodied my
  30. own principles about userspace design. It turns out this is a ton of work -
  31. here's how it's done.
  32. Let's distinguish a Linux "system" from a Linux "distribution". A Linux system
  33. is anything that boots up from the Linux kernel. A Linux *distribution*, on the
  34. other hand, is a Linux system that can be *distributed* to end users. It's this
  35. sort of system that I wanted to build. In my opinion, there are two core
  36. requirements for a Linux system to become a Linux distribution:
  37. 1. It has a package manager (or some other way of staying up to date)
  38. 2. It is self-hosting (it can compile itself and all of the infrastructure runs
  39. on it)
  40. The first order of business in creating a Linux distro is to fulfill these two
  41. requirements. Getting to this stage is called *bootstrapping* your distribution -
  42. everything else can come later. To do this, you'll need to port your package
  43. manager to your current system, and start building the base packages with it.
  44. If your new distro doesn't use the same architecture or libc as your current
  45. system, you also need to build a cross compiler and use it for building your
  46. new packages.
  47. My initial approach was different - I used my cross compiler to fill up a chroot
  48. with software without using my package manager, hoping to later bootstrap from
  49. it. I used this approach on my first 3 attempts before deciding to make
  50. base packages on the host system instead. With this approach, I started by
  51. building packages that weren't necessarily self hosting - they used the
  52. host-specific cross compiler builds and such - but produced working packages for
  53. the new environment. I built packages for:
  54. * my package manager
  55. * musl libc
  56. * bash
  57. * busybox
  58. * autotools
  59. * make
  60. * gcc (clang can't compile the Linux kernel)
  61. * vim
  62. I also had to package all of the dependencies for these. Once I had a system
  63. that was reasonably capable of compiling arbitrary software, I transferred my
  64. PKGBUILDs (scripts used to build packages) to my chroot and started tweaking
  65. them to re-build packages from the new distro itself. This process took months to
  66. get completely right - there are *tons* of edge cases and corner cases. Simply
  67. getting this software to run in a new Linux system is only moderately difficult -
  68. getting a system that can build itself is *much harder*. I was successful on
  69. my 4th attempt, but threw it out and redid it to get a cleaner distribution with
  70. the benefit of hindsight. This became agunix.
  71. Once you reach this stage you can go ham on making packages for your system. The
  72. next step for me was graduating from a chroot to dedicated hardware. I built out
  73. an init system with runit and [agunix-init](http://git.agunix.org/init/) and
  74. various other packages that are useful on a proper install. I also compiled a
  75. kernel without support for loadable modules (on par with the static linking theme
  76. of agunix). If you make your own Linux distribution you will probably have to
  77. figure out modules yourself, likely implicating something like eudev.
  78. Eventually, I was able to get agunix [running on my
  79. laptop](https://sr.ht/OzCq.jpg), which has now become my primary agunix dev
  80. machine (often via SSH from my dev desktop).
  81. The next stage for me was getting agunix.org up and running on agunix. I
  82. deliberately chose not to have a website until it could be hosted on agunix
  83. itself. I deployed agunix to a VPS, then ported nginx and put the website up.
  84. The rest of the infrastructure was a bit more difficult: cgit took me about 10
  85. packages of work, and bugzilla was about 100 packages of work. Haven't started
  86. working on mailman yet.
  87. Then begins the eternal packaging phase. At this point you've successfully made
  88. a Linux distribution, and now you just need to fill it with packages. This takes
  89. *forever*. I have made 407 packages to date and I still don't have a desktop to
  90. show for it (I'm *almost* there, just have to make a few dozen more packages
  91. before [sway](https://github.com/SirCmpwn/sway) will run). At this point to have
  92. success you need others to buy into your ideas and start contributing - it's
  93. impossible to package everything yourself. Speaking of which, check out
  94. [agunix.org](http://agunix.org) and see if you like it! I haven't been doing
  95. much marketing for this distro yet, but I do have a little bit of help. If
  96. you're interested in contributing in a new distro, we have lots of work for you
  97. to do!