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/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
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: https://www.clockworkpi.com/product-page/clockworkpi-core-a-06
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.
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.
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.
1 Like
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.
Did you notice that a part of the fan blades is missing?
I did not notice that at all. Relooking at the picture I see it now.
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 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.