Review of recently recieved A04

[BlayTation]

Since I could not do FDE as the system was already installed onto the microSD, I am following these instructions toe encrypt the home directory and swap. A portable device needs encryption in the modern age. If you are not storing things on your DevTerm, and only using it as a portable remote-terminal, I still think you should encrypt as that information of connection is logged.

TransparentEncryptionForHome…

Also, I recommend doing this prior to moving any data onto it as the entire home folder will be encrypted file-by-file. After this is done, all subsequent data will be automatically stored encrypted so there’s no worry. Since I’ve already moved so much over (though I deleted that Kiwix Wikipedia archive) I have a significant amoiunt of time to wait while it also encrypts every single file I just put on it.

[BlayTation]

A potential idea for future use however is to have a number of flash drives, each with a special collection, to connect to the device as needed. This may be superior and similar to carrying around CDs or Floppys from way back when.

I also think that a carrying-case for the DevTerm would be nice, and if one were designed it should have a dedicated pouch for such flash drives, similar to a CD/DVD book.

I would happily buy a carrying case, especially since the device itself seems so fragile when left out in the open.

[BlayTation]

Encryption via the Debian Guide has completed, but the system is running slow and appears to be frozen on Init. Last notice: [OK] Started Session 3 of user cpi. I switched to TTY3, but there was no login. Then, I switched to TTY1, and there was a different read out of Init. Before I could see what it said, the screen went blank and the selector (again) went into a different orientation. Now, the login screen appears. The only user listed, CPI. I select, enter my password that I set prior to the encryption of home, and it logs into the DE without error.

After login, a window pops up with the xTitle: Information avalible. The screen reads

(i) Update information

(null)

with two options: Run this action now, and close. I close the window.

The system appears to run at a slightly slower speed, but hardly. I look around and see that it did not automatically connect to my home WiFi, but it did not forget the network. I also see that there is no audio again. Opening the mixer (the only option from tray) it displays a message “Establishing connection to PulseAudio. Please wait…”

Continuing to wait appears to do nothing. I believe this may be due to the previous firmware upgrade not being implemented anymore. I am going to attempt to run it again.

[BlayTation]

Following the instructions of the driver upgrade in apt, there was no upgrade avalible. I rebooted the system. The Init ends with the normal message “[OK] Started Session 2 of user cpi.” (on last reboot it was Session 3, but it is usually Session 2). The device still is in Init, like last time, and I wait for a login screen. This time, I press no buttons and simply wait.

After about a minute, I get impaitent and cycle through TTY sessions myself. It seems the problem is that it does not automatically switch over. I assume this Init is preprogrammed to automatically open the cpi desktop, which it obviously can no longer do. I have to go to TTY4 before a response happens. Then, I go backwards to TTY3. TTY2 does not appear upon switching, and it remains at TTY3. I go up to TTY6, then try again to switch to TTY2. No-go. TTY1 however works. I see the other Init readout again, and see only the last message before it dissapears: “[OK] Started Session 38 for user cpi.” The screen again goes blank, and I see the login manager. Cycling through TTYs again, I see that the login manager is on TTY1. I can not access any TTYs higher than 6. I go back to the login manager on TTY1.

The login manager shows a full volume in its upper-right corner. I login and see my desktop. It does not automatically connect to WiFi again (and like before it did not lose the login cridentials), and the sound is still non-existant.

I begin to think that the sound not working may simply be the result of the DE’s taskbar not being able to connect to PulseAudio, so I attempt to test it using a random YouTube video. From the front-page, I play “Family Guy: The Golden Years (Season 3)” by HippieJoe. Sure enough, there is no sound. I attempt to see if pavucontrol will run as root (under the assumption that this may be a simple permissions error) but the controlling software opens under root with the same error “Establishing connection to PulseAudio. Please wait…”. I decide that PulseAudio probably simply did not start, so I run it. I get a bunch of errors saying it is not meant to be run as root, so I send an intterupt (^C) and leave the root session. Sure enough, when I run PulseAudio in the terminal as my user, the volume control in the taskbar goes full-blast showing that PulseAudio simply isn’t starting.

