The Industrial Raspberry Pi Forum

Our company bought a Connect 4 module for me to verify it with our measurement logger applikation. During my preparation and configuration of it have I found several issues that caused extra work compared to modules based on Stretch and Buster. I upgraded the Linux distribution with sudo apt update and sudo apt full-upgrade with some upgrade issues reported from the 177 packages that were updated and installed.

• 1. The commands ethtool -P eth0 and ethtool -P eth1 returns other MAC addresses than those on the module cover, those returned from the command ifconfig and those presented in the DHCP server function of my router
  2. The apache2.service stops with a configuration error in the configuration file /etc/apache2/sites-enabled/revpi-nodered-proxy.conf where a keyword on line 10 is invalid. When I commented out this keyword did apache2.service start correctly on every reboot.
  3. The package proftpd-basic doesn't install correctly. The log file directory /var/log/proftpd isn't created upon every reboot and the proftpd.service doesn't start. When I tried to first purge the package and reinstall it dpkg returned several errors about corrupted files.
  4. The Bullseye based image (as returned from the command lsb_release -a) uses Network Manager instead of dhcpcd. Since Raspberry Pi OS based on Debian 11 Bullseye still uses dhcpcd am I curious as why Kunbus based on the same uses Network Manager?

I expected minimal issues with a Kunbus module with a Linux distribution based on Bullseye since I have tested our application with a Connect+ module based on Buster, a Flat module based Stretch and a Raspberry Pi 4 with 4 GiB RAM and SD cards with Raspberry Pi OS based on 32-bit Buster, 64-bit Buster, 32-bit Bullseye, 64-bit Bullseye, 32-bit Bookworm and 64-bit Bookworm. The differences between Kunbus based on 64-bit Bullseye and Raspberry Pi OS based on 64-bit Bullseye was surprising and unanticipated.

Hi Mats,

I'm sorry to hear that you're facing problems with your Connect 4. Let's find the cause and fix this.

In order to get a better understanding of your system, please answer that the following commands print on your device:

• cat /etc/revpi/image-release
• revpi-device-info
• ip link show
• sudo apt update && apt list --upgradable

The Bullseye based image (as returned from the command lsb_release -a) uses Network Manager instead of dhcpcd. Since Raspberry Pi OS based on Debian 11 Bullseye still uses dhcpcd am I curious as why Kunbus based on the same uses Network Manager?

We have choosen the NetworkManager because it provides a better (and consistent) fronend to the user. There are CLI (nmcli), TUI (nmtui) and graphical frontends so a user can choose what fits best. Also it can configure much more stuff like dhcpcd and the Raspberry Pi switched with Bookworm to NetworkManager too (Bullseye was already optional).

Nicolai

Here is the output you requested Nicolai:
pi@RevPi107258:~/src/loggerd $ cat /etc/revpi/image-release
2023-07-28-revpi-bullseye-arm64.img
pi@RevPi107258:~/src/loggerd $ revpi-device-info
------------------------------------------------------------
Product
------------------------------------------------------------
Vendor: KUNBUS GmbH
Product: RevPi Connect 4 32/4GB
Version: 0.10
Data Version: 1
Id: PR100378R00

------------------------------------------------------------
Device
------------------------------------------------------------
Serial: 107258
First MAC: c8:3e:a7:10:dc:c4
EOL Date: 2023-08-31
Batch / Lot: 0

