SIGSEGV
-
Posts
73 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by SIGSEGV
-
-
@Igor, is there a way to have access and test pre-release images from the official Armbian build system (nightly images should be fine)?
That way we can participate on the QA process and help raise flags when pre-released changes break the stable builds.
I understand that you do not have an Helios64 to test, and so as part of the community we should be able to help in that regard.
-
-
I get this as output:
Package: armbian-bsp-cli-helios64 Version: 21.05.8 Priority: optional Section: kernel Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 1,024 B Provides: linux-focal-root-legacy-helios64, linux-focal-root-current-helios64, linux-focal-root-edge-helios64 Depends: bash, linux-base, u-boot-tools, initramfs-tools, lsb-release, fping Recommends: bsdutils, parted, util-linux, toilet Suggests: armbian-config Breaks: linux-focal-root-legacy-helios64 (<< 21.05.8~), linux-focal-root-current-helios64 (<< 21.05.8~), linux-focal-root-edge-helios64 (<< 21.05.8~) Replaces: zram-config, base-files, armbian-tools-focal, linux-focal-root-legacy-helios64 (<< 21.05.8~), linux-focal-root-current-helios64 (<< 21.05.8~), linux-focal-root-edge-helios64 (<< 21.05.8~) Download-Size: 417 kB APT-Manual-Installed: yes APT-Sources: http://apt.armbian.com focal/focal-utils arm64 Packages Description: Tweaks for Armbian focal on helios64
I see a few packages listed under 'Breaks'
-
-
-
Right now the file present on the installation is: '90-helios64-hwmon-legacy.rules'
I'll update the title of this post to mark a temporary fix, I agree with both of you that the fans should be tied to the CPU temperatures and not the board. But since the release broke monitoring having the fan control tied to something is better than nothing - otherwise the fan don't even spin up.
-
A few Armbian packages were updated (armbian-bsp-cli-helios64, armbian-config, armbian-firmware &armbian-zsh) to version 21.05.08.
At some point I noticed that the fancontrol service had failed to start up after the reboot - it was complaining about a file missing(/dev/thermal-cpu). If you run into this after the update, just update your /etc/fancontrol to the content below and your fancontrol should go back to normal.
# Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu # After 21.05.08 [2021.08.10] # Temp source : /dev/thermal-board INTERVAL=10 # FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input # After 21.05.08 [2021.08.10] FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-board/temp1_input /dev/fan-p7/pwm1=/dev/thermal-board/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINPWM=20
-
You can just write the image to the SD card and boot.
For SSH, as long as you know what IP address the Helios64 gets than you can just use that to connect.
The serial terminal is just to check if things booted correctly or in case of an error that needs to be diagnosed.
You should be fine with your usual process.
-
-
I checked for any available updates yesterday, and this (linux-u-boot-helios64-current 21.08.1) was applied.
Can't find what was new or if it was only a version bump.
By the way, nothing broke after the update.
-
I'm curious about this issue.
Let us know if changing the CPU Voltage has an effect on system stability.
-
-
Enjoy your time off - looking forward to new products from you guys.
-
My comment might be late to the party - if there was a possibility to add an optional display and a few user-configurable buttons to the Front Panel, that would be great.
I know it would mess a bit with the airflow, but it could be used for system monitoring and few other specific use cases.
-
-
-
On my system the helios64-ups.timer is disabled by default.
Is this a timer that has to be manually enabled ?? I thought that the Helios would check if it had the battery and activate this automagically.
It might be better to have a daemon in the background that checked the battery value every 20 seconds and only printed out output when there was a change.
-
-
-
Thanks for the tip @ShadowDance, in my case I haven't had any crashes while using ZFS.
But I've updated my systemd scripts to take the ZFS scheduler into account.
What I did notice was that my data-sets on raid-z1 pool seems to be a bit more snappy (it might be a perception issue on my part).
[Unit] Description=HDD-Idle service After=basic.target multi-user.target [Service] Type=oneshot ## Set Power Management parameters to all HDD ExecStart=/bin/sh -c '/usr/sbin/hdparm -qB255S120 /dev/sd[a-e]' ## Allows ZFS to use it's own scheduler for rotating disks. ExecStart=/bin/sh -c 'echo none | tee /sys/block/sd[a-e]/queue/scheduler' [Install] WantedBy=multi-user.target
-
21 hours ago, oneo said:
Hey there, so I was curious is there an easier way to make microSD take precedence in the boot order then having to futz with jumpers?
Wanting to try out a new distro on microSD before deciding to make the switch and flash it to eMMC.
If I do futz with jumpers I'll still be able to mount and write to the eMMC correct?@oneo - what distro are you trying out?
-
@allen--smithee Thanks for the feedback.
-
6 hours ago, snakekick said:
hello @SIGSEGV tuned is only a another CPU Scaling Governor or?
do you have problems before you switch to tuned and this solve your problems ?
I did have a few lockups when running my setup scripts that actually install a few of the packages I needed/wanted to run on the Helios64. It would lock sometimes while idle.
'tuned' was one of the packages that is installed on our cloud environments and some options are available through the cockpit management interface. I wouldn't describe 'tuned' as a CPU Scaling Governor.
The one thing I noticed was that if configured tuned in the early steps of installation - my scripts would finish running their task and I didn't have lockups (if tuned was not configured early in the process it would freeze at random points).
tuned project - their website description is as follows
Tuned is a system tuning service for Linux. It: monitors connected devices using the udev device manager tunes system settings according to a selected profile supports various types of configuration like sysctl, sysfs, or kernel boot command line parameters, which are integrated in a plug-in architecture supports hot plugging of devices and can be controlled from the command line or through D-Bus, so it can be easily integrated into existing administering solutions: for example, with Cockpit can be run in no-daemon mode with limited functionality (for example, no support for D-Bus, udev, tuning of newly created processes, and so on) for systems with reduced resources stores all its configuration cleanly in one place – in the Tuned profile – instead of having configuration on multiple places and in custom scripts
Take my word with a grain of salt - this is only my experience with the Helios64.
-
One thing that has worked for me since I got the board around on Nov of last year is to install package 'tuned' and set the profile to 'server-powersave'.
The two BIG cores can go up to 1.8GHz and the little cores go up to 1.4GHz under heavy usage without any lockups - most of the time in idle they stay at 408MHz.
apt -y install tuned tuned-adm profile server-powersave systemctl restart tuned
Upgrading to Bullseye (troubleshooting Armbian 21.08.1)
in Rockchip
Posted
Thanks @lanefu.
Another idea would be a "test week" (or whatever period makes sense) - a time when the users can download pre-release/test images of the upcoming version/release and the maintainers give timely feedback about issues found in the test kernels and user space binaries. I know that Fedora follows a similar approach (I get the notifications from the Fedora Magazine) - the main objective is to catch breaking bugs.
Now, if the community doesn't participate - then all complaints can be considered rants. We have to participate to make sure our systems are running as smoothly as possible. Software development, QA, Trouble shooting are task that take time/effort, as @Igor has always pointed out, we need to get involved somehow in order to contribute back. In the end Armbian is a community project - if you can't/want to donate funds, donate time and effort instead.