I assume the problem is probably with Init, and I go check the Init directory (after returning as root). I find /etc/init.d/pulseaudio-enable-autospawn. This appears to be the only Init file for PulseAudio. Paging the file shows it simply puts the line “autospan=yes” to /run/pulseaudio-enable-autospawn. I also see that the file does not exist. I decide to attempt to enable the init as a service, service pulseaudio-enable-autospawn start and it returns with an error:

“Failed to start pulseaudio-enable-autospan.service: Unit pulseaudio-enable-autospan.service is masked.”

I am unfamiliar with what this means, so I do a web search and find that it is some Pottering bullsh*t that has been put into SystemD. According to Ubuntu Answers,

"mask is a stronger version of disable . Using disable all symlinks of the specified unit file are removed. If using mask the units will be linked to /dev/null . This will be displayed if you check e.g. by systemctl status halt.service . The advantage of mask is to prevent any kind of activation, even manual."

Why are some systemd services in the “masked” state? - Ask …

Annoyed at this, I perform another websearch for the general term “PulseAudio boot”. I find an article providing a custom Init script, and look it over.

How to make PulseAudio run once at boot for all your users …

The Init script looks fine enough, so I install it (and not in the init folder, but in the SystemD folder listed on the site). I do not know how PulseAudio was coming up prior to the installation of the service. If it were not for the disgusting fact that so many “”“modern”"" programs have PulseAudio as a dependency, I would simply remove it and install ALSA.

Instead of enabling it as a service, I run the command provided on the webpage, systemctl --system enable --now pulseaudio.service and I am greeted with the error that the file “has a bad unit file setting”.

I am lost at what to do now, so I push this issue back knowing that all I need to do is setup a file to start the actual pulseaudio program at boot. I look around at the DE’s settings and see an option in settings called “Session and Startup”. I see PulseAudio included multiple times in the list, with “PulseAudio Sound System” being the only relevant one. It is checked and says to start on login. My assumption is that the Armbian developers set up a specific definition for “on login” and my modifications have changed this. However, this idea quickly escapes my mind as valid due to the fact that pasystray is also enabled and set to trigger “on login”, and is appearing in the taskbar.

So the only faults I see after encrypting the home directory are:

1. A slower-boot and the requirement of manually switching TTY to bring up LightDM Login Manager

2. Automatic connection to WiFi no longer works, and manual trigger is needed

3. PulseAudio simply does not come-up at boot, and needs to be manaually enabled

[BlayTation]

I also noted after posting the above that pavucontrol now detects a non-existant microphone, listing the port as “Analog input”. I also looked and saw “Analog output” as the output device. I decided to check again, to ensure that I had audio after manual launcing of pulseaudio. Again, a random video from the frontpage: “Is Anything on the Internet Real?” by MinutePhysics (I used an Invidious Instance instead of vanilla YT this time). Sure enough, audio /does/ play. So if it plays, why does pavucontrol list the default sink prior to the change, and now lists a non-existant microphone?

[BlayTation]

I now notice other errors in general use. Caps works, but Shift does not (both Shifters). Strange, as it worked to enter my password in LightDM. Doing some further tests. I see that Shift does work when using shift to access specialty keys (e.g. @, |, ), +, and so on) but I can not produce capital letters. I was typing into the terminal, so I decided to open LibreOffice Writer to test further. The same thing occurs, Shift is in-fact working, but there are no capital letters.

I try to close LibreOffice Writer with ^C-q, but it fails. ^C-q works to close a terminal though, and ^C-c sends an interupt. I run dpkg-reconfigure locales belieivng this may be the source of the issue (NOTE: Fn still works and I can Page-Down, and Page-Up). Just like before, the only relevant locale enabled is en_US.UTF-8. I set it as default, and it regenerates the installed locales. Strangely, despite that being the only one selected (I interupted the generation and rechecked) it begins generating locales beginning with de_XX, and then begins generating the en_XX and es_XX locales too. I assume it may install all locales despite instructing it not to. All locales thus-far are UTF-8 only.

I wait paitently for the generation of locales to complete and I have to wonder if this has to do with the custom firmware I installed earlier for Trackpoint. The posting lists that it also has affect on the keyboard. Looking at the thread, I may have installed v0.2 rather than the later v0.21 and v0.3. I am unsure. Once finished, if the locale generation does not fix the issue, I will (re)install v0.3.

I've rewritten DevTerm keyboard & trackball firmware

