vor 30 Minuten schrieb Mangix:

2 days uptime without DFS patches. No issues to report. Marked as solved.

 

I assume new kernels will be out if they're not already.

OTOH After the upgrade to 5.8.18, containing the DFS patches, my installation is up and running for 4 days now.

Are there any negative implications to be expected after the release of the new kernels without DFS management?

15 hours ago, FredK said:

OTOH After the upgrade to 5.8.18, containing the DFS patches, my installation is up and running for 4 days now.

Are there any negative implications to be expected after the release of the new kernels without DFS management?

2 degrees higher CPU temperatures were reported on a WRT3200ACM.

 

That's a router with no fans. In other words, no difference.

@FredKout of curiosity, did you just replace the PSU? And you're doing the same high I/O tasks as before?

 

The updates are underway, PR need to be approved, merged and debs rebuild. Probably today.

vor 6 Stunden schrieb Mangix:

2 degrees higher CPU temperatures were reported on a WRT3200ACM.

 

That's a router with no fans. In other words, no difference.

@Mangix Thank you.

vor einer Stunde schrieb Heisath:

@FredKout of curiosity, did you just replace the PSU? And you're doing the same high I/O tasks as before?

 

The updates are underway, PR need to be approved, merged and debs rebuild. Probably today.

@Heisath The reboots took place with 5.8.16-mvebu. After replacement of the PSU I had a reboot after one day, so I excluded the PSU as the root cause, but I left the new one in operation. Next step was the upgrade to 5.8.18-mvebu, five days ago. Since then uninterrupted operation.

The usage profile is always the same, a RAID5 serving as media server plus a nextcloud docker installation.

Is that btrfs raid5?

 

edit: I just had a thought. Since the Helios 4 is underclocked, I wonder if placing it back to the stock clocks would make the DFS patches work.

 

Then again, I do remember my Turris Omnia freezing as well.

 

Never mind.

vor einer Stunde schrieb Mangix:

Is that btrfs raid5?

@Mangix No. it's a EXT4 RAID5.

@gprovost I went the upgrade path where i went from debian 9 to debian 10 so i could upgrade from omv4 to 5 using the omv upgrade script. After having random reboots after the upgrade, I did a clean install of debian 10 buster with omv5. I had no issues with reboots for about 20 days until i updated and reboot since then I am having random reboot after about 3 days.

 

If the watchdog service is off, i will get hard lockups with a powercycle reboot so i kept the watchdog service on.  It points to the orion watchdog service.

 

Since omv5 has changed a couple things are different now: kernel, urbackup service is now a docker, cockpit, and portainer.

 

i stopped the urbackup docker.. still had random reboots ~3 days.

 

i decided to switch to the older 4.19.159 kernel now.

 

I will see how it works.

 

Other notes about armbian 20.11

@gprovost

I have not had issues with going to the kernel 4.19.159 or greater

 

@Igor

 

The armbian-apt-updates located here: /usr/lib/armbian this bash script does not work on a clean build(it will not create the temp file needed for updates). I switched to the python script version from debian 9 so it will download updates. (Not sure why it switched) 

Also, the file in /etc/update-motd.d 30-armbian-sysinfo always gets changes when armbian is updated and i have to switch the STORAGE= variable to the correct storage i am using.

 

Thanks

 

Patrick

 

 

2 hours ago, PEW said:

The armbian-apt-updates located here: /usr/lib/armbian this bash script does not work on a clean build(it will not create the temp file needed for updates). I switched to the python script version from debian 9 so it will download updates. (Not sure why it switched) 

Also, the file in /etc/update-motd.d 30-armbian-sysinfo always gets changes when armbian is updated and i have to switch the STORAGE= variable to the correct storage i am using.

Review is welcomed:
https://github.com/armbian/build/pull/2402

On 11/30/2020 at 2:30 AM, FredK said:

@Mangix No. it's a EXT4 RAID5.

Maybe btrfs does something special.

@FredK the PR has been merged.   Maybe @Igor can give a little notice here, once the next bugfix debs are released? 

I just ran

apt-get update && apt-get upgrade

and did not see a kernel update. Is this expected, if yes is there any ETA if I do not want to build the kernel myself?

New kernel 5.9.14-mvebu available and installed.

 

vor 10 Stunden schrieb FredK:

New kernel 5.9.14-mvebu available and installed.

Mail from cron at 00:34:

/usr/lib/armbian/armbian-apt-updates: line 39: lsb_release: command not found

 

@FredK is lsb_release (/usr/bin/lsb_release) really missing or it's a path issue ?

 

I don't see this issue on my side.

 

 

vor 10 Stunden schrieb gprovost:

@FredK is lsb_release (/usr/bin/lsb_release) really missing or it's a path issue ?

 

I don't see this issue on my side.

It's really missing. How to restore it?

EDIT: Restored via "apt-get reinstall".

Edited December 14, 20205 yr by FredK

Unrelated but one of the patches that I removed seems to actually be useful.

 

I just talked to Felix Fietkau and according to him, it seems the mvneta driver does not do any hardware queue configuration, leading to a nasty performance problem. Testable with iperf -P 4. Not iperf3.

 

Although the equipment he tested on did have a switch. The Helios4 does not.

 

I don't think the way I'm using mine it matters a whole lot though.

Ah but that might matter for the clearfog. Remember armbian supports more than only the helios4. The mvebu patches we've removed also affect clearfogbase & pro. 

 

So if I understand correctly we need this patch again? https://github.com/armbian/build/commit/15cb0f6e3f688d60a4565079468d9c7fd6b2f7a3#diff-0e2d5f1c7cffdc7dfa0c8bb8730d65ee262430d835a454ba5b0046dcb907800a

It should probably be tested beforehand.

 

Again, he tested "iperf -P 4" with swconfig on an armada device. He doesn't remember if it was the armada 37x or 38x. Clearfog devices are only the latter I believe.

 

edit: ehm I'm getting full speeds when I tested this. I think he tested this on the older 37x platform.

 

edit2: second posibility: iperf from one device connected to the switch to another connected to the switch. I tested from the helios device itself to a router (mvebu 385 platform running OpenWrt).