[Tinkerphones] makesd (was Re: [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts)

Paul Boddie 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 
stage:

https://www.elinux.org/How_to_make_a_debian_rootfs_for_MIPS_CI20

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 
itself.

(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:

https://hg.boddie.org.uk/qi-emdebian

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.

[remakesd]

> 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 
instead.

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 
this:

----

partition debian
type: ext4
root: debian
kboot: latest
dboot: latest
modules: latest
config: latest

partition lxde
$debian
root: lxde

partition lc8-boot
type: fat
size: 5
boot: Letux-Cortex-8/latest
kernel: latest
devices: latest

partition lc8-root
$lxde
kernel: none
devices: none
size: 95

system lc8
$lc8-boot
$lc8-root

----

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:

----

system lc8
$lc8-boot
$lxde
kernel: none
devices: none
size: 95

----

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 
another partition?

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 
definitions:

----

[Debian]
packages=udev busybox-static
packages=openssh-server openssh-client
...

----

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.

Paul

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:

https://lava.collabora.co.uk/static/docs/v2/index.html

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 
obvious.


More information about the Community mailing list