I rewrote DevTerm keyboard & trackball firmware from scratch to fix trackball movements. I think that a good trackball controller satisfies these conditions: It should be responsive to your rolling speed. The faster you roll, the faster it moves. But it should be precise if you want, without ‘Fn’ key mode. Also it shouldn’t be janky when you move diagonally in any angle. While doing so, it shouldn’t be slippery. It stops to move immediately when you stop to roll. I’ve also rewrote the keyb…

[BlayTation]

I canceled the rest of the locale generation, as I did not need Espanol or whatever would come after. It had generated the relevant en_US.UTF-8 many locales prior. Opening a terminal still produces no ability for capital letters. I reboot the machine. A printout shows with a Call Trace for ecryptfs, and then a few printouts from systemd-shutdown. It looks pretty standard for a closing Init, but the ecryptfs trace does worry me. All calls in the trace are listed as hex. A few more moments go by and systemd-shutdown keeps sending SIGKILL to rsync. I do not know what is being rsync’d, I did not bring it up by myself. After failing to SIGKILL rsync, systemd waits for it to stop on its own. After sending an interupt into the window (and I am unsure if it accepted it), it shuts down.

Reboot finishes, and I see the boot-time Init. Yet again, it stalls at “Session 2 of user cpi”. I notice however that a few of the previous entries include “Starting User Runtime Directory /run/user/1000…” as well as “Starting User Manager for UID 1000”. I have to think these are Init scripts for the expected login, that brings you straight to the Desktop (NOTE: Prior to encryption, it still booted into the desktop despite having set a custom password.) I do the trick to switch to TTY1, and immediately the screen goes blank, a flashing underscore in the upper-left, the mouse appears in the wrong orientation in the center-right, and then LightDM starts.

I enter my password (Shift works for relevant characters) and the desktop opens. Same issues showing in taskbar, I open a terminal to test for capital letters. Capital letters now appear. What was causing the issue before perhaps was incorrectly configured locales.

[BlayTation]

I decide to see if armbian-config can fix some of these problems. I open it from the DE’s menu, and check the Keyboard submodule after looking at a few options. It states is is Loading the keyboard module, then Console appears over it stating it is running update-imatfs. It then goes back to its previous menu. I go into the System submodule. I look at BootEnv and see that disp_mode is set to 1920x1080p60. I choose to change this to 1280x480p60. This isn’t nessesary, but may make booting look nicer. I change nothing else in that submenu. I went to Desktop and selected it. It told me that Desktop was running, and asked if I wanted to stop and disable the service. I selected yes, and nothing happened. Perhaps I need root in order to do anything? Looking through the rest of the options, there appears to be nothing that can help me.

I reboot again to see what affect changing that BootEnv setting is. It turns off fast, and I see the Init as it normally looks. Switch to TTY1 again, I see “Session 4” through “Session 26 of user cpi”. After a minute it says “Succesfully finished Hide Boot Splash[…]”. I didn’t read the full thing.

At this point, I assume that the issues I am experiencing are the result of custom configuration files either produced by Armbian or by ClockworkPi. I begin looking through Armbian’s website to see if it easily lists these hypothetical custom configuration files. There remain only the aformentioned three annoyances, having to switch TTY to get LightDM as Auto-Login fails, no automatic connection of WiFi, and a failure to open PulseAudio “on login”.

[BlayTation]

I found /etc/lightdm/lightdm.conf.d and found 12-autologin.conf containing the user cpi. However, I also found a Debian guide for reconfiguing LightDM, so I decided to follow that first. It seems I can configure it through dpkg-reconfigure so I do so.

https://wiki.debian.org/LightDM

Running dpkg-reconfigure lightdm prompts for the default display manager. The only options are gdm3 and lightdm. I choose to stay with lightdm. Selecting it closes the session. A lot of help that was. I comment out the file and look at the rest. Everything else looks fine so I reboot the system.

Again, shutdown is quick. Now Init shows up, and does not stall on creating a session for the user cpi. It goes into LightDM. However, LightDM’s session looks radically different than what it was prior. It looks like the default setup. The background is black and white, and the login window is on the far-left rather than center. The screen also flashes a bit, like a flicker. I enter the password and it goes to the desktop. the Taskbar Audio is setup, and the WiFi autoconnected.

It seems all issues were connected to the simple fact that LightDM’s Auto-Login was broken upon encryption of the home directory (besides the brief and odd error with the keyboard, of course).

