Heisath

I think what he meant is: "Your data is expensive, don't stick to ARM" -> Buy a better / easier supported and more stable / mature board like literally ANY x86 small form factor thing. Can get them easy with actual SATA etc. Real BIOS....

@halfa merging both files into one is the proposed solution. No need for PR, I already created one here: https://github.com/armbian/build/pull/3092 One thing I am not sure about is removing the old file(s) in case of update...

Ok @SIGSEGV thanks for confirming that the old bug is back. So the buildscript still does not correctly seperate between legacy and current. If you are able to build images yourself it would be great if you could build a helios64 image (current) from this pr/branch https://github.com/armbian/build/pull/3092 and test if it works + the correct files are present.

@Igor no. This is a) a new problem and the proposed fix is IMHO not correct. AND b) the old fix (on branch https://github.com/armbian/build/tree/helios64-udev-hwmon-fix) was never merged, tested or anything else. Regarding the old problem: As mentioned in the previous thread, I do NOT have a helios64 so cannot test any changes. Nobody else stepped up to test and report back. Also sometime later someone said: SO I assumed this had magically fixed itself and did not need further attention. Read here for full thread: Regarding the new problem: Simply changing the fancontrol rules from thermal-cpu to thermal-board is incorrect AFAIK. Looking at the udev rules: https://github.com/armbian/build/blob/master/packages/bsp/helios64/90-helios64-hwmon.rules It should be thermal-cpu for the cpu temperature and thermal-board for the board temperature. And then it only makes sense to attach the fancontrol to the CPU temp. Why the thermal-cpu is not available anymore I don't know. But it is not a solution to the root cause to just fix the fancontrol to the board temp. We should instead investigate why the thermal-cpu node is not available anymore and fix it. Maybe @aprayoga or @gprovost are back from their break? EDIT: Looking back at it, maybe it is the same problem. @SIGSEGV can you check if you have the 90-helios64-hwmon.rules or the 90-helios64-hwmon-legacy.rules in your udev? EDIT2: PR here: https://github.com/armbian/build/pull/3092

Armbian has no default iptables rules configured. So all rules are from either Docker or OpenMediaVault.

For future reference, the *-u-boot* packages contain the uboot (bootloader). When installed it puts some files into /usr/lib/u-boot and /usr/lib/<packagename> These files can be used to install / update the actual uboot on the box/board, although the process is not started automatically as updating uboot is mostly unneccessary and might lead to problems only fixable with serial uart access. For actually updating the bootloader the armbian-config utility can be used. (Or check what the platform install file in /usr/lib/u-boot does and do it manually). If you receive updates from future version you might be on 'nightly' branch / mode.

Just a hunch, have you maybe on the helios specified the ip address of your laptop? And that has changed?

Its interesting whats possible, isn't it?

Hi, how long does the time have to stay within the 1/60th of a second requirement? Minutes? Hours? I think there are tutorials out there on how to use common GPS modules (ebay search for raspi gps gives some), most of the ublox ones also have a rather precise timing output. From the website (ublox) it seems the also sell modules explicitly made for time synchro. Depending on how long you want to keep the devices in sync it might be acceptable to only sync them before you start filming (?) and have the device clock continue when gps goes away. If a really precise clock is required I would maybe turn away from SBCs (boards with multithread, multiprocessors) have a tendency to have problems with jitter (obv. reasons). If you need a precise time (as in your link) I'd suggest going for a simple microcontroller. There you can grab the GPS signal once, and then setup an internal timer - which are pretty precise considering the micro does only a thing at a time (if you go for cheap AVR ones). Afterwards just have the timer run out every 1/60th of a second and toggle a IO pin. Time reference done. EDIT: Bonus: If you are in Europe (although other regions probably have similar services) you could also use DCF77 to do the initial sync.

It seems like you would need to setup LVM first. Maybe try to redo the config as it was on the old sd card? For general mdadm raid importing: https://wiki.kobol.io/helios4/mdadm/#import-an-existing-raid-array For future: Backup the sd card (atleast rsync) in regular intervals. These things will fail.

How / to which connectors did you connect the Arduino? USB?

Thats sad. Another Marvell SoC which has dvfs advertised but not working. We went through similar troubles with A380 (Helios4 and Clearfog), seems like there is not much interest from chipmaker to help out.

Measure the power output from the power supply. Make sure to have everything disconnected from the helios and no shorts ( dont put it on a metal surface ) before trying again. For measuring the power supply, you can either measure on the power plug directly or on the hdd connectors. Check the images here: https://wiki.kobol.io/helios4/hardware/#connector-interface-list (J19 middle two pins are GND, outer pins should be +5 and +12V; careful not to short them!)

Why not just install and configure the servies you need seperately? If you want samba / windows network share, take samba. `apt install samba` For dns / dhcp / dns over tls there's dnsmasq, stubby... For sharing with TV, you could use minidlna. For backups DO NOT use raid. Raid is not a backup solution. Rather use rsync or more advanced tools to sync the drives at predefined time intervals. This gives you defined backup behaviour and allows you to use the disk in all other devices without problems should the helios fail.

Question is, is it really fixed? Or is it just by chance now always including the current udev rule? Also maybe on legacy now using the current file? I'd think so... I will leave my branch open for now. Maybe someone has the time & hardware to fully test.

There is no good way to only build uboot sorry. Regarding the created uboot, I am pretty sure all variants are built. But ./cache/sources/ is not the right place to look for them. Please check ./output/debs/ for a uboot deb archive. Its should be named somewhat like these: https://beta.armbian.com/pool/main/l/linux-u-boot-clearfogbase-current/ If you unpack the .deb you can find all variants of u-boot inside ./usr/lib/linux-u-boot.../ they should be named accordingly. EDIT: Just checked by building: Said .deb gets created and contains all needed files. You can also abort the buildscript with ctrl-c after it is done with uboot (and has started the kernel) to not have to build everything all the time.

Historic images are available here: https://archive.armbian.com/helios64/archive/ or https://mirrors.dotsrc.org/armbian-dl/helios64/archive/ You could also build an image yourself (maybe from this branch https://github.com/armbian/build/tree/helios64-udev-hwmon-fix) and report if it works.

Fix for the problem by combining the hwmon rules into one file and adding it regardless of kernel branch: https://github.com/armbian/build/tree/helios64-udev-hwmon-fix Please review the changes and _test_ them. I do not have a helios64 so just done quickly. @halfa @gprovost

Maybe create a service that toggles a pin as a watchdog and setup the service in a way it gets shutdown at the latest possible stage? Then you still have to wait a few seconds, but there is less variation. Or maybe the device has a power led which turns off? Or network led? Then you could hook onto that. Or connect the DEBUG UART tx to your ATiny and use that do detect when after shutdown has begun no more message are sent. Or keep it like it is but make sure to issue a 'sync' command before actually starting the shutdown. This way the shutdown will probably have less time variation. Btw. the ATtiny is a AVR not ARM micro controller.

Another temporary solution is already provided in the first post btw. Anyone struggling with this issue and only wants the fan to work again can just:

might need to do sudo ncdu -x / Then you can navigate through a tree-view, and figure out where the size comes from. As a general step-by-step guide: - use "df -h" (or something like that), to figure out which device / mountpoint is getting full user@builder:~$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 1,6G 1,2M 1,6G 1% /run /dev/sda3 79G 31G 44G 41% / tmpfs 7,9G 0 7,9G 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 4,0M 0 4,0M 0% /sys/fs/cgroup /dev/sda2 94M 5,2M 89M 6% /boot/efi tmpfs 1,6G 136K 1,6G 1% /run/user/1000 We now know, /dev/sda3 is fullest, and is mounted on / - next use "sudo ncdu -x /" to check the contents / where the space goes: ncdu 1.15.1 ~ Use the arrow keys to navigate, press ? for help --- / -------------------------------------------------------------------------- 17,2 GiB [##########] /home 8,5 GiB [#### ] /usr 2,0 GiB [# ] swapfile 1,0 GiB [ ] /var 760,0 MiB [ ] /root 508,4 MiB [ ] /opt 251,1 MiB [ ] /boot 11,6 MiB [ ] /etc 68,0 KiB [ ] /tmp 36,0 KiB [ ] /snap e 16,0 KiB [ ] /lost+found 8,0 KiB [ ] /media e 4,0 KiB [ ] /srv e 4,0 KiB [ ] /mnt e 4,0 KiB [ ] /cdrom @ 0,0 B [ ] libx32 @ 0,0 B [ ] lib64 @ 0,0 B [ ] lib32 @ 0,0 B [ ] sbin @ 0,0 B [ ] lib @ 0,0 B [ ] bin Total disk usage: 30,1 GiB Apparent size: 28,8 GiB Items: 789697 We see that most storage goes to /home, /usr and the swapfile. As the interface is interactive, you can just navigate down the folder structure to find the culprit.

Use a tool like ncdu to figure out which folder(s) are getting so big. Then look into them.

To confirm I checked with https://armbian.systemonachip.net/apt/pool/focal-utils/a/armbian-bsp-cli-helios64/ Which really shows that there is a wrong file in 21.05.2 (/etc/udev/rules.d/90-helios64-hwmon...), interestingly the nightly build from beta.armbian.com does have it right... @Igor pinging you here, as I am not familiar with the new packaging. Was this only an issue in one version and will be fixed automatically with next release/minor version? Or do we have to fix some packaging somewhere...?

Just to clarify, was this a problem with 21.05.1 or IS it still a problem with 21.05.2? If it is still active problem, we should seek to do a Pullrequest to fully fix it in the buildsystem. EDIT: Seems to be correct in the buildsystem: https://github.com/armbian/build/blob/3b3d85e25c2ecde30df7b5274fc6f1b9c0299ea2/config/sources/families/include/rockchip64_common.inc#L395-L401

@tony013Seems ok to me? Sure the bootlog is posting some messages which overlap with the new password prompt (see first line after "New to Armbian?") Have you tried just typing in a new root pw and pressing enter?