The Tar Pit

Abstract: Cuntoo is a gargantuan beast (Gentoo), tamed by a few human-edible bash scripts aiming to whip it into a usable operating system for The Most Serene Republic. Following a very limited amount of experience with Gentoo and a somewhat decent understanding of Trinque's bootstrapper, I am jotting down various notes on my experiences so far in getting this up and running. Please read below for the gory details.

For the first part of this adventure, the environment: I deliberately chose to run my experiment on QEMU, an emulator and virtual machine monitor -- considering that I made use of Intel's modern-schmodern hardware acceleration features combined with Linux's KVM, all this to get some decent compilation times. Yes, QEMU is a piece of shit, but it's one that gives its users the illusion of complete access to the "hardware" interface and software infrastructure, the latter including a x86 BIOS. This comes as a boon for the software-inclined¹ among systems folks, which is perhaps one of those sexy things that attracts "software developers" to virtualization like flies to horse dung. This long parenthesis aside, it's very useful when you have an overprovisioned box around and you'd rather use that one for some testing than buying new hardware.

By the way, LXC or some other container-based thingamajigg should work just as well for this purpose. In any case, what you want to do is make yourself a disk image, e.g.:

$ qemu-img create -f qcow2 test.qcow2 10G

which will serve as the image for the test OS, i.e. the environment where the Cuntoo bootstrapper will run. Moreover, Cuntoo needs a target disk, where the bootstrapped system will reside -- on a real machine, this would be a USB stick or a second hard-disk or whatever. This'd be created exactly the same way²:

$ qemu-img create -f qcow2 cuntoo.qcow2 20G

This is where I should add some intricate details about booting a QEMU VM instance with the two disks plus a heathen operating system ISO image. I won't; please study the QEMU manual if you intend to do this.

Since it's becoming apparent that I'm trying to shoot myself in the foot, I've chosen to install on test.qcow2 a Debian Wheezy³ image, because ideally one should be able to bootstrap Cuntoo off any Linux-based operating system that hasn't been completely taken over by wreckers. It's never as easy as that, of course, but let's see where this leads us, shall we?

Given our Debian on test.qcow2 (or /dev/sda, as the OS calls it), our goal is to bootstrap a fully working Cuntoo system on cuntoo.qcow2, which from the bootstrapper-OS view is /dev/sdb. The first step towards that is to get a kernel config going. Thus, knowing that Cuntoo runs a 4.9 kernel, we download the 4.9 Linux release off kernel.org or whatever, then we run

$ make menuconfig

and go through the lengthy tree of configuration options, carefully selecting whatever works best for our QEMU VM⁴, resulting in a Linux kernel config which I named 4.9-qemu. Then, using Trinque's document as a guide, we verify and unpack the cuntoo tarball, we copy 4.9-qemu to the config directory and we run:

$ ./bootstrap.sh -k ./config/4.9-qemu -d /dev/sdb

and after waiting for a few hours -- the thing went at snail's pace, because fuck, I forgot to give this more CPUs! note to self for next time I reboot the thing -- we notice that the bootstrapping process has stopped and emerge gives a weird error when trying to install Python, along the lines of:

configure has detected that the sem_open function is broken.
Please ensure that /dev/shm is mounted as a tmpfs with mode 1777.

So looking at /dev/shm, we see that it's a symbolic link to nowhere, i.e. /run/shm, a directory which exists on the Debian system, but not in cuntoo/build, i.e. the place where the bootstrapper prepares a chroot jail for the new root filesystem. So we have /run mounted as a temporary filesystem, which means that we should maybe add a

mount --rbind /run run

to cuntoo/scripts/prepare_chroot.sh, in prepare_chroot⁵.

After getting that out of the way and after adding more CPUs to our virtual machine, we're now ready to run the bootstrapper again... and then yet again, after, as discussed in the second footnote, adding more space for the bootstrapping process. This time, the script stops at the kernel build phase, waiting for me to provide a few more kernel configuration options, which by the way, results in a second kernel config, 4.9-qemu-gentoo.

