Review of recently recieved A04

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.

Looking in the output of parted -l I see /dev/zram listed as a “loop” partition table. It is only 52.4MB. It has an ext2 filesystem. There is also /dev/zram0 which is also a loop, and it is only using 1043MB. It is labled as a linux-swap(v1) filesystem. This is it. So, there are two seperate RAM devices as swap, using a combined 1095.4MB (or, approx 1.07 GB). This means that 952.32MB would be free for the system outside of swap. No wonder this thing isn’t working correctly!

More on zram can be found here.

In such a case, I think that it’s probably better to just reserve 1 GB or so of diskspace to swap rather than overtax the limited ram on the device. The problem with this of course is that this is a microSD card and not an actual HDD or SDD. Would that be too read/write intensive for the microSD card?

Maybe the swap-space in the RAM block would be good to simply be reduced in size.However, good practice shows that swap is made to be 2X the amount of RAM, so 4GB is actually what swap should be on this system. In such a case, reducing it even further would probably render the system even more inoperable.

Usually, I keep these things as seperate partitions for optimum efficency. On a portable device, especially one running the system on a microSD card, the opppisite would probably happen and it would be more prone to error. Besides this, the system arrived already installed and with a user. Any new flashes of ClockworkOS I assume to have the same without a partition guide or anything else.

I think the best course of action is to stop using the default zram, and make a large swapfile on the microSD card. I will do this later and report back.

The A06 runs a different SoC, the Rockchip RK3399, visible in an image of the compute core on this page:

It has been a while since I even turned on my A04. I’m now using it again. I have archived large amounts of things for use on the device. This is the reason I bought the device to begin with, for use as an emergency computer for the comming collapse. I have numerous USB deives with Calibre libraries and Kiwix, and am also downloading packages such as doc-rfc, manpages, and GNU’s miscfiles. Also installing wordnet. When I first started this thread I was going to show myself using a cellular modem I purchased for the machine that I was studying how to program to not only use cellular data but also make and revieve calls. It ended up being defective. I think I may be able to get a new one soon. As for the issues I previously mentioned, they are still there. I need to extend SWAP as the device uses an apparently-poor ZRAM configuration made worse by my transparent home encryption. I would have liked to FDE it, but it came with the software preinstalled. I still have yet to send more photographs of the scratched screen to the helpdesk line, and I still have yet to get paper to test its printer.

I will provide more technical analysis later, but I spent an entire week on something that I had expected to recieve over a year ago, and became incredibly angry when I saw a lot of crippling mistakes the devs made in engineering, and configuration. I still have not dissasembled it to see the severity of the melting on the back panel. I will be doing that tomorrow and uploading images. I need to do this anyway to take pictures of the screen, and the slightly-defected WLAN antenna. I believe I am still within the 60 day warranty period to recieve replacements of both.