Raspi4@Buster mit statischer IP und DNS-Probleme

[Bartimaus]

Moin,

ich habe an meinem Raspi in der /etc/dhcpcd.conf eine statische IP definiert. Auch in der resolv.conf ist korrekt mein Router eingetragen.
Sobald ich jetzt aber ein Update machen möchte, kann der Rpi die statische DNS nicht mehr auflösen, das Update schlägt fehl.

Als Gateway+DNS ist jeweils mein Router eingetragen.

Ändere ich jetzt komplett auf dynamische IP klappt das Update. D.h. die DNS-Auflösung funktioniert dann.

Wo ist hier mein Denkfehler bzw. das Problem ? Haben die Profis ne Idee ?

[CoolTux]

zeige mal den inhalt der datei

[Bartimaus]

/etc/resolv.conf

Code Auswählen Erweitern

# Generated by resolvconf
nameserver 1.1.1.1


/etc/dhcpcd.conf

Hab jetzt mal Cloudflare als DNS probiert, auch ohne Erfolg:

Code Auswählen Erweitern


# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
interface eth0
static ip_address=192.168.241.7/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
static routers=192.168.241.2
static domain_name_servers=1.1.1.1


[CoolTux]

was bedeutet für dich geht auch nicht.

was sagt ein dig heise.de

oder nslookup heise.de

[Bartimaus]

Code Auswählen Erweitern


host -t A heise.de 192.168.241.2
Using domain server:
Name: 192.168.241.2
Address: 192.168.241.2#53
Aliases:

heise.de has address 193.99.144.80
pi@RPi4FHEM:~ $


Hab jetzt alles nochmal neu eingegeben, gespeichert und kompletter Reboot. Jetzt funktioniert das Update wieder. Danke für den Schubs....

Jetzt muss ich nur noch prüfen, wieso der Raspi nicht mehr vom USB-Stick bootet....

[MadMax-FHEM]

Jetzt muss ich nur noch prüfen, wieso der Raspi nicht mehr vom USB-Stick bootet....

Kann der PI4 das überhaupt (schon)!?

Bislang hab ich immer noch im Kopf, dass der nur von SD booten kann...
...klar rootfs kann dann schon von USB gemounted werden (ich mounte nach dem Boot von SD eine SSD)...

Wenn du das meinst, also nach dem Boot von SD USB mounten etc. dann mal folgendes prüfen:

/boot/cmdline.txt -> rootfs device: root=...

/etc/fstab -> Mountpunkte prüfen...

Gruß, Joachim

[Bartimaus]

Hi Joachim,

ja, korrekt, offiziell kann der RPI4 noch nicht ausschliesslich von USB booten.
Ich hatte es bislang, rootfs@USB-Stick, und in der cmdline.txt darauf verlinkt. Das hat auch seit 10-2019 tadellos geklappt. Nur gestern abend ist mir das Ding abgestürzt und bootete nicht mehr.
USB-Stick raus, und Backup eingespielt. Keine Chance, bootet noch immer nicht.

Ich vermute auch, das der beim ersten Boot von der SD-Karte den USB-Stick vielleicht nicht mehr als SDA in /dev einhängt. Weil ich habe noch einen USB-Stick (/dev/sdb) dran, da wo die Backups draufkopiert werden.

Die fstab liegt doch schon in rootfs.... da kommt er doch schon scheinbar garnicht mehr hin...

Ich starte jetzt als Notbehelf wieder komplett von der SD-Karte, und habe die beiden USB-Sticks mit ihren Partitionen (sda1=rootfs,sda2=media,sdb1=backup) händisch in ein Verzeichnis gemountet. Dadurch sehe ich auch die alte Konfig komplett und kann dort auch editieren

[MadMax-FHEM]

Um das evtl. /dev/sda bzw. wahrschenlicher /dev/sda1 Problem zu umgehen: uuid nehmen...

Natürlich muss erst cmdline.txt passen...

Aber danm halt auch fstab...

EDIT: die uuid kriegst du mittels

Code Auswählen Erweitern

