Linbo regpatcher ab 4.0.13

Das hat jetzt auch bei uns an den ersten drei HW-Gruppen funktioniert.
Die Schritte waren folgende:

  • backup per zfs Snapshot
  • Upgrade auf diese Versionen von lmn71 und Linbo 4.0.23
  • umwandeln der cloop Images per
  • root@server:/srv/linbo# linbo-cloop2qcow2 metall_w10.cloop
  • im neu erstellen Verzeichnis, den vorhandenen Reg-Patch durch obigen ersetzt (natürlich ohne den Namen zu ändern)
  • da bisher beim Starten der Clients Linbo nicht selbständig ein Upgrade von Vers. 2.4 auf 4.x durchführt, immer jeweils 1x unter Vers. 2.4 partitioniert, Reboot, ein zweites mal unter der dann neu gezogenen Linbo Vers. 4.0.23 partitioniert, Reboot
  • erst nach diesen Prozessen per roten neuinstallieren Schaltfläche Windows 10 neu aufgespielt
  • bei den anschließenden Tests funktionierte der Domain Login und der Hostsname war der, den dieser Client per devices.csv bekommen soll

EDIT: Teil 2 meiner ToDo Liste:

  • nacheinander sämtliche cloop Images umwandeln
  • da ich hier von einer großen Schule mit zu vielen HW-Gruppen und noch mehr cloop Images spreche, brauchte ich eine Calc-Tabelle zum „abhaken“ und Dokumentieren
  • alle *.reg Datein neu schreiben, nach dem Schema:
    cat mustervorlage.reg > /srv/linbo/images/fujitsu_p900/fujitsu_p900.reg
  • sämtliche start.conf.HW-Gruppe Datein Umgeschrieben, „cloop“ in „qcow2“ geändert und evtl. den Autostart je nach Vorhaben, erst mal auf „no“
  • Aufgefallen ist mir dabei, dass der Server vor allem wegen der ganzen /usr/bin/ctorrent prozesse eine hohe Systemlast zeigte, auch noch mit vielen cloop prozessen
  • also aufräumen:
  • Verzeichnis „MÜLL“ erstellt und mit Befehlen wie den folgenden alles, was nicht mehr benötigt wird, also zB alles mit „cloop“ im Namen, dorthin verschoben
find /srv/linbo/ -name '*HW-Gruppe*' -exec mv -v -t /srv/linbo/MÜLL/ {} +
find /srv/linbo/ -name '*cloop*' -exec mv -v -t /srv/linbo/MÜLL/ {} +
  • Ebenfalls wieder per copy&past Dokumentiert
  • Da sich das Verzeichnis /srv/linbo langsam leert, bekommt man hier allmählich den Überblick was weg sollte und was nicht, dann noch mal:
linuxmuster-import-devices
systemctl restart linbo-torrent.service
update-linbofs
reboot
  • dann waren auch bei uns die letzten cloop Prozesse weg, siehe:

    Die Last der qcow2.torrent’s ist, weil sie neu sind, das lässt nach ein paar Minuten nach

Die nächsten Tage geht’s ans Verteilen an grob 600 Clients :wink:

OT: noch ein unbedingter Tipp für Leute, die per Remote unter Linux auf alles zugreifen können wollen, seit kurzen und nach einigen Posts mit einem der Entwickler, auch Multiuserfähig, in diesem Bereich klar das Beste: Ásbrú Connection Manager

Danke und Grüße,
gerd

2 „Gefällt mir“

Hallo Gerd,

Danke für die Zusammenfassung.
Jetzt wo du es sagst, erinnere ich auch Probleme mit dem upgrade von 2.4 auf 4.x am Client.
Ich meine, ich mußte auch unter 2.4 partitionieren (während schon 4 auf dem Server war).
Es hat aber auch gereicht einmal den Inhalt der Cachpartition per linbo-ssh komplett zu löschen.

