This article might be of some interest to readers tuned in to my recent Debian adventures. I personally find it relevant within the larger area of bootstrapping systems, and while it perhaps doesn't bring much news, this field report serves as a reference on how to bring up a The Real Bitcoin node on top of this particular operating system.
So starting where we left off, we have a fresh, clean1 Debian system and we want to install TRB; how do we do that?
Looking at it from the airplane, TRB requires V, so there's two steps: a. build V, i.e. vtools; and b. press and build TRB. Of course, vtools requires a working Ada toolchain, so three steps: 1. build GNAT, 2. build V, 3. build TRB; except the first step requires an already working GNAT, so α. install a GNAT bootstrapper, β. build GNAT, γ. install a V bootstrapper, δ. press and build V, and ε. press and build TRB; so fourfivean endless array of steps!
As the reader's keen eye might have noticed, we're running into a multi-layered bootstrapping problem: V and GNAT require themselves in order to press and build respectively; and furthermore, vtools also requires a V (and thus a vtools), in addition to GNAT, to press and build itself. Fortunately for me, I already had ksum, vdiff and vpatch built on another machine, so a. I copied them; b. copied the V patches and seals for v.pl; c. manually verified the seals for the V V tree; d. manually applied each patch using vpatch. This yields a working v.pl, although at the moment we're still relying on our ksum/vpatch/vdiff from the starter kit. However, at this point we can't do anything without GNAT, so...
Bootstrapping GNAT. Similarly to the above, I copied an older GNAT (generated previously using Ave1's recipe) into my starter kit, along with said recipe, and I tried to run the bootstrapper. I noticed that the following software pieces were needed and missing from the system: bzip2, g++ (ugh!), flex, bison, patch, rsync and python (yuck!). So I installed them, then I noticed that at some point in the second-stage build, i.e. when the "native" compiler is generated, the configure script tries to build binutils with shared library support. After a few hours of trying to figure out what's actually, going on there, I noticed that build-native.sh does not pass --disable-shared to the binutils configuration script, so I added it. The result was a working GNAT compiler.
So we move on to:
Pressing and building V. We have a working v.pl, but no vtools. So using the GNAT compiler obtained above and the quasi-starter v.pl, we press and we compile vtools, which bootstraps the ksum/vpatch/vdiff piece of v.pl. Once this is done, we can finally press TRB.
Pressing and building TRB: We just grab Mod6's latest from the Keccak regrind, press and follow the instructions. Not much to add here except that I already have a working GNAT (including a gcc and a g++), so I could have also tried Mod6's buildroot-snip recipe. I didn't give it a try at this particular point, which on one hand means that we haven't used our fresh GNAT to its full potential, and on the other that the old buildroot-based recipe works on Debian without any issues2.
So now we can finally configure the node, sync it and so on and so forth, which is just about the scope of this report. For the record, it took me a full ten-hour day to get everything working, including hardware setup, Debian install and configuration and so on. I expect rereading the steps above next time will cut my time in half, which is what this was all about in the first place.
-
"Clean" as in "not yet soiled with whatever pieces we want to populate it with".
Moreover, this "clean" of mine assumes that only the base Debian system is installed: at some point during the install process, the user is asked to install other utilities, e.g. a SSH server, a web server, plus a "standard Debian system", which, if I remember correctly, includes a whole pile of unneeded stuff, such as a mail transfer agent, pythonisms and some other fancy shit. In contrast, the "base" install doesn't even include sudo, let alone particulars such as a text editor for the user to masturbate with; it has nano, sure, but otherwise, it's left to me to decide how exactly I want to shoot himself in the foot.
I know it's not exactly the fashionable approach to computing but what can I say. It's mine. ↩
-
For the reader's information, Debian Wheezy comes with a (glibc-based) GCC 4.7, which is perfectly usable for bootstrapping. The musl piece is still required for a sane environment though, so I've kinda duplicated things there going with both buildroot and GNAT. The GNAT piece alone should be more than sufficient, since it already does the same thing as the compiler built during the "buildroot" phase, plus it comes with a working Ada compiler. ↩
As Vtron is subject to "bootstrap problem", IMHO ought to be treated in the same way as the compiler -- i.e. made part of the basic OS install.
Indeedly!
For the record, that's what irks me about Debian: that it doesn't come with a compiler included in the base system, as if there's any separation between "building" and bringing up the system. One step further, it would make "debootstrap" a "batteries included" item, indistinguishable from Gentoo's emerge world or FreeBSD's make buildworld, which would close that damned bootstrapping loop already and it would turn the OS into the infectious beast that it's supposed to be.
[...] story short, for those who are still tuned in: following my recent adventures getting a TRB node up and running on Debian, I proceeded to get it to sync with the rest of the network over some period of time. Alas, [...]
[...] http://thetarpit.org/2020/building-trb-on-debian-wheezy-a-report << The Tar Pit -- Building TRB on Debian Wheezy; a report [...]