sudo blkid und dann eben entsprechend übernehmen (in der original-cmdline.txt steht ja drin wie das "Format" lautet / einfach die richtige uuid eingeben). Hilft auch in der fstab... Aber: jeder wie er will...

Gruß, Joachim

[Bartimaus]

Danke, ich bin auch soweit, das aktuell die "usb-storage.quirks" am Beginn der cmdline.txt nicht auf die PARTUUID matched.

Was mich gerade nur Stutzig macht, ist die Tatsache das die UUID des Boot_USB-Stick deutliche länger ist als die des 2. USB-Sticks... kann das ?

[MadMax-FHEM]

Kann schon so sein...

Gruß, Joachim

[Bartimaus]

Es will nicht klappen.

Magst Du mir bitte mal eine Beispiel cmdline.txt zeigen ?

Die UUID findest Du mit "sudo blkid" heraus ?

[MadMax-FHEM]

Here it comes, ist von meinem PI4

Code Auswählen Erweitern


:~ $ sudo blkid
/dev/mmcblk0p1: LABEL_FATBOOT="BOOT" LABEL="BOOT" UUID="FD44-CB94" TYPE="vfat" PARTUUID="0e63ef3d-01"
/dev/sda1: LABEL="rootfs" UUID="5df398fb-c6a6-43ce-85e2-6c78b002e297" TYPE="ext4" PARTUUID="9617cddb-01"
/dev/sdb1: LABEL="data" UUID="bfb5468b-4e69-46ec-8fec-db079dd97ad6" TYPE="ext4" PARTUUID="41eb0112-7912-41d4-b476-9541435602ea"
/dev/mmcblk0: PTUUID="0e63ef3d" PTTYPE="dos"


Code Auswählen Erweitern


:~ $ cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=9617cddb-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait


Code Auswählen Erweitern


:~ $ cat /etc/fstab
proc            /proc           proc    defaults          0       0
PARTUUID=0e63ef3d-01  /boot           vfat    defaults          0       2
PARTUUID=9617cddb-01  /               ext4    defaults  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
# data disk for shares
PARTUUID=41eb0112-7912-41d4-b476-9541435602ea /mnt/data ext4    defaults  0       1


Ich habe noch eine HDD dran hängen, die ich mit samba freigebe, der PI ist quasi mein Plattenserver...

EDIT: wenn man mal verstanden hat wie das geht, isses ganz einfach   Ich sichere meine PIs mittels tar (ausgeschalteter Zustand und mit einem Linux-Rechner). Das Backup ist dann nur so groß wie der genutzte Platz. Ich kann diese Backups auch auf JEDE "Platte" (SD, SSD, HDD, ...) aufspielen die genug Platz hat. Ich kann so auch Boot-Partitionen vergrößern. Danach muss ich nat. (falls es nicht dieselbe "Platte" ist) die entsprechenden Einträge (cmdline.txt bzw. fstab) anpassen aber das war's dann auch schon...

Gruß, Joachim

[Bartimaus]

Danke,

mir fällt auf, Du hast in der cmdline.txt keine "usb-storage.quirks=xxxx:xxxx:u" eingetragen ?

Bei mir:

Code Auswählen Erweitern

pi@RPi4FHEM:~ $ sudo blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5203-DB74" TYPE="vfat" PARTUUID="6c586e13-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e" TYPE="ext4" PARTUUID="6c586e13-02"
/dev/sda1: LABEL="FritzUSB64" UUID="5C940EF3940ED006" TYPE="ntfs"
/dev/sdb1: UUID="5f92e3b0-60af-442e-846c-0083c4f887d3" TYPE="ext4" PARTUUID="00021594-01"
/dev/sdb2: UUID="339473c6-e9f2-469e-92be-cb182dfcbf00" TYPE="ext4" PARTUUID="00021594-02"
/dev/mmcblk0: PTUUID="6c586e13" PTTYPE="dos"


trage ich jetzt

Code Auswählen Erweitern

console=serial0,115200 console=tty1 root=PARTUUID=00021594-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

ein, bootet die Kiste nicht.....
Die LED des Sticks blinkt zwar ab und an, aber die gelbe LED auf dem Board nur ganz kurz am Anfang....

Werde jetzt nochmal ein Backup auf die Partition aufspielen

