Posts by blacksun

Quote from framp

Einfach in den Code reinsehen

welches File ist das?

Quote from hyle

Na raspi-config ansich aktualisieren!

das ist schon klar.

wenn du dein System aktualisierst mit apt update && apt upgrade, dann bringt der Aufruf in raspi-config selbst nichts zusätzliches

Quote from DistroEx

Alles Erforderliche sollte aber nach Auswahl von Wayland in raspi-config installiert werden. Hattest Du eigentlich ein Update von raspi-config gemacht, aus raspi-config heraus?

seh ich auch so. weiß jemand was genau passiert wenn man den Schalter x11-wayland umstellt? Da muss es 2 "Listen" was zu tun ist wenn der Schalter auf die ein oder eben die andere Option gesetzt wird. Auf den ersten Blick sieht es so aus als würde der Schalter auf beiden Stellungen das gleiche machen, so als gäbe es nur x11.

was soll ein Aufruf der Funktion "Update" in raspi-config bringen?

raspi-config wird auch nur über ein deb-Paket geupdated. Ruft man die Funktion auf, passiert laut dem was angezeigt nichts anderes was du nicht selbst auch machst:

zuerst apt update

dann apt upgrade

Quote from DistroEx

Ich würde noch mal versuchen erst den VNC-Server zu deaktivieren in raspi-config, anschließend bei der Auswahl wayland/x11 wayland zu wählen und erst einmal speichern. Dann noch mal raspi-config und VNC aktivieren.

das ist ganz genau der Weg den ich gegangen bin

VNC deaktivieren, RealVNC deinstallieren, in raspi-config von x11 auf wayland

dennoch wechselt das System nicht auf wayland. Das Verhalten ist auf allen Pis bei mir so.

die nächste Idee war einfach mal das Paket wayvnc zu installieren, in der Hoffnung über die Paketeverknüpfung kommen die Pakete für wayland mit drauf. hat auch nicht funktioniert.

Hinter welchen Paketen steckt denn wayland?

bei mir sieht es so aus:

root@blackPI:~# dpkg --print-architecture
armhf
root@blackPI:~# getconf LONG_BIT
32
root@blackPI:~# uname -a
Linux blackPI 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux

Quote from Franjo G

Stelle mit raspi-config um auf wayland.

Deinstalliere den Real-VNC Server

genau diese beiden Schritte habe ich nun durchgeführt, inkl. jeweils Reboot

eine schnelle google-Suche hat mir gesagt dass man mittels

echo $XDG_SESSION_TYPE

abfragen kann ob man auf X11 oder Wayland ist.

Als Antwort bekomme ich nach wie vor x11

rufe ich nach einem Neustart raspi-config erneut auf, dann steht der Auswahlbalken auch hier nach wie vor auf der ersten Zeile, also x11.

und nu?

Quote from hyle

Schrieb ich irgendwo TigerVNC Server? Falls ja, dann meinte ich den Viewer!

nein.

Es ist inzwischen klar dass du immer nur den Viewer meinst um auf einen Server zuzugreifen wenn Du TigerVNC schreibst.

framp hatte den TigerVNC-Server in's Spiel gebracht. Mich würde interessieren ob der auf einem 32-bit Raspian funktioniert, und wenn ja, ob unter Wayland oder X11

Mir geht es um 2 Fragestellungen:

- gibt es funktionierende Alternativen für den WayVNC-Server für Raspbian 32bit?

- welche VNC-Clients funktionieren für den Zugriff auf funktionierende VNC-Server auf 32bit-Raspian? Hintergrund: ich greife von diversen Clients auf meine rPIs über VNC zu. Meine Clients haben unterschiedlichste Betriebssysteme: Android in diversen Versionen, Windows in diversen Versionen, Ubuntu x64 und weitere

Bisher war bei mir VNC auf Server als auch auf Client-Seite zu 100% von RealVNC.

Hallo zusammen,

wie erkennt man eigentlich an der Oberfläche eines laufenden Raspian ob X11 oder Wayland genutzt wird?

"Sieht" man da was?

Ich kenne bisher nur den Schalter in raspi-config. Durch ein Umstellen scheinen Pakete weder installiert noch deinstalliert zu werden. Und LXde sieht auch nicht anders aus.

Quote from Outlaw

Ich vermute, dass ab dem 4er eh jeder 64Bit nutzt.

und das schlimme ist dass die Raspberry-Foundation scheinbar ebenfalls davon ausgegangen ist.

Als ich mir in 2019 meine rPis zugelegt habe und in das Thema eingestiegen bin, da war der rPi4 das neueste Modell, Buster war aktuell, und man war weit entfernt von 64bit.

Begründung war dass man mit Raspian bis zum allerersten Pi kompatibel bleiben wollte, dass es keinen Pi mit mehr als 4GB Ram gab und daher 32bit immer noch ausreichend war, und ich meine auch weil fast kein Maintainer eine 64bit-Version für arm64 bauen wollte.

Dass man das nicht im Repo und in Abfragen berücksichtigt hat, das halte ich für unverantwortlich.

Wir sprechen von der Stable, nicht von Testing, nicht von sid.

