Beiträge von ENOLINK

Ich antworte mal eben auf meine eigene Frage, zu der ich nun (endlich) durch etwas Zufall die Ursache gefunden habe.

Falls also noch jemand das Problem hatte, dass der Server nach dem Upgrade auf Debian 10 trotz vorhandenem DEVICE/IP-Setting im initramfs immer noch DHCP versucht (und dabei fehlschlägt), ist hier nochmal das entsprechend fragende Zitat von mir und direkt darunter die Lösung:

Zitat von ENOLINK

Das "DEVICE/IP"-Setting in "/etc/initramfs-tools/initramfs.conf" klappt bei mir merkwürdigerweise nicht, sondern initramfs fragt trotz vorhandener "DEVICE"- und "IP"-Option (und erfolgtem update-initramfs) noch per DHCP ins Netz (siehe folgende zwei Zeilen).

DEVICE=ens3   # netmask: /22 (status 2019-09-25)

IP=XXX.XXX.XXX.XXX::YYY.YYY.YYY.YYY:255.255.252.0::ens3:off::

XXX.XXX.XXX.XXX ist hierbei die IPv4-Adresse des ens3-Interfaces am lokalen Server.

YYY.YYY.YYY.YYY ist hierbei die IPv4-Adresse des Gateway-Hosts.

Tja, die Lösung dazu ist fast schon peinlich simpel:

Die letzten beiden Parameter in der Zeile "IP=..." sind oben als leere Werte angegeben. Genau deshalb schlägt das ganze seit dem Buster-Upgrade fehl.
Das ganze funktioniert sofort (wieder) problemlos, nachdem man diese beiden (leeren) Einträge mitsamt ihrer parametertrennenden Doppelpunkte komplett rausschmeißt, also statt wie oben nun so:

IP=XXX.XXX.XXX.XXX::YYY.YYY.YYY.YYY:255.255.252.0::ens3:off

<verbose>

Hier noch ein paar Anmerkungen und meine eigenen Notizen zu den gesamten Parametern, vielleicht hilft das ja einem verzweifelten Suchenden als Überblick:

Alle möglichen Parameter der "IP"-Option in "/etc/initramfs-tools/initramfs.conf" mit den jeweiligen Kommentaren darunter:

IP=IPADDRESS:SERVERIPADDRESS:GATEWAY:NETMASK:HOSTNAME:INTERFACE:AUTOCONF:DNS1:DNS2

Anmerkungen zu den Einzelparametern der "IP"-Option:

IPADDRESS=IPv4-Adresse, z.B 10.10.10.10

SERVERIPADDRESS=IPv4-Adresse des Servers, nur benötigt für NFS-Root, anderenfalls leer

GATEWAY=IPv4-Adresse des Gateways, z.B. 10.10.10.1

NETMASK=IPv4-Subnetzmaske, z.B. 255.255.252.0 für ein "/22"-Subnetz

HOSTNAME=Hostname für namensbasiertes DHCP, anderenfalls leer

INTERFACE=Name des Netzwerkinterfaces, z.B. eth0, ens1 o.ä.

AUTOCONF=Autokonfigurations-Flag, z.B. off

DNS1=IPv4-Adresse des ersten DNS-Servers, nur bei namensbasierte Verbindung benötigt, anderenfalls leer (bzw. komplett weglassen)

DNS2=IPv4-Adresse des zweiten DNS-Servers, nur bei namensbasierte Verbindung benötigt, anderenfalls leer (bzw. komplett weglassen)

Optionale Parameter am Ende kann man komplett weglassen und die meisten tun das vermutlich auch, weshalb das wohl sonst niemandem aufgefallen war.

Ich hatte die Parameterzeile auf meinen Servern stets komplett, damit beim ersten Draufblicken schon klar ist, dass und wieviel da noch zusätzliche stehen könnte. Genau solche leeren Platzhalterparameter am Ende mag die unter Buster aktuelle Paketversion jedoch offenbar nicht mehr.

</verbose>

Zitat von Orangelynx

[...]nachdem ich meinen Debian Stretch server auf Buster upgraded habe. Dabei schlägt die Netzwerkkonfiguration während der initramfs phase des Bootprozesses fehl, da der Netcup server nicht auf Discovery Requests des verwendeten dhcp clients ipconfig antwortet.[...]

Exakt dasselbe wie OrangeLynx kann ich für sämtliche von mir administrierten Server bei netcup bestätigen:

Nach dem auf mehreren VPS- und Root-Servern über mehrere Wochen verteilten dist-upgrade von stretch auf buster (inkl. grub und initramfs) versandeten die DHCP-Requests von dropbear konsequent in Timeouts, wodurch beim Reboot dann zunächst mal nur die VNC-Konsole als Ausweg blieb.

Heißt: Das Problem ist leider kein Einzelfall, sondern mit einem aktuellen Debian (stable) sowohl im VPS- als auch im Root-Server-Segment zuverlässig reproduzierbar.

Daher schonmal einen Dank an die Admins, von denen vielleicht jemand etwas Zeit findet, um nachzuforschen, ob es diesbezüglich bereits Erkenntnisse oder vielleicht sogar auch eine einigermaßen leicht behebbare Ursache am DHCP-Server gibt.

Bezüglich der von mir administrierten Server sehe ich die zuständigen DHCP-Server unter den IPv4-Adressen 46.38.225.134 und 46.38.225.234.

Zitat

[...]Ein workaround ist die statische Konfiguration mittels Kernel Option IP,[...]

Das "DEVICE/IP"-Setting in "/etc/initramfs-tools/initramfs.conf" klappt bei mir merkwürdigerweise nicht, sondern initramfs fragt trotz vorhandener "DEVICE"- und "IP"-Option (und erfolgtem update-initramfs) noch per DHCP ins Netz (siehe folgende zwei Zeilen). Falls sich jemand erklären kann, wieso die nicht greifen... Danke

DEVICE=ens3   # netmask: /22 (status 2019-09-25)

IP=XXX.XXX.XXX.XXX::YYY.YYY.YYY.YYY:255.255.252.0::ens3:off::

XXX.XXX.XXX.XXX ist hierbei die IPv4-Adresse des ens3-Interfaces am lokalen Server.

YYY.YYY.YYY.YYY ist hierbei die IPv4-Adresse des Gateway-Hosts.

(Bei einem anderen Provider habe ich dieses Problem merkwürdigerweise nicht, allerdings gibt es dort gar kein DHCP und die dortigen (Redundanz-)Server waren auch unter stretch schon immer fix konfiguriert.)

p.s.

Auch ich habe mich nach vielen Jahren nun erstmalig hier im Forum mit registriert und möchte das nutzen, um rückwirkend einfach mal "Danke!" zu sagen, dass es dieses Forum gibt und dass die netcup-Mitarbeiter hier auch hin und wieder aktiv mit antworten.