Hallo, >> stimmt, sonst wären wohl nicht alle Hardwareklassen betroffen. >> Vielleicht handelt es sich um irgendwelche Altlasten, die die >> Migrationsroutine aus grauer Vorzeit "herübergerettet" hat... > > Den Verdacht werde ich auch nicht so richtig los. Genauer gesagt, nachdem ich > gelesen habe, dass der betreffende Server von 4.0 -> 6.0 -> 6.1 gewachsen > ist, hat er sich sogar verstärkt.
.. ich glaub das nicht. Die Migration rettet vor allem die Daten und die Datenbanken. Dazu noch einige config Dateien. Ich kann mir nicht vorstellen, dass da ein "angeschossenes" linbo mit genommen wird: das wird auf dem Server neu installiert: ganz frisch, da bei 4.0 linbo 2.0 dabei war, bei 6.0 war es linbo 2.1 und bei 6.1 ist es linbo 2.2 > Hast Du seit dem ersten Schritt mal die Partitionsgrößen angepasst? In der > Historie der lmn wurde ja die Berechnung der Partitionsgrößen für SSDs > gegepasst, vielleicht liegt da der Hund begraben. das könnte natürlich sein, wobei isch mir auch nicht vorstellen kann, weswegen dann manchmal das linbo selbst zerschossen wird .. > Wenn es daran liegt, würde ich mal in einer start.conf alle Partitionen > minimal vergrößern (Teilbar durch 2048). Dann einen Rechner völlig platt > machen und mittles Linbo neubespielen. Was ich mir davon erhoffe: Die > Festplatte ist dann sauber hintereinander mit den Partitionen befühlt so wie > es Linbo erwartet. das würde ich auch mal machen: nur um das aus zu schließen, da ich nicht glaube, dass es daran liegt. Also paß mal die Größen so an: sda1 20992000 sda2 kannst du so lassen: ist schon ohne Rest durch 2048 Teilbar. Noch meine allgemeine Einschätzung der Lage: das Problem betrifft alle HWKs und es hat sonst niemand: es muß also irgendwo vor Ort liegen. Müßte ich raten, wo das Problem ist, würde ich so vermuten (Absteigende Wahrscheinlichkeit): 1) Manipulation durch Nutzer. Ja, das halte ich für das wahrscheinlichste. Ein Schüler hat herausbekommen, wie das linbopasswort ist und drückt auf "linbo", dann auf Partitionieren und währenddessen macht er den Rechner aus (wie sonst sollte der Cache unvollständig sein?) Alternativ bootet der Angreifer von einem USB Stick oder einer CD .. Abhilfe: - linbo Passwort ändern in der /etc/rsyncd.secret - BIOS Passwörter vergeben UND alles ausser Netzwerk und Festplatte aus der Bootreihenfolge nehmen. Hinweise: gibt es Rechner die nie Betroffen sind? Wo stehen die? Haben die ein BIOS Passwort? .. 2) Probleme im Netz: hier fehlt mir schon die Erklärung, wie das so auf den Client durchschlagen sollte, dass er Beschädigt wird: aber wer weiß. Tests: auf torretn umstellen und beobachten 3) Fehler in linbo: unwahrscheinlich, da es "so" keiner hat. Hier würde ich also Fehler in den configs annehmen. Da ich keine sehen kann, würde ich mal eine neue Hardwareklasse erstellen und danach nur die Partitionsgrößen und Imagenamen in der Defaultconfig ändern und dann nochmal versuchen. Das bezieht sich jetzt alles auf das: linbo cache wird Zerstört" Problem. Für das "booten durch Offlien Grub geht nicht" würde ich folgendes machen: 1) /var/linbo/menu.lst.hwk bereitstellen und auf Client spielen mittels sync wenn das nicht hilft: 2) Partitionsgrößen anpassen (siehe oben) und die Clients frisch ausrollen Wenn das nicht hilft: 3) mit neuer Partitionsgröße den Client von DC jooten->Rettungskonsole-> fixboot und fixmbr Dann ein neus Image ziehen. VIele Grüße Holger -- Mein öffentlicher PGP-key ist hier hinterlegt: pool.sks-keyservers.net _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
