I decided to make a DIY lyre. And then I played a song on it. And here it is!
Categories
Author: dejvino
Chunk-sized tutorial is back! In the previous part, we booted into Armbian and watched it all via a USB-to-serial console. But that was just the beginning, since we need to set it up before it becomes useful.
Step 1: Initial Armbian setup
- root password: Generate some from your password manager and paste it twice.
- Live in the fast lane: Consider the warning that this is only an automated build for developers and think to yourself “Well, I already have this Neo3, why not make it do some work?”
- PS: using something fully supported would be a more reasonable idea.
- Select your shell: either bash or zsh are fine.
- Create a standard user: Again make use of your password manager and create the user that will be doing the actual backups.
Step 2: Reboot to verify
After restarting, you might be greeted with a root filesystem journal error. In other words, the SD card went bad and corrupted the data. Looks like it is time to go back to the first part of the tutorial and try again with a different SD card!
See you there!
Welcome back! In Offsite backup solution – Part 0 we discussed the importance of offsite backups and self-hosted solutions. We also went through the general steps of setting this all up. Now, let’s dive into getting Armbian running on a NEO 3 ARM computer since that is what I have at hand. We’ll cover everything from downloading the Armbian image to seeing the Neo3 booted up.
Step 1: Downloading the Armbian Image
Simple, right?
- Visit the Armbian Website: Head over to the Armbian download page.
- Search for the Neo3: The image should match your hardware.
- Download via Torrent: Opt for the torrent link. Your download client will handle the rest.
Why Torrent?
Downloading the large image via torrent is the way to go. Not only does it help share the bandwidth load, but it’s also a nod to the volunteer-supported nature of the project. Let’s give back to the community while we get what we need.
Step 2: Flashing the SD Card
Choosing Your Tool
For flashing your SD card on Linux, we have some great tools available. While Etcher is popular, let’s highlight Popsicle—a simple yet effective tool for this job.
- Install Popsicle:
Either from your distribution’s repository, or via Flatpak.
- Flash the Image:
- Open Popsicle: Launch the tool.
- Select Image: Choose the Armbian image file you downloaded.
- Select Target: Pick your SD card as the target device.
- Flash: Hit ‘Next’ and let it work its magic.
Step 3: Connecting via USB-to-Serial Adapter
Compatibility Matters
Not all USB-to-serial adapters are equal. The Neo3 requires a high baud speed: 1500000. Not all adapters support this and they won’t even give you an error when you try it. The CH340 chipsets are reliable and widely available, making them an excellent choice.
- Connecting the Adapter:
- Plug In: Connect the USB-to-serial adapter to your Neo3 and your computer.
- Check Compatibility: Ensure your adapter supports the required baud speed.
- Using GNU Screen to Connect:
- Install Screen
, - Start the Connection,
bash screen /dev/ttyUSB0 1500000
At this point, you should see…nothing! Because the device is not running.
Step 4: Booting the Neo3
- Insert the SD Card: Place the flashed SD card into your Neo3.
- Power Up: Connect the power supply. Your Neo3 should start booting with Armbian Linux.
Now if you look at your serial console, you should see the Neo3 boot into Armbian Linux:
Welcome to Armbian_community 24.11.0-trunk.351 noble!Congratulations! In the next part, we’ll build the software stack to perform an automated backup onto an external drive. Things will get interesting!
Our digital belongings are growing in size and importance. Family photos, accounting documents, beloved video games, losing them would be a nightmare. Having a backup is definitely mandatory. And if you’re self-hosting a lot like me, an offsite backup is a good way to be able to sleep calmly at night. I recently needed to rebuild my offsite storage system and so I decided to share my setup and my experience using it. This might be a long series, so hold on!
What Are Offsite Backups?
Offsite backups mean storing copies of your data in a different physical location from your main data. That means outside of your house! This way, if something unexpected happens (like a fire, theft, or hardware failure), your data is not completely lost. You could use cloud services for this, but we’ll focus on self-hosted solutions. I like to be in control, plus it gives me good understanding of how it all works.
Benefits of Offsite Backups
- Data Security: Keeping your data in a separate place protects it from local disasters.
- Redundancy: Extra copies of your data mean you’re covered if something goes wrong.
- Peace of Mind: Knowing your data is safe offsite gives you one less thing to worry about.
Additionally, if your backup is offline (in cold storage), it will be cheaper to run. No electricity or compute needed. And no need for fancy firewalls or access management, no one has access to the data unless they physically get to the hard drive.
My Self-Hosted Offsite Backup Setup
I run a local NAS with mirrored hard drives, shared over SMB on the LAN. This is the primary storage.
Next, there is a tiny ARM computer with an external hard drive that receives a weekly snapshot from the NAS, stored and encrypted via BorgBackup.
Lastly, a lonely external hard drive lives in my relative’s flat. And every time I make a visit there, I bring the other hard drive and swap them out.
Self-Hosted Backup Solution Overview
Step 1: Set Up Your Backup Server
- Choose Your Hardware: An old computer, a NAS, a Raspberry Pi. Make sure you have enough storage space on two separate drives.
- Install Linux: A lightweight Linux distro like Ubuntu Server or Debian works great.
- Secure Your Server: Set up SSH for remote access, configure a firewall, and keep your system updated.
Step 2: Configure the Backup Software
- Install the backup software: BorgBackup in this case.
- Configure mount points: both to the source and the destination of the backup.
Step 3: Automate and Monitor Your Backups
- Set up the automation: Fetch the data diff, compress and encrypt it, store it.
- Monitoring: Make sure you periodically find out that things DO work.
- Swap the drives: This is the actual offsite step!
Step 4: Test Your Backups
- Regular Testing: Periodically try and restore some data to make sure your backups and tools work.
- Health Checks: Inspect the state of the drives to replace them before they go ERR!
Is that it?
I didn’t even start yet! This was just a brief introduction of what I’m about to discuss in this series. More details to come in the next part where I’ll look into setting up the hardware.
Categories
Moon Bus :: PICO-8 game
I couldn’t resist the temptation to get down to coding a game like it was the 1980s again: small screen, huge pixels, 8-bit values, limited resources, limited instruction set, lots of fun.
PICO-8 is a fantasy console that only ever existed as an emulator. But oh boy, what a fun and well executed concept. I bought the license (sic, this is not a free nor open source software) so that I could play it on my Anbernic RG35XX H emulator console. And it is an amazing experience, being able to play 8-bit retro games that are freshly released and wirelessly downloaded onto a handheld device.
Since PICO-8 provides an all-in-one environment for games development, I decided to give it a try. Enter Moon Bus. This is a simple ‘Lunar Lander’-like game, where you have to travel from station to station, landing several times in a row to carry passengers around a low-gravity planet. I had a lot of fun building this and subsequently playing this on my handheld.
You can find the game on the official PICO-8 site: Moon Bus at www.lexaloffle.com
I love that there are still options to get into simple programming, without any need for massive frameworks and libraries. It is a refreshing experience and it really reminds me of coding way back when you didn’t have that many options or expectations. You definitely don’t need a cluster of GPUs to compile shaders like with other current platforms.
Categories
Keeping PinePhone Awake With Podcasts
Lately, I experimented with listening to podcasts on my PinePhone. The idea was to listen to some interesting topics while I’m on a walk, returning home. As you’d expect, nothing “just works” on a Linux phone.
I set up an automated download process via podget so that I can listen even with no network access. I got a pair of Bluetooth headphones to avoid fighting with headphone cords and to make this easy and convenient (as much as using a Linux phone can be). I picked up pragha as my new dedicated podcast player (‘P’ as in ‘Podcasts’!). The player even supported MPRIS2 via a plugin, so everything was great. Well, apart from my phone auto-suspending while the player was running.
One day later, I was halfway into creating a sleep-inhibit plugin for the pragha player. And then I found out there is an even better solution: sleep-inhibitor. This is a system service that monitors the audio output and if there is some sound playing through ALSA, it keeps the system from suspending. Just what I needed!
The service is even better than a player plugin, since this solution is generic. I also had a similar problem with the VLC player. And seeing this VLC ticket, I wasn’t the only one. Actually, this ticket brought me to the sleep-inhibitor, while researching ways to inhibit the system suspend.
Categories
PinePhone Daily Cron Fixed
I needed to run a daily cron job on my PinePhone, but that turned out to be trickier than expected. How can you schedule a job to be run in the morning, when the phone is most likely asleep (suspended) at that time?
My solution (workaround?) was to have the cron job run every 10 minutes, checking if the job was already executed today and if not, run the actual job command. This check is pretty cheap and I don’t need to wake the phone up to run my job. All I need is to get the job executed “today, whenever you have the time”.
The Cron Limiter tool (crolim for short) is available in my snippets repository.
With this tool, the crontab is as easy as: */10 * * * * crolim podget. Now my daily podcasts can be downloaded daily, when the phone is awake.
Categories
PinePhone Printing Receipts (pt. 2)
Another way to print on a POS Printer on Linux is to use the python_escpos library. It requires programming, but if you really want to get a lower level access to the printer, this is a nice solution.
All you need is to connect the printer over USB, find out the vendor and product ID via lsusb, create a short python script using the escpos library and you can print text, images, barcodes, whatever!
This is the code I used for my Sewoo SLK-TS400 printer, identified as “0525:a700 Netchip Technology, Inc. POS PRINTER”:
from escpos.printer import Usb
p = Usb(0x0525, 0xa700)
p.text("Hello World\n")
p.barcode('1324354657687', 'EAN13', 64, 2, '', '')
p.cut()
Easy! Time to build a “Today’s News Headlines” service. Or maybe a “Error logs needing your attention” syslog service?
I like using PinePhone as a general purpose computer for various tasks and purposes, such as a dedicated alarm clock, trying out networking software (I have several of them), etc. This time I tried attaching a POS Printer, creating a print server.
Linux is great when it comes to printers support, thanks to CUPS. It usually just works. For the POS Printer I needed to install additional drivers, but luckily there are some generic ones available, covering most of the 58mm / 80mm thermal printers (they share the same ESC/POS protocol, making them widely compatible).
Initially I wanted to use the official vendor-supplied printer drivers for Linux ARM, but there are several ARM architectures and this wasn’t the right one. Therefore I used these CUPS drivers instead: github.com/klirichek/zj-58. And since this is open source, I was able to compile them for the PinePhone’s ARM architecture and get it working.
Adding a printer can be done through the CUPS web interface running on localhost:631, where you can add the printer connected over USB. You can also connect a printer over serial or Bluetooth, all you need is a special connection URL: serial:/dev/ttyXXX or bluetooth://123456789a/ where you specify the serial file or the device address.
Once the printer is added, you can use all the lp* commands to manage your print jobs, such as lpoptions to configure the printer defaults, or lp tux.png to print out an image on a thermal printer!
When setting up Kodi under Arch Linux ARM running on Raspberry Pi 3, I encountered this error, which crashed the graphical environment right from the start:
[drm:vc4_bo_create [vc4]] ERROR Failed to allocate from CMA:
...After some searching, I ran into an issue thread, where it was advised to increase the CMA memory (as a workaround that seems to just be the actual fix). You need to add ‘cma=256M’ to the kernel boot parameters. But how do you do that?
# Run as root...
# dependencies
pacman -S uboot-tools
# modify the kernel boot parameters
cd /boot
vim boot.txt # append cma=256M to the line with boot params
./mkscr
rebootBefore this fix, I had only 64 MB of CMA. This wasn’t enough. To check that this worked:
if the cma parameter is present and /proc/meminfo
cat /proc/cmdline
# should contain cma=256M
cat /proc/meminfo | grep Cma
# should say CmaTotal: 262144 kBNow Kodi finally starts!
…though there are still some problems with the graphics driver (video doesn’t play, random switching to the console and back).
As it turns out, using the AArch64 version of Arch Linux ARM for Kodi is not the best option. Switching to the ARMv7 version helped a lot, everything worked from the start.