debian 12 ble_enable permanent setzen

[Willydb123]

Hallo, ich experimentiere mit dem Board BeagleY-AI und Debian 12. Möchte Bluetooth starten, um Logitech Maus und Keyboard zu betreiben. Habe mich mühsam dazu vorgetastet, dass /sys/kernel/debug/ieee80211/phy0/cc33xx#/ble_enable auf 1 gesetzt werden muss. Dies wirkt sofort. btmgmt kennt danach hci0. Habe auch schon die Maus erfolgreich paired. ble_enable wird beim boot leer initialisiert. Wie kann ich das permanent machen? Irgendwie mit Autostart rc-local, das aber anscheinend nicht empfohlen wird. Ich wühle mich durch viele Webseiten, aber vielleicht ist jemand im Forum, der Erfahrung mit meinem Problem gemacht hat oder eben Tipps hat, wo ich weiter suchen kann. Es muss ja nicht die ultimative Lösung sein, aber vielleicht werde ich auf eine schnellere Spur gelenkt.
Ich bin neu hier im Forum, das ist mein erster Beitrag.

[hikaru]

/sys ist ein vom Kernel bereitgestelltes, virtuelles Dateisystem, das bei jedem Boot neu initialisiert wird. Wirklich permament setzen kannst du dort nichts. Du kannst nur dafür sorgen, dass deine gewünschten Änderungen bei jedem Boot angewendet werden.

Um das umzusetzen gibt es mehrere Wege:
Falls du initscripts installiert hast, dann kannst du das durchaus über ein Eintrag in /etc/rc.local lösen. Abgeraten wird davon höchstens, weil es nicht die reine Systemd-Lehre ist, aber funktionieren wird es.
Mit sysfstools und einem Eintrag in /etc/sysfs.conf sollte es auch funktionieren, habe ich aber noch nie probiert.
Am saubersten wäre es, wenn du dir dafür eine Systemd-Unit schreibst, die du bei jedem Start aufrufst.

[tobo]

Bezüglich /etc/rc.local ist vielleicht das hier noch relevant für dich:
https://www.cyberciti.biz/faq/how-to-en ... ux-system/

[Willydb123]

Genauso habe ich mir die Unterstützung des Forums vorgestellt. Mir war nicht klar, dass /sys bei jedem Boot neu aufgebaut wird. Wenn man das nicht weiss, kann man lange suchen. Ich werde die weiteren Tipps untersuchen. Danke.

[GregorS]

Ich würde das einfach durch einen Eintrag in rc.local machen. Gerade, weil es auch in nicht-systemd-Systemen funktioniert.

[MSfree]

Ich würde erstmal schauen, ob man mit rfkill etwas ausrichten kann.
Ein einfacher Aufruf von rfkill listet alle Funkmodule auf, mit denen rfkill etwas anfangen kann, also WLAN, BT, UWB...
Mit rfkill unblock <Gerät> kann man das jeweilige Funkgerät an- bzw. ausschalten.

Für rfkill gibt es auch fertige systemd-Units, die man ggfls. noch aktivieren und konfigurieren muß.

Das wäre dann nicht ganz so kernelnah wie mit echo etwas in eine Kernelvariable zu schreiben.

[Willydb123]

MSfree: rfkill funktioniert für mein Problem nicht. Es zeigt nur wlan, erst nach echo 1 >ble_enable wird auch bluetooth angezeigt. Ist aber ein weiteres Teil für meine Werkzeugkiste.

[GregorS]

... rfkill funktioniert für mein Problem nicht. Es zeigt nur wlan, erst nach echo 1 >ble_enable wird auch bluetooth angezeigt. ...

Ein weiterer Grund dafür, das durch einen Eintrag in rc.local zu erledigen. Meine rc.local sieht so aus:

Code: Alles auswählen

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.

if test -d /etc/boot.d ; then
        run-parts /etc/boot.d
fi

echo "----- Gregors Zeug in rc.local wird ausgefuehrt -----"

#ip tuntap add mode tap; ifup tap0
#sysctl net.ipv4.ip_forward=1
#iptables -t nat -A POSTROUTING -s 192.168.1.1/24 -o eth0 \
#        -j MASQUERADE
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 \
#        -d 192.168.1.0/24 -j MASQUERADE

echo "----- Zeug sollte jetzt eingerichtet sein -----"
#sleep 10

#eof

Wie Du siehst, steht da noch Zeug drin, das ich vor vielen Jahren mal brauchte und jetzt auskommentiert ist. Die Pause am Ende hatte ich nur die ersten paar Tage drin, um auch wirklich mitzubekommen, dass das ausgeführt wurde.
Das so zu machen, ist vielleicht nicht die modernste oder feinste Art, das zu erledigen, aber rc.local existierte und funktionierte IIRC schon, als Beethoven noch hören konnte.

