Hallo, ich bin gerade dabei einen Installationsserver aufzusetzen, der Yast's automatisierte Installationsmoeglichkeiten benutzt. Es gibt dazu einen Eintrag in der SDB (Titel: "Automatische Installation mit YaST"), der diese Installationsmethode recht gut beschreibt. Eine solche automatisierte Installation wird von Info-Dateien auf dem Bootmedium (Diskette) und/oder Installationsmedium (Verzeichnis auf NFS Server) gesteuert, die die Parameter der Installation (IP-Konfiguration, Plattenpartitionierung, Dateisysteme, zu installierende RPMs, etc) beschreiben. Bei der IP-Konfiguration gibt's allerdings ein Problem. In der Theorie soll, wenn in der Info-Datei auf der Boot-Diskette *keine* IP-Adresse angegeben ist, eine bootp-Anfrage abgesetzt werden. Auf SuSE's Bootdisketten ist dazu ein Bootp-Client integriert. Die bootp-Kommunikation laeuft leider so ab (mittels Tracing auf dem Netzwerk ermittelt): 1) bootp-Client sendet erste Anfrage (bootp-Broadcast) 2) bootp-Client sendet zweite Anfrage (bootp-Broadcast) 3) bootp-Server sendet Antwort auf erste Anfrage 4) bootp-Server sendet Antwort auf zweite Anfrage 5) bootp-Client sagt, dass keine IP-Adresse ermittelt werden konnte, Installation bricht ab. Da auch der Linux-Kernel einen (auf anderem Code basierenden) bootp-Client enthaelt (Kernel-Konfig-Parameter "IP: kernel level autoconfiguration" CONFIG_IP_PNP und "BOOTP support" CONFIG_IP_PNP_BOOTP,), habe ich mal probiert wie sich dieser Bootp-Client bei unveraendertem bootptab-Eintrag auf dem Bootp-Server verhaelt. Da Ergebnis war sehr erfreulich. Ein mit den obigen Parametern erzeugter Kernel sendet brav seine bootp-Anfrage, erhaelt eine Antwort und konfiguriert seine Netzwerkkarte korrekt. Leider ist mein Problem bei der automatisierten Installation damit nicht geloest. Auch wenn die IP-Konfiguration durch den Kernel-Bootp-Client schon korrekt gesetzt ist, versucht der auf SuSE's Bootdisketten integrierte Bootp-Client trotzdem wieder seine Bootp-Anfragen und scheitert. Ich sehe im Moment folgende Alternativen: 1. Bei der Info-Datei, die die automatisierte Installation steuert, muesste man angeben koennen "Uebernehme die IP-Konfiguration, die du vorfindest". Dann koennte die IP-Konfiguration vom Kernel-Bootp-Client vorgenommen werden, der Bootp-Client auf der Bootdiskette wuerde uebersprungen werden und die Installation koennte weiterlaufen. 2. In der Info-Datei koennte man erweiterte Angaben fuer das Verhalten des auf der Bootdiskette integrierten Bootp-Clients setzen. Als Vorlage koennte der Kernel-Bootp-Client dienen. Dessen Verhalten kann man uber den Kernel-Parameter "ip=<client ip>:<server ip>:<gw ip>:<netmask>:<hostname>:<device>:<autoconf>" steuern. 3. Man ersetzt den auf der Bootdiskette integrierten Bootp-Client durch einen "Fake"-Bootp-Client, der keine bootp-Anfragen absetzt, sondern aus einem exit(0) besteht. Leider sind auf den SuSE Bootdisketten (genauer: auf der initrd auf der SuSE Bootdiskette) die einzelnen Programme (linuxrc, insmod, cardmgr, etc) in ein einzelnes (statisch gelinktes?) Super-Binary gepackt worden. Auf der initrd sieht man nur Hardlinks der einzelnen Programme auf dieses Super-Binary. Weiss jemand, wie dieses Super-Binary erzeugt wird? Sind die Sourcen fuer linuxrc (dort ist der bootp-Client drin) verfuegbar? Hat jemand schon Erfahrungen mit der automatisierten Installation gemacht? In der letzten Ausgabe von "SuSE aktuell" war ein Artikel ueber DESY drin. Dort wurde wohl auch ein Installationsserver aufgebaut. Weiss jemand, wie dort das Bootp-Problem angegangen wurde? Die Links auf der DESY-Homepage (www.desy.de) verweisen leider auf nur vom internen Desy-Netz lesbare Dateien. Ich nehme an, dass diese Art der Installation nicht vom normalen SuSE Installationssupport abgedeckt wird, oder? Gruss, Stefan Voss (stefan.voss@hamburglb.de) --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com