j___r

Well, I had Plex running. I had two other tabs open: Tautulli and americascup.com (the racing has started) but it wasn’t playing any video. Or doing anything else. Syncthing also running in the background. That’s it. I have Jellyfin installed but yet to configure it for remote access so not currently using it. Can I do anything to rectify the memory usage issue (assuming Plex is the culprit) ?

armbianmonitor -u said "Network/firewall problem detected. Not able to upload debug info. Please fix this or use "-U" instead and upload whole output manually"

Here https://pastebin.com/TFZLdScm

Hello again all, Following the success of my last need to post here I changed my Odroid N2+ Plex server over to Armbian (making two Armbian-running Odroids in the house). The N2+ is running Debian GNU/Linux 10 (buster) with Linux 5.9.6-meson64 I have had a few occasions where I have encountered a system-wide freeze. Today's lasted over an hour, whilst others have unfrozen after ~20-30 minutes. Today the machine was ping-able but attempts to ssh in were unsuccessful though there was no timeout and no error messages when trying. Prior to that I was listening to some music in which the playback was faltering, leaving silence for several seconds duration before resuming with the audio. I'd like some assistance in learning what to look for and where. I have run cat /var/log/syslog and the log is dominated by repeated entries as shown below. Entries that don't match the below are mostly cron jobs for pinhole checking for updates etc and are running successfully. Jan 15 16:39:04 localhost systemd[1]: Started Serial Getty on ttyS0. Jan 15 16:39:14 localhost systemd[1]: serial-getty@ttyS0.service: Succeeded. Jan 15 16:39:14 localhost systemd[1]: serial-getty@ttyS0.service: Service RestartSec=100ms expired, scheduling restart. Jan 15 16:39:14 localhost systemd[1]: serial-getty@ttyS0.service: Scheduled restart job, restart counter is at 101879. Jan 15 16:39:14 localhost systemd[1]: Stopped Serial Getty on ttyS0. II see another user has mentioned this issue in this thread without resolution. At the point below the freeze has started, as I can see when I unplugged the network cable and plugged it in again. Jan 15 13:25:52 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 203768 bytes (530 ms). Jan 15 13:25:53 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the A$ Jan 15 13:26:06 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: snd_pcm_dump(): Jan 15 13:27:08 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: Hardware PCM card 1 'E30' device 0 subdevice 0 Jan 15 13:28:27 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: Its setup is: Jan 15 13:29:43 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: stream : PLAYBACK Jan 15 13:32:09 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: access : MMAP_INTERLEAVED Jan 15 13:34:05 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: format : S32_LE Jan 15 13:36:31 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: subformat : STD Jan 15 13:38:47 localhost pulseaudio[3426]: E: [alsa-sink-USB Audio] alsa-util.c: channels : 2 Jan 15 13:40:17 localhost kernel: [1042357.158180] meson8b-dwmac ff3f0000.ethernet eth0: Link is Down Jan 15 13:40:24 localhost kernel: [1042363.948844] meson8b-dwmac ff3f0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx Prior to that is just hundreds of the message groups as per the top example, with the exception of this. Jan 15 13:07:07 localhost rngd[2716]: stats: bits received from HRNG source: 8720064 Jan 15 13:07:07 localhost rngd[2716]: stats: bits sent to kernel pool: 8668192 Jan 15 13:07:07 localhost rngd[2716]: stats: entropy added to kernel pool: 8668192 Jan 15 13:07:07 localhost rngd[2716]: stats: FIPS 140-2 successes: 436 Jan 15 13:07:07 localhost rngd[2716]: stats: FIPS 140-2 failures: 0 Jan 15 13:07:07 localhost rngd[2716]: stats: FIPS 140-2(2001-10-10) Monobit: 0 Jan 15 13:07:07 localhost rngd[2716]: stats: FIPS 140-2(2001-10-10) Poker: 0 Jan 15 13:07:07 localhost rngd[2716]: stats: FIPS 140-2(2001-10-10) Runs: 0 Jan 15 13:07:07 localhost rngd[2716]: stats: FIPS 140-2(2001-10-10) Long run: 0 Jan 15 13:07:07 localhost rngd[2716]: stats: FIPS 140-2(2001-10-10) Continuous run: 0 Jan 15 13:07:07 localhost rngd[2716]: stats: HRNG source speed: (min=205.091; avg=474.633; max=1059.638)Mibits/s Jan 15 13:07:07 localhost rngd[2716]: stats: FIPS tests speed: (min=3.701; avg=20.017; max=59.419)Mibits/s Jan 15 13:07:07 localhost rngd[2716]: stats: Lowest ready-buffers level: 2 Jan 15 13:07:07 localhost rngd[2716]: stats: Entropy starvations: 0 Jan 15 13:07:07 localhost rngd[2716]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us Then there's bunch of kernel stuff but I'm not sure of the best way to copy it all out. Lots of references to memory and swap. Jon