[MadMax-FHEM]

Was steht denn in der fstab!?

Weil nach dem Boot kommt ja dann fstab.

Wenn das nicht passt, dann geht es (auch) nicht weiter...

Und du bist sicher, dass auf sdb1 liegt!?

EDIT: ich gehe (immer) so vor: Partitionen mit gparted anlegen (fat32: boot / ext4: rootfs). Sicherung per tar aufspielen. PARTUUID rausfinden und dann cmdline.txt und fstab anpassen. Hat noch immer funktioniert...

EDIT: cmdline.txt und fstab sind "Original-PI-Dateien", nur halt angepasst bzgl. meiner UUIDs...

EDIT: die angepasste cmdline.txt muss nat die auf der SD Karte sein. Die angepasste fstab nat. auf rootfs (bei dir /dev/sdb1 !?)... Du kannst eigentlich als Basis die Dateien der SD nehmen (cmdline.txt musst du ja eh DIESE nehmen), wenn der PI damit bootet. Evtl. auch mal die 2te Platte abstecken, nicht dass wegen Strom die "wichtige" Platte nicht zur Verfügung steht. Ich habe für meinen Aufbau eine "fremdversorgte" Platte...

Gruß, Joachim

[Bartimaus]

Hier der Inhalt die fstab (die ich gerade angepasst habe)

Code Auswählen Erweitern

proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=00021594-01  /               ext4    defaults,noatime  0       1
/dev/sda2 /media/ssd      ext4 defaults 0 0
UUID=5C940EF3940ED006 /media/USBStick64/ ntfs-3g utf8,uid=pi,gid=pi,noatime 0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that


angepasst deswegen weil die PARTUUID falsch war. Ich mene gelesen zu haben, die ändert sich, wenn man eine Partition neu formatiert oder so. Jedenfalls hat diese Änderung auch nicht zum Erfolg geführt

Edith: Diese Konfiguration lief wie gesagt seit 10-2019 stressfrei. Es sind keine Platten angeschlossen, sondern nur schnelle USB-Sticks (Sandisk Extreme als rootfs+data, Sandisk Ultra als Backupstick).

Wenn man über die UUID "geht", sollte das Problem mit sda oder sdb garnicht auftauchen, oder ?

Ich editiere die fstab nun wie folgt:

Code Auswählen Erweitern

proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=00021594-01  /               ext4    defaults,noatime  0       1
PARTUUID=00021594-02  /media/ssd      ext4    defaults 0 0
UUID=5C940EF3940ED006 /media/USBStick64/ ntfs-3g utf8,uid=pi,gid=pi,noatime 0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that


Und ja, cmdline liegt auf der SD-Karte und wird da angepasst. Bekomme schon Kilometergeld, weil mein PC im Keller steht, und der Pi auf dem Dachboden liegt.... Treppe rauf, Treppe runter... seit gestern gefühlt 100x

[MadMax-FHEM]

Ja, beim Neuanlegen einer Partition ändert sich diese.
Auch wenn du ein image einspielst (außer nat. wenn es immer dasselbe ist [denke ich])...

Noch mal: bist du sicher, dass /dev/sdb1 dein rootfs enthält!?

Prüf das und dann nimm doch einfach mal meine cmdline.txt und meine fstab (wirf den Eintrag meiner data-Platte raus) und passe die UUIDs an.
Dann steck nur die SD und die rootfs USB dran...

Wenn dann nichts bootet (wobei ich meinen schon mal stromlos machen "musste"), dann stimmt was mit deinem rootfs nicht...

Du kannst auch eine Sicherung machen und dann das rootfs von der SD auf /dev/sdb1 "kopieren", dann sollte der PI booten, sofern er von SD (noch) bootet...

Ansonsten wäre halt interessant was du so getrieben hast...

Und am besten immer Ausgabe von blkid, fstab und cmdline.txt zusammen und NEU posten...

Und auch mal eine Ausgabe des Inhalts von /dev/sdb1, musst halt schauen wo das gemountet ist oder mal an einen Linux Rechner stecken. Nur um zu sehen, ob das wirklich das (von dir vermutete) rootfs ist...

