VSOBFS-L: From VSOBFS to a Linux + toolchain installation --------------------------------------------------------- by an 2024 All parts of the project not covered by someone else's copyright are put in public domain. For jurisdictions which do not recognize public domain the project is under Zero Clause BSD license (SPDX: 0BSD) Copyright 2023-2024 an Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. v.0.3 2024-05-12 v.0.2 2024-05-01 v.0.1 2023-12-15 Scripts yielding a reproducible disk image of a Linux installation with a C99 toolchain, starting from the Minix-vmd disk image produced by VSOBFS. The only used specific binary blob is the one with a strongly proven provenance: the Minix-vmd disk image from VSOBFS. Requirements: ------------- - a POSIX-like OS on a 32+ bit CPU as a host for the building procedure - a Bourne sh compatible script interpreter - if the pseudo_compress.sh tool is too challenging for your sh, then you may need an ANSI C (C89) compiler to compile the trivial pseudo_compress.c tool necessary for an initial data exchange with the Minix-vmd installation - either an i486+ legacy-bios-compatible system emulator on the host system or a corresponding physical hardware with an IDE disk interface along with a means to write and read its hard disk (128MiB is enough) The host hardware and software does not have to be open-source, nor needs to be trusted. To ensure integrity of the resulting disk image, the build shall be carried out on as wide as possible variety of build platforms, origins and architectures, yielding always the same result, bit-for-bit. The outcome: ------------ A *reproducible* raw disk image with an mbr partition table and a Linux installation in the first two partitions, usable on hardware or emulators. When booted for the first time, it unpacks all OS data from a stash in the first partition. The disk is partitioned as if it were 512MiB in size. Then the installation can be easily used and modified via scripting, if you supply an rc script as a gzip-compressed tar file on the third unused partition of the disk. For an example see l_qemu.next-step-example.sh and z_*generic.sh scripts. The initial data: ----------------- NOTE! the data consists of four parts, all of them subject to your review, in different ways: START/ minvtin_ref_0 the Minix-vmd disk image produced by the VSOBFS project, to be generated by yourself and/or verified against multiple independent parties/mirrors sha256sum: 59db99726254488a61b554fa458e439de7d41da887673e66557bed28990da0c2 minvtin_ref_0 sha512sum: d0e01e3583aba0d970f52be64acfc7ff47ba6dc87e21e4258b19163125c3800c0ebe1ea42ed7fcec09373682fae95a38eaf0af44d526c9c46f4ed00d5c14af73 minvtin_ref_0 SOURCES/ mostly the historical data, present in multiple copies across independent sites, verifiable via checksums sources are given and CAN *NOT* BE CHANGED but they shall be verified for authenticity and/or audited for bugs and backdoors PATCHES/ the patches (to the sources), developed by the VSOBFS-L project, they DO need your review and understanding, because potentially we could implant harmful code there patches SHALL *NOT* BE CHANGED because this would make the result incompatible with reviews made by any parties without/before the corresponding change SCRIPTS/ the scripts which describe the verifiable bootstrapping sequence, they are *NOT* necessarily directly usable on each given host platform, moreover it is the intention that they *ARE* to be modified, to be used on a variety of even yet unknown platforms, to confirm and ensure the independence of the results from the building platform; these scripts SHALL NOT be seen as trustable and DO need your review before usage scripts ARE SUBJECT TO CHANGES BY YOU, there can be also multiple useful versions of them, not included in this original package, each of them MUST be analyzed before usage, the responsibility is yours! The resulting artefacts: ------------------------ l2426_0_ref is 116MiB, the partition table contains two partitions inside this size and a third partition covering 396MiB more as if the disk were 512MiB; that data can be added at will and corresponds to /dev/hda3 in the installation; the added contents is examined at boot for a hook signature and can be used to control the behaviour of the installation Tiny C Compiler is in /bin/tcc, the C library is mililibc, a port of Minix-2 C library (networking omitted), the modified builtin kernel bootloader works with mbr partitions. known bugs: execve() via symlinks and stty misbehave. the sha256sums calculated as in the scripts shall strictly correspond to the following: 8725ac5a6b5a50db6e865cddfd34f55933ae2cd5a877375f76f8665f8c9d3755 LINUX file tree 9efc4961ff1f1e67462b5f34357c4ad4abdd89f3461bc2fcc77dec1813c623ae l2426_ref_0 their sha512sums calculated in a corresponding way i.e. for disk images: sha512sum, for file trees: ( find . -type f | LANG=C sort | xargs sha512sum find . -type l | LANG=C sort | ( while read a; do printf '%s\n' "$a"; readlink "$a"; done ) ) | sha512sum shall strictly correspond to the following: 15a9d84687339efa43206af3f7704d670c21a65e7c6fadad2121f07095a2d02a9332ef04399ac901929b04f89c04479ce3a24eb3c6a7e1f6635b01ad1c9cd8be LINUX file tree 776440a6daac6127462272302d06b5593b6e017a6cc3006b45728401bc75bd771318ef03440461241dae7068debf345417ea36f04e57aa5c9e2df7d36bacb8ba l2426_ref_0 copies of checksums of the disk images (omitting those of the file trees) are also present in the files VERIFY_SHA256 and VERIFY_SHA512 End of README