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