# Review of recently recieved A04 **URL:** \ **Category:** DevTerm\ **Tags:** feedback, tinkering, community, hardware\ **Created:** [January 5, 2022, 2:48am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803 "2022-01-05T02:48:06Z")\ **Posts on this page:** 20\ **Page:** 4
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 14, 2022, 10:57am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/66 "2022-01-14T10:57:07Z")
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. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 15, 2022, 4:13am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/67 "2022-01-15T04:13:16Z")
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. ---
**Author:** ![annathyst](https://avatars.discourse-cdn.com/v4/letter/a/eb9ed0/32.png) [@annathyst](https://forum.clockworkpi.com/u/annathyst)\ **Post date:** [January 15, 2022, 7:35pm UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/69 "2022-01-15T19:35:39Z")
armbian produces .debs you can install. ---
**Author:** ![annathyst](https://avatars.discourse-cdn.com/v4/letter/a/eb9ed0/32.png) [@annathyst](https://forum.clockworkpi.com/u/annathyst)\ **Post date:** [January 15, 2022, 7:36pm UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/70 "2022-01-15T19:36:26Z")
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 ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 15, 2022, 9:36pm UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/71 "2022-01-15T21:36:52Z")
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/README.md.dpkg-new` 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 ---
**Author:** ![annathyst](https://avatars.discourse-cdn.com/v4/letter/a/eb9ed0/32.png) [@annathyst](https://forum.clockworkpi.com/u/annathyst)\ **Post date:** [January 16, 2022, 2:58am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/72 "2022-01-16T02:58:57Z")
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. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 16, 2022, 4:40am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/73 "2022-01-16T04:40:50Z")
> [@annathyst](#): > > I’m sorry, but I can’t keep holding your hand through this step by step. 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. > [@BlayTation](#): > > I decide to check what the kernel the system is running. `uname -srm` produces “Linux 5.10.75-sunx164 arch64”. 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](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/48) 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. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 16, 2022, 5:01am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/74 "2022-01-16T05:01:41Z")
Continuing my review, I wish to cross-post [from here](https://forum.clockworkpi.com/t/a04-proc-cpuinfo-only-showing-2-cores-should-have-4/7828/17) 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: ![photo_2022-01-14_19-38-501280×720 31.1 KB](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/d/da5d2f0476a6f1c8c64350bf2c08d7009ee1d794.jpeg) These issues are significant. As I say in the other thread: > [@A04 /proc/cpuinfo only showing 2 cores (should have 4)](https://forum.clockworkpi.com/t/a04-proc-cpuinfo-only-showing-2-cores-should-have-4/7828/17): > > This is probably due to the fact that the fan is useless because there is no airflow in the device. The fan is just pushing air outside of the machine rather than through it. Someone has made a [Fan shroud for Devterm](https://forum.clockworkpi.com/t/fan-shroud-for-devterm/7598/37) to fix this defect. I also should update regarding my immense anger following that security issue and all that followed. This is the latest exchange with the developers. ![2022-01-15-132829_785x292_scrot](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/e/eba9f24912783f320ac9c487299818f572ecbe17.png) ![2022-01-15-140827_774x620_scrot](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/c/cf8c75a714fcbd832f76f9ca6fc5c18117e893e8.png) ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 17, 2022, 2:08am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/75 "2022-01-17T02:08:32Z")
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](https://support.mozilla.org/en-US/questions/959765) 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](https://stackoverflow.com/questions/48843217/unable-to-kill-process-in-linux) shows the exact issue that I am having. In `htop`, `/usr/lib/lib/firefox` is marked with a “D” meaning [“uninterruptible sleep (usually IO)”](https://www.man7.org/linux/man-pages/man1/ps.1.html). Now a question arises as to _why this is flagged uninterruptible sleep_. Looking further, this [Stack Overflow thread from 2016](https://stackoverflow.com/questions/35987982/process-is-in-interruptible-sleep-how-to-find-out-what-it-is-waiting-for) 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. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 17, 2022, 2:30am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/76 "2022-01-17T02:30:19Z")
Here also is an explanation of the uninterruptible sleep mode from a [Stack Overflow thread from 2008](https://stackoverflow.com/questions/223644/what-is-an-uninterruptible-process/223727#223727) explaining: > [@](#): > > - How to prevent this from happening: > figure out which driver is causing you trouble, and either stop using, or become a kernel hacker and fix it. 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. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 17, 2022, 2:37am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/77 "2022-01-17T02:37:15Z")
I have found the bug reported in [The Linux Kernel Mailing List](https://lkml.org/lkml/2009/8/21/268) back in 2009: > [@](#): > > At the moment about half of the framebuffer drivers can return an error code in fb\_set\_par. Until now it would be silently ignored by fbmem.c and fbcon.c. This patch fixes fbmem.c to return the error code and restore var on error. But it is not clear in which video mode the device is when fb\_set\_par fails. It would be good and reasonable if it were in the old state but there is no guarantee that this is true for all existing drivers. Additionally print a message if a failing fb\_set\_par is detected in fbmem.c or fbcon.c. > > Although most errors should be caught by the previous fb\_check\_var some errors can’t as they are dynamic (memory allocations, …) and can only be detected while performing the operations which is forbidden in fb\_check\_var. > > This patch shouldn’t have a negative impact on normal operation as all drivers return 0 on success. The impact in case of error depends heavily on the driver and caller but it’s expected to be better than before. > > – Florian Tobias Schandinat [FlorianSchandinat@gmx.de](mailto:FlorianSchandinat@gmx.de) 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](https://forum.armbian.com/topic/16859-allwinner-h6/?do=findComment&comment=121378): > [@](#): > > The Allwinner H6 SoC is only capable to handle up to 3GB of memory. So if any OS on H6 shows 4GB or more it is fake since it cannot be addressed. > > About the 2GB only no idea. Maybe balbes knows. > > – Werner 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. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [January 17, 2022, 3:07am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/78 "2022-01-17T03:07:35Z")
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](https://en.wikipedia.org/wiki/Zram). 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. ---
**Author:** ![poulsbo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/poulsbo/32/5845_2.png) [@poulsbo](https://forum.clockworkpi.com/u/poulsbo)\ **Post date:** [January 17, 2022, 4:20pm UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/79 "2022-01-17T16:20:04Z")
> [@BlayTation](#): > > The A-0604 is listed as having 4GB LPDDR4. This may be something to look at, certinally. The A06 runs a different SoC, the Rockchip RK3399, visible in an image of the compute core on this page: [https://www.clockworkpi.com/product-page/clockworkpi-core-a-06](https://www.clockworkpi.com/product-page/clockworkpi-core-a-06) ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [February 4, 2022, 4:00am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/80 "2022-02-04T04:00:25Z")
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. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [February 5, 2022, 1:09am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/81 "2022-02-05T01:09:15Z")
Finally opened and saw that the only scratch on the screen was actually from the protective film. I was very supprised. As for the melting, you can see meltlines of whatever plastic this is made of. There are also small signs of melting on the actual PCB. I was able to get these marks off of the back with a Clorox Wipe. ![photo_2022-02-04_17-06-45](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/6/63a54a63aab1ba01f387c044d68629b427b72944.jpeg) ![photo_2022-02-04_17-07-02](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/0/0e1a0a2bcd3d2bacf6a85a9cdc67b75ea7fd6441.jpeg) ---
**Author:** ![ghalfacree](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/ghalfacree/32/5448_2.png) [@ghalfacree](https://forum.clockworkpi.com/u/ghalfacree)\ **Post date:** [February 5, 2022, 10:52am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/82 "2022-02-05T10:52:44Z")
I don’t know what those marks are, but I’m 99-point-9-9-recurring percent sure they’re not “melt marks.” They’re concentrated under the printer bay… where there’s zero heat generated. There are none I can see where the SOM lives, where is where there _is_ considerable heat generated. And if the plastic had actually melted, it wouldn’t have been something you could remove with a wet wipe. Looks to me like something got spilled on the plastic and dried, leaving behind a residue. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [February 8, 2022, 2:07am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/83 "2022-02-08T02:07:40Z")
I spilled nothing on the device, and this was what occured after a CPU overlclock lead to overheating while I was trying to perform a kernel compile. You are right though, the placement would have it where the printerbay is, but that is only the majority. There are other marks on the PCB which are slightly faded. I do not understand what caused these, but it was only discovered after the overheat. I still have yet to bother to change the Zram to account for the too-low default for encryption. ---
**Author:** ![mth75](https://avatars.discourse-cdn.com/v4/letter/m/ecccb3/32.png) [@mth75](https://forum.clockworkpi.com/u/mth75)\ **Post date:** [February 8, 2022, 3:21am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/84 "2022-02-08T03:21:48Z")
Did you notice that a part of the fan blades is missing? ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [February 9, 2022, 4:33am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/85 "2022-02-09T04:33:17Z")
I did not notice that at all. Relooking at the picture I see it now. ---
**Author:** ![BlayTation](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@BlayTation](https://forum.clockworkpi.com/u/BlayTation)\ **Post date:** [February 9, 2022, 4:45am UTC](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803/86 "2022-02-09T04:45:30Z")
I am currently working on this again and trandfered over my Workstation’s files, but I accidently also moved over my xinitrc. The version uploaded at [https://github.com/clockworkpi/launcher/blob/master/.xinitrc](https://github.com/clockworkpi/launcher/blob/master/.xinitrc) is for the GameStation. Could someone please upload their default .xinitrc? I did not look at it so I do not know if there was custom implementation there. [Previous page](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803.md?page=3) [Next page](https://forum.clockworkpi.com/t/review-of-recently-recieved-a04/7803.md?page=5)