FredK Posted November 29, 2020 Posted November 29, 2020 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?
Mangix Posted November 30, 2020 Author Posted November 30, 2020 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.
Heisath Posted November 30, 2020 Posted November 30, 2020 @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.
FredK Posted November 30, 2020 Posted November 30, 2020 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.
FredK Posted November 30, 2020 Posted November 30, 2020 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.
Mangix Posted November 30, 2020 Author Posted November 30, 2020 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.
FredK Posted November 30, 2020 Posted November 30, 2020 vor einer Stunde schrieb Mangix: Is that btrfs raid5? @Mangix No. it's a EXT4 RAID5.
PEW Posted December 1, 2020 Posted December 1, 2020 @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
Igor Posted December 1, 2020 Posted December 1, 2020 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
Mangix Posted December 2, 2020 Author Posted December 2, 2020 On 11/30/2020 at 2:30 AM, FredK said: @Mangix No. it's a EXT4 RAID5. Maybe btrfs does something special.
Heisath Posted December 2, 2020 Posted December 2, 2020 @FredK the PR has been merged. Maybe @Igor can give a little notice here, once the next bugfix debs are released? 1
kratz00 Posted December 9, 2020 Posted December 9, 2020 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?
FredK Posted December 12, 2020 Posted December 12, 2020 New kernel 5.9.14-mvebu available and installed.
FredK Posted December 13, 2020 Posted December 13, 2020 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
gprovost Posted December 14, 2020 Posted December 14, 2020 @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.
FredK Posted December 14, 2020 Posted December 14, 2020 (edited) 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, 2020 by FredK 1
Mangix Posted December 18, 2020 Author Posted December 18, 2020 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.
Heisath Posted December 19, 2020 Posted December 19, 2020 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
Mangix Posted December 20, 2020 Author Posted December 20, 2020 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).
Recommended Posts