In 2019 haben mir die Alteingesessenen hier im Forum erklärt dass Raspbian aus dem Debian-Zweig kommt, dass der Debian-Zweig sehr konvervativ gehandhabt wird, dass Stablilität vor neuester Version steht, dass Debian im Serverumfeld gerne genutzt wird, und dass Server zig Jahre ohne Neuinstallation laufen.

Und ausgerechnet da macht man bookworm zu stable und vergisst die Abhängigkeiten die verhindern dass die neuen Bookworm-Pakete installiert werden wenn bisher X11 genutzt wird, wenn bisher der RealVNC-Server als Paket installiert ist.

Quote from framp

Siehe hier  blacksun

ich wollte nur sichergehen.

hast du auf einem anderen Pi oder sonst jemand TigerVNC auf Raspian 32bit in Verbindung mit bookworm am laufen?

Gilt für TigerVNC-Server das gleiche wie für RealVNC-Server?

EDIT:

zu deinem 64-Bit-Raspian mit TigerVNC, hast du da X11 oder Wayland?

Quote from framp

Eben habe ich mal VNC per raspi-config enabled und

sudo apt install tigervnc-standalone-server

hast du auf deinem rPI4 denn eine 32 oder eine 64-bit Version von Raspian installiert.

Ich muss Franjo schon recht geben. Das hat RealVNC dämlich formuliert. Ich hab das auch falsch gelesen. Die Aussage lautet RealVNC-Server auf 32bit Raspbian funktioniert aktuell in keiner Konstellation, egal welches Raspberry Modell, egal ob X11 oder Wayland.

Quote from hyle

Stelle wieder auf Wayland zurück! Dort den VNV-Server aktivieren. Dann läuft dort der WayVNC-Server,

...

Der RealVNC Viewer funktioniert da nicht. Aber das schrieb ich ja bereits.

In Raspi-Config kann ich ja nur zwischen X11 und Wayland wählen. Aber was ist mit den Paketen für RealVNC-Server bzw. WayVNC. Die werden ja nicht automatisch ab- und angewählt

Was ist VNV?

Gut das nochmal zu erwähnen mit dem Viewer. Das stand ebenfalls in dem heise-Artikel, dass viele Viewer nicht mit WayVNC können. Das hat mich davon abgehalten den WayVNC anzuschauen - und eben wie man am besten umsteigt von RealVNC-Server auf WayVNC

hyle

das heißt du hattest in Post#2 die Idee dass bei einem nicht funktionierenden RealVNC-Server die Verwendung des TigerVNC-Clients helfen könnte?

@ all

es wäre schon interessant wenn sich Nille äußern würde mit seiner Bestätigung, ob er 64bit oder 32bit hat.

Was ist aber nun mit dem Thema Anmeldung direkt an der grafischen Oberfläche wenn man in raspi-config auf X11 umstellt?

Das Feld für Benutzernamen und PW für die Anmeldung, das heißt doch greeter, oder?

Warum funktioniert das nicht mehr wenn man X11 auswählt?

journalctl sagt wie gesagt:

gkr-pam: unable to locate daemon control file

simonz
in den Repo-Links steht bei mir ein stable.
Das wurde mir auch explizit hier so in 2019, als ich hier im Forum gestartet bin, so empfohlen. Da ging es darum auf gar keinen Fall auf einem Produktivsystem testing oder sid zu nehmen.

Dass die Raspian-Verantwortlichen sowas wie jetzt als stable freigeben, das ist unterirdisch.

hyle
du hast immer "...VNC Viewer" geschrieben.
Ist das ein Tippfehler?
VNC ist eine Client-Server-Anwendung. Bei jedem Hersteller, also sowohl RealVNC als auch TightVNC, gibt es eine Serveranwendung und eine Clientanwendung. Es gibt daher den RealVNC-Server und RealVNC-Viewer, und auch den TightVNC-Server und TightVNC-Viewer

Quote from Outlaw

Du kannst über raspi-config in den Einstellungen Wayland in X11 ändern, dann funzt es wieder laut RealVNC.

das führt leider zum nächsten Problem. Man kann sich am greeter nicht mehr anmelden --> Fehler beim Starten der Sitzung

Im Journal heißt es:

gkr-pam: unable to locate daemon control file

Wie lässt sich das wieder beheben?

hyle

Das Problem liegt auf Server-Seite, der Port 5900 ist auch nicht erreichbar, wie kann da ein anderer Client weiterhelfen?

DistroEx

dann auf Raspberry.

Dort werden wieder armhf und arm64 angeboten.

direkt nachdem Bookworm zu stable wurde gabe es dort nur arm64

Hallo zusammen,

durch die Umstellung einer bestehenden 32-bit Installation von Raspian von Bullseye auf Bookworm funktioniert der RealVNC-Servers nicht mehr. Laut der Heise-Mitteilung soll man warten bis RealVNC eine neue Version des VNC-Servers in der 32-bit-Version liefert.

Inzwischen kann man auf deren Homepage wieder eine entsprechende Version als deb-Paket herunterladen.

Dennoch funktioniert der Server noch nicht.

