[solved] RHEL 7.4, UEFI, PXE-Boot, Kickstart, Problem mit network

[Geier0815]

Moin Moin,

ich stehe hier gerade wie ein Ochs vorm Berg. Ich versuche RHEL per PXE zu installieren. System zieht vom PXE-Server zuerst eine IP aus einem anderen Adressbereich um vom PXE-Server die zusätzlichen PXE-Optionen per DHCP zu ziehen. Dazu läuft auf dem PXE ein dnsmasq. Das funktioniert. Dann holt er sich die grub-config und damit Kernel und initrd. Klappt. Ebenso zieht er das kickstart-file und die Installations-Quelle per nfs was auch klappt.
Wenn ich allerdings eine Zeile der Form:

network --activate --bootproto=static --onboot=yes --ip=10.1.1.148 --netmask=255.255.0.0 --gateway=10.1.1.5 --noipv6 --nameserver=10.1.1.11 --hostname=rhel

im ks-file habe, bleibt die Installation direkt nach den VNC-Meldungen hängen. Lasse ich die Zeile raus läuft die Installation durch aber er hat sich eine IP von meinem "normalen" DHCP-Server gezogen. Ich möchte aber eine feste IP vergeben.
Verschiebe ich die network-config in eine post-install-section kriege ich eine per DHCP vergebene IP in der fertigen Installation und sehe im anaconda-log einen "error code 127 running the kickstart script at line ..."

Hat einer von euch eine Idee was da schief läuft bzw wie ich das konfiguriert kriege?
Btw: Mit SLES hab ich solche Probleme nicht, da funktioniert Alles so wie es soll, also scheint mein Aufbau nicht grundsätzlich falsch zu sein.

[goeba]

Hi,

ich schaue nur in den Faden rein, weil ich auch einen PXE Server habe - aber ebenfalls mit SLES.

In dieser Doku:

https://www.centos.org/docs/5/html/Inst ... tions.html

(die sich aber auf centos bezieht, kann also falsch sein, obwohl natürlich eng verwandt)

gibt es den Parameter "activate" nicht - nur so ein Schuss ins Blaue.

[Geier0815]

--activate - activate this device in the installation environment.
If you use the --activate option on a device that has already been activated (for example, an interface you configured with boot options so that the system could retrieve the Kickstart file) the device is reactivated to use the details specified in the Kickstart file.

Kannte ich vorher auch nicht, steht aber so im Abschnitt network. Aber wie auch immer: Auch wenn ich das weg lasse, klappt es nicht. So hatte ich das nämlich zuerst. Ich habe auch schon versucht per "device=link" das erste hoch gekommene Netzwerk-Device explizit anzusprechen. Ganz im Zweifel versuch ich halt die /etc/sysconfig/network-scripts/ifcfg-eth0 per Skript in einem post-Abschnitt zu bauen aber eigentlich kann es nicht sein das das nicht einfacher geht.

[spoensche]

Zitat aus der Doku: "you should always specify a --device= for every network command."

Du musst also noch ein

Code: Alles auswählen

--device=eth0

in deine Zeile einfügen. Dann sollte es klappen.

[Geier0815]

"--device=eth0" hab ich schon genauso erfolglos wie "--device=link" probiert. Was mich ja auch sehr stark irritiert ist die Tatsache das sich die ganze Installation aufhängt und auf nichts mehr reagiert wenn die Zeile drin ist. Bei anderen Fehlern im ks-file taucht entweder das Menü auf (wenn es essentiell ist) oder es kommt einfach eine Fehlermeldung oder nur im installierten System eine Fehlermeldung im anaconda.log.

[spoensche]

Wechsel mal vom Installer in eine Konsole und poste mal die Ausgabe von

Code: Alles auswählen

egrep -i "err|fail|fault|warn|crit" /var/log/messages

. Wenn es egrep nicht gibt, dann

Code: Alles auswählen

grep -Ei "err|fail|fault|warn|crit" /var/log/messages

[Geier0815]

Als ich schrieb "Was mich ja auch sehr stark irritiert ist die Tatsache das sich die ganze Installation aufhängt und auf nichts mehr reagiert wenn die Zeile drin ist", meinte ich auch aufhängen. Ich kann zwar noch per <ALT><TAB> durch die Konsolen schalten aber die Tastatur funktioniert ansonsten nicht mehr, sprich ich kann nichts eingeben. Die Meldungen auf den anderen Konsolen, die noch zu sehen sind, geben auch nichts her was nach einer Fehlerursache aussieht.

[Geier0815]

Was ich jetzt noch durch probieren heraus gefunden habe: Der Client zieht erst über den dnsmasq, auf dem PXE, eine IP und holt sich darüber die initrd und den Kernel und zieht danach direkt eine IP von meinem "normalen" DHCP. Verwende ich nämlich als Adresse für das ks-file (in der grub.cfg) die IP des PXE aus dem Netz das per dnsmasq vergeben wird, findet der Client kein ks-file und auch kein Image.
Diesmal habe ich es auch geschafft schnell genug auf eine Konsole zu kommen um zumindest ein "ip addr sh" abzusetzen bevor die Konsole eingefroren ist. Er gab die von mir angegebene feste IP zurück.
Stellt sich die Frage warum er mit einer IP die er sich per DHCP holt sauber installiert aber mit einer festen IP aus dem gleichen Adressbereich einfriert. Nein, die IP ist nicht schon vergeben, extra mehrfach überprüft. Und ohne PXE dazwischen, also direkt von einer DVD installiert, klappt die Installation mit dieser festen IP im ks-file.

[Geier0815]

So, nun wird der Hund in der Pfanne verrückt: Diesmal hab ich nach dem Einfrieren dringend etwas anderes erledigen müßen und als ich zurück zum System kam, war es sauber installiert, incl. der von mir vergebenen IP. DH das Einfrieren incl. des nicht mehr auf die Tastatur reagieren, ist offensichtlich nur temporär. Ich werde jetzt mal die Logs checken ob ich den Grund finde. Trotzdem empfinde ich es als ungewöhnlich das sich das System so unterschiedlich verhält wenn es mit einer festen IP umgehen soll. Bei der Installation per DVD ist mir das nicht untergekommen.

Wie auch immer: Danke an alle die versucht haben mir zu helfen.

[spoensche]

Wenn das System den Admin vom Rechner verscheucht, damit es in Ruhe installieren kann, nennt man es auch, neue Definition von unbeaufsichtigter installation?