Gruß, Joachim

[Bartimaus]

Code Auswählen Erweitern

pi@RPi4FHEM:~ $ sudo blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5203-DB74" TYPE="vfat" PARTUUID="6c586e13-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e" TYPE="ext4" PARTUUID="6c586e13-02"
/dev/sda1: UUID="5f92e3b0-60af-442e-846c-0083c4f887d3" TYPE="ext4" PARTUUID="00021594-01"
/dev/sda2: UUID="339473c6-e9f2-469e-92be-cb182dfcbf00" TYPE="ext4" PARTUUID="00021594-02"
/dev/mmcblk0: PTUUID="6c586e13" PTTYPE="dos"
pi@RPi4FHEM:~ $


fstab (Backup-USB-Stick auskommentiert, weil ich jetzt ohne diesen zu starten versuche)

Code Auswählen Erweitern

proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=00021594-01  /               ext4    defaults,noatime  0       1
PARTUUID=00021594-02  /media/ssd      ext4    defaults 0 0
#UUID=5C940EF3940ED006 /media/USBStick64/ ntfs-3g utf8,uid=pi,gid=pi,noatime 0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that


cmdline.txt

Code Auswählen Erweitern

console=serial0,115200 console=tty1 root=PARTUUID=00021594-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Momentan läuft der RPI gerade von der SD-Karte.
Das "alte" rootfs auf dem Sandisk-Stick (erst Partition) habe ich nach /media/256GB gemountet.

Code Auswählen Erweitern

pi@RPi4FHEM:/media/256GB $ ls
bin  boot  boot.bak  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var


Nachdem der Raspi gestern Abend abgestürzt war, und nicht mehr bootete, habe ich wie jetzt auch von der SD-Karte gebootet, das alte rootfs nach /media/256GB eingehängt, sämtlichen Inhalt dort gelöscht, und aus meinem VollBackup (*.tgz) alles dorthin extrahiert.

Mit diesem Prozess war ich in der Vergangenheit immer erfolgreich, nur damals war es ein BananaPi mit SSD, dorthin war auch rootfs ausgelagert....

Edith: Teilerfolg, habe jetzt auch in der fstab die 2. Partition auf dem Stick deaktiviert, jetzt ist er gestartet !!!

Edith2: Mein 1wire-USB wird nicht mehr gefunden, ebenso der Zwave-USB. Verzeichnis /dev/serial kann nicht gefunden werden.... ächz...

Edith3: Kopiere ich das Verzeichnis /dev erneut, so wird es beim starten gelöscht. Ich glaube, das hat alles keinen Zweck, und werde die Tage die Kiste neu aufsetzen müssen

[MadMax-FHEM]

Hast du alles ohne USB-Hub am PI hängen!?

Ist evtl. ein wenig viel für das USB...

Was für ein Netzteil!?

Und war da nicht was mit den USB-3 Anschlüssen des PI mit diversen USB-Platten/-Geräten!?

Wie geschrieben habe ich meine HDD per "fremdversorgtem" SATA-Adapter angeschlossen (geekworm).

Die SSD (mit rootfs) ist eine USB-SSD für den PI (renkforce).

Und dann nat. die SD von der er bootet (4GB weil reicht ja leicht )...

Weil wenn er nur von SD bootet, hängt ja weniger an den USB Anschlüssen...

Bei meinem "TV-PI" (tvheadend) habe ich auch einen aktiven USB-Hub (ist allerdings ein PI3, daher auch ganz ohne SD).
Habe ich gebraucht nachdem ich von "billig-China-TV-Tunern" auf Hauppauge Dualtuner umgestiegen bin.
(Trotzdem) nicht bereut...

Der fhem Server läuft auch mit einer renkforce SSD aber OHNE SD (ist ein PI3B+) und einem Aufsteckmodul für EnOcean, einem HM-CFG-USB und einem ZWave-USB-Stick...
...per POE-Adapter

Gruß, Joachim

[Bartimaus]

Ist incl. USB2-Hub. Aber die Sticks hängen an den USB3-Ports.
Hardware hat sich seit 10-2019 nicht geändert.