rm -r /cache/*

LG

Hogler

nur eine kurze vielleicht abschließende Rückmeldung:
wir haben jetzt grob 95% der Clients, ganz grob ca. 500, nach obigem Schema umgestellt bekommen.
Die ein zwei Hand voll, die blöd gemacht haben, haben nichts mit dem Upgrade zu tun.
Wir mussten so gut wie alle -wie oben beschrieben- manuell zum Ziehen der 4er LINBO Version überreden, das funktinierte bei fast allen auch nach zwei Reboots nicht von allein.
Sprich: Gute Arbeit! Bei uns hat der Upgrade auf 7.1 sehr gut funktioniert, den Produktiven Test im Einsatz folgt ab Monatg :wink:

Grüße,
gerd

Hallo zusammen,
leider muss ich diesen Threat noch einmal hervor holen.
Ich habe gerade das Problem, dass alle Rechner (Win7 pro) eines Typs die Vertrauensstellung zur Domäne verloren haben.

Die Rechner wurden auf cqow2 umgestellt und sie laufen mit dem neuen Linbo. Danach sind sie noch gelaufen.

Nach ewigen suchen bin ich darauf gestoßen: Die image.reg sieht aus, wie oben, also z. B.
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters]
„Hostname“=„{$HostName$}“
„NV Hostname“=„{$HostName$}“

Ursprünglich war hier das s von services klein geschrieben. Übrigens: Ich glaube, klein ist richtig. In der Registry ist services klein geschrieben. Nun habe ich genau das Problem, dass die o. g. Fehlermeldung beim Durchlaufen des reg Patches kommt:

— Import KEY <\ControlSet001\Services\Tcpip\Parameters> add_key: key Services already exists!
trav_path: Error: Not a ‚nk‘ node!
add_key: current ptr not ‚nk‘
trav_path: Error: Not a ‚nk‘ node!
add_key: current ptr not ‚nk‘

END OF IMPORT, file </tmp/reg.2674.02>, operation FAILED!
1 keys
0 new keys added
0 values total

Dabei ist es völlig egal, ob s klein oder groß ist. Wozu führt das nun? Der Rechner hat an manchen Stellen den richtigen Namen. Ich kann mich z. B. mit 304-pc12\admin lokal anmelden. Wenn man aber in die Systemsteuerung schaut, dann ist der Computername der Computer, der das Image gebaut hat. In meinem Fall 304-pc01. Damit ist klar, wo mein Problem plötzlich herkommt. 42 Rechner, darunter 304-pc01 laufen mittlerweile auf Win 11 pro. D. h. er versucht, sich mit dem Konto eines Rechners anzumelden, den es „so“ nicht mehr gibt. Sprich: Unter Win11 hat er ein anderes Konto.

Wenn ich in der Registry in Tcpip\Parameters den Rechnernamen 2x ändere, dann klappt wieder mit der Anmeldung.

Als workarround baue ich gerade ein Image mit einem Rechner, den es noch gibt und hoffe, dass sich dann alle anderen Rechner mit dessen Konto an der Domäne anmelden.

Kann es evtl. so gelaufen sein: Unter Win 7 schreibt man services klein. Unter Win 10 groß. Damit dass mit den alten reg Files klappt, wird das s im Hintergrund nun immer groß gemacht, obwohl es für Win 7 klein sein müsste.

Kann ich evtl. im postsync etwas machen, damit diese beiden Hostnamen wieder gesetzt werden?
Gruß,
Markus

Hallo Markus,

ersetz doch mal deine image.reg durch eine frische aus der Vorlage …

LG

Holger

H Holger,
ich habe doch die obige reg. (mit diff überprüft) Ok, mit einem Zusatz am Ende.

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation]
„RealTimeIsUniversal“=dword:00000001

In der Vorlage in meinem linbo/examples ist …services… klein geschrieben und war es bei mir auch. Egal ob klein oder groß: Wie bei Dir damals klappt alles. Ich habe heute jeden Eintrag nach dem Hochfahren überprüft. Nur die beiden Hostnamen im …services… Pfad werden mit genau der Fehlermeldung die Du auch hattest nicht gesetzt.

Meine Theorie: Im Hintergrund guckt ein Programm, dass Services groß geschrieben ist, was bei Win 10 auch richtig ist, aber eben bei Win7 nicht. Irgendwie lese ich das bei Thomas zwischen den Zeilen. Ich kann mich natürlich irren und das Problem sitzt wo anders.

Eine andere win7 reg habe ich nicht in linbo/examples.

Gruß,
Markus

Liebe Kollegen, Hallo Thomas,
meine Vermutung war richtig:

Thomas hat es ja oben angedeutet:
Auf den Clients gib es in Linbo /usr/ die Datei linbo_patch_registry

Offensichtlich wird dort geprüft, ob in der .reg Datei auf dem Server diverse Namen groß geschrieben sind. Aus services wird Services.

Wir haben noch weit über 100 Rechner mit Win 7, die natürlich nun Stück für Stück ersetzt werden. Aber bei diesen Rechnern ist in der Registry services klein geschrieben und nicht wie bei Windows 10 groß.

Daher meine Bitte an Thomas: Diese Korrektur für Services muss raus. Ich habe es gerade probiert. Wenn ich diese eine Zeile (Services) in linbo_patch_registry lösche, dann wird der Patch ausgeführt.

Der obige Fehler ist dann weg und die Rechner haben den richtigen Namen. So haben sie nun in der Domäne alle den gleichen Namen, der vom Musterrechner stammt.

Wie gesagt es geht um …CurrentControlSet\services\Tcpip.… für Win 7.

Gruß,
Markus

P. S. Liest Thomas automatisch mit, oder muss ich ihn direkt anschreiben?

Hallo Markus,

Wir haben noch weit über 100 Rechner mit Win 7, die natürlich nun Stück
für Stück ersetzt werden. Aber bei diesen Rechnern ist in der Registry
services klein geschrieben und nicht wie bei Windows 10 groß.

Daher meine Bitte an Thomas: Diese Korrektur für Services muss raus.

… ich bezweifle dass das so einfach geht: die Korrektur steht da ja
nicht umsonst drin.
Nehmen wir die raus, dann bekommen andere mit Win10 Probleme …
Ich erinnere mich nämlich an Probleme mit dem regpatcher bei Tests mit
linbo 4.1 und die hat Thomas dann, unter anderem mit dieser Korrektur,
behoben.
Mit win 7 hat das niemand getestet: das war zum Zeitpunkt der Tests
schon seit 3 Jahren aus dem Support raus.

P. S. Liest Thomas automatisch mit, oder muss ich ihn direkt anschreiben?

er liest manchmal hier. Aber was du willst ist eine Änderung an linbo:
das gehört in GitHub.
… ich würde es als Featurerequest ansehen, nicht so sehr als Bug.

LG

Holger

Hi Holger,
ich finde, da machst Du es Dir etwas leicht. Die 42 neuen Rechner, die wir bekommen haben, sind das Kontingent für zwei Jahre! Es gibt eben Städte, die „pleite“ sind. Ich werde auch noch morgen mit Windows 7 Rechner leben müssen. Einfach zu sagen: Da gibt es Leute, die haben uralte reg Dateien. Da ist das Wort services klein geschrieben, müsste aber für Windows 10 groß geschrieben werden. Also was machen wir: Wir ändern das nicht in der reg Datei, sondern machen das im Background groß und hauen alle raus die noch Windows 7 haben… Ich kann mir nicht vorstellen, dass das Absicht war. Das war eben ein Versehen. Und ja: Die mit Windows 10 + müssten eben mal schauen, ob auch wirklich das Services mittlerweile groß geschrieben ist. Das wäre wenn man die Information bekommt sicher machbar.

Habe ich überhaupt eine Alternative: Ich lese mich gerade durch das Thema registry und postsync. Ich blicke aber bei den Beispielen nicht durch. Wenn es einen Zusatz für die Postsync gäbe, der diese beiden Registry patches macht, dann könnte ich damit leben. Kann da evtl. jemand helfen.

Oder habe ich selbst die Möglichkeit? Kann ich diese Datei linbo_patch_registry, die via linbo auf allen Geräten landet händisch ändern. Dann müsste man bei jedem Update wieder ran, aber auch das wäre zur Not machbar.

Auf jeden Fall brauche ich eine Lösung.

Gruß,
Markus

Ich habe mich jetzt hingesetzt und versucht, zu verstehen was reged ist und macht.

Nun habe ich eine Lösung für mich - wie gesagt es geht um Windows 7 für die postsync Datei:

cmd=„cd ControlSet001\services\Tcpip\Parameters\ned Hostname\n$HOSTNAME\ned NV Hostname\n$HOSTNAME\nq\ny\n“
hive=„/mnt/Windows/System32/config/SYSTEM“
echo -e „$cmd“ | reged -e „$hive“

Hier wird aus dem service kein Service gemacht und die Recher haben am Ende den richtigen Namen.

Gruß,
Markus

Hallo zusammen,

spielt vermutlich keine Rolle, aber ich finde, Markus hat hier schon einen Punkt.

Es gibt offenbar fehlerhafte Reg-Vorlagen und darum wird HART eine Änderung in den Regpatcher kodiert, die das Ganze unter Win7 nicht mehr nutzbar macht? Und Betroffene müssen das 1) herausfinden und 2) sich eine Krücke basteln, um das zurückzunehmen?

Die richtige Vorlage und meinetwegen ein Test des aktuellen Regpatches (z.B. bei linuxmuster-import-devices) mit entsprechendem Hinweis („Sie benutzen noch die Schreibweise für Win7 - soll der Regpatch korrigiert werden“) scheint mir die nachhaltigere und freundlichere Lösung.

In jedem Fall gut, dass Du einen alternativen Weg gefunden (und hier gepostet) hast.

Viele Grüße
Thomas

Das sehe ich genauso. Was mir auch in den Sinn kam: Wie wäre es mit einer Mailling Liste für Notfälle und Updates. Mir geht es so: Wenn es läuft, schaue ich doch nicht „tätglich“ hier hvorbei. Was echt Klasse wäre: Man meldet sich als Admin bei einer Mailingliste an und wenn es etwas wichtiges gibt, wenn man wegen eines Bugs etwas machen muss, oder auch ein Hinweis auf neue Funktionen, dann bekommt man eine Mail. Das wäre echt Klasse.

Gruß,
Markus

Ja. So funktioniert das hier. Seit 20 Stunden gibt es einen Issue dazu. WTF?

Nein, ich lese hier nicht alles mit, da ich in meiner Freizeit gerne auch noch was anderes mache als vor dem Rechner zu sitzen.

Manchmal ist es echt schwer, sich für das Projekt zu motivieren.

VG, Thomas

2 „Gefällt mir“

Windows 7 ist seit 3 Jahren aus dem Support und wird somit von Linuxmuster nicht mehr supported. Wenn es noch funktioniert, ist das Glück.

Hallo, Rupprecht -

Frage: wir haben ebenfalls Rechner von der Stadt Mönchengladbach mit Windows 7 erhalten und dann recht problemlos die kostenlose Upgrade Möglichkeit auf Windows 10 genutzt, die meines Wissens nach auch heute noch so funktioniert. Würde das bei euch nicht gehen?
L.G. Christoph G.

Hallo Christoph,

Wir haben von einem großen Unternehmen Rechner mit von denen ungenutzten Windows 7 Professional Aufklebern und mit im BIOS eingebrannter Windows 8 Lizenz bekommen. Beide lassen sich problemlos mit Windows 10 oder Windows 11() aktivieren. Falls nicht alle Hardware erkannt wird, kannst Du die dieser die Treiber für Windows 7 (nicht 8!) „von Hand“ unterjubeln. Es gibt nur wenige Grafikkarten wie Intel GMA 950 oder ATI Radeon X1300, für die es nur 32-Bit-Treiber gibt. Wenn 1024768 genügt und Du keine 3D-Beschleunigung braucht, laufen die mit dem Microsoft Standard Treiber.
Windows 7 solltest Du nicht mehr einstzen (müssen).

Gruß Jürgen

(*) Aktuell kann ich alle Einschränkungen von Windows 11 gegenüber Windows 10 z. B. mit Rufus überwinden.

Hallo Christoph,
ich will ehrlich sein: Ich hatte keine großen Bedenken wegen der Sicherheit von Windows 7. Es mag sein, dass das eine falsche Sicherheit ist, in der ich mich da wegen Linbo wiege… Es ist aber so.

Hinzu kommt: Mit der Software, die wir brauchen, laufen die Kisten „perfekt“.

Zu guter letzt und neben „Never change a running system“: Ich hatte mal ein paar Windows 7 Notebooks neu aufzusetzen und bin dann tatsächlich zu Win 10 und ganz schnell wieder zurück zu 7. Mein Eindruck war: Von Windows Version zu Windows Version braucht man eben mehr Power (und vor allem RAM) und wenn es da fehlt, wird man einfach nicht froh.

Ich denke, dass war der Hauptausschlag, dass ich in Richtung Windows 10 nichts unternommen habe.

Wenn ich ein bisschen Zeit habe, werde ich es vielleicht nochmal mal testen…

Gruß,
Markus

Lieber Rupprecht,

hmm…, Ich kenne diese Bedenken bezüglich eines Upgrades, bei dem man hinterher mehr Ärger hat als vorher. Meine Erfahrung nach aber laufen Windows 10 Kisten etwas stabiler als Windows 7-Rechner. Zum Teil scheint auch die Speicherverwaltung optimiert zu sein, so dass man vermutlich ähnliche positive Effekte erzielt wie ab und zu bei einem linux-kernel-Upgrade.
Ich würde es mal testen…

L.G.

Hallo Christoph,

Für Windows 10 64-bit oder 11 brauchst Du mindestens 4 GB RAM und zwei Prozessorkerne. Eine SSD wäre auch gut. Unter diesen Bedingungen läuft es zumindest nicht schlechter als Windows 7 und viel besser als Windows 8 (Hatte das überhaupt wer im Einsatz?).
Für Windows 7 32-bit reichen auch 2 oder 3 GB. Mehr kann es eh nicht nutzen. Windows 10 32-bit finde ich auf solcher Hardware nicht brauchbar.

Gruß Jürgen