------------------------------------------------------------
RevPi HAT EEPROM
------------------------------------------------------------
UUID: 0598cb4f-3ffe-3f61-8a03-e2b7b78e74c6
Format Version: 1
pi@RevPi107258:~/src/loggerd $ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether c8:3e:a7:10:dc:c4 brd ff:ff:ff:ff:ff:ff permaddr d8:3a:dd:37:0d:52
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether c8:3e:a7:10:dc:c5 brd ff:ff:ff:ff:ff:ff
pi@RevPi107258:~/src/loggerd $ sudo apt update
Hit:1 http://deb.debian.org/debian bullseye InRelease
Get:2 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:3 http://security.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:4 http://archive.raspberrypi.org/debian bullseye InRelease [23.6 kB]
Hit:5 http://repository.teamviewer.com/deb stable InRelease
Hit:6 https://deb.nodesource.com/node_18.x bullseye InRelease
Hit:7 http://packages.revolutionpi.de bullseye InRelease
Hit:8 http://packages.revolutionpi.de bullseye-backports InRelease
Get:9 http://archive.raspberrypi.org/debian bullseye/main arm64 Packages [307 kB]
Get:10 http://archive.raspberrypi.org/debian bullseye/main armhf Packages [313 kB]
Fetched 736 kB in 3s (235 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
pi@RevPi107258:~/src/loggerd $ apt list --upgradable
Listing... Done
pi@RevPi107258:~/src/loggerd $

I only have an Ethernet cable connected to Ethernet port A on the Connect 4 module. If you require more information please inform me.

Regarding the MAC: Which address is printed on the cover? Does the mac address in revpi-device-info match the address?

Other issues: Check wether the /var/log/ tmpfs feature is active (revpi-config status var-log.mount) and disable it if it is present (revpi-config disable var-log.mount). Sound like issues where log files cannot be written. What is the problematic keyword in /etc/apache2/sites-enabled/revpi-nodered-proxy.conf ?

Nicolai

The MAC addresses on the front of the module cover is C8:3E:A7:10:DC:C4 and C8:3E:A7:10:DC:C5.

The output from the revpi-device-info command matches the first of the MAC addresses which is normal since I have put the Ethernet cable in Ethernet port A.

The output from the revpi-config status var-log.mount command is 0 which I assume means it is disabled? Or do I have to enter the revpi-config disable var-log.mount evenso? When I entered the command sudo revpi-config disable var-log.mount I got the following output:
Failed to stop var-log.mount: Operation refused, unit var-log.mount may be requested by dependency only (it is configured to refuse manual start/stop).
See system logs and 'systemctl status var-log.mount' for details.
Created symlink /etc/systemd/system/var-log.mount → /dev/null.
4

The output from the revpi-config status var-log.mount command was still 0 after the sudo revpi-config disable var-log.mount command.

The erroneous keyword in the /etc/apache2/sites-enabled/revpi-nodered-proxy.conf configuration file is RewriteEngine On in the section beginning with <VirtualHost *:1880>.

With regards
/m-o r

Regarding the mac: Looks like everything works as intended. `ethtool -P` requests the permanent mac address which is set in the compute module. The mac address is overriden by a udev rules in order to match the assigned address for the individual device. In order to get the _used_ mac address for a particular interface you can use `cat cat /sys/class/net/eth0/address`

var-log: What does `mount` show? Did you do a restarte after the disable command (with sudo)

apache: How does the file /etc/apache2/conf-enabled/0-revpi-directory.conf look like? Should be:
```
LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

<Directory /var/www/html/>
AllowOverride all
</Directory>

<Directory /var/www/revpi/>
AllowOverride all
</Directory>
```
If the file is missing, please try to enable the config: `sudo a2enconf 0-revpi-directory`

Nicolai

I tried the command cat /sys/class/net/eth0/address and cat /sys/class/net/eth1/address on a Flat 8 GB running Debian 9 'Stetch', on a Connect+ running Debian 10 'Buster' and on a Connect S running Debian 10 'Buster'. On all of these devices are the the outputs from the cat command the same same as the outputs from the ethtool -P command.

I also compared the output from cat /sys/class/net/eth0/address against the output from ethtool -P eth0` on a Raspberry Pi 4 running Debian 10 'Buster', Debian 11 'Bullseye' and Debian 12 'Bookworm' in sequence. The output from cat /sys/class/net/eth0/address and cat /sys/class/net/eth1/address was the same as from the command ethtool -P eth0 and ethtool -P eth1. Why are they different on the Connect 4 module? Is that because is is based on Compute Module 4 or because it is based on Debian 11 'Bullseye' or both?

The output from the mount command is:
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1907804k,nr_inodes=476951,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=777024k,nr_inodes=819200,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /var/log type tmpfs (rw,size=51200k)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=388508k,nr_inodes=97127,mode=700,uid=1000,gid=1000)

When I entered the sudo revpi-config enable var-log.mount command I got the following output:
Removed /etc/systemd/system/var-log.mount.
Created symlink /etc/systemd/system/local-fs.target.wants/var-log.mount → /lib/systemd/system/var-log.mount.
Failed to start var-log.mount: Operation refused, unit var-log.mount may be requested by dependency only (it is configured to refuse manual start/stop).
See system logs and 'systemctl status var-log.mount' for details.
4

The command systemctl status val-log.mount gave the following output:
● var-log.mount - Tmpfs-Backed Log Directory
Loaded: loaded (/proc/self/mountinfo; enabled; vendor preset: enabled)
Active: active (mounted) since Mon 2024-06-03 15:00:47 CEST; 1 weeks 0 days ago
Where: /var/log
What: tmpfs
Docs: man:revpi-config(1)
Tasks: 0 (limit: 4471)
CPU: 7ms
CGroup: /system.slice/var-log.mount

Warning: journal has been rotated since unit was started, output may be incomplete.


The Apache 2 configuration file /etc/apache2/conf-enabled/0-revpi-directory.conf contains:
LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

<Directory /var/www/html/>
AllowOverride all
</Directory>

<Directory /var/www/revpi/>
AllowOverride all
</Directory>

It seems to be the same as what your presented.