Hello Everyone,

As I continue to learn Raspberry Pi OS Bookworm (Debian 12), I'm finding a strange inconsistency and I think it either depends on:

?? a) the hardware I'm using or the use of Raspberry Pi OS Lite (No GUI) vs Raspberry Pi OS Desktop (GUI)
?? b) different versions of Rpi-OS images where they are making changes mid-release


I'm curious if anyone can confirm this on your setups:


?? Raspberry Pi 4 with 4GB of RAM running Bookworm Lite (No GUI)
????? --
????? cat /etc/os-release
????? --
????? PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
????? NAME="Debian GNU/Linux"
????? VERSION_ID="12"
????? VERSION="12 (bookworm)"
????? VERSION_CODENAME=bookworm
????? ID=debian
????? HOME_URL=
????? SUPPORT_URL=
????? BUG_REPORT_URL=

????? --
????? Shows all config files in /boot are symlinks to /boot/firmware/.? That makes things backwards compatible:
??????? --
? ?? ??? ls -la /boot/*.txt
??????? lrwxrwxrwx 1 root root 20 Oct? 9 20:39 /boot/cmdline.txt -> firmware/cmdline.txt
???? ? ? lrwxrwxrwx 1 root root 19 Oct? 9 20:39 /boot/config.txt -> firmware/config.txt
??????? --

????? Here is what is in the new /boot/firmware directory for config files
??????? --
??????? ls -la /boot/firmware/*.txt
??????? -rwxr-xr-x 1 root root? 132 Oct? 9 21:00 /boot/firmware/cmdline.txt
??????? -rwxr-xr-x 1 root root 1364 Oct 27 17:39 /boot/firmware/config.txt
??????? -rwxr-xr-x 1 root root? 145 Oct? 9 20:57 /boot/firmware/issue.txt
??????? --


Now compare that to a Raspberry Pi 5 with 8GB RAM running Bookworm Desktop (GUI enabled):

?? $ cat /etc/os-release
?? --
?? PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
?? NAME="Debian GNU/Linux"
?? VERSION_ID="12"
?? VERSION="12 (bookworm)"
?? VERSION_CODENAME=bookworm
?? ID=debian
?? HOME_URL=
?? SUPPORT_URL=
?? BUG_REPORT_URL=
?? --

?? $ ls -la /boot/*.txt
?? -rw-r--r-- 1 root root 92 Feb? 5 18:49 /boot/cmdline.txt
?? -rw-r--r-- 1 root root 91 Feb? 5 18:49 /boot/config.txt
?? lrwxrwxrwx 1 root root 18 Dec? 4 21:04 /boot/issue.txt -> firmware/issue.txt

????? These configuration files only contain text like:
? ? ???? --
? ? ? ?? DO NOT EDIT THIS FILE

???? ? ? The file you are looking for has moved to /boot/firmware/config.txt
? ? ???? --

?? The new REAL location of these files is now ONLY in /boot/firmware..
?? --
?? $ ls -la /boot/firmware/*.txt
?? -rwxr-xr-x 1 root root? 132 Feb? 5 18:57 /boot/firmware/cmdline.txt
?? -rwxr-xr-x 1 root root 1315 Feb 14 12:45 /boot/firmware/config.txt
?? -rwxr-xr-x 1 root root? 145 Dec? 4 21:04 /boot/firmware/issue.txt
?? --


By NOT making /boot/cmdline.txt a symlink to /boot/firmware/cmdline.txt, this BREAKS backwards compatibility with various tools, documentation, etc.? I'm curious if anyone knows WHERE and WHY this is happening?

--David
KI6ZHD

Hmmm..this shows ax25 version 0.11.8

newer? changes?

Just sorta stumbled upon this..haven't tried anything tho...

On 2024-02-12 12:23 a.m., David Ranch wrote:

Hello Mike,

Again, thank you for the detailed email and I think this all helps in tracking down the real issue here.? I've been discussing this on the side with Bernard F6BVP who maintains FPAC (node) and FBB (BBS) and uses the ROSE protocol heavily.? He reported that he's "running three ROSE/FPAC nodes on a local network and I haven't observed any connections issues with Raspbian OS 64bit for a long time nor with Ubuntu (20.04)".? He showed months of uptime with LOTS of connections without either any panics or any orphaned AX.25 connections.? One key point he mentioned is that he does NOT have any RF connections, it's all via AXUDP and he also noted he's NOT using mkiss for linking the AXUDP to the kernel with kissattach.

--David

On 02/10/2024 12:27 PM, Michael Dunn wrote:

? Hi everyone,

Been quiet on this topic recently as I haven't had much to report. ?I've had a lack of any crashes for over 12 days now, which seems to be related to disabling Pat in my environment. ?Please don't jump to conclusions here; this is a complex issue. ?As I've said in the past, Pat doesn't appear to be the cause of the crash, just the process that trips over the kernel garbage to trigger it.

Since I've had some time to think about this problem, here's what I've noticed:

? - Jon and I both run rmsgw. ?We both have crashes on the system running rmsgw.
? - The process that triggers the crash is mobile (beacon, pat, netstat), but is never rmsgw.
? - Jon and I both have few outside connections to rmsgw. ?My last outside connection was 10 days ago.
? - Jon has crashes in just a few hours; my crashes take days to weeks.
? - Jon frequently self checks his mail (possibly hourly? but I don't think he stated). ?I self check my mail infrequently (daily).

Based on these facts, my theory is this. ?rmsgw puts the kernel in some sort of bad state. ?This state is tripped over later by some unsuspecting process, causing the kernel crash.

To prove this out, I need to separate my rms server from my rms client. ?Unfortunately, I have only one radio, so I decided to take this test off-air. ?In my test setup, I built 2 Pi's, let's call them RMS and PAT to distinguish their roles. ?The Pis were built by imaging the SD card from PROD in the manner I've described previously.

Instead of connecting to a radio, I simply connected sound card to sound card using a pair of TRS cables (headphone to microphone in both directions). ?Direwolf was configured to match and PTT was disabled. ?RMS ran rmsgw from ax25d and a shell loop on PAT checked my mail every 30 minutes using pat -s (send only, as not to eat my actual inbox).

I let this setup run over night. ?In the morning, neither Pi had crashed, but I did notice that PAT was no longer able to connect to RMS. ?Tracking through the logs, it looks like about 7 hours after I setup the test, connections started failing. ?Digging into the RMS Pi, I found the netstat condition that Jon first reported. ?Note ax0 missing from the device column:

Dest ? ? ? Source ? ? Device ?State ? ? ? ?Vr/Vs ? ?Send-Q ?Recv-Q

* ? ? ? ? ?MYCALL-10 ? ? ? ? ?LISTENING ? ?000/000 ?0 ? ? ? 0

?

The kernel on RMS had been trashed, but the Pi was still operating. ?Checking the PAT Pi, netstat output looked normal. ?Realizing I still needed an AX25 event to trigger the crash, I used axcall on RMS ?to generate some traffic. ?The RMS Pi immediately crashed, blaming axcall as it went down:

[61160.353159] CPU: 1 PID: 130380 Comm: axcall Tainted: G ? ? ? WC ? ? ?6.1.0-rpi7-rpi-vB #1 Debian 1:6.1.63-1+rpt1

?

For me, this is great news. ?I have an off-air way to quickly show the problem. ?This also continues to show that the crash is mobile between processes and demonstrates an unrelated trigger event. ?Next steps are to reproduce the crash to ensure it is reliable. ?I'm also going to move RMS and PAT out of the RF environment (e.g. the other end of the house) to ensure there is no RFI element.

? Cheers
? Mike

Hello Mike,

Again, thank you for the detailed email and I think this all helps in tracking down the real issue here.? I've been discussing this on the side with Bernard F6BVP who maintains FPAC (node) and FBB (BBS) and uses the ROSE protocol heavily.? He reported that he's "running three ROSE/FPAC nodes on a local network and I haven't observed any connections issues with Raspbian OS 64bit for a long time nor with Ubuntu (20.04)".? He showed months of uptime with LOTS of connections without either any panics or any orphaned AX.25 connections.? One key point he mentioned is that he does NOT have any RF connections, it's all via AXUDP and he also noted he's NOT using mkiss for linking the AXUDP to the kernel with kissattach.

--David

On 02/10/2024 12:27 PM, Michael Dunn wrote:

? Hi everyone,

Been quiet on this topic recently as I haven't had much to report. ?I've had a lack of any crashes for over 12 days now, which seems to be related to disabling Pat in my environment. ?Please don't jump to conclusions here; this is a complex issue. ?As I've said in the past, Pat doesn't appear to be the cause of the crash, just the process that trips over the kernel garbage to trigger it.

Since I've had some time to think about this problem, here's what I've noticed:

? - Jon and I both run rmsgw. ?We both have crashes on the system running rmsgw.
? - The process that triggers the crash is mobile (beacon, pat, netstat), but is never rmsgw.
? - Jon and I both have few outside connections to rmsgw. ?My last outside connection was 10 days ago.
? - Jon has crashes in just a few hours; my crashes take days to weeks.
? - Jon frequently self checks his mail (possibly hourly? but I don't think he stated). ?I self check my mail infrequently (daily).

Based on these facts, my theory is this. ?rmsgw puts the kernel in some sort of bad state. ?This state is tripped over later by some unsuspecting process, causing the kernel crash.

To prove this out, I need to separate my rms server from my rms client. ?Unfortunately, I have only one radio, so I decided to take this test off-air. ?In my test setup, I built 2 Pi's, let's call them RMS and PAT to distinguish their roles. ?The Pis were built by imaging the SD card from PROD in the manner I've described previously.

Instead of connecting to a radio, I simply connected sound card to sound card using a pair of TRS cables (headphone to microphone in both directions). ?Direwolf was configured to match and PTT was disabled. ?RMS ran rmsgw from ax25d and a shell loop on PAT checked my mail every 30 minutes using pat -s (send only, as not to eat my actual inbox).

I let this setup run over night. ?In the morning, neither Pi had crashed, but I did notice that PAT was no longer able to connect to RMS. ?Tracking through the logs, it looks like about 7 hours after I setup the test, connections started failing. ?Digging into the RMS Pi, I found the netstat condition that Jon first reported. ?Note ax0 missing from the device column:

Dest ? ? ? Source ? ? Device ?State ? ? ? ?Vr/Vs ? ?Send-Q ?Recv-Q

* ? ? ? ? ?MYCALL-10 ? ? ? ? ?LISTENING ? ?000/000 ?0 ? ? ? 0

?

The kernel on RMS had been trashed, but the Pi was still operating. ?Checking the PAT Pi, netstat output looked normal. ?Realizing I still needed an AX25 event to trigger the crash, I used axcall on RMS ?to generate some traffic. ?The RMS Pi immediately crashed, blaming axcall as it went down:

[61160.353159] CPU: 1 PID: 130380 Comm: axcall Tainted: G ? ? ? WC ? ? ?6.1.0-rpi7-rpi-vB #1 Debian 1:6.1.63-1+rpt1

?

For me, this is great news. ?I have an off-air way to quickly show the problem. ?This also continues to show that the crash is mobile between processes and demonstrates an unrelated trigger event. ?Next steps are to reproduce the crash to ensure it is reliable. ?I'm also going to move RMS and PAT out of the RF environment (e.g. the other end of the house) to ensure there is no RFI element.

? Cheers
? Mike

? Hi everyone,

Been quiet on this topic recently as I haven't had much to report. ?I've had a lack of any crashes for over 12 days now, which seems to be related to disabling Pat in my environment. ?Please don't jump to conclusions here; this is a complex issue. ?As I've said in the past, Pat doesn't appear to be the cause of the crash, just the process that trips over the kernel garbage to trigger it.

Since I've had some time to think about this problem, here's what I've noticed:

? - Jon and I both run rmsgw. ?We both have crashes on the system running rmsgw.
? - The process that triggers the crash is mobile (beacon, pat, netstat), but is never rmsgw.
? - Jon and I both have few outside connections to rmsgw. ?My last outside connection was 10 days ago.
? - Jon has crashes in just a few hours; my crashes take days to weeks.
? - Jon frequently self checks his mail (possibly hourly? but I don't think he stated). ?I self check my mail infrequently (daily).

Based on these facts, my theory is this. ?rmsgw puts the kernel in some sort of bad state. ?This state is tripped over later by some unsuspecting process, causing the kernel crash.

To prove this out, I need to separate my rms server from my rms client. ?Unfortunately, I have only one radio, so I decided to take this test off-air. ?In my test setup, I built 2 Pi's, let's call them RMS and PAT to distinguish their roles. ?The Pis were built by imaging the SD card from PROD in the manner I've described previously.

Instead of connecting to a radio, I simply connected sound card to sound card using a pair of TRS cables (headphone to microphone in both directions). ?Direwolf was configured to match and PTT was disabled. ?RMS ran rmsgw from ax25d and a shell loop on PAT checked my mail every 30 minutes using pat -s (send only, as not to eat my actual inbox).

I let this setup run over night. ?In the morning, neither Pi had crashed, but I did notice that PAT was no longer able to connect to RMS. ?Tracking through the logs, it looks like about 7 hours after I setup the test, connections started failing. ?Digging into the RMS Pi, I found the netstat condition that Jon first reported. ?Note ax0 missing from the device column:

Dest ? ? ? Source ? ? Device ?State ? ? ? ?Vr/Vs ? ?Send-Q ?Recv-Q

* ? ? ? ? ?MYCALL-10 ? ? ? ? ?LISTENING ? ?000/000 ?0 ? ? ? 0

?

The kernel on RMS had been trashed, but the Pi was still operating. ?Checking the PAT Pi, netstat output looked normal. ?Realizing I still needed an AX25 event to trigger the crash, I used axcall on RMS ?to generate some traffic. ?The RMS Pi immediately crashed, blaming axcall as it went down:

[61160.353159] CPU: 1 PID: 130380 Comm: axcall Tainted: G ? ? ? WC ? ? ?6.1.0-rpi7-rpi-vB #1 Debian 1:6.1.63-1+rpt1

?

For me, this is great news. ?I have an off-air way to quickly show the problem. ?This also continues to show that the crash is mobile between processes and demonstrates an unrelated trigger event. ?Next steps are to reproduce the crash to ensure it is reliable. ?I'm also going to move RMS and PAT out of the RF environment (e.g. the other end of the house) to ensure there is no RFI element.

? Cheers
? Mike

To add on to Ray's response, I recently saw this excellent video on Youtube about Xwindows history and it's dead-end future:

??

There is some fascinating details in there and I bet there are some tidbits that even the the most senior "grey beard" sysadmins might not know.? Good stuff.

--David
KI6ZHD

On 02/07/2024 04:37 PM, Ray Wells wrote:

Maybe some useful info here ....

Ray vk2tv

On 8/2/24 10:52, N5XMT wrote:

Unfortunately, bookworm isn't returning to anything. X is being replaced by all distros with Wayland as the display manager. Not sure why, because X worked just fine.

Get

On Feb 7, 2024, at 09:03, mike <pencoys@...> wrote:

Hi, G8NXD here, been running RPi since the first board release and have a box full of old RPi's sitting waiting for Godot.
Been using RPi for local and remote QRSS and? WSPR reporting for ages., also GP desktop applications.
I've just aquired a couple of RPi5 8Gb but hate the OS for it so staying on Bullseye and RPi4 until Bookworm returns to sanity.

I've just joined looking for help on why certain distros, Ubuntu and DV as examples, dont recognise my Monitor but Raspbian of all colours seem quite happy with it.
It does'nt appear to be video drive level, #hdmi_drive=2 and dmi_force_hotplug=1, may be depreciated in modern Config.txt configurations, it does'nt seem to work these days.
The monitor is an ASUS VE247.
I have a feeling that the problematic distros assume a 4k monitor when first booting, but not sure about that and have no idea how to reject that option and default to a more antique resolution.

Ideas on a ?5 note please :-) 73 Mike

Maybe some useful info here ....

Ray vk2tv

On 8/2/24 10:52, N5XMT wrote:

Unfortunately, bookworm isn't returning to anything. X is being replaced by all distros with Wayland as the display manager. Not sure why, because X worked just fine.

Get

On Feb 7, 2024, at 09:03, mike <pencoys@...> wrote:

Hi, G8NXD here, been running RPi since the first board release and have a box full of old RPi's sitting waiting for Godot.
Been using RPi for local and remote QRSS and? WSPR reporting for ages., also GP desktop applications.
I've just aquired a couple of RPi5 8Gb but hate the OS for it so staying on Bullseye and RPi4 until Bookworm returns to sanity.

I've just joined looking for help on why certain distros, Ubuntu and DV as examples, dont recognise my Monitor but Raspbian of all colours seem quite happy with it.
It does'nt appear to be video drive level, #hdmi_drive=2 and dmi_force_hotplug=1, may be depreciated in modern Config.txt configurations, it does'nt seem to work these days.
The monitor is an ASUS VE247.
I have a feeling that the problematic distros assume a 4k monitor when first booting, but not sure about that and have no idea how to reject that option and default to a more antique resolution.

Ideas on a ?5 note please :-) 73 Mike

Hmmm, I might have answered my own question. After looking at a few of the online Pi shops without success, I searched broader and found a couple of 3D cases that should work.

This one looks excellent:?

Cheers,

Ken van Wyk

Armata Scientia

On Feb 5, 2024, at 7:26?AM, Kenneth R. van Wyk <ken@...> wrote:

I plan on adding my Pi 5 to my portable rig. It’s currently caseless, however, as the Pimoroni NVM3 base board doesn’t seem happy in other cases.

Anyone know of a case that can accommodate this configuration, while still allowing access to the external ports?

here's the link to the model for the pi5 with pineberry bottom drive HAT case

On Sat, Jan 27, 2024 at 1:44?PM Jerry Rector - K4OAM <kb4oam@...> wrote:

Would you be able to share a link to that .stl file?

On Sat, Jan 27, 2024 at 6:41?PM N5XMT <dacooley@...> wrote:

There isn't anything commercially available, but I found the STL (3D model) of one and 3D printed it myself.? Works perfectly!

Get

On Jan 27, 2024, at 08:07, John <radio@...> wrote:

Hi Ed,

I have the BOT Pineberry card I received in late December, but I'm still awaiting the 8gb Pi-5 kit I ordered in September from SparkFun.

Have you found a case yet that works with the Pi-5 and BOT together?? I would like one that encloses the sides and bottom of the BOT with openings for cooling.

Have you seen such a case yet?

Best regards,

John,? WoGN

On 2023-12-27 14:32, Edward Seeliger wrote:

[Edited Message Follows]

Thanks David.
After I posted my question I searched again and found a review of the Pineberry Pi boards posted yesterday on Toms Hardware by Les Pounder that shows a picture of the Bottom Board connected to the RPI5. Yes, the mount for the SSD requires removal from the RPI5 board. Another problem is the SD card slot is hidden by the PCIe connecting cable between the RPI5 and the Bottom Hat. To change / remove the SSD card you must also remove the Bottom Hat from the RPI5.
I am looking for a case to mount the RPI5 / Bottom Board in to protect the SSD - I have two on order from Amazon arriving tomorrow to try. - They are both simple top / bottom plexiglass with standoffs.
Thanks again.
Happy New Year.
Edd - KD5M

Unfortunately, bookworm isn't returning to anything. X is being replaced by all distros with Wayland as the display manager. Not sure why, because X worked just fine.

Get

On Feb 7, 2024, at 09:03, mike <pencoys@...> wrote:

Hi, G8NXD here, been running RPi since the first board release and have a box full of old RPi's sitting waiting for Godot.
Been using RPi for local and remote QRSS and? WSPR reporting for ages., also GP desktop applications.
I've just aquired a couple of RPi5 8Gb but hate the OS for it so staying on Bullseye and RPi4 until Bookworm returns to sanity.

I've just joined looking for help on why certain distros, Ubuntu and DV as examples, dont recognise my Monitor but Raspbian of all colours seem quite happy with it.
It does'nt appear to be video drive level, #hdmi_drive=2 and dmi_force_hotplug=1, may be depreciated in modern Config.txt configurations, it does'nt seem to work these days.
The monitor is an ASUS VE247.
I have a feeling that the problematic distros assume a 4k monitor when first booting, but not sure about that and have no idea how to reject that option and default to a more antique resolution.

Ideas on a ?5 note please :-) 73 Mike

Hi, G8NXD here, been running RPi since the first board release and have a box full of old RPi's sitting waiting for Godot.
Been using RPi for local and remote QRSS and? WSPR reporting for ages., also GP desktop applications.
I've just aquired a couple of RPi5 8Gb but hate the OS for it so staying on Bullseye and RPi4 until Bookworm returns to sanity.

I've just joined looking for help on why certain distros, Ubuntu and DV as examples, dont recognise my Monitor but Raspbian of all colours seem quite happy with it.
It does'nt appear to be video drive level, #hdmi_drive=2 and dmi_force_hotplug=1, may be depreciated in modern Config.txt configurations, it does'nt seem to work these days.
The monitor is an ASUS VE247.
I have a feeling that the problematic distros assume a 4k monitor when first booting, but not sure about that and have no idea how to reject that option and default to a more antique resolution.

Ideas on a ?5 note please :-) 73 Mike