Review of recently recieved A04

I am confused as to the proper compilation method. I have followed the readme, and am prompted with a kernel compiling window (as expected). I choose “U-Boot and kernel packages” followed by “Do not change the kernel configuration” as I do not believe I need to change the flags from the existing system. However the next window is asking to select which board I am running. The truth is I do not know what the A04 is running. I have been confused since I purchased the device. I therefore do not know the proper compiling enviornment, and the readme here does not say.

It’ll be the only board with “clockworkpi” in the name if you’ve followed the DevTerm README.

I see. I forgot to add the wildcard per the readme. I followd and got a bunch of gawk errors from /home/cpi/build/lib/ It now appears to be running apt to “install build dependencies”. They are installing, all of which are being fetched from One of the packages installed is gawk. Another is cpp-10-arm-linux-gnu.... There are over 70 build dependencies it appears. For some ungodly reason qemu is also being installed. I guess it’s needed for Armbian compilation since it’s hard to compile on pure-hardware on a SBC? I don’t know. Other packages I see including nfs-kernel-server. It finishes and enters the next step.

It now appears to be running a git clone on u-boot after “syncing clock”. It finishes and is now “Checking out”. It seems to take a long while at this step. I double-check to confirm that the system is not frozen. It is not.

After a while, it now is getting the git for “linux-mainline orange-pi-5.10”. Why? Is this what I am running? How can I know? Everything is branded ClockworkPi. I still don’t know if ClockworkPi made this SBC or not. It’s all very vague. It finishes and is checking out again. I’m tempted to end the program and start from the beginning again to ensure that I’ve done everything correctly. I am certain that I selected “clockworkpi-a04” after seeing it in the menu. It was alphabetical. Why would it skip to “O”? It probably wouldn’t. I trust that it’s doing what it’s supposed to do so I don’t close the program. This takes significantly longer to checkout than the u-boot. There is no status bar for this, nor verbose output of any kind.

After a while, I convince myself it is hung so I try again. Now, instead of gawk errors I get an error saying uuidgen: command not found. Interesting it did not install it with its download of dependencies. The script skips back to where it was, checking out “linux-mainline orange-pi-5.10”. At least I now know this is expected behavior.

I guess I just play the waiting game now…

The SoC in the A04 is an Allwinner H6, a SoC in the same family as the one that is in the Orange Pi, which is why the kernel tree used for it is that.

While I was gone a lot happened. I left it unattended for a long while. It is well into make now. Slowly and surely it continues. It finishesm and begins building a .deb rather than installing the compiled headers to the system directly. Then it runs make clean. After this, it begins compiling select drivers. Apparently it needs the rtl8192eu chipset driver? I did not know that the embeded board was Realtek. Quite honestly, that doesn’t make a lot of sense. Still, with a Mystery-Board who can say? (UPDATE: Thank you @annathyst for telling me it is an Allwinner H6, which is not in doumentation anywhere I can find). However, it then compiles another realtek driver, for the rtl8188eu. Then the rtl88x2bu. And it continues with many more realtek chipset drivers.

After a while, it spits out a lot about patching in incemental patch files, then named patchfiles for the drivers it has compiled. After this, more makefile lines, all referencing the scripts/ directory. It then begins “compressing sources for the linux-source package”. This does have a status bar which pops up after a period of time, but does not say how big the final file is expected to be. At time of typing 7%, 106MB @ 959Kib/s. A lot of fluxuation in speed. Later on, it appears to peak at 5+MiB/s. 67% is ~922MiB compressed. 76%, ~1.02 GiB at ~415Kib/s. At 86% it cocurently began running a dpkg-deb on linix-source-5.10.75. Or perhaps 1.16GiB is complete and the status bar was incorrect at 86%? The fan is running harder, and it’s hot to the touch.

“Make the linux source package compeled 1992 seconds”

Now it’s running make on the arch/ folder. Later, the other folders are being compiled too. Just boring gcc/makefile output to report.

I make sure to give the device proper ventilation too and also check that the room is cool enough for it. The compilation continues to make it hotter. How hot? I don’t want to try to check because this is so resource-intensive opening a new terminal may be detrimental to the entire thing.

For some readson it generated an RSA keypair. Perhaps this is part of the script for pubishing compiled kernels?

After that, more gcc output.

After a while the fan is moving so fast it’s making the device hum. I decide to unplug the device from AC (as it appears to be fully charged) hoping this cools down the unit. Almost immediately after I do that the fan stops making noise. I touch the back and it still feels hot, but less so. I still feel airflow from the fan. A minute later, the fan is makingnoise again. I move the device to a different corner of the room in hopes it will cool down.