[tobo]

Meine rc.local sieht so aus:

Macht die denn überhaupt irgendwas, außer die Ausgabe der beiden echos - hast du ein Verzeichnis /etc/boot.d? Auf die in den Kommentaren hingewiesene, abschließende "exit 0"-Zeile verzichtest du absichtlich?

[GregorS]

Meine rc.local sieht so aus:

Macht die denn überhaupt irgendwas, außer die Ausgabe der beiden echos - hast du ein Verzeichnis /etc/boot.d?

Nein und nein. Inzwischen brauche ich das einfach nicht mehr. Ich habe halt „damals“ einfach das auskommentiert, was ich nicht mehr brauchte und meine eigenen Ausgaben dringelassen, weil's egal war.

Auf die in den Kommentaren hingewiesene, abschließende "exit 0"-Zeile verzichtest du absichtlich?

Ja – es funktioniert auch so und es gab auch im Original keine solche Zeile.

[tobo]

Auf die in den Kommentaren hingewiesene, abschließende "exit 0"-Zeile verzichtest du absichtlich?

Ja – es funktioniert auch so und es gab auch im Original keine solche Zeile.

Klar, das ist in Kombination mit set -e auch eher ein stilistisches Mittel.

[Willydb123]

Ein weiterer Grund dafür, das durch einen Eintrag in rc.local zu erledigen. Meine rc.local sieht so aus:

Prima dass du das aufgehoben hast. Irgendwer kann es irgendwann wieder gebrauchen, nämlich jetzt ich. Schönes Beispiel.
Auch der Hinweis mit sleep, um die Funktionsfähigkeit zu begutachten, ist neu für mich (zumindest die Anwendung in rc.local, ansonsten
kenne ich das).

[tobo]

Ein weiterer Grund dafür, das durch einen Eintrag in rc.local zu erledigen. Meine rc.local sieht so aus:

Prima dass du das aufgehoben hast. Irgendwer kann es irgendwann wieder gebrauchen, nämlich jetzt ich. Schönes Beispiel.
Auch der Hinweis mit sleep, um die Funktionsfähigkeit zu begutachten, ist neu für mich (zumindest die Anwendung in rc.local, ansonsten kenne ich das).

Hast du dein Problem inzwischen gelöst? Weißt du, was du machen sollst/kannst und wie du es umsetzt, denn dein Geschreibe klingt irgendwie nicht so?!

[Willydb123]

Hast du dein Problem inzwischen gelöst? Weißt du, was du machen sollst/kannst und wie du es umsetzt, denn dein Geschreibe klingt irgendwie nicht so?!

Ich bin auf dem Weg. rc.local script läuft. Erst mal nur ein echo drin. Habe gesucht, in welchem log ich das finden kann. Bin mit journalctl und grep fündig geworden.
Meine geplanten Aktionen:

• ble_enable auf 1 setzen.
• bluetoothctl scan on, sonst kein pair möglich.
• "pair XX:XX:..." Die Adressen habe ich herausgefunden.

Da ich momentan nur die Logitech-Tastatur habe, kann ich nur über X2Go von Windows aus zugreifen. Ich will ja direkt mit dem Monitor am BeagleY-AI arbeiten. Vor dem pairen muss auf der Logitech-Tastatur (und der Maus) der entsprechende Kanal auf pairen gesetzt werden (hat 3 Stück). Im Falle der Tastatur kann ich aber das pair Kommando nicht eingeben, die Maus habe ich erfolgreich mit X2Go Zugriff gepairt. Auf dem BeagleY-AI direkt mit HDMI Monitor konnte ich die Maus bewegen. Deswegen will ich das alles automatisch laufen lassen. Habe auch diverse /etc Einträge gefunden
/etc/bluetooth
/etc/default/bluetooth
/etc/init.d/bluetooth
Beim inspizieren der Dateien dort gab es leider kein "Heureka" Erlebnins um sich den ganzen Aufriss mit rc.local zu sparen. Die Dateien gehören wohl zum Paket blueZ, sind aber vielleicht von BeagleY angepasst, da ich deren Debian Image laufen lasse. Leider habe ich bei BeagleY nichts gefunden, was mir weiterhelfen könnte.
Puh, jetzt habe ich auch etwas Zeit benötigt, die BBCode Formatierung anzuwenden.

[Willydb123]

So, ich bin einen großen Schritt weiter. rc.local ist nicht die Lösung, da zwar damit ein script läuft, das enable_ble setzen könnte, aber zum Startzeitpunkt
/sys/kernel/debug/ieee80211/phy0/cc33xx noch garnicht existiert. Meldung aus dem log: directory not found.
Ich habe einen Artikel von SuSe gefunden
https://www.suse.com/de-de/support/kb/doc/?id=000019672
Eine Anleitung in systemd einzusteigen, mit einem Beispiel, wo lediglich ein shell script aufgerufen wird.
Dann habe ich folgendes aufgebaut, das Shell Script