Netzteil ist das originale von Raspberry für den Pi4.

Ich boote jetzt von der SD-Karte, und trinke ein Bier. Danke für Deine Hilfe und Geduld !!
Evtl. komme ich nochmal auf Dich zu, wenn ich das alles neu einrichte...

[Otto123]

Hi,

nur mal so: die Verwendung von normalen USB Sticks als Alternative zur SD Card ist aus Sicht "SD Card geht häufig kaputt" sinnfrei. USB Sticks sind nicht besser oder schlechter als vergleichbare SD Cards. Es ist die gleiche Technik drin.

Vorteile bringen nur SSD oder USB Sticks mit wear leveling.

🍻

Gruß Otto

[Bartimaus]

Hallo Otto,

danke für den Hinweis, aber es ist ein Sandisk-Extreme, der hat einen SSD-Controller, dadurch ist er auch ultraschnell (190MB/s schreiben). Der SSD-Controller verwaltet die Cluster intelligenter als ein SD-Kartencontroller.

[MadMax-FHEM]

Dann mal Prost!!

Und meld dich einfach...

Gruß, Joachim

[Bartimaus]

 

[Otto123]

Naja für mich ist Sandisk-Extreme erstmal nur eine Bezeichnung vom Hersteller, die gleichnamigen SD Cards sind ja auch ohne SSD Controller

Wenn Du eine USB - SSD dran hast ist ja alles gut

Ich hatte das übrigens mal so aufgeschrieben.
Dabei war mir aufgefallen, man kann UUID oder PARTUUID verwenden, ob das Vor- oder Nachteile ist mir allerdings nicht klar.
Zum Wohl!

[Jewe]

Hallo, seit ein paar Tagen gibt es nun eine neue Firmware für den Pi 4 mit der dann von USB gebootet werden kann.
Ich habe das testhalber mal ausprobiert und es läuft seit eine Woche stabil.

https://youtu.be/zVhYvvrGhMU

Ist allerdings noch eine Beta [emoji3]

Grüssle, Jens


Gesendet von iPhone mit Tapatalk

[Bartimaus]

Moin,

ich versuche mich gerade wieder daran, meinen RPi4 mit rootfs@USB-Stick zum fliegen zu bekommen.
Dabei möchte ich auch die fstab korrekt einstellen.

Wenn ich 2 ext4-Partitionen (besfinden sich beide auf demselben USB-Stick) in der fstab mounten möchte

Code Auswählen Erweitern


PARTUUID=00021594-01  /               ext4    defaults,noatime  0       1
PARTUUID=00021594-02  /data               ext4    defaults,noatime  0       1

beides dann mit den Optionen "0" + "1" ??
Partition 01 = rootfs
Partition 02 = Datenpartition

[MadMax-FHEM]