Was muss man zusätzlich noch tun?

Es handelt sich um einen rPi4, 4MB

Da es ein Bestandsinstallation mit Bullseye war, sollte laut der Heise-Meldung nicht automatisch von xorg-legacy auf wayland umgestellt werden. Weiter hieß es dass RealVNC dennoch Anpassungen vornehmen müsse. Da es nun wieder eine 32bit-Version zum DL gibt gehe ich davon aus dass dies nun erfolgt ist.

RealVNC für Wayland soll hingegen erst in 2024 kommen

Vielen Dank.

Hallo zusammen,

durch die Umstellung einer bestehenden 32-bit Installation von Raspian von Bullseye auf Bookworm funktioniert der RealVNC-Servers nicht mehr. Laut der Heise-Mitteilung muss man warten bis RealVNC eine neue Version des VNC-Servers in der 32-bit-Version liefert.

Inzwischen kann man auf deren Homepage wieder eine entsprechende Version als deb-Paket herunterladen.

Dennoch funktioniert der Server noch nicht.

Was muss man zusätzlich noch tun?

Vielen Dank.

Quote from FSC830

Die 8.8.8.8 gehört einem DNS Server im Internet.

ah, ok, an diese Stelle im Skript kommt nicht die IP der zu prüfenden Maschine, sondern hier wird nur ein DNS-Server angegeben.

Quote from Hofei

Bash

#!/bin/bash
#==============================================================================================
# serverctl by TomL*thlu.de
#
# Script-Name :  serverctl
# Version     :  1.0
# Date        :  31.07.2017
# Lizenz      :  GNU GPL3
# Description :  Check if given server is reachable
#==============================================================================================

[ -z "$1" ] && Server="8.8.8.8" || Server=$1
echo "active/running   Server=$Server" | systemd-cat -t "thlu:`basename $0`" -p "info"

timeout=85
Diff=0
HomeNetIsConnect=-1

Display More

da ich auf thu.de das Skript nicht gefunden habe, warum wird die eine IP-Adresse als Parameter übergeben während die andere fest im Skript hinterlegt ist?

Wenn ich das skript richtig verstanden habe, dann wird beim Aufruf eine IP-Adresse übergeben. Dann wird verglichen ob das, was beim ping zurück kommt, auch dem entspricht was fest im Skript hinterlegt ist, also hier die 8.8.8.8

Welche Idee steckt dahinter dass man nicht prüft ob der Wert, der beim ping zurück kommt, nicht dem Wert entspricht der per Parameter übergeben wurde?

Wie müsste die Zeile aussehen wenn ich den Server nicht fest eintragen möchte?

Ich bin schon dabei das Thema dieses Threads, als systemd.mount, auszuprobieren. Allerdings habe ich mehrere mounts zu unterschiedlichen Servern. Damit ich die serverctl in allen mounts verwenden kann, müssten die IP-Adressen von der jeweiligen mount-unit beim Aufruf übergeben werden.

Vielen Dank.

Quote from RTFM

"Mount units must be named after the mount point directories they control."

genau das hat mir gefehlt.

man muss den Pfad nehmen und die Schrägzeichen durch ein Minus ersetzen, und am Ende eine .mount schreiben

Übrigens ein sehr gutes Beispiel warum man-pages nicht immer weiterhelfen. Der Satz sagt nur dass eine Abhängigkeit besteht, aber nicht wie diese aussieht.

Erst dein Beispiel war die Erklärung wie diese Abhängigkeit aussieht.

Quote from RTFM

Gemounted wird immer (wenn vorhanden) die im Filesystem des Sticks vergebene Bezeichnung ("label")

auch hier, das hat mir gefehlt. Vom Label eines Datenträgers kommt die Anzeige/Bezeichnung

Das muss man auch erst mal darauf kommen

Vielen Dank für die Hilfe.

EDIT:

Quote from RTFM

Steht alles in der Man Page drinnen.

in welcher muss ich schauen?

Quote from rpi444

Code

[Unit]
After=media-amplefolder.mount
Requires=media-amplefolder.mount
ConditionPathExists=/dev/sda1

Code

deddddd
ConditionDirectoryNotEmpty=/media/USB/Datenträger

ich stehe noch auf dem Schlauch

a) an deinem Beispiel mit media-amplefolder.mount, wo wird definiert was dieser Mounpoint? Woher weiß systemd welcher Mountpoint gemeint ist?

b)

ich mounte den USB-Stick so über fstab:

UUID=CA33-B138 /media/USB/MP1/ vfat defaults,utf8,uid=pi,gid=pi,rw,user,sync,nofail 0 2

Daraus macht irgendwas die Bezeichnung

/media/USB/Datenträger 31 GB

Wie ist mit dem Umlaut ä und den Leerzeichen umzugehen, bei den Condition?

muss dieses

ConditionPathExists=/dev/sdxy

als eigene Zeite in die "Unit"-Sektion oder hinter Wants=

In einem Tutorial habe ich gelesen man

After=media-volume.mount

BindsTo=

verwenden.

Gibt es das Unterschiede bzw. wann welches besser ist?

Vielen Dank.