lessdisks (war: etherboot /nfsexports [geloest])
Mittlerweile läuft die erste Workstation mittels lessdisks. Nochmals vielen Dank an alle, die sich mit mir den Kopf zerbrochen haben. Zusammenfassung: Warum lessdisks - weniger Platten! lessdisks ermöglicht die Nutzung lokaler Ressourcen auf Clients. Die Workstations erhalten von einem Server ein komplettes Dateisystem per NFS-Export, führen Programme aber auf ihrer lokalen CPU aus. Lokale Grafik- und Soundkarten werden genutzt. Das benötigte chroot-Dateisystem wir von Lessdisks automagisch erzeugt. Hinzukommende Clients werden on-the-fly eingerichtet. Der Vorteil der zentralen Verwaltung bleibt erhalten, während Arbeitsspeicher und Prozessor des Servers entlastet werden. Ich empfehle, die NFS-Freigaben und den DHCP-Server vor der Installation von lessdisks einzurichten und mit einem Client mit lokalem Dateisystem zu testen. Lessdisks verlangt Boot-ROMs mit aktivierter Option DOWNLOAD_PROTO_NFS. Es bringt vorbereitete Kernel (inkl.config-Datei zum Nachlesen) und initrd mit. Die bei der Einrichtung erzeugten tagged images erwiesen sich bei meiner Installation als untauglich. Die Optionen für mknbi wurden vom install-lessdisks-Skript abgefragt. Weder die Vorgabe noch ein Beispiel führten zu funktionierenden images. Das Problem scheint in der Übergabe der Parameter für nfs-root (per DHCP erhalten) an den Kernel zu liegen. Letzlich habe ich die images selbst erzeugt und dabei die nfs-Freigabe hart kodiert. mknbi-linux --rootdir=192.168.123.107:/var/lib/lessdisks --ip=rom vmlinuz-2.4.18-1-386 initrd.img-2.4.18-1-386 > vmlinuz-2.4.18-1-386.nb Von der Verwendung von Boot-ROMs auf Disketten kann ich nur abraten. Mir erscheint sinnvoll, die Workstations in einem eigenen Netz unterzubringen (extra Netzwerkkarte am Server -> switch -> Workstations) um die NFS-Freigaben nicht unnötig zu exponieren. Als größtes Problem empfand ich die völlig unzureichende Dokumentation des Projektes (allerdings sprechen wir hier von Release 0.6.2b) http://lessdisks.net deb http://lessdisks.net/debian/current / Herzliche Grüße Dirk Wenzel _ may contain nuts!
Re: etherboot /nfsexports [geloest]
Hallo Bernd, Am 16.02.2005 um 23:57 schrieb Bernd Schubert: Hmm, liegt vermutlich an fehlenden dev-Packeten, bei mir gehts problemlos. Was sind denn die Fehlermeldungen? Das weiß ich nicht mehr, ich hab's recht bald aufgegeben. Ich verstehe immer noch überhaupt nicht, wozu Du zu diesem Zeitpunkt überhaupt nfs brauchen solltest. Die Entwickler weisen in ihrer - spartanischen Dokumentation - darauf hin, daß beim Erstellen der ROM-Images die Option DONLOAD_PROTO_NFS aktiviert sein muß. Während ich diverse ROM-Images funktionierte mal das Laden des Kernels per tptfd, mal nicht. Ob jemals einer per nfs geladen wurde, weiß ich nicht. Ich tippe ganz stark auf die NIC. Du kommst nicht zufällig aus der Nähe von Heidelberg und könntest Dir so von uns eine verfünftige 3COM Karte ausborgen? Vielen Dank für das Angebot (nein, ich bin zur Zeit in Dresden), mittlerweile habe ich eine rtl8139 mit Boot-ROM. Das Fehlerbild blieb zunächst ähnlich. Daher hab ich eigene Kernelimages erzeugt und getagged. Siehe da: es geht! Vielen Dank für Deine Ausdauer und das große Entgegenkommen. Es motiviert sehr, wenn man solche Hilfe hat. Herzliche Grüße Dirk Wenzel
Re: etherboot /nfsexports
>> Dann noch zum Etherboot, ich habe noch nie den rom-o-matic benutzt, >> sondern >> mir immer die Disketten- und Lilo-Images aus den etherboot tar.gz >> Images >> selber erzeugt. > Das hab ich auch schon probiert. Leider lief der Comiler nicht durch > und bewarf mich mit Fehlermeldungen, die ich nicht verstehe. Hmm, liegt vermutlich an fehlenden dev-Packeten, bei mir gehts problemlos. Was sind denn die Fehlermeldungen? Ich hänge an die mail mal noch die rtl8139.dsk Datei an. Das etherboot möchte mit 'dd if=bin/rtl8139.dsk bs=512 conv=sync of=/dev/fd0' auf die Floppy schreiben (interessant, conv=sync muss ich mir merken ;-) ). > Dummerweise hat man, wenn man die ROMs online holt, hinterher keine > Konfiguratinsdatei, sodass es extrem schwierig ist, nachzuvollziehen, > an welcher Option es nun hängt. > > Am 15.02.2005 um 17:33 schrieb Dirk Wenzel: >> mir scheint, daß die Aktualisierung der nfs-exporte auf meinem System >> nicht richtig funktioniert. (Debian-Woody mit custom-Kernel) > Zumindest dieses Problem ist verschwunden. Die "Lösung" ergab sich von > selbst, als ich probehalber das nfs-user-Paket installierte (und > natürlich das nfs-kernel-Paket deinstallierte). Danach waren > /var/lib/nfs/xtab und /var/lib/nfs/etab gelöscht und auch die > veralteten Infos des Kernels unter /proc/fs/nfs/exports verschwunden. > > Da mein Problem mit dem user-space-Dämon nicht gelöst war, installierte > ich den Kernel-space-Dämon wieder und seither wird tatsächlich > exportiert, was in der /etc/exports steht. > > Kein eleganter Weg, aber immerhin. Eine Erklärung kann ich allerdings > nicht liefern. > Da das Exportieren nun funktioniert, kann mein Client zumindest den vom > dhcp angegebenen Kernel (auch ohne tftp) laden, leider startet er aber > nicht. Ich verstehe immer noch überhaupt nicht, wozu Du zu diesem Zeitpunkt überhaupt nfs brauchen solltest. > > So bleiben noch die beiden Möglichkeiten. > > 1. Motherboard/NIC bringen es nicht. Ich tippe ganz stark auf die NIC. Du kommst nicht zufällig aus der Nähe von Heidelberg und könntest Dir so von uns eine verfünftige 3COM Karte ausborgen? > 2. Mit dem image stimmt was nicht. Auch möglich. Was macht denn das image, dass ich Dir bereitgestellt habe? Grüße, Bernd -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: etherboot /nfsexports
Hallo Bernd, danke für Deine ausführliche Antwort. Am 16.02.2005 um 02:05 schrieb Bernd Schubert: darf ich erst einmal fragen um welche Netzwerkkarten es sich handelt? Bei uns tuen 3com Karten problemlos. Wobei die älteren ohne Eeprom jetzt auf mit Eeproms aufgerüsted werden und wir dann nur noch PXE benutzen werden. Nur für die Karten ohne den Eeprom und somit ohne PXE Fähigkeit braucht man ja überhaupt das etherboot. Noch verwende ich eine rtl8139 noname-Karte ohne ROM. Das sollte nur dazu dienen, alles zu testen um später auf solche mit ROM umzusteigen. Lessdisks verwendet mit mknbi-linux markierte Kernel-Images. Wenn ich eine PXE-fähige Karte hätte, könnte ich sicher auch das verwenden. [...]irgendwo im Netz geistern aber etherboot Anleitungen herum, bei denen nicht der tftpd die Images bereit stellt, sondern das irgendwie über nfs geht. So genau wie das gehen soll und was es tut, stand aber immer nicht dabei. Ich hab sämtliche Howtos 5 mal auf und ab studiert und nix dazu gefunden. Dann noch zum Etherboot, ich habe noch nie den rom-o-matic benutzt, sondern mir immer die Disketten- und Lilo-Images aus den etherboot tar.gz Images selber erzeugt. Das hab ich auch schon probiert. Leider lief der Comiler nicht durch und bewarf mich mit Fehlermeldungen, die ich nicht verstehe. Dummerweise hat man, wenn man die ROMs online holt, hinterher keine Konfiguratinsdatei, sodass es extrem schwierig ist, nachzuvollziehen, an welcher Option es nun hängt. Am 15.02.2005 um 17:33 schrieb Dirk Wenzel: mir scheint, daß die Aktualisierung der nfs-exporte auf meinem System nicht richtig funktioniert. (Debian-Woody mit custom-Kernel) Zumindest dieses Problem ist verschwunden. Die "Lösung" ergab sich von selbst, als ich probehalber das nfs-user-Paket installierte (und natürlich das nfs-kernel-Paket deinstallierte). Danach waren /var/lib/nfs/xtab und /var/lib/nfs/etab gelöscht und auch die veralteten Infos des Kernels unter /proc/fs/nfs/exports verschwunden. Da mein Problem mit dem user-space-Dämon nicht gelöst war, installierte ich den Kernel-space-Dämon wieder und seither wird tatsächlich exportiert, was in der /etc/exports steht. Kein eleganter Weg, aber immerhin. Eine Erklärung kann ich allerdings nicht liefern. Da das Exportieren nun funktioniert, kann mein Client zumindest den vom dhcp angegebenen Kernel (auch ohne tftp) laden, leider startet er aber nicht. Aktiviere ich beim Erstellen des ROMs Unterstützung für PXE-, Tagged- und ELF, wird der tagged kernel geladen. Nachdem das beendet ist, wird wieder auf die Diskette zugegriffen. "Loading ROM ". Dann hängts. Ist PXE nicht aktiviert, kommt die altbekannte Meldung "Unable to load file". Das ist strange, da es sich ja nicht um PXEs handelt, sondern um mit mknbi-linux getaggede kernel. So bleiben noch die beiden Möglichkeiten. 1. Motherboard/NIC bringen es nicht. 2. Mit dem image stimmt was nicht. Das letztere werd ich heut noch überprüfen, indem ich einen neuen Kernel für die Clients kompiliere und mit mknbi-linux vorbereite. may contain nuts! Herzliche Grüße Dirk Wenzel _ may contain nuts!