This is possible on a time/energy basis. Not exactly sure what I could contribute- probably documentation & design focussed.

Thanks for your response and explanation. I performed the backup and upgraded the kernel to 4.14.202 and it has gone smoothly. And, Tailscale is back to it's happy self again. I really enjoy these little devices too, so I will continue to try and learn more and more about them and Linux but sometimes it seems bottomless. I appreciate the efforts of the contributors. Jon

I do find it not very clear. That page you linked to for example describes current as 'fully supported', but then states that kernel support is dependent on the board family - fair enough, this is a resourcing issue and completely understandable. It then recommends to use a legacy kernel if there are problems - so are legacy kernel images more or less supported than current? It then goes on to say - confusingly in my opinion - that testing images are, somehow, simultaneously, 'made from stable branches' but also 'not very well tested'. I guess what I desire is to be on a stable version but to also have the ability to upgrade to a more recent version when that newer version has matured and is considered suitable for non-testing, non-experimental machines. This is what I am used to I suppose in the macOS environment. I am not interested in the bleeding edge at all but I am now in a situation where a software service that I was using is now - for reasons I don't understand - no longer working, and it seem I have no path to upgrade to a more modern kernel version to try and get that software service working again. I started out with a legacy kernel, because I wanted stability (see my posts above about the prominence on the download pages of the images with the 4.14 kernel. But now I find myself in a bind because of this decision with Werner seeming to imply that I had made a bad decision in one post by saying and then a few posts later saying (about upgrading to the newer version). By starting over with Ubuntu I thought might get me that ability, backed by a larger community, wouldn't see me having to deal with these issues. I think also that for non-professional users such as myself the Linux realm suffers from not having a clearly defined path to knowledge. There is a lot of assumed knowledge among those who deal with this stuff everyday which is natural in any niche industry but it does make it difficult for others.

So it is true there is no upgrade path beyond 4.14? Is this true with all types of Linux distributions? My studies will end soon for summer. Perhaps I am best to start over with Ubuntu or something very mainstream?

There are a few additional 4.14 variants not visible in the screenshot

This is not good news. Yes, I knew this. They should probably all be bundled together for this reason. Having said that, like the HC1 downloads page the two most prominent downloads for the XU4 as show on the page are both for the 4.14 kernel. See the note *kernel 5.4 is still considered experimental. If it is so old why is it being presented as the main option? Perhaps I should've gone with a ubuntu image direct from hardkernel?

Not sure what you mean by causal? I did a firmware upgrade via armbian-config and couldn't boot afterward. That was why I restored the SD card from a backup. It seems like the fstab file had been changed in the upgrade.

Yes, I wonder... The two most prominently displayed images on the download page are 4.14 You have to scroll further down to find others with more recent kernels. Can I upgrade the os on my sata drive without overwriting current configuration and user files?

I only set up this server during June this year. I am pretty sure I used Armbian_5.83_Odroidxu4_Ubuntu_bionic_next_4.14.111 which means I should have config-tun. So something has happened between the bad upgrade and the restore. I just restored my sd card, yet the system os is residing on my data drive. Is there a way I can restore the kernel configuration?

To be honest Werner, I'm not sure what that shows.