Lilblue Linux: release 20140925. Adventures beyond the land of POSIX.

It has been four months since my last major build and release of Lilblue Linux, a pet project of mine [1].  The name is a bit pretentious, I admit, since Lilblue is not some other Linux distro.  It is Gentoo, but Gentoo with a twist.  It’s a fully featured amd64, hardened, XFCE4 desktop that uses uClibc instead of glibc as its standard C library.  I use it on some of my workstations at the College and at home, like any other desktop, and I know other people that use it too, but the main reason for its existence is that I wanted to push uClibc to its limits and see where things break.  Back in 2011, I got bored of working with the usual set of embedded packages.  So, while my students where writing their exams in Modern OS, I entertained myself just adding more and more packages to a stage3-amd64-hardened system [2] until I had a decent desktop.  After playing with it on and off, I finally polished it where I thought others might enjoy it too and started pushing out releases.  Recently, I found out that the folks behind uselessd [3] used Lilblue as their testing ground. uselessd is another response to systemd [4], something like eudev [5], which I maintain, so the irony here is too much not to mention!  But that’s another story …

There was only one interesting issue about this release.  Generally I try to keep all releases about the same.  I’m not constantly updating the list of packages in @world.  I did remove pulseaudio this time around because it never did work right and I don’t use it.  I’ll fix it in the future, but not yet!  Instead, I concentrated on a much more interesting problem with a new release of e2fsprogs [6].   The problem started when upstream’s commit 58229aaf removed a broken fallback syscall for fallocate64() on systems where the latter is unavailable [7].  There was nothing wrong with this commit, in fact, it was the correct thing to do.  e4defrag.c used to have the following code:

#warning Using locally defined fallocate syscall interface.

#ifndef __NR_fallocate
#error Your kernel headers dont define __NR_fallocate

 * fallocate64() - Manipulate file space.
 * @fd: defrag target file's descriptor.
 * @mode: process flag.
 * @offset: file offset.
 * @len: file size.
static int fallocate64(int fd, int mode, loff_t offset, loff_t len)
    return syscall(__NR_fallocate, fd, mode, offset, len);
#endif /* ! HAVE_FALLOCATE */

The idea was that, if a configure test for fallocate64() failed because it isn’t available in your libc, but there is a system call for it in the kernel, then e4defrag would just make the syscall via your libc’s indirect syscall() function.  Seems simple enough, except that how system calls are dispatched is architecture and ABI dependant and the above is broken on 32-bit systems [8].  Of course, uClibc didn’t have fallocate() so e4defrag failed to build after that commit.  To my surprise, musl does have fallocate() so this wasn’t a problem there, even though it is a Linux specific function and not in any standard.

My first approach was to patch e2fsprogs to use posix_fallocate() which is supposed to be equivalent to fallocate() when invoked with mode = 0.  e4defrag calls fallocate() in mode = 0, so this seemed like a simple fix.  However, this was not acceptable to Ts’o since he was worried that some libc might implement posix_fallocate() by brute force writing 0’s.  That could be horribly slow for large allocations!  This wasn’t the case for uClibc’s implementation but that didn’t seem to make much difference upstream.  Meh.

Rather than fight e2fsprogs, I sat down and hacked fallocate() into uClibc.  Since both fallocate() and posix_fallocate(), and their LFS counterparts fallocate64() and posix_fallocate64(), make the same syscall, it was sufficient to isolate that in an internal function which both could make use of.  That, plus a test suite, and Bernhard was kind enough to commit it to master [10].  Then a couple of backports, and uClibc’s 0.9.33 branch now has the fix as well.  Because there hasn’t been a release of  uClibc in about two years, I’m using the 0.9.33 branch HEAD for Lilblue, so the problem there was solved — I know its a little problematic, but it was either that or try to juggle dozens of patches.

The only thing that remains is to backport those fixes to vapier’s patchset that he maintains for the uClibc ebuilds.  Since my uClibc stage3’s don’t use the 0.9.33 branch head, but the stable tree ebuilds which use the vanilla release plus Mike’s patchset, upgrading e2fsprogs is blocked for those stages.

This whole process may seem like a real pita, but this is exactly the sort of issues I like uncovering and cleaning up.  So far, the feedback on the latest release is good.  If you want to play with Lilblue and you don’t have a free box, fire up VirtualBox or your emulator of choice and give it a try.  You can download it from the experimental/amd64/uclibc off any mirror [11].

3 thoughts on “Lilblue Linux: release 20140925. Adventures beyond the land of POSIX.”

  1. Did you change the µClibc configuration during the past year or the Lilblue configuration is the same as the one for stages (I know you switched from ~ to last April for Lilblue) ?

    Getting rid of pulseaudio was one the first thing I did when I installed Lilblue. As I said to my boss a few years ago «Moins de code, moins de bogues» (less code, less bugs). And Lennart code is very bad. I ban GTK+3 because their maintainers pisses off theme developers, non-GNOME developers, pulls more dependencies and GIMP does not use it yet. Damn, that toolkit name is GNU’s Not Unix Image Manipulation Program Tool Kit Plus!

    I use dash for /bin/sh (and busybox as /bin/ash) and I am currently in the init war. I installed runit, just to get rid of sysvinit while keeping OpenRC happy, as I use the init from busybox with an hybrid inittab. I just replaced eudev with mdev-like-a-boss (oops 🙂 . Next steps: measure mdev impact on bootup with classic bootchart 0.9 (/sbin/bootchartd from bootchart2 segfaults on µclibc), port Alpine Linux busybox-initscripts to Gentoo, patch Busybox applets so that BusyBox can be used with OpenRC.

  2. 1) I did not change the config file. I want to keep some backwards compatibility.
    2) mdev is okay for really simple systems, but I just can’t see it working on a desktop or any system that needs to respond to system events. I maintain eudev as a last resort against the systemd juggernaut.
    3) I’d be interested in tyour patches that get busybox working with openrc. See bug #468396 which I just have not had time for.

    1. > I maintain eudev as a last resort against the systemd juggernaut.

      Thanks for that! first thing I do when install new Gentoo on every computer — is “emerge eudev”. It’s PRIMARY and ULTIMATE thing. I have to move to Gentoo after Debian surrender to systemd.

Leave a Reply

Your email address will not be published. Required fields are marked *