Also ich habe das so eingebunden (wie auch hier bereits gepostet: https://forum.fhem.de/index.php/topic,111643.msg1058883.html#msg1058883 ) und es läuft.

Ob das nun so "optimal" ("korrekt") ist: keine Ahnung

Warum noatime!?
Ist eigentlich eher relevant, wenn es eine SD ist...

Äh was spricht gegen: lass doch mal laufen

EDIT: die '0' und '1' (oder was auch immer) am Ende ist hier beschrieben https://wiki.ubuntuusers.de/fstab/ bzw. hier https://wiki.ubuntuusers.de/fstab/#Aufbau und für mich nicht (wirklich) relevant...

EDIT: ob -01 oder -02 die jeweils "gewünschte" Partition ist hängt davon ab, wann (Reihenfolge) du sie mit beispielsweise partedMagic angelegt hast... Du kannst sie ja mal eine nach der anderen einfach mal so auf einem anderen Linux-System mounten und dann anhand der Daten prüfen...

Gruß, Joachim

[Bartimaus]

Moin Joachim,

danke für Deine schnelle Antwort.

noatime verwende ich "deswegen":

Code Auswählen Erweitern

noatime atime Keine Zugriffszeiten für Dateien und Verzeichnisse (nodiratime wird durch noatime impliziert und muss nicht zusätzlich gesetzt werden) in der Inodetabelle speichern. Dies reduziert die Datenträger-Schreibzugriffe und wird für SSDs empfohlen sowie, falls Snapshots genutzt werden sollen, für Btrfs.

Deine fstab hatte ich mir natürlich angesehen, aber Du hast keinen vergleichbaren Fall mit 2 Partitionen auf einem Laufwerk.

xxx-01 ist die erste Partition auf dem Stick die als rootfs herhalten soll, 02 dann die Datenpartition. Ausgelesen mit "blkid". Jetzt gehe ich erstmal futtern, danach kommt dann der Neustart. Bin gespannt. Aber vielleicht fällt mir vorher noch was wichtiges ein....

ach ja, die (künftige rootfs)Partition auf dem USB-Stick habe ich mit "rsync" von der aktuellen rootfs@sd-karte betankt.

Danke für den Hinweis mit den Optionsfeldern dump+pass 

[MadMax-FHEM]

Ich weiß nicht von wann die Aussage mit noatime auch bei SSDs stammt, würde mir aber erhoffen, dass aktuelle Controller da kein Problem mehr haben...

Aber vielleicht schalte ich das auch ein, tut ja nicht weh...

Bei SDs ist es klar.

Äh, ja keine 2te Partition auf einer SD...
...aber wenn es "nur" um die "Bezeichnung" geht: schau bei der Original-fstab nach

Da sind ja auf der SD 2 Partitionen...

Wenn du sicher bist, "was" Part-01 und "was" Part-02 ist, dann ist es so richtig.

Ich hatte nur mal gemerkt, dass ich dachte zu wissen "was" 01 und "was" 02 ist, habe mich aber getäuscht.
Weil (zumindest in meinem Fall) hatte es NICHTS mit "vorne"/"hinten" (in der Partitionsanzeige) zu tun, sondern wirklich mit "wann/Reihenfolge" habe ich sie angelegt...

Guten Hunger, Joachim

[Wernieman]

No atime reduziert das schreiben ... insofern ist der Tipp älter, als es SSD giebt.

Hatte ich schon bei meinem ersten Fileserver .. und da waren es Magnetplatten

[Bartimaus]

Genau,

hatte das hier gefunden: https://wiki.archlinux.de/title/Fstab

Sodele, lecker gegessen, alles nochmal überprüft, erster Schuss = nur Partition1@fstab eingebunden.... läuft.
2. Schuss weiterer Stick + 2. partition per fstab gemountet, läuft.

Kaum macht man es richtig.... funktionierts.

Ich danke für Eure Geduld+Hilfe.

Nächste Baustelle: FHEM von "aussen" wieder "safe" erreichbar machen. Haben Inet per Deutsche Glasfaser und "nur" eine IPV6.

Mein erster Versuch mit VPN-Server auf zweitem Raspi klappte nicht, war auch wirklich sehr umständlich.

Wenns Tips habt, gerne her damit.... schönenRestsonntag

[MadMax-FHEM]

Genau,

hatte das hier gefunden: https://wiki.archlinux.de/title/Fstab

Sodele, lecker gegessen, alles nochmal überprüft, erster Schuss = nur Partition1@fstab eingebunden.... läuft.
2. Schuss weiterer Stick + 2. partition per fstab gemountet, läuft.

Kaum macht man es richtig.... funktionierts.

Ich danke für Eure Geduld+Hilfe.

Gerne.

Nächste Baustelle: FHEM von "aussen" wieder "safe" erreichbar machen. Haben Inet per Deutsche Glasfaser und "nur" eine IPV6.

Jaja, weiß schon, da ist es nicht so einfach...
...habe aber im Kopf im Forum genau bzgl. vpn und Glasfaser IP V6 was gelesen zu haben.

Mein erster Versuch mit VPN-Server auf zweitem Raspi klappte nicht, war auch wirklich sehr umständlich.

Umständlich!?

piVPN genommen!?

Dauert ungefähr 5min und VPN läuft...

Kann sogar mit auf dem fhem Server laufen...
...wenn man will (oder muss: bei meiner Freundin gibt es nur den einen fhem PI [mehr "Käfer" werden nicht "geduldet"   ] und da ich bei Problemen "rein kommen will/muss" läuft piVPN da drauf / Router ist so ein "Telekom-Ding" und scheidet somit aus   )...

Ist aber wohl erst dann eine Lösung, wenn man das "Kabel IP 6 Problem" gelöst hat...

Viel Erfolg, Joachim

[Bartimaus]

Ok, ich schaue mal.

Hab gerade ein anderes Problem,

Code Auswählen Erweitern

ping: socket: Die Operation ist nicht erlaubt

Müllt mir das Log voll. Presence ist nicht in Benutzung, FHEM hat Sudo-Rechte in sudoers, aber ich finde die Ursache nicht. Nutze WOL mit Etherwake, aber alles gem. Wiki eingerichtet. Hat noch jemand eine Idee ?

[Wernieman]

Gut währe, was für "ping" Du machen willst ... und wie die sudo Rechte aussehen ...

[Bartimaus]

Wenn ich das mal wüsste, wie gesagt, ich nutze keine PRESENCE. Das einzige was mir auffällt, ist, das meine Geräte die ich per WOL aus FHEM heraus starte, melden, sie seien online, was sie aber definitiv nicht sind. Ich vermute hier den Zusammenhang.

So sieht meine Sudoers aus:

Code Auswählen Erweitern

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
pi ALL=(ALL) NOPASSWD: ALL
fhem ALL=(ALL) NOPASSWD: ALL


[Wernieman]

Code Auswählen Erweitern

pi ALL=(ALL) NOPASSWD: ALL
fhem ALL=(ALL) NOPASSWD: ALL

So kannst DU Dir eigentlich gleich das sudo sparen ... Sicherheit=0 .. würde Dir empfehlen das Zurückzubauen und wirklich nur das zu erlauben, was fhem (und pi) nur für Rechte braucht

[Bartimaus]

Ok, damit befasse ich mich dann, wenn ich das "Ping-Problem" gelöst habe...

[Wernieman]

Wenn das ping dauern im fhem logfile kommt, muß es dauerhaft aufgerufen werden. Kontrolliere mal Deine FHEM-Config, auch Deine Zusatzprogramme.

Bezüglich "Zurückbauen hinterher": Meinst Du wirklich, das Du es nachher "richtig" machst? Will Dir nicht zunahetreten, sondern spreche aus Erfahrungen mit anderen Systemen. Zurückgebaut, Sicherheit erhöht, wird dann meistens nicht mehr ....
Ich bin dagegen der Meinung, es gleich "richtig" zu machen ....

[Bartimaus]

Hast ja Recht, habe aber mein Problem gelöst. Ich hatte mir in meiner persönlichen FAQ@FHEM+Raspi mal folgendes Kommando notiert, falls der Ping Socket Fehler kommt:

Code Auswählen Erweitern

sudo setcap cap_net_raw+ep /bin/ping

Jetzt melden meine WOL-Geräte auch korrekt ihren Status zurück.

Jetzt schaue ich mal, was FHEM an Rechten wirklich braucht

[Bartimaus]

Umständlich!?

piVPN genommen!?

Dauert ungefähr 5min und VPN läuft...

Kann sogar mit auf dem fhem Server laufen...
...wenn man will (oder muss: bei meiner Freundin gibt es nur den einen fhem PI [mehr "Käfer" werden nicht "geduldet"   ] und da ich bei Problemen "rein kommen will/muss" läuft piVPN da drauf / Router ist so ein "Telekom-Ding" und scheidet somit aus   )...

Ist aber wohl erst dann eine Lösung, wenn man das "Kabel IP 6 Problem" gelöst hat...

Viel Erfolg, Joachim

Ja, habe PI-VPN genommen, wollte es auf meinem Pi-Hole Raspi laufen lassen. Scheiterte glaube ich an der IPv6-Adresse des Raspi, weil ich dem ne statische IPv4 verpasst habe. Deswegen hat er glaube ich dann auch keine DHCP-IPv6 von der Fritte bekommen. Am Ende hatte ich den Pi-Hole Raspi komplett verkonfiguriert, und es lief darauf  garnix mehr.... muss ich nochmal in Ruhe schauen