[Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts

H. Nikolaus Schaller hns at goldelico.com
Mon May 27 16:28:15 CEST 2019


Hi Paul,

> Am 27.05.2019 um 12:33 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Tuesday 21. May 2019 23.29.43 Paul Boddie wrote:
>> 
>> I can't judge what is conservative or not, but the first thing I thought of
>> was this:
>> 
>> https://wiki.debian.org/vmdebootstrap
> 
> It appears that it now has a successor:
> 
> http://git.liw.fi/vmdb2
> 
>> And, of course, it is deprecated. Good thing I never paid it any attention
>> when people were talking it up! More here:
>> 
>> https://wiki.debian.org/SystemBuildTools
> 
> So, in the context of the makesd script...
> 
> http://projects.goldelico.com/p/gta04-makesd/
> 
> ...I had a look at what kind of tools might also do the same job. The tasks 
> makesd appears to do are as follows:
> 
> * Downloads pre-built bootloader, device tree, kernel, modules, root
>   filesystems
> 
> * Partitions a disk according to device expectations
> 
> * Formats filesystems
> 
> * Unpacks or copies the different payloads into their destinations

Exactly. It is coming not from theory but practice and has evolved over
the years into a simple workhorse. Features were added where needed
and over the years some of the underlaying tools had changed.

So it basically is a macro processor which allows to describe how to
partition and fill an SD card with a bootable system for the most
common bootable SD card schemes we find for OMAP, i.MX, Broadcom processors.

It also knows abbreviations for many components for the SD card so that
nobody has to type http: links or run gunzip manually.

Key principle is: people need a useful SD card for first boot of a naked
device which may not have any external interfaces. So you can't bootstrap
in on the device itself.

Most SBC vendors provide some .dd or .tgz files for this purpose which
need to be manually fetched, extracted and copied to the raw SD card.
In most cases the SD card size is fixed (e.g. 1GB) even if your destination
card is bigger. And for every board there is a different download location,
download and installation procedure - and finally every board has a different
password, different preinstalled packages, different kernel version etc.

This is what makesd (and LetuxOS) wants to get rid of. Have a single OS
that runs everywhere (almost) the same. Like macOS or iOS or Windows can
be installed on any current hardware without need for "configuration".

> 
> Not wanting to spend weeks looking at this, I briefly looked at the following:
> 
> ELBE - https://elbe-rfs.org/docs/sphinx/article-elbeoverview-en.html
> 
> Seems very powerful, but is also rather heavy, needs to use virtual machine 
> technology, has a verbose XML configuration language.
> 
> isar - https://github.com/ilbers/isar
> 
> Seems to be oriented towards building root filesystems, delegates image 
> generation and other such tasks to other tools, needs qemu.
> 
> FAI - https://fai-project.org/
> 
> Seems powerful for its intended use but overkill and maybe not even completely 
> appropriate for the more modest goals being considered here. Also needs qemu.
> 
> Boxer - https://wiki.debian.org/Boxer
> 
> Since Jonas is the author and maintainer of the software and Debian package, 
> he can correct me on my impressions. This appears to be a framework for 
> performing system configuration tasks, maybe even deployment, but the Debian 
> source package doesn't seem to contain much of immediate use (at least to my 
> eyes).
> 
> Meanwhile, I took a closer look at makesd itself. It seems like a very capable 
> script but is also rather complicated. Out of curiosity, I wanted to see if I 
> could break it up into smaller pieces that are easier to inspect and maintain. 
> Consequently, I ended up rewriting functionality, investigating some awkward 
> issues with sfdisk, and generally spending more time on doing all of this than 
> is perhaps worthwhile.
> 
> Still, my ongoing efforts can be found here:
> 
> https://hg.boddie.org.uk/remakesd

I have looked into it but did not get the feeling that it is easier to maintain
than a single script file which is broken up into shell functions. With multiple
files, you have to open them separately to get the overall structure. Maybe that
depends on the source code editor you have...

Makesd just defines a set of shell functions and then runs through the main
code in a predetermined sequence (parse arguments, setup partitions, format
the partitions, extract files into the partitions, fsck and umount everything).

So it is just an SD card baking recipe with some common subroutines.

And it is tied closely to a server infrastructure which provides the files
to be installed at certain well known locations.

BTW: maintaining makesd is a recreational walk compared to maintaining kernel
drivers that are not upstream and where others break in-kernel APIs without
documentations besides the code or similar drivers...

> Eventually, I will get round to looking at more substantial things, of course.

The key question I have is what you think is missing or wrong with makesd that
you did spin your own or did you just want to learn something? Which is mostly
my motivation to do something myself, even if similar things exist. We are
tinkerers...

BR,
Nikolaus



More information about the Community mailing list