Hi Paul, > Am 27.05.2019 um 12:33 schrieb Paul Boddie <[email protected]>: > > 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 _______________________________________________ Community mailing list [email protected] http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
