JRPi Tech Blog

Let's start from the beginning,

I'm a tech hoarder with a penchant for collecting embedded development hardware and coming up with projects that force me to learn, often I find myself flipping through projects and leaving things for an extended period when they get hard. After several months, I will face a harder problem as I progress, and looking for respite, I eagerly pick up the original project. Hopefully having a blog will help me launch back in from my drop-off points in the future.

Such is the case with my e-ink display, several months ago I picked up an 800x480p 7-color e-ink from a local retailer after doing minimal research (Unaffiliated link to the display from Pimoroni); when I went to use it I was surprised to see they only included a Python library! My original use was to have a slow refresh calendar that would update by push from a local server that sent bitmaps to a Raspberry Pi Nano.

Napkin math makes me reckon that the 800x480 display in a frame buffer would have to represent 512,000 pixels. So with the 264KB of onboard RAM on the Pico I would have to be careful since even a byte per pixel, (512KB), is just under double the total RAM available before even writing any code. Even still, I also presumed that I could use 3 bits for each pixel and have a 154KB data structure for a frame buffer that would also be quicker to iterate through when needed.

The Python library was a heartbreaker because I would have to use MicroPython. #1, I'm not even sure that's possible, #2, if it is possible I'm still not doing that when there is a wonderful C/C++ SDK for the device. I ended up getting a basic grasp for the few supported use cases of a 45-second refreshing, Python-driven display (with a glass panel, excellent resolution, and color clarity) with Python3 on Pi Zero W.

Fast Forward to Today

The Problem

For the last two days, I have been reconfiguring my personal network infrastructure to create a complete, secure, and coherent solution for my needs. For context, this server is running systemd Gentoo Linux with +march=native and standard stable compile flags, testing packages are not allowed globally, the kernel is manually configured, it was compiled and installed 12/31. Special care was used to ensure I selected compatible kernel options matching the Gentoo Wiki's article on Docker.

This issue took longer than I care to admit because of a couple now glaringly obvious red herrings. I was able to emerge and install Docker without a problem, but when I attempted to run the service I received the following error:

Dec 31 10:34:56 gentoo systemd[1]: Starting Docker Application Container Engine...
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.093036541Z" level=info msg="Starting up"
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.280360174Z" level=info msg="[graphdriver] using prior storage driver: overlay2"
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.280599062Z" level=info msg="Loading containers: start."
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.282787923Z" level=warning msg="Running modprobe bridge br_netfilter failed with message: modprobe: WARNING: Module bridge not f>
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.287999183Z" level=info msg="unable to detect if iptables supports xlock: 'iptables --wait -L -n': `modprobe: FATAL: Module ip_t>
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.340305545Z" level=info msg="stopping event stream following graceful shutdown" error="<nil>" module=libcontainerd namespace=moby
Dec 31 10:34:56 gentoo dockerd[134836]: failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to register "bridge" driver: failed to create >
Dec 31 10:34:56 gentoo dockerd[134836]: iptables v1.8.11 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Dec 31 10:34:56 gentoo dockerd[134836]: Perhaps iptables or your kernel needs to be upgraded.
Dec 31 10:34:56 gentoo dockerd[134836]:  (exit status 3)
Dec 31 10:34:56 gentoo dockerd[134836]: time="2024-12-31T10:34:56.340724371Z" level=info msg="stopping event stream following graceful shutdown" error="context canceled" module=libcontainerd na>
Dec 31 10:34:56 gentoo systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Dec 31 10:34:56 gentoo systemd[1]: docker.service: Failed with result 'exit-code'.

This is where I went naive, the error there clearly indicates iptables is not working properly and the docker service can't properly register it's network configuration causing it to fail. Working through that error log from the bottom up, reviewed all the wiki entries on iptables & ip_tables, I emerged iptables again and once it was finished I attempted to run "iptables -L" which met me with another error shown below. One thing I learned through this is that ip_tables, and iptables, are two related but different things (ip_tables is a kernel module and iptables is a front-end for the module).