Over the next hour the fan continued to cycle, and it continued to compile. I went back after about an hour and saw that the battery died before finishing the compile. Since there is now the major issue of apt being completely compromised, and @guu not understanding what that means, I think I’m going to stop posting my audit until this is fixed. I am considering demanding a refund for this product if the security has been long-term compromised like this and the devpool is inept to this degree.

[Apt] [Keysigning] [Security] Entire Apt Repositiory compromised

Things are happening

I am still in the process of self-compilation of the Kernel in an attempt to rectify the framebuffer issues. This has taken several hours of my day. I hope to be able to provide extended report soon and see if this fixes the previously-mentioned errors. Hopfully I come-accross nothing as extreme as I have already found, and censorship of my forum posts ends. I hope to see this thread relisted in the near future. It has been an incredible 26 hours since I had initially discovered the problems with the apt repo, and I hope that this is the only security problem I find going forward.

The only other things to add to this Audit so-far are included in my previous FTC complaint, which are that the screen in advertisment is simulated without notice that it is simulated, and the machine reports to only have 2 cores instead of the advertised 4. This issue regarding cores appears to have been previously reported seven days prior. The thread shows that this is a userspace issue, and changing the CPU mode using devterm-a04-gearbox -s 5 fixes the issue. Doing so made the fan kick on again. I am unsure if I may have problems as I changed the setting during the Kernel compile.

It also would do well to state the board provided on the advertisment page, which I have since learned is an Allwinner H6. There is no documentation or notice in advertisment that this is the board being recieved.

The kernel compile script runs make clean when it detects that the make has already run. As I have had to stop the script multiple times this makes needless excess compile time as it has to recompile what it already has done. Then, it also continues to reduce memory as the .deb files it is producing are not being deleted as well. I had to restart it again as my WiFi dropped after a while and the script started yelling about git errors after a long period of compilation (at least 3 hours). I think I’ll leave this unattended and resume in the morning. This issue isn’t ClockworkPi related, it is related to the Armbian build system.

Well @annathyst my Kernel Compile completed as I slept, and I am unsure how to now import the kernel or switch to it as default. Terminal output produced no instruction. Again, this is Armbian’s Build System and not the fault of ClockworkPi which only patches these. I don’t believe it automatically switched to the new kernel. If it did, then the problem with firefox and other browser problems were not kernel related. However, the fbcon errors did not appear on latest shutdown.

armbian produces .debs you can install.

note that these will NOT be named the same as the clockworkpi kernel, as their process modifies the results of the armbian build process so they don’t conflict with the kernel packages in the armbian repository

I found ~/build/output/debs and ran dpkg -i *.deb. This produces errors on several packages, but installs the rest. The errors are on:

  • armbian-zsh
  • linux-dtb-current-sunx64
  • linux-image-current-sunxi64

The report says that armbian-zsh has a dependency on file /etc/oh-my-zsh/plugins/osx/ which is a weird thing to have a dependency for. The file does not exist. For the other package, it lists conflicting package devterm-kernel-current-cpi-a04. I don’t know how to swap these out in such an event.

The kernel errors still exist and are prevelant, especially with fbcon and the failure to run the web-browsers or kill them

Yes, as I said, the clockworkpi packages are produced by taking the linux-dtb and linux-image packages from this and modifying them both in terms of the filename and internal package metadata. You can either uninstall the clockworkpi ones (which will briefly leave you without an installed kernel) and install these, or figure out how to do the same operation again.

I’m sorry, but I can’t keep holding your hand through this step by step. Good luck.

I wasn’t seeking you to, this is a build system I am completely unfamiliar with. It has confused me a bit. I uninstalled the old kernel, and this allowed the packages (except armbian-zsh) to be installed. I’m unsure what armbian-zsh is, but can assume it relates to zshell. I ignore this issue, assuming that the already-installed armbian-zsh is satisfactory. I reboot, see my familiar fbconf error, see that systemd-shutdown is trying to kill rsync (I don’t know why it was spawned in the first place) and hangs. After a minute or so, it finally finishes shutdown after failing to kill rsync.

Reboot goes into Init without issue, and opens LightDM. I login. Considering that I uninstalled the previous kernel, I imagine uname -srm to produce different output. The output is Linux 5.10.75-sunxi64 aarch64.