So now we run the bootstrapper yet yet again with the new config, which finally results in a genesis.vpatch. However, the signature doesn't verify against Trinque's key, which led me to look at the comments⁶ -- fortunately, Lobbes provides his own genesis, which supposedly gave him a working Cuntoo system. So diffing my genesis.vpatch file against his, I notice some very weird paths being created in cuntoo/portage, containing some pieces from my Debian system! After digging through the scripts which create those paths, more specifically make_portage_tree.sh, I notice that the destination path is set by the following line:

    dest=$pdir/profiles/${src#/mnt/trove/src/cuntoo/build/usr/portage/profiles/}

I have no fucking idea what mnt slash trove is, so I change the line to:

    dest=$pdir/profiles/${src#$bdir/usr/portage/profiles/}

in collect_used_profiles, where bdir is set before said function is called.

Rerunning the bootstrapper now finally yields a genesis.vpatch that is identical to Lobbes' and which verifies against Trinque's signature of the Keccak V patch. Now that I have all this, I should at least expect it to run, shouldn't I? Well...!

Let's not get ahead of ourselves: for some reason the QEMU Linux kernel I built insists to label the newly bootable disk as /dev/sdb instead of /dev/sda⁷. So I had to chroot into the Cuntoo system and update my LILO to point to /dev/sdb3 et voila, I finally have a bootable Cuntoo in front of me. All in all, arriving here required about two weeks of bootstrapper runs, modifications and reruns, accompanied by time passed waiting for those 4-hour builds to finish -- the GCC 5.4.0 -> 4.9.4 fandango in particular is truly depressing, especially since building GCC 5.4.0 on systems with less than 3GB of RAM causes the build to crash. So what can I say, if you ever meet the Gentoo maintainer who committed this atrocity, or perhaps any Gentoo maintainer at all, grab the nearest blunt object and hit the fucker as hard as you can.

I'll leave the reader with a few comments:

Comment the first: I could verify my genesis against Trinque's signature in the end, which is all nice and well. However, I did require a reference genesis.vpatch to do any debugging, and I'm not sure that this is even sufficient. Don't get me wrong, I very much like the idea of using the bootstrapper's output as a basis for further ebuilds, but what am I going to do if I can't even debug the process of producing a verifiable basis?

Comment the second:

spyked@cuntooer ~ $ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, stripped

I really don't know whether the Musl-GCC 4.9 toolchain should have spat statically linked binaries, or whether I need to do a world rebuild, or what.

Comment the third: I made changes to the Cuntoo scripts and I have no sane way of publishing them. Shouldn't the bootstrapper itself, or maybe just the text included therein, come in the form of a genesis?

Comment the fourth: Emacs doesn't compile on my new system; and from what I understand, it's not possible to compile Emacs using Musl. Does that mean that Cuntoo and Emacs are mutually exclusive? I suspect there's no easy way out of this, probably a hero will have to saw the glibc-isms apart from Emacs at some point... or not, in which case I'll be left without a SLIME and with a horrible development environment for my Lisp stuff.

Comment the fifth: if I understand correctly -- and please do let me know if I'm wrong, because I hope I am -- Cuntoo still relies on downloading pieces off Gentoo mirrors in order for the bootstrapping process to complete successfully. This means that when -- very pointedly when, not if -- GCC 4.9 disappears off the Internets, no one will be able to use this anymore. So what do? This IMHO is a very important problem.

Comment the sixth: tries to make two points, one minor and one major. The minor point is that the scripts could be reorganized/recompartmentalized a tad, so as to allow the user to do partial bootstrapping runs, followed by later reruns, e.g. if a kernel build has failed at some point, then one could simply remount the target partition and rerun it without going through all the intermediate steps. Which brings us to the major point: this is probably obvious to those who've already been through the bootstrapping experience, but the Cuntoo bootstrapper is very different from ye olde "OS installers", in that you can in general expect it to fail midway for some reason or another. That's fine from my point of view, as long as there's some means of efficiently finding out the root cause and some means of fixing the problem and restarting the process, preferrably without fear that it's gonna fail again at the same point. More importantly, I'm not sure whether it's the best idea to target this at newbies coming from Windows⁸, at least not before going through some work to make the process one order of magnitude smoother, even if this "only" means documenting the whole thing to exhaustion.

Comment the seventh: I might have had a seventh comment, but if I did I forgot what it was. Well, I guess this is it then.

Filed under: computing.
RSS 2.0 feed. Comment. Send trackback.