Skip to content

FAN control OMV Auyfan 0.10.12: gitlab-ci-linux-build-184, Kernel 5.6

Linux
12 3 1.3k 1
  • Hey,

    I will do it in english, hope it is okay. Thanks, for very informative forum.

    My question is, is it possible to control the FAN in the newest OMV Auyfan 0.10.12: gitlab-ci-linux-build-184, Kernel 5.6?
    The install was very easy no problems at all, the only problem is i did try some different commands to reach the fan, but was not able to get it going. Do somebody know how? Thanks.

    Best Regards.
    Soeren

  • Hi Soeren,

    I have this succesfully running.

    Kind Regards
    Martin

  • Hi Soeren,

    I have this succesfully running.

    Kind Regards
    Martin

    @mabs sagte in FAN control OMV Auyfan 0.10.12: gitlab-ci-linux-build-184, Kernel 5.6:

    Hi Soeren,

    I have this succesfully running.

    Kind Regards
    Martin

    Thanks, i will try the fan tool again. I'm almost sure i did try without luck, have you edited something in the fan tool conf..?

  • Hi,

    I only played with two parameters.

    I have two rockpro64 boards, currently one has a small fan and the other one has a large fan.

    Therefore I changed PROFILE_NR accordingly.

    Also I have ALWAYS_ON on true on the one with the large fan, but don't see a difference. The fan goes on and off still, maybe I misinterpreted the parameter.

    Also I just noticed now that the CTL settings of the version on github changed slightly, but I think this only improved the detection depending of the kernel settings.

    M

  • @mabs

    With the new OMV kernel 5.6 image from Auyfan, i can't get the FAN to spin - If the fan spins it runs really slow, no sound from the fan.

    With the FAN tool the master installation "failed" and with the release installation it did report "active"..
    I have installed a 92mm FAN inside the NAS case, it runs on Armbian with kernel 5.4.32

    I will open op the case later today to be sure. Thanks.

  • Hi,

    Now i did find the fan, here it goes "nano /sys/devices/platform/pwm-fan/hwmon/hwmon3/pwm1" it is at "0" can be controlled to "255"

    Best Regards.

  • Yes that is basically the way ATS is doing the changing as well I think, as those /sys entries are in the _CTL variables.

    good that you got it working, or are you only half way?

    M

  • @mabs

    The tool works on all image under 5.4 or so for me. But yes i am at the finish line, just wanted the fan to be always on. Just wanted to share, if someone will run in the same problems. Thanks.

  • Helpful Thread!

    But, ATS don't work for me on kernel 5.6 with ayufan release. Only this command works.

    nano /sys/devices/platform/pwm-fan/hwmon/hwmon3/pwm1
    

    Thanks @soerenderfor for the hint.

  • Ok, problem in ATS is this?

    -- FAN Control[ String ]
    	PWM_CTL		= {
    			"/sys/class/hwmon/hwmon0/pwm1",
    			"/sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1",
    			"/sys/devices/platform/pwm-fan/hwmon/hwmon1/pwm1"
    	},
    
  • Ok, problem in ATS is this?

    -- FAN Control[ String ]
    	PWM_CTL		= {
    			"/sys/class/hwmon/hwmon0/pwm1",
    			"/sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1",
    			"/sys/devices/platform/pwm-fan/hwmon/hwmon1/pwm1"
    	},
    

    @FrankM - did you try fix the ATS tool, if yes. Will it Work?

    Best Regards.

  • Hi,

    since I'm currently change my rockpro64 setup I came across this.

    With the kernel from ayufan you need to set PWM_CTL to

    /sys/devices/platform/pwm-fan/hwmon/hwmon3/pwm1
    

    for my self compiled one I need

    /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1
    

    But I got it only working with one entry for PWM_CTL e.g.

    PWM_CTL		= "/sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1",
    

    after that you need to start ats again

    sudo systemctl stop ats
    sudo systemctl start ats
    

    initially the fan should start immediately for a short period of time.

    In case it is even a different one on your kernel you can find the right one using this command.

    sudo find /sys -name pwm1 | grep hwmon
    

    So far I'm not sure which kernel parameter or modul changes this.

    Martin

  • Nextcloud - Upgrade Hub 9 (30.0.0)

    Nextcloud nextcloud linux
    3
    2
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF
    Ich habe dann mal weitergesucht, dank ein paar Tipps aus dem Fediverse, sehe ich jetzt was heller https://chaos.social/@towo/113152384137718991 Nachdem ich dann ein paar Apps gefunden und installiert hatte AppAPI Flow tauchte dann im Benutzermenü, rechts oben, folgendes auf. [image: 1726992766346-bildschirmfoto_20240922_101125.png] Das Interessante ist der Menüpunkt Externe Apps. Nun sollte ich diese Funktion verstanden haben. Das Nextcloud Team integriert also diese Windmill App via Docker Container und greift dann darauf zu. In der Videopräsentation war doch von in Nextcloud integriert die Werbeansprache!? Ein Docker Container ist für mich keine Integration. Ich habe einige rudimentäre Kenntnisse von Docker, ausschließlich lokal. Aber, ich komme nicht auf die Idee das auf einem produktiven Server zu installieren. Somit kann ich das Testen hier beenden und die Apps alle wieder deinstallieren. Jetzt habe ich noch im Kopf, ob man das mal mit einem Nextcloud-AIO testen soll? Natürlich auf einem Testsystem. https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-to-use-this
  • Semaphore - Die API

    Verschoben Ansible ansible semaphore linux gitlab
    2
    0 Stimmen
    2 Beiträge
    330 Aufrufe
    FrankMF
    Ich hasse schlecht lesbaren Code, scheint man sich bei Python so anzugewöhnen. Habe da nochmal was mit der langen Zeile getestet. stages: - deploy deploy: stage: deploy script: # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables - >- curl -v XPOST -H 'Content-Type: application/json' -H 'Accept: application/json' -H "Authorization: Bearer $SEMAPHORE_API_TOKEN " -d '{"template_id": 2}' https://<DOMAIN>/api/project/2/tasks only: - master # Specify the branch to trigger the pipeline (adjust as needed) Hier noch was Dr. ChatGPT dazu schreibt [image: 1692643209159-631de9d4-b04d-4043-bfff-c5f2d1b6eea7-grafik.png] Erledigt - läuft Und verstanden habe ich es auch.
  • NanoPi R5S - Samba

    NanoPi R5S nanopir5s linux
    5
    1
    0 Stimmen
    5 Beiträge
    508 Aufrufe
    FrankMF
    Test zu dem NFS Mount (240GB USB SSD an USB-Port) [frank-ms7c37 nfs]# dd if=/dev/zero of=sd.img bs=1M count=2048 oflag=direct,nonblock 2048+0 Datensätze ein 2048+0 Datensätze aus 2147483648 Bytes (2,1 GB, 2,0 GiB) kopiert, 20,0851 s, 107 MB/s Test zum NAS Mount (Samba) (2TB 2,5Zoll HDD am USB-Port) [frank-ms7c37 NAS]# dd if=/dev/zero of=sd.img bs=1M count=2048 oflag=direct,nonblock 2048+0 Datensätze ein 2048+0 Datensätze aus 2147483648 Bytes (2,1 GB, 2,0 GiB) kopiert, 21,4538 s, 100 MB/s Das für den NAS Mount (Samba) sollte die maximal Schreibgrenze der Festplatte sein. Mehr dürfte da nicht gehen. Das andere könnte an den Adaptern liegen, die ich dafür benutze. Bei mir ist NFS hier aktuell nicht viel schneller, oder ich bin zu doof dafür.
  • Nextcloud 23.0.3

    Nextcloud nextcloud linux
    1
    0 Stimmen
    1 Beiträge
    179 Aufrufe
    Niemand hat geantwortet
  • Images 0.11.x

    Images linux rockpro64
    5
    0 Stimmen
    5 Beiträge
    491 Aufrufe
    FrankMF
    0.11.2: gitlab-ci-linux-build-187 released 0.11.2: Update OMV install (to also be able to run OMV6)
  • ROCKPro64 - Debian Bullseye Teil 1

    ROCKPro64 debian linux rockpro64
    17
    4
    0 Stimmen
    17 Beiträge
    2k Aufrufe
    FrankMF
    Durch diesen Beitrag ist mir mal wieder eingefallen, das wir das erneut testen könnten Also die aktuellen Daten von Debian gezogen. Das Image gebaut, könnt ihr alles hier im ersten Beitrag nachlesen. Da die eingebaute Netzwerkschnittstelle nicht erkannt wurde, habe ich mal wieder den USB-to-LAN Adapter eingesetzt. Bus 005 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Die Installation wollte ich auf einem NVMe Riegel installieren. Die Debian Installation durchgezogen und nach erfolgreicher Installation neugestartet. Und siehe da, ohne das man alles möglich ändern musste, bootete die NVMe SSD Eingesetzter uboot -> 2020.01-ayufan-2013...... Die nicht erkannte LAN-Schnittstelle müsste an nicht freien Treibern liegen, hatte ich da irgendwo kurz gelesen. Beim Schreiben dieses Satzes kam die Nacht und ich konnte noch mal drüber schlafen. Heute Morgen, beim ersten Kaffee, dann noch mal logischer an die Sache ran gegangen. Wir schauen uns mal die wichtigsten Dinge an. root@debian:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: enx000acd26e2c8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff inet 192.168.3.208/24 brd 192.168.3.255 scope global dynamic enx000acd26e2c8 valid_lft 42567sec preferred_lft 42567sec inet6 fd8a:6ff:2880:0:20a:cdff:fe26:e2c8/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:20a:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5426sec preferred_lft 1826sec inet6 fe80::20a:cdff:fe26:e2c8/64 scope link valid_lft forever preferred_lft forever Ok, er zeigt mir die Schnittstelle eth0 ja an, dann kann es an fehlenden Treibern ja nicht liegen. Lässt dann auf eine fehlerhafte Konfiguration schließen. Nächster Halt wäre dann /etc/network/interfaces Das trägt Debian ein # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug enx000acd26e2c8 iface enx000acd26e2c8 inet dhcp # This is an autoconfigured IPv6 interface iface enx000acd26e2c8 inet6 auto Gut, bei der Installation hat Debian ja nur die zusätzliche Netzwerkschnittstelle erkannt, folgerichtig ist die auch als primäre Schnittstelle eingetragen. Dann ändern wir das mal... # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug enx000acd26e2c8 allow-hotplug eth0 #iface enx000acd26e2c8 inet dhcp iface eth0 inet dhcp # This is an autoconfigured IPv6 interface #iface enx000acd26e2c8 inet6 auto iface eth0 inet6 auto Danach einmal alles neu starten bitte systemctl status networking Da fehlte mir aber jetzt die IPv4 Adresse, so das ich einmal komplett neugestartet habe. Der Ordnung halber, so hätte man die IPv4 Adresse bekommen. dhclient eth0 Nachdem Neustart kam dann das root@debian:/etc/network# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff inet 192.168.3.172/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 42452sec preferred_lft 42452sec inet6 fd8a:6ff:2880:0:6003:b0ff:fed6:dcb3/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:6003:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5667sec preferred_lft 2067sec inet6 fe80::6003:b0ff:fed6:dcb3/64 scope link valid_lft forever preferred_lft forever 3: enx000acd26e2c8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff Fertig, eth0 läuft. Nun kann man den zusätzlichen Adapter entfernen oder halt konfigurieren, wenn man ihn braucht. Warum der Debian Installer die eth0 nicht erkennt verstehe ich nicht, aber vielleicht wird das irgendwann auch noch gefixt. Jetzt habe ich erst mal einen Workaround um eine Installation auf den ROCKPro64 zu bekommen.
  • Logger

    Linux linux
    1
    0 Stimmen
    1 Beiträge
    436 Aufrufe
    Niemand hat geantwortet
  • Installation von Grav & NGinx & PHP7.2

    Angeheftet Verschoben Grav grav linux
    2
    1
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF
    Nachdem ich den ROCKPro64 jetzt auf den Mainline umgestellt habe, lief meine Testinstallation von Grav nicht mehr. Hilfreiche Sache um das Problem zu lösen -> https://gist.github.com/GhazanfarMir/03bd1f1f770a3834d47274586d46ea62 Ich bekam immer 502 Bad Gateway, Grund war ein nicht korrekt gestarteter php-pfm Service. rock64@rockpro64v2_0:/usr/local/bin$ sudo service php7.2-fpm start rock64@rockpro64v2_0:/usr/local/bin$ sudo service php7.2-fpm status ● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-08-16 20:15:20 CEST; 21s ago Docs: man:php-fpm7.2(8) Main PID: 3206 (php-fpm7.2) Status: "Processes active: 0, idle: 2, Requests: 3, slow: 0, Traffic: 0.2req/sec" Tasks: 3 (limit: 4622) CGroup: /system.slice/php7.2-fpm.service ├─3206 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf) ├─3207 php-fpm: pool www └─3208 php-fpm: pool www Aug 16 20:15:19 rockpro64v2_0 systemd[1]: Starting The PHP 7.2 FastCGI Process Manager... Aug 16 20:15:20 rockpro64v2_0 systemd[1]: Started The PHP 7.2 FastCGI Process Manager.