Posts by debug

    Seit wann sind auch diese anderen User, in der Gruppe pi? Hat sich beim letzten Update, in dieser Gruppe pi, etwas geändert? Was ist der Grund, für andere User in der Gruppe pi?

    Wie sind jetzt die Ausgaben von:

    Code
    ls -la /etc/group
    ls -la /usr/sbin/sshd

    ?

    Die User sind schon immer (seit Jahren) vorhanden, habe diese damals selber angelegt.

    Code
    ls -la /etc/group
    -rw-r--r-- 1 root root 1196 Sep 24 22:55 /etc/group
    ls -la /usr/sbin/sshd
    -rwxr-xr-x 1 root root 658152 Mär 12  2021 /usr/sbin/sshd



    ok, hatte vergessen, dass ich vor kurzem der PI Gruppe einen Nutzer hinzugefügt habe. War nur zum testen, kann ich wieder entfernen.

    Dann lag es daran und nicht am letzten Update, sry. :wallbash:


    Nutzer ist jetzt auch wieder aus der Gruppe entfernt, per gpasswd -d user group .


    Trotzdem, leicht zu übersehen, so schnell kann zu ssh Zugriff weg sein wenn die Berechtigung bei authorized_keys noch Gruppenberechtigung hat.

    Also bei mir ist Public Key die einzige Anmeldemethode, Passwort ist extra gesperrt.


    Andere User sind auch auf den pi und der user "pi" ist in der Gruppe von 2 anderen Nutzern.


    Wenn ich nicht gerade Zugriff auf den pi gehabt hätte, wäre ich jetzt ausgesperrt, gestern hat ssh per public key noch funktioniert.

    Heute wollte mein raspberry kein Login per SSH zulassen, hatte schon das schlimmste befürchtet.


    Gestern lief ein Upgrade der Pakete:

    Code
    Start-Date: 2021-09-24  22:47:49
    Commandline: apt-get dist-upgrade
    Requested-By: pi (1000)
    Upgrade: libraspberrypi-bin:armhf (1:1.20210831-1, 1:1.20210831-3~buster), libraspberrypi-dev:armhf (1:1.20210831-1, 1:1.20210831-3~buster), libraspberrypi-doc:armhf (1:1.20210831-1, 1:1.20210831-3~buster), linux-libc-dev:armhf (1:1.20210831-1, 1:1.20210831-3~buster), openssl:armhf (1.1.1d-0+deb10u6+rpt1, 1.1.1d-0+deb10u7), ntfs-3g:armhf (1:2017.3.23AR.3-3, 1:2017.3.23AR.3-3+deb10u1), libntfs-3g883:armhf (1:2017.3.23AR.3-3, 1:2017.3.23AR.3-3+deb10u1), raspberrypi-kernel:armhf (1:1.20210831-1, 1:1.20210831-3~buster), raspberrypi-bootloader:armhf (1:1.20210831-1, 1:1.20210831-3~buster), libwebkit2gtk-4.0-37:armhf (2.32.3-1~deb10u1+rpi1, 2.32.4-1~deb10u1+rpi1), libssl-dev:armhf (1.1.1d-0+deb10u6+rpt1, 1.1.1d-0+deb10u7), libraspberrypi0:armhf (1:1.20210831-1, 1:1.20210831-3~buster), libssl1.1:armhf (1.1.1d-0+deb10u6+rpt1, 1.1.1d-0+deb10u7), libjavascriptcoregtk-4.0-18:armhf (2.32.3-1~deb10u1+rpi1, 2.32.4-1~deb10u1+rpi1)
    End-Date: 2021-09-24  22:51:52



    Die Meldung aus den Auth-Log:

    Code
    sshd[942]: Authentication refused: bad ownership or modes for file /home/pi/.ssh/authorized_keys


    Die Datei war bei mir schon ewig auf:

    Code
    -rw-rw---- 1 pi pi  744 Nov 17  2016 authorized_keys

    Die Änderung hat das Problem gelöst:

    Code
    -r-------- 1 pi pi  744 Nov 17  2016 authorized_keys



    Gab es vor kurzem eine Verschärfung der Regeln bezüglich Dateirechte im ssh Ordner?


    Die Rechte 660 hatte ich bestimmt nicht gesetzt, waren wohl vor ~8 Jahren Standard?


    Jedenfalls solltet ihr vor dem Update nochmal die Berechtigungen prüfen, nicht das ihr euch ebenfalls aussperrt. :lol:

    Wenn man nicht direkt am Gerät sitzt könnte es zu einem Problem werden.


    VG

    Es ist raspbian mit der entsprechenden version bullseye.


    Aber wie bekomme ich eine Verbindung zum Netzwerk?

    Der Router verteilt die ipv4 Adressen per dhcp.


    In raspi-config gibt es unter Advanced Options - Network Interface Names


    Mit der Einstellung habe ich diese Deaktiviert und neu gestartet und dann wieder aktiviert und neu gestartet.

    In beiden Fällen war die Bezeichnung gleich, wie oben beschrieben. Anscheinend ist etwas bei dem System kaputt? :/

    Hi,


    bei dem Update von buster zu bullseye, habe ich die Quellen in der sources.list umstellt.


    Als erstes hab es ein Abhängigkeitsproblem, das konnte durch die Installation von gcc-8-base behoben werden.<br>

    https://unix.stackexchange.com…6-dev-breaks-libgcc-8-dev


    Während der Aktualisierung gab es zwei Meldungen, mit denen ich erst mal nicht viel anfangen kann:


    binutils scheint aktuell zu sein

    https://lists.debian.org/debia…ity/2019/12/msg00007.html

    https://packages.debian.org/bullseye/binutils


    Ist es richtig, dass so viele Aktualisierungen deaktiviert wurden?



    Nach einem Neustart wird keine IPv4 Adresse mehr dem pi zugewiesen. Nach ifconfig hat er eine inet6 Adresse, mein Router verteilt aber keine, wie kann ich IPv4 wieder im PI aktivieren?

    Der Ethernet Device Name ist etwas seltsam, hat ungewöhnlich viele Zeichen: enxb********ac



    Code
    echo net.ipv6.conf.all.disable_ipv6=1 >> /etc/sysctl.conf

    Mit der Einstellung bekomme ich keine IP mehr.


    ifup enxb********ac funktioniert nicht, da interface unbekannt.

    Hofei

    Wie viel Ram würdest du empfehlen?

    Hatte vorher auch 128MB, aber jetzt bei der Aktualisierung zu NextCloud 20 hat der Updater abgebrochen und ist erst nach der Erhöhung auf 512 MB durch gelaufen.


    Die Datei war /etc/php/7.3/apache2/php.ini , ich versuche jetzt 256MB.

    Hi,


    ich nutze die Nextcloud auf dem Raspberry hauptsächlich für Kalender, Contact sync und Notes App. Dateien sind eher Nebensache, nutze ich dort wenig.


    Vorher lief NC sogar auf einen raspberry pi 1 einige Jahre, seit einiger Zeit raspberry pi 3.


    Der php Memory sollte bei dem letzten Update erhöht werden 512MB. Dann bleibt ja nur das System nichts mehr, hatte schon Probleme befürchtet. Es gibt im Syslog jetzt öfters eine Meldung


    "Out of memory: Killed process 23321 (mysqld) total-vm:730240kB ..."


    Der PI3 ist natürlich nicht optimal, war aber für meinen Zweck immer vollkommen ausreichend.


    Macht es keinen Sinn mehr Nextcloud auf dem PI3 laufen zu lassen oder kann ich die Einstellungen ändern?


    Es gibt zwar Cloud Anbieter, sogar kostenlose, da es nur um ein paar MB geht bei mir. Die Daten zu hause gespeichert zu haben fand ich immer angenehm.

    Habe hier noch drei defekte Transcend Premium 300x Karten liegen:


    Bei der aktuellen Karte mit 1,5 Jahren, Lifetime writes: 1066GB.


    Bei einer Transcend Karte aus meinen Handy, die ausgefallen ist Lifetime writes: 41GB.


    Bei der dritten Karte können die Daten nicht mehr ausgelesen werden.


    Nutze auch noch andere SDs von anderen Herstellern, aber dort sind in den letzten Jahren keine kaputt gegangen.


    daxb

    Drei Jahre und 588GB, bei mir werden anscheinend doch etwas mehr Schreibzyklen zu verursacht.


    Himbeer-Eis Es ist ein Raspberry PI 3B

    Die SD-Karte ist wieder Defekt ... die Karte hat damit nur ca.1,5 Jahre gehalten, die Karte davor noch weniger < 1J ... damals schafften die SD-Karten deutlich länger bei ähnlicher Config.


    Es sind die gleichen Fehler, nur das es eine 16 GB Karte war. Entweder die Schreibvorgänge haben sich irgendwie erhöht, oder die letzten beiden Karten (von Transcend) sind einfach nicht belastbar gewesen.



    Sehr enttäuschend, aber nur ein Beweis dafür, dass Backups wichtig sind.

    Hallo,


    eine Frage zu dem aktuellen upgrate mit apt.


    Der hat das Paket rpi-eeprom-images bei mir heute aktualisiert, dann möchte es wieder entfernen bei autoremove ?




    apt autoremove:

    Quote

    Die folgenden Pakete werden ENTFERNT:
    rpi-eeprom-images*
    0 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
    Nach dieser Operation werden 14,3 kB Plattenplatz freigegeben.
    Möchten Sie fortfahren? [J/n] n


    Habe daher abgebrochen, da mir nicht klar ist, ob das überhaupt korrekt ist.

    Der omxplayer gibt mir

    Code
    * failed to open vchiq instance

    Habe vorerst ein kleines Skript angelegt, das scheint mit ogg123 zu funktionieren, bisher gab es zumindest keinen Fehler.

    Code
    find "${music}" -type f -iname "*.ogg" | shuf > /tmp/playlist.m3u
    while read line; do ogg123 "$line"; done < /tmp/playlist.m3u

    bzw. geht auch so

    Code
     find "${music}" -type f -iname "*.ogg" | shuf | while read line; do ogg123 "$line"; done

    Nur der Player wird jedes mal neu gestartet, was nicht so schön ist.

    Hätte ein Frage dazu, geht die SD-Karte eher kaputt wenn es mehrere kleine Schreibzugriffe gibt?

    Wie bei einem Log, das wird immer nur erweitert und nicht neu geschrieben.


    Wenn man das Log z.B. im Ram anlegt und am Ende des Tages per Cron auf SD schreibt, ist das wesentlich schonender für die sd?


    Die Anzahl der überschriebenen Blöcke müssten in dem Fall ja gleich bleiben?

    schlizbäda

    Danke, es scheint nicht an einer ogg zu liegen, wenn es bei einer Datei zu dem Fehler kommt, kann ich dem Player neu starten mit der gleichen Datei und es läuft fehlerlos durch.



    Zum abspielen generiere ich mir eigentlich eine Playlist (playlist.m3u), die Dateien sind einfach inklusive Pfad aufgelistet.

    Bei dem omxplayer geht das vermutlich nur per Skript?

    Hi,

    der raspberry spielt bei mir per mplayer Musik ab, nach einiger Zeit kommt immer die folgende Fehlermeldung:

    Anscheinend wird von mplayer noch etwas per recover versucht, aber kurz danach kommt immer "End of file" ...


    Befehl:

    Code
    mplayer -quiet -shuffle -playlist /tmp/playlist.m3u



    Weiß jemand woran das liegen kann? :daumendreh2:


    Von der Meldung würde ich vermuten eine defekte Datei, aber es wurden von ogginfo keine Fehler ausgegeben.

    Code
    find . -name "*.ogg" -exec ogginfo -q {} > /tmp/ogg-check.log \;