There is no difference. I asume the kernels are similary-named. I try to open firefox again. I see the cursor change to a loading screen, and firefox opens. Since firefox had sometimes opened and sometimes had not before, I am unsure to see if the issue is permantely fixed. I decide to check the output of dmesg | tail and I see the previous noted output again repeated over and over: sun8i-ce 190400.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-ce, probably related to the transparent encryption I performed on the /home/cpi directory which initially led to these troubles and bugs.

For now, the problems appear to be rectified though I have no real way of knowing if I am on another kernel except assuming that my action of removing devterm-kernel-current-cpi-a04 was the correct package to remove prior to installing the .debs that the Armbian Build System produced.

Continuing my review, I wish to cross-post from here a photograph of my CPI having melted from the aformentioned Kernel compilation. The fan does not have actual use as there is no airflow in the system. During compile I changed to the highest mode, which has all four cores on and maxed speed on each. Even so, I had to wait until morning for the (final attempt to) compile to complete. When morning came, this was what I found:

These issues are significant. As I say in the other thread:

I also should update regarding my immense anger following that security issue and all that followed. This is the latest exchange with the developers.

That firefox error(s) still persists, as well as the 1b_set_par error, error code -16 and systemd-shutdown failing to close GeckoMain. I am going to research this more and report back. The SystemD helpchat told me that this is not an init problem. Maybe I should not have believed them. The inability to open and subsequently kill firefox is not exclusive to firefox so I do not believe this to be a Firefox error. This Firefox bug report from 2013 resolves the problem showing that the root issue was with Windows Registry for the reporter. That would imply that this is a system issue, especially when multiple problems are occuring and that shutdown output only occurs when the error is occuring (exept in the few odd exceptions when systemd-shutdown could not kill rsync which I had not manually spawned).

This Stack Overflow thread from 2018 shows the exact issue that I am having. In htop, /usr/lib/lib/firefox is marked with a “D” meaning “uninterruptible sleep (usually IO)”. Now a question arises as to why this is flagged uninterruptible sleep.

Looking further, this Stack Overflow thread from 2016 states that the solution is to increase the swap size. This device does not have SWAP and has RAM only, per my understanding. Perhaps (((modern))) firefox is too resource-intensive for such a setup, and this is causing immense errors. On the other hand, the first sign of these problems occured after transparent home encryption. Why should this matter if the encryption is on one directory, /home/cpi, and swap isn’t a file but an entry in RAM in the first place?

I think that it wouldn’t have much prevelance and the fault is that I did not test this more prior to transparent home encryption. It is only a coincidence that these issues began after it. If someone else still has their DevTerm and is experiencing these issues without running an encryption then the problem is in-fact the amount of RAM being used as swap.

These are all inferences based on tangently-related Stack Overflow threads and may not be correct.

Here also is an explanation of the uninterruptible sleep mode from a Stack Overflow thread from 2008 explaining:

Since the 1b_set_par error, error code -16 emerges only when this issue occurs, it must then be the kernel’s drivers. It was the SystemD IRC that told me that this was an fbcon (FrameBuffer) error. I believe them, despite their not-a-bug attitude and crippiling failure to make a simple init. I have already recompiled and installed a fresh kernel using Armbian-Build and the ClockworkPi patches. Is it possible that the patchfiles made by ClockworkPi for kernel building are defective? Is it Armbian’s primary firmware-source for the Allwinner H6 that is defective? I don’t see an alternative explanation, it must be one of the two.

This bug may or may not have been triggered by using LuksCrypt in the home directory, but it is a bug nonetheless. Who’s fault is it though, that is the major question.

I have found the bug reported in The Linux Kernel Mailing List back in 2009:

What follows is a diff for the referenced files. This confirms for me that it is kernel related, and shows me which files to look at specifically in the codetree to see what might be causing this. Unfortunately, I can not seem to find a list of errors and their meaning, nor much else in a basic web search. Hopfully the error codes are presented in the codepages.

Considering that Mr. Schandinat lists “memory allocations” as a potentiall for error, this brings me back again to the probability of swap/ram problems. I am unsure what running a ramcheck on an SBC would do. If the RAM is shown via a ramcheck to be shot, then that’s irreplacable. The only program I know of for running a ramcheck is MemTest86, and as its name implies is programmed to run on x86 chipsets.

As a side note, I have found this interesting tidbit in the Armbian forums:

I got the A-0402 with 2GB DDR3 ram (which is a strange designation since it’s SBC). The A-0604 is listed as having 4GB LPDDR4. This may be something to look at, certinally.

If this is in-fact DDR3, where is it physically located? Is it on the CPI module? Is it on the Allwinner H6? It certinally wouldn’t be on the expansion-card.