Raymond P. Burkholder - Things I Do

Here is an interesting note from Connor's Blog - an automatic reboot after kernel panic with the following sysctl setting:

$ sysctl -w kernel.panic=60

... or on the kernel command line:

panic=60

Yes, this is a very old device (back to 2017 or so). But I have a couple, and I need to keep a few reference notes to see if it is upgradeable.

• Linux for Tegra R21.8 found from Jetson Linux Archive -- shows a 3.10.40 version kernel with a 32 bit driver package -- pretty old, if only 32 bit.
• Installing Debian on nvidia Jetson TK1 - based on the Tegra K1 chip (also known as Tegra 124). The Tegra K1 (codenamed "Logan") features a quad-core 32-bit ARM Cortex-A15 CPU and Kepler GPU (GK20A) with 192 CUDA cores. The Jetson TK1 can run Debian's armhf port.

I picked up a zigbee controller and was going to attach it to me BeagleBoard. Zigbee2MQTT. Recent installs of Zigbee2MQTT require recent versions of node.js, which the latest BeagleBoard operating system can't quite yet supply.

I did have an espressobin sitting around. After reviewing it's capabilities, it looks feasible. But it needed an operating system update.

I needed to boot it up to see what flavour it is. A couple of startup notes:

• It requires more power than what the USB can provide, so even though there is a green light lit on the board when the USB cable is inserted, the power adapter must be connected as well.
• command to start a console: screen /dev/ttyUSB0 115200
• The startup text showed I had a version with 1G memory, 1000Mhz CPU, 800 Mhz memory
• The starting page with cryptic notes: Espressobin
• I first needed to reflash the boot loader. This required downloading from /dl/espressobin/u-boot with my boot file being flash-image-DDR3-1g_2cs_2-1000_800.bin and placing the file on a vfat SD
• booting up the espressobin, and starting the boot prompt, the boot flash could be installed with:
• bubt flash-image-DDR3-1g_2cs_2-1000_800.bin spi usb
• from my linux desktop, I downloaded Armbian Bookworm and imaged to an SD card with: sudo dd if=Downloads/Armbian_23.5.1_Espressobin_bookworm_current_5.15.113_minimal.img of=/dev/mmcblk0 bs=1M status=progress
• A reboot started Debian and entered in to the initial configuration process.
• a line in /etc/NetworkManager/conf.d/10-ignore-interfaces.conf needed to be commented out to be able to manage the interfaces (networking in this espressobin build may not be fully baked), and NetworkManager restarted

Espressobin Reference:

• Documentation
• Community

References

• systemd-networkd - from archlinux, with reference to systemd-nspawn for container networking. -- interesting note: "it is possible to run Docker containers inside an unprivileged systemd-nspawn container with cgroups v2 enabled". But from an old talk:
  • Creating containers with systemd-nspawn - It is targeted at "building, testing, debugging, and profiling", not at deployment. systemd-nspawn uses the same kernel APIs that the other two tools use, but is not a competitor to them because it is not targeted at running in a production environment.

Gone are the good 'ole days of using /etc/network/interfaces to manage basic networking stack configurations. There seems to be an explosion of alternate ways, each stepping on each other's toes: /etc/network/interfaces, NetworkManager, NetPlan, systemd-networking, ...

A problem I had the other day was where a new installation of an espressobin had NetworkManager installed, no NetPlan, and some stuff in /etc/network/interfaces. Unfortunately, since NetworkManager controls the dhcp-client, the /etc/network/interfaces interface was not obtaining an address.

The solution was to edit /etc/NetworkManager/conf.d/10-ignore-interfaces.conf, and comment the following line:

[keyfile] #unmanaged-devices=interface-name:eth*,interface-name:wan*,interface-name:lan*,interface-name:br*

After 'sudo service NetworkManager restart', this solves the error of NetworkManager not being able to manage strictly unmanaged interfaces, which for the espressobin, are lan0, lan1, wan.

Some commands for NetworkManager:

• nmcli
• nmcli device show
• nmcli connection show

File locations:

• /etc/NetworkManager/system-connections/ - interface configurations
• /usr/share/doc/network-manager/README.Debian - notes about managed/unmanaged devices

Some references:

• Debian NetworkManager - mostly desktop?
• Debian NetworkConfiguration - nostly server?
• NetworkManager homepage
• nmcli - command-line tool for controlling NetworkManager
• NetworkManager.conf - NetworkManager configuration file
• NetworkManager - archlinux view of NetworkManager, with a section on VPN connectivity based upon profiles

Visual Studio Code, by default, when using the clangd language server, will automatically insert headers files for types which may have already been declared.

To disable this, go into the configuration options for clangd, and in 'clangd:arguments' add:

--header-insertion=never

Source: Stop VSCode from adding redundant headers

It is always interesting looking at bug reports. They uncover interesting nooks and crannies of system tooling. In reading Debian Bug#1037194, there is a command for watching dbus:

$ sudo dbus-monitor --system

To keep locally generated systemd service files separate from distribution files (as an example):

$ sudo mkdir -p /usr/local/lib/systemd/system
$ sudo vim /usr/local/lib/systemd/system/bme680.service
$ sudo systemctl enable bme680
$ sudo systemctl daemon-reload
$ sudo systemctl start bme680

An example systemd service file in /etc/systemd/system might look like:

[Unit]
Description=BME680 Collector
Documentation=https://github.com/rburkholder/bme680
After=network.target

[Service]
Type=simple
User=debian
WorkingDirectory=/home/debian
Environment="ID=02" "LOCATION=top floor"
ExecStart=/home/debian/bme680/build/bme680-mqtt ${ID} ${LOCATION}
ExecReload=kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=5s
StandardOutput=null
# note change with logrotate implemented, or to a memory file

[Install]
WantedBy=multi-user.target

The example from ecowitt2mqtt got me started - is a small CLI/web server that can receive data from Fine Offset weather stations (and their numerous white-labeled counterparts, like Ecowitt and Ambient Weather), adjust that data in numerous ways, and send it on to one or more MQTT brokers.

Reference to:

• systemd.service — Service unit configuration
• systemd.exec — Execution environment configuration - has list of expanded exit codes