I am slowly getting back into building the next Turtle Kevux distribution.
This distribution is being re-developed in parallel to the Featureless Linux Library.
I am testing out the 0.6.x releases of the FLL and the Controller program.
The Controller program is not truly part of the FLL.
This program is in the 0.6.x release of the FLL for convenience reasons but will soon be separated into its own dedicated project.
The problems and missing functionality discovered while trying to utilize the 0.6.x version of the Controller program will be developed either in the 0.6.x release (for non-breaking changes) or the 0.7.x.
As for the Turtle Kevux distribution, I have the system now booting.
I experimented with the trying to build the kernel without the hard disk drivers compiled in.
I want to use two initrds such that the first is the filesystem that does not change and the second contains the kernel modules.
This will take more time to figure out than I am willing to spend on this.
I decided to go back to the old way of booting the system and I am compiling the disk drivers into the kernel.
I can now focus on the Controller program as the Init program with the kernel now booting and with a working initrd (which is actually an initramfs, technically speaking).
The first problem is that it boots way too fast.
Instantly.
Probably because I am using an example template that is incomplete and theoretical.
All of the messages and errors fill the screen before I can see the first message.
A second problem is that the agetty program doesn't like something about the Init program using the console and has segmentation faults on tty1.
This requires investigation.
For the time being I am going to just not do anything on tty1.
I suspect that I will need to add new features to the Controller program to stop printing or release control over tty1 before calling the appropriate agetty.
I've been planning on eventually adding custom file input and output controls.
This many now happen sooner than later due to the agetty situation.
The next step in Turtle Kevux that is to be performed in conjunction with the Init program is to start building the packages for the on-system compilation.
I do not plan on using the Turtle Kevux Installation Scripts (TKIS) for the normal system packages.
Most of the TKIS includes hacks, patches, and work-arounds due to differences between host systems and packages.
One of the major problems I noticed is that the CMake is a horrible build system.
This system segmentation faults consistently while bootstrapping within the system.
The cause is not immediately clear but might be related to the system security practices.
cmake-3.25.2/bootstrap: line 2042: 29217 Segmentation fault "${cmake_bootstrap_dir}/cmake" "${cmake_source_dir}" "-C${cmake_bootstrap_dir}/InitialCacheFlags.cmake" "-G${cmake_bootstrap_generator}" ${cmake_options} ${cmake_bootstrap_system_libs} "$@"
Looking into the code I find numerous potential memory leaks and failing to reset variables to NULL from just glancing through with the help of valgrind.
==36556== Invalid free() / delete / delete[] / realloc()
==36556== at 0x48C51CB: free (vg_replace_malloc.c:884)
==36556== by 0x60FC24: cmListFileLexerSetToken (in /tkis-1.1.0/work/cmake-3.25.2/Bootstrap.cmk/cmake)
Address 0x4b0dcc0 is in a rw- mapped file /lib/x64/libgcc_s.so.1 segment
The CMake code itself is an utter mess.
Projects that use CMake will either have to be removed entirely and not used or I will have to craft my own build rules using the Featureless Make system.
I really do not want to spend time dealing with this problem but it is what it is.
Further investigation has shown that CMake is no the main culprit here. There appears to be something wrong with the system libraries. The likely candidates are Musl libc, GCC, Binutils, and Valgrind. The problem might be made worse when threads are in use. Even the ls command is showing problems. I would not be surprised if there is some sort of optimization problem.
I intend to first try different versions of Musl. The compiler and the linker are additional points of interest. I must also consider Valgrind to be mis-reporting. However, I believe the mis-reporting to be unlikely as I can identify bad behavior in several programs that works fine outside of this environment.
Kevin Day