Code: Alles auswählen

/usr/sbin/enable-ble.sh
#!/bin/bash
echo 1 >/sys/kernel/debug/ieee80211/phy0/cc33xx/ble_enable
echo "enable-ble.sh run" >> /tmp/enable-ble.txt

und die systemd Unit

Code: Alles auswählen

/etc/systemd/system/enable-ble.service
[Unit]
Description=Enable ble after creating of virtual /sys folders

[Service]
Type=oneshot
ExecStartPre=/bin/sleep 3m
ExecStart=/bin/bash /usr/sbin/enable-ble.sh

[Install]
WantedBy=multi-user.target

Danach das command

Code: Alles auswählen

systemctl enable enable-ble.service

zum registrieren eingeben. Oben gezeigtes coding ist das funktionierende Ergebnis. Hier noch ein paar Zwischenschritte bis dahin.
Ich habe auch ChatGPT gefrage. Die Empfehlung den Zeitpunkt des Starts der eigenen Unit zu bestimmen, mit "After=graphical.target"
und "Requires=graphical.target" hat nicht funktioniert. Vielleicht habe ich auch das erneute Registrieren (systemctl enable ...) vergessen.
Jedenfalls wurde meine enable-ble.service Unit nicht mehr angefasst.
Den Tipp aus ChatGPT mit "ExecStartPre=/bin/sleep 3m" habe ich übernommen. Da die Anweisung "Type=oneshot" noch nicht drin war, kam es zu einem Timeout.
Hier sind wohl 90 Sekunden erlaubt.
Ich habe leider (noch) keine andere Möglichkeit gefunden, enable_ble in irgendeiner config zu platzieren, die zum richtigen Zeitpunkt angewendet wird.
Deshalb die Notlösung mit systemd und einfach 3 Minuten warten, da dann /sys/kernel/... existiert.
Jetzt muss ich noch mein Keyboard permanent registrieren. Wie ich schon in einer vorigen Antwort geschildert habe, will ich das unter Kanal 3 machen (mein Logitech hat 3 Kanäle für Bluetooth). Dazu muss ich aber Kanal 3 zum pairing bringen, im X2Go benötige ich aber Kanal 1 (Windows) um was einzutippen.
Langer Weg, aber mit den ersten Ideen aus dem Forum weitergekommen und viel gelernt!

[tobo]

Ich will dich von deinem Weg nicht abbringen, aber wenn es mit Zeitverzögerung sein muss, dann könnte man das in einer /etc/rc.local genaus o einbauen. Z.B. max. 36 Versuche alle 5 Sekunden schauen, ob die Datei vorhanden ist und dann Wertt setzen::

Code: Alles auswählen

FILE=/sys/kernel/debug/ieee80211/phy0/cc33xx/ble_enable
ATTEMPTS=36
WAIT=5s
count=1
until [ -e "$FILE" ]; do
    count=$((count+1));
    [ "$count" -gt "$ATTEMPTS" ] && exit 1
    sleep "$WAIT"
done
echo 1 >"$FILE"

echo "enable-ble.sh run" >> /tmp/enable-ble.txt

EDIT: z->count neu benannt und neu initialisiert

[rodney]

@tobo Sollte in der Zeile nicht das z durch count ersetzt werden:

Code: Alles auswählen

z=$((z+1));

[Willydb123]

tobo, das ist neu für mich, und solche Tipps kommen in meine Werkzeugkiste. Ich habe auch schon an die Prüfung, ob das file da ist, gedacht.
Wusste aber nicht, wie ich das in einem script bewerkstelligen sollte. Danke für das Beispiel.

[tobo]

@tobo Sollte in der Zeile nicht das z durch count ersetzt werden:

Code: Alles auswählen

z=$((z+1));

Klar, Danke! Das passiert, wenn man sich beim schnellen Refactoring auf den internen Single-Core verlässt...

[Willydb123]

Ich will dich von deinem Weg nicht abbringen, aber wenn es mit Zeitverzögerung sein muss, ...

Ich habe dein script unverändert übernommen und es funktioniert perfekt. Bluetooth ist jetzt viel schneller bereit.
Da ich Bluetooth Manager installiert habe, wird bei erfolgreichem ble_enable das BlueTooth Logo im Tray angezeigt.
Damit ist das Thema "debian 12 ble_enable permanent setzen" für mich abgehakt. Vielen Dank für die Unterstützung. Für mich wertvoll ist,
dass nicht sofort eine perfekte Lösung herauskommt, sondern auch die eigene Nachforschung angeregt wird, wodurch die Lernkurve steigt.