Manuelle Pictory Treiberkonfiguration ohne Neustart?

[Lace]

Hallo,

ich installiere die _config.rsc Konfigurationsdatei mit Ansible nach /var/www/pictory/projects/ und setze danach auch einen Symlink nach /etc/revpi/config.rsc
Leider funktioniert piTest -x danach nicht um die Konfiguration zu laden, es kommt die Fehlermeldung: "Cannot reset: No such device"
Nach einem Neustart des Gerätes funktioniert es, aber ich möchte keinen Neustart durchführen da dies den weiteren Ansible Installationsprozess unterbrechen würde.

Wie kann ich die Konfiguration config.rsc laden ohne Neustart?

[Lace]

Ich bin mittlerweile ein Stück weiter.

Nachdem ich die config.rsc bereitgestellt habe, lade ich das Kernelmodul
modprobe piControl
und restarte nochmal den Treiber
piTest -x
Das funktioniert alles ohne Fehlermeldungen.

Danach gibt piTest -d folgendes aus:

Found 1 devices:

Address: 0 module type: 95 (0x5f) RevPi Core V1.2
Module is present
input offset: 0 length: 6
output offset: 6 length: 5

Wenn ich dann aber die A1 LED auf grün setzen will passiert nichts, obwohl der Schreibbefehl ohne Fehlermeldung durchläuft:
piTest -s 6,0,1

Nach einem Neustart allerdings funktioniert es!
Wie krieg ich piControl korrekt OHNE Neustart initialisiert?

[dirk]

Hallo Lace, was ist Ansible? Ich würde vergleichen, was das Tool anders macht, als wenn man die Schritte selbst durchführt. An Deiner Vorgehensweise kann ich keinen Fehler sehen.
Die Datei "config.rsc" kopieren, piTest -x ausführen. Falls Du Änderungen am System gemacht hast, lade Dir das aktuelle "Stretch" Image herunter und versuche es von Hand. Wenn das tut dann mit Deinem Tool und schaue, was hier anders läuft. Evtl. steht im "kern.log" eine Ausgabe.

[Lace]

Hallo Dirk,

meine Vorgehensweise ist:
- frisches Stretch aufspielen
- Ansible Installation, hier mein Script (ist eigentlich selbsterklärend), dann kannst Du auch gleich etwas Ansible-Luft schnuppern
-> revpi-factory-reset ausführen
-> dtoverlay Krams in /boot/config.txt konfigurieren
-> pictory konfigurieren und Treiber neu starten

Meine Frage: kann es sein, dass die dtoverlay Kerneldatei geladen sein muss? Weil die wird zwar konfiguriert, aber das Kernel hat diese ja noch nicht geladen

Code: Select all

---
# tasks file for linux_revpi_setup_role

# check if this is a RevPi device by testing for revpi-factory-reset file
- stat:
    path=/usr/sbin/revpi-factory-reset
  register: isrevpi

- name: execute revolution pi init command
  become: yes
  command: '/usr/sbin/revpi-factory-reset {{ revpi_devicetype }} {{ revpi_serial }} {{ revpi_mac }}'
  when: isrevpi.stat.exists == True
  register: revpifactoryreset
  
- debug: var=revpifactoryreset.stdout_lines

- name: insert dtoverlay into /boot/config.txt
  become: yes
  lineinfile:
    dest: /boot/config.txt
    regexp: 'dtoverlay=revpi-.*'
    insertbefore: '^dtparam=eth0_mac_hi=.*$'
    line: 'dtoverlay=revpi-{{ revpi_devicetype }}'
    state: present
  when: isrevpi.stat.exists == True

- name: Install standard pictory setup file
  copy:
    src: "{{ role_path }}/files/pictory_config_revpi_{{ revpi_devicetype }}.rsc"
    dest: /var/www/pictory/projects/_config.rsc
    group: www-data
    owner: www-data
    mode: 0644
    backup: yes
  when: isrevpi.stat.exists == True
  
- name: Create symbolic link
  become: true
  file:
    src: "/var/www/pictory/projects/_config.rsc"
    dest: "/etc/revpi/config.rsc"
    state: link
  when: isrevpi.stat.exists == True
  
- name: Add the piControl module
  modprobe:
    name: piControl
    state: present
  when: isrevpi.stat.exists == True

- name: Restart pictory device driver globally
  shell: /usr/bin/piControlReset
  when: isrevpi.stat.exists == True
  
- name: Restart pictory device driver
  shell: /usr/bin/piTest -x
  when: isrevpi.stat.exists == True

[lukas]

ich installiere die _config.rsc Konfigurationsdatei mit Ansible nach /var/www/pictory/projects/ und setze danach auch einen Symlink nach /etc/revpi/config.rsc
Leider funktioniert piTest -x danach nicht um die Konfiguration zu laden, es kommt die Fehlermeldung: "Cannot reset: No such device"

Diese Fehlermeldung kommt, wenn das Device /dev/piControl0 nicht existiert, so dass piTest nicht mit dem piControl Kernel-Modul sprechen kann. Die Frage ist, hat Ansible das Kernel-Modul erfolgreich geladen? Schau doch mal in /var/log/kern.log, ob es Fehlermeldungen gab. Ein typischer Fehler ist, dass der Kernel-Thread spi0 nicht gefunden wurde. Das liegt dann meist daran, dass nicht das passende DT-Overlay geladen ist.

Meine Frage: kann es sein, dass die dtoverlay Kerneldatei geladen sein muss? Weil die wird zwar konfiguriert, aber das Kernel hat diese ja noch nicht geladen

Ja, der "dtoverlay" Eintrag in /boot/config.txt wird erst beim nächsten Booten gelesen und führt dann dazu, dass der Bootloader die passende dtbo-Datei lädt und in den generischen DeviceTree des CM3 einfügt, bevor der sich daraus ergebende DeviceTree an den Kernel übergeben wird.

Es ist aber möglich, mit dem Kommando /usr/bin/dtoverlay auch bei Laufzeit DT-Overlays zu laden und auch wieder zu entladen.

Das Script /usr/sbin/revpi-factory-reset ruft bereits /usr/bin/dtoverlay auf, d.h. das DT-Overlay ist dann sofort aktiv. Wenn du eigene DT-Overlays lädst, musst du diese ebenfalls mit /usr/bin/dtoverlay laden, wenn sie sofort und nicht erst beim nächsten Reboot aktiv werden sollen. Wenn du hingegen nur das für dein Gerät passende revpi-<gerät>.dtbo laden möchtest, ist hierfür eigentlich überhaupt kein Aufruf im Ansible Playbook nötig, da dies bereits von /usr/sbin/revpi-factory-reset für dich erledigt wird.

Wichtig: Wenn revpi-factory-reset über ssh ausgeführt wird, aktiviert es die geänderte MAC-Adresse erst beim nächsten Reboot, weil hierfür das Interface runter- und wieder hochgefahren werden muss, und das könnte zum Abbruch der ssh-Session führen.

Hilft dir das weiter? Gerne melden wenn nicht.

[Lace]

Wichtig: Wenn revpi-factory-reset über ssh ausgeführt wird, aktiviert es die geänderte MAC-Adresse erst beim nächsten Reboot, weil hierfür das Interface runter- und wieder hochgefahren werden muss, und das könnte zum Abbruch der ssh-Session führen.

Hilft dir das weiter? Gerne melden wenn nicht.

Hat mir geholfen, Danke