NOTE: After looking up gdm3 I see that was the default, not lightDM. I may change back later for asthetic choice.

So, a long-about way to fix a simple problem due to a custom default setup, but hopfully my posts here help others.

[BlayTation]

Just noticed I provided the wrong date, it was 1/4/2022, not 1/13/2021.

[BlayTation]

In the time since I changed that, Firefox fails to open with known errors. Most web searches bring results for incompatiblity with Nvidia, and another showing bad RAM. Chromium-Browser also failed to open. I repeatedly attempted fixing the problem using complete uninstalls via apt and reinstalls, and it still did not function. It did not appear to be a system issue as other GTK-based programs opened without issue. I decided to try to uninstall firefox via apt, and install it via the Pi-Apps (though it appears to just use apt anyway). This did not fix the issue either.

I changed the armbian bootenv back to its default, 1920x1080p60, and rebooted. The reboot hung showing GeckoMain, chromium-browse failing to close (despite sending KILLALL to them while in the DE, and in-fact uninstalling them completely). After a period of time, it succeeds in failing and just turns off.

Init shows up as normal, system boots into LightDM. I login. I open a terminal on the desktop and run firefox. It now returns with a completely different error, Segmentation fault. A second-attempt hangs in the terminal, with no output whatsoever. No windows pop up immediately. I wait. A minute goes by, and I sent the interrupt. The Interupt is not accepted, and the terminal is still hung. I close the terminal, open another, and send a kill -9 via htop. To my supprise, the SIGKILL is not accepted. I try kill -15. No response. I try again in htop running as root. Still no response. The file is /usr/lib/firefox/firefox.

Instead of killing, I try again to open in the terminal. The previous errors finally display and a window pops up showing “Firefox is already running”. The errors are:

Crash Annonation GraphicsCriticalError: [[0]GFX- ]: No GPUs detected via PCI (t=12.2863) [GFX- ]: No GPUs detected via PCI
Crash Annonation GraphicsCriticalError: [[0]GFX- ]: No GPUs detected via PCI (t=12.2863) [GFX- ]: glxtest: process failed (recieved signal 11) (t=12.2865) [GFX- ]: glxtest: process failed (recieved signal 11)

###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

This eror is found on a few forums. firefox fails to load libEGL.so using i965 · Issue #77995 · … states that the solution was to install firefox-wayland, which does not exist in this distribution’s apt repo. Most results seem to apply to persons using Nvidia. One solution regarding Nvidia asks to check the lspci output. I try that, and get greeted with

pcilib: Cannot open /proc/bus/pci
lspci: Cannot find any working access method

Obviously, this is either a major problem, or it is the result of Armbian. I check the Armbian docs again. I search for the command lspci and find nothing. For all I know this is expected behavior. I have no idea why this is happening, and can find very little. Undoing what I did regarding the armbian-config does nothing. I don’t see why encrypting the /home/cpi directory would have any affect on display drivers or /proc, or the PCI Bus (which I assume this device, like almost every computer in existance made past 1995, would have one).

I decide to move-on for now, and try another browser. I download Pale Moon via Pi-Apps (which appears to just install via apt). I run palemoon in a terminal, and it opens without issue.

What’s the rub then? Researching the issue appears to be a Firefox issue, with many different Distros reporting it, and it involves GFX (the browser engine) unable to detect GPU on PCI. Very interesting.

[BlayTation]

I guess it really doesn’t have a PCI bus.

https://forums.raspberrypi.com/viewtopic.php?t=87407

As such, the only problem remaning is to figure out why Firefox was working and is now (seemingly spontaniously) is no longer working. Could a change have resulted in Firefox attempting to find a GPU through the non-existant PCI bus, and when failing to execute the command simply fails to run? To my knowledge, I have changed nothing regarding anything to do with system-wide configurations in the IO bus.

This is very interesting, though I am probably getting far off-topic for this forum. As such, I will continue to try to fix Firefox and simply report the fix at a later time. The point of making this thread was to provide a review and an analysis of my A04, and I’ve gone far beyond that in rectifying these minor errors.

[BlayTation]

Just a quick follow-up, I tried to run firefox again this morning and it displayed the error again, but it actually opened this time. Perhaps the problem was simply an overworked CPU as the device was on most of the day? I don’t know the issue.

[Eugene]

@BlayTation, you are doing fantastic work here. Thanks for all of this information, it’s helping me keep my expectations in check for when I get my A06, and it’ll help me to know what to look out for.

[BlayTation]

I am still having problems with firefox, and now am having the same problems with palemoon. These things just fail to open. Other things work, these browsers don’t. What caused this I do not know. Sometimes they open, other times they don’t. If anyone could direct me to figuring out how to fix it, or look over this thread to tell me if it’s something I may have done, I would be appreciative. Using lynx is fine, but not nesesarily a daily-driver.

[BlayTation]

Firefox is hit-or-miss. Working again… I have also discovered that Armbian proper does not offer support for the system (The Armbian-based Clockwork OS) because it is a custom, in-house build of Armbian. I did not realize this, and thought it might be prudent to anlalyze these custom system images as they originate from China. If you have been reading this thread, you will see I already ran rkhunter and did a clamscan on the binary directories. Nothing was found, but since a custom-kernel is being run, this is prudent to check as well.

Checking the /etc/apt/sources.list*/* I see that it is fetching from ClockworkPi’s Github. However, looking at its resource it appears to be firmware. This is easily audited and can be inspected for CCP creeperware. The only other (default) entry was apt.armbian.org.

GitHub - clockworkpi/apt

The kernel is in a prepackaged .deb as expected

https://github.com/clockworkpi/apt/blob/main/debian/pool/main/d/devterm-kernel-current-cpi-a04/devterm-kernel-current-current-cpi-a04_0.6_arm64.deb

But where is the source for this deb file? There is no deb-src directory. I find a Kernel entry in the larger list of repositories by the ClockworkPi team:

GitHub - clockworkpi/Kernel: CPI Linux Kernel

All I find in this directory are pre-compiled binaries and a few patchfiles. The directory is labled (per the Readme) “clockworkPI (CPI3) Linux Kernel 4.14.2 Patch”. So this repo is not the kernel, but a patchfile for the kernel it is using. It also has not been comitted to in three years. Dead end. I look through other repos and find no code. In fact, a few of the repos are blank with only a README and a LICENSE file.

I decide to check what the kernel the system is running. uname -srm produces “Linux 5.10.75-sunx164 arch64”. I don’t know what the sunx164 is supposed to mean, so I check the patchfiles to see if it’s labled. I don’t see it. I download the .deb for the latest kernel and run clamscan on it (from my main computer). No infection.

The only web-reference I can find to sunx164 is a userpost from 2014 on the Chinese website Badiu

https://zhidao.baidu.com/question/689126902998431764.html

Searching the entire Github account for ClockworkPi shows nothing.

Finally, I decide to websearch “armbian sunx164” and see it is a custom build from armbian. False-alarm, no problem there. It appears that sunx### is some kind of custom-built kernel for a specialty serial-driver, and there are numerous entries returned (though none by the exact name).

So now, the only issue really is to check the firmware patch files and confirm that these patches are valid hanges and not installing CCP creeperware. Then, for a fuller-audit, confirm that the .debs being fetched do what they appear to do and patch the Armbian-provided kernel. I plan to do this later, as this is time and resource-intensive. I was previously told that this project is in no way affiliated with the Chinese Communist Party, but considering the international troubles it is not overzealous or paranoid to confirm that a custom-repo for a portable computer does not have malicious intent.

SUGGESTION: Provide a deb-src tree.

[stefan]

regarding your browser-trouble: Did you try another sdcard? Those are technically cheap and as far as I know don‘t do the same data cleanup as ssds do… we are essentially running the OS on a storage for cameras

[BlayTation]

I do not know the read-speed for the provided mciroSD card. I did not try any other microSD card for the system as I have no spares to try. I am currently seeking help on a few different help-forums for this web-browser issue as I now believe this stems from SystemDickery.

[stefan]

I did not think about the speed but the data reliance of sdcards, this can be abysmal… many small systems running of sdcards use a readonly system that is written to RAM instead of the card for that reason…

[BlayTation]

Still trying to seek information. As for the board itself, I am having some confusion about what exactly is running on this. Is this a custom-board based off of the CM3, or is this a rebranded RaspberryPi? The GPU is different than the RaspberryPi, and the spec page has no real specs listed.