Source based Linux distribution CRUX-ARM adhering to ideology keep it simple, has its own package system, also supports the port system.
the image building system now supports slaсkwarearm, slarm64, crux-arm
crux-arm-3.6-aarch64-core-rock_3-4.19.193-build-20210830.img.zst
crux-arm-3.6-aarch64-core-rock_3-4.19.193-build-20210830.img.zst.sha256
crux-arm-3.6-aarch64-core-rock_3-4.19.210-build-20211009.img.zst
crux-arm-3.6-aarch64-core-rock_3-4.19.210-build-20211009.img.zst.sha256
hello
I just tested it just by burning image to sd card with balena. It booted with several errors:
Is there any installation docs? what is that boot-20211009.tar.xz file?
@mara I tested few things today on this build and I think it’s worth to mention about that,
First: there are problems with certificates, let’s encrypt R3 is insecure for system and packaging system uses it to get some ports. All those fails so You can’t update system right after installation.
Second: those packages that can be updated fails to build, i left sysup for whole day and was sure that it is just very slow on rock3A to get and compile all sources, later I found out that it doing same thing in endless loop.
Of course probably both can be resolved easily, I will be looking for more information on those plus startup errors when I’ll have more time.
boot-20211009.tar.xz these are the compiled bootloader components, they are also located in /boot
installation is similar README.TXT
the rest is according to the crux-arm / crux documentation
both problems are most likely due to the wrong system time.
I wanted to be sure that everything was installed correctly, I just checked that and - those components were installed just from image, checksums are same. No additional steps are needed with this file.
Yes, this is correct - I adjusted time and updates did not end in loop. It took about 15h to update system (crux is compiling most things). At the end it could not update two packages (glibc and python3), could see that there are newer but also claimed that everything is up to date. When trying to update manually it used old version.
When it updated everything it could I restarted it few times and wanted to debug issue with time and date. Something is obviously wrong here. When I plug out usb-c it come back with 2017 date. I searched for ntpdate, but seems that this package is not in ports and I didn’t wanted to spend extra time compiling that one. I set date&time manually and synced that to hwclock. Sometime time is ok after restart but never when it’s power is unplugged. AFAIK board has RTC but could not find more information on that. I checked debian again and it never loose time on reboot. It also don’t fetch it on start from Internet (I checked that with unplugged cable). I guess that messages above about rk817 battery can say more about this problem.
Right now I need to control and set time manually on each reboot. Any idea how to fix it?
for this in crux-arm there is a task /etc/cron/dail/rdate or https://crux.nu/Wiki/Faq?from=Main.Faq#ntoc33
also installed a script to maintain time when turning off/on without RTC that synchronizes the time every 15 minutes from the time the image was created.
I know it should work with ntpdate, but there none in ports or system. Should there be any?
I briefly checked that script too, but then just started to wondering if it should have hardware clock or not I checked ubuntu image and it keeps time correctly. There is also same message about rk817 in dmesg, but time is ok, both with power or disconnected and without network (so it can’t ntpdate it).
