[Tinkerphones] makesd (was Re: [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts)
paul at boddie.org.uk
Tue May 28 13:20:26 CEST 2019
On Monday 27. May 2019 20.46.32 H. Nikolaus Schaller wrote:
> The pre-built images are just the result of a complete debootstrap in a
> fresh chroot on some ARM or MIPS SBC. Either bare bone with some minimal
> set of required or generally useful packages or with some more, e.g. a full
> GUI like Xfce or QtMoko.
Right. So they are already fully configured. This is the challenge when cross-
bootstrapping, and with the CI20 they recommend using qemu for the second
I never got that to work, and given that a lot of the package configuration
should be machine-independent (it shouldn't need to see specific hardware), I
would rather see some kind of generic configuration getting done, leaving only
a small amount of machine-specific stuff, if any, to the actual hardware
(Emulation is just a hack because there isn't a nice way of running host
programs to do the configuration work within the target environment. So one
ends up running emulated binaries that do the same things as host binaries,
discarding the portability and interoperability benefits of having a set of
programs that behave the same way and can act on filesystems and other things
regardless of the system architecture.)
So, I decided to use my own tool to make a root filesystem instead:
This runs the second stage on the CI20 itself.
> Configuration of the LetuxOS is now completely done by some
> letux-something.deb packages. So no single file is touched (well, there is
> some fallback at the moment that should be eliminated soon) besides through
> installing a .deb package. So it can also be removed or replaced (there are
> usually preinst and postrm scripts to make backups). The same for the
> kernel package.
This part starts to sound a bit like Jonas's Boxer tool and its objectives.
> Yes, I noticed that you are trying to make it a little more object-oriented
> by this approach, especially in the aspect of modularization and
> encapsulation of implementations.
> Unfortunately the bash isn't the best OO language :)
If I were really going for object orientation, I would probably use Python
I did think a bit more about the formulation of systems in makesd yesterday,
trying to understand how some of the options work, and it occurred to me that
if I were describing the partitioning scheme then I might use a notation like
The motivation here is that I want to be sure of how many partitions there
are, which is not immediately clear from the macro argument syntax. So,
partitions are described (using the argument names from makesd in the above as
parameters) and can be specialised. Thus, the "debian" partition is a general
description of "vanilla" Debian, but the "lxde" definition incorporates the
"debian" definition and specialises it.
What I would want to enforce is the separation of partitions and other things.
Here, I define the "lc8" system as incorporating two partitions. It would not
be allowed to just reference "lxde" and then add some overriding parameters:
This is because it would become difficult to see how many partitions there
might be, and the semantics would need to be considered about what happens
when partitioning parameters (like "size") are mentioned: do they declare
This kind of notation reminds me of other things, which I suspect might be
these "orchestration" tools people use for cloud computing and provisioning.
However, I think multistrap also has some similar notion of specialising
Here, from this extract of my CI20 configuration, the existing "Debian"
definition (not shown) is augmented by additional packages. Naturally,
multistrap focuses on root filesystem population, not partitioning, but the
customisation principle involved seems to be very similar.
P.S. In the wider Debian realm, I remembered that there is a Linaro-
originating project that tests single-board computers, and I had thought that
there might be some tools of interest within that. Here is the documentation:
But it seems like a very heavyweight thing, aimed at continuous integration.
And the documentation does not make the parts of interest to us particularly
More information about the Community