Client bootet weiter trotz linbo-remote

Cgsman · 28. Februar 2017 um 08:03

Hallo,

ich fahre gerade die LM 6.2 mit linbo 2.3 und Linuxclients (14.04 und 16.04 versuchsweise auf einer Platte, sonst kein BS).
ich muss vor jedem Absetzen der linbo-remote-Befehle (z.B. des sehr nützlichen … -c format, initcache,…) die /var/linbo/boot/grub/[Gruppenname].cfg editieren und den “Default” auf 0 stellen, damit nach linbo gebootet und gewartet wird.
Nach meinem Verständnis des linbo-remote-Ablaufs sollte das doch selbstständig von linbo-remote erledigt werden - oder?

Übrigens hat dieses Anhalten und auf linbo warten noch nie funktioniert. Der Rechner bootet immer daran “vorbei”.
Kann da jemand helfen ?

Gruß Christoph Gü.

baumhof · 28. Februar 2017 um 09:02

Hallo Christoph,

ich fahre gerade die LM 6.2 mit linbo 2.3 und Linuxclients (14.04 und
16.04 versuchsweise auf einer Platte, sonst kein BS).
ich muss vor jedem Absetzen der linbo-remote-Befehle (z.B. des sehr
nützlichen … -c format, initcache,…) die
/var/linbo/boot/grub/[Gruppenname].cfg editieren und den „Default“ auf 0
stellen, damit nach linbo gebootet und gewartet wird.
Nach meinem Verständnis des linbo-remote-Ablaufs sollte das doch
selbstständig von linbo-remote erledigt werden - oder?

ja.
Bitte schick mal die linbo-remote Zeile, die du verwendet hast.

Übrigens hat dieses Anhalten und auf linbo warten noch nie funktioniert.
Der Rechner bootet immer daran „vorbei“.

also auch schon bei linbo 2.2?

Kann da jemand helfen ?

versuch mal
linbo-remote -p sync:1,start:2 -i

Das weckt den Client nicht auf, sollte ihn aber dazu veranlassen beim
nächsten Starten einmalig die angegebenen Befehle aus zu führen.
Du kannst ihn dann mit etherwake wecken.

Viele Grüße
Holger

Cgsman · 28. Februar 2017 um 11:21

Hallo, lieber Holger:

Meine Zeile:
linbo-remote -i pc21 -w75 -c partition,format,initcache,sync:1,sync:2,halt

Und ja: Das Problem existiert seit Linbo 2.2

Jetzt hab ich eben mal den Rechner mit Deiner Zeile vorbereitet…
Erst hab ich die entsprechende .cfg zurückgestellt auf Autostart…
Dann hab ich den Rechner mit linbo-remote -w 10 -i [Hostname] geweckt…
Ok - das geht nicht: Hier läuft er an der linbo-remote-Vorbereitung vorbei !
Jetzt mal wieder schlafen gelegt und nach einem erneuten
"linbo-remote -p usw." mit etherwake geweckt…
Klappt gar net !
Jetzt mal mit wakeonlan …
Rechner wacht auf, rennt aber wieder weiter durch !

Also, Resumee:
Wenn der Rechner keinen Autostart macht, sondern in linbo stehenbleibt, akzeptiert er die linbo-remote-Befehle, die man dann abschickt.

Schade !
L.G.
Christoph

crazy-to-bike · 28. Februar 2017 um 12:38

Hallo Christoph,

Meine Zeile:
|linbo-remote -i pc21 -w75 -c partition,format,initcache,sync:1,sync:2,halt|

partition und format sind redundant (bei partition wird auch
formatiert). nach -w sollte ein Leerzeichen sein.
Wait von 75 ist recht lang, vielleicht reicht weniger?

Wenn du nicht jedes Mal neu partitionieren willst, würde ich mal

linbo-remote -i pc21 -w 40 -c format,sync:1,sync:2,halt

nehmen. Ich denke zwar nicht, dass es dein eigentliches Problem löst,
aber wer weiß…

Also, Resumee:
Wenn der Rechner keinen Autostart macht, sondern in linbo
stehenbleibt, akzeptiert er die linbo-remote-Befehle, die man dann
abschickt.

Ich hab auch autostart aktiviert. Allerdings endet meine Zeile auf
start:1, nicht auf halt, da ich so morgens so immer die Rechner aufwecke
und synchronisiert starten lasse.

Ob ein Rechner trotz Autostart in der start.conf das halt macht, müsste
ich mal testen.

Viele Grüße
Steffen

baumhof · 28. Februar 2017 um 14:23

Hallo Christoph,

Meine Zeile:
|linbo-remote -i pc21 -w75 -c partition,format,initcache,sync:1,sync:2,halt|

ich halte 75 auch für sehr Groß: das sollte aber irrelevant sein.

Soweit ich weiß, ersetzt linbo-remote temporär die start.conf des zu
bootenden CLients: das funktioniert beiu euch offensichtlich nicht.
Da ich niemand kenne, bei dem dieses Problem auftritt, liegt es wohl in
eurem System.

Kannst du mal die Ausgabe von
ls -al /var/linbo/
posten?

Du kannst ja die Imagedateien rauslöschen.

VIele Grüße

Holger

Cgsman · 28. Februar 2017 um 21:32

Lieber Holger,

nach der Eingabe eines linbo-remote-Befehls mit -p und erfolgreicher Rückmeldung, aber keiner Abarbeitung sieht das Verzeichnis so aus:

22:25/0 server /var/linbo # ls -al
    insgesamt 55559128
    drwxr-xr-x 13 root root       16384 Feb 28 22:24 .
    drwxr-xr-x 17 root root        4096 Jan 15 16:50 ..
    drwxr-xr-x  3 root root        4096 Sep  4 21:32 backup
    drwxr-xr-x  3 root root        4096 Sep  4 13:21 boot
    drwxr-xr-x  2 root root        4096 Feb 26 21:59 examples
    -rw-r--r--  1 root root        2823 Feb 17 13:08 german.kbd
    -rw-rw-r--  1 root root  8009366169 Apr 24  2016 HULC-7.cloop
    -rw-rw-r--  1 root root          17 Apr 24  2016 HULC-7.cloop.desc
    -rw-rw-r--  1 root root         131 Apr 24  2016 HULC-7.cloop.info
    -rw-------  1 root root         158 Apr 24  2016 HULC-7.cloop.macct
    -rw-rw-r--  1 root root      611282 Apr 24  2016 HULC-7.cloop.torrent
    drwxr-xr-x  2 root root        4096 Feb 26 21:59 icons
    -rw-r--r--  1 root root          59 Sep 12 10:34 last_registered
    -rw-r--r--  1 root root     3351680 Feb 17 13:06 linbo
    -rw-r--r--  1 root root     3454592 Feb 17 13:07 linbo64
    -rw-r--r--  1 root root          33 Feb 17 13:08 linbo64.md5
    drwxr-xr-x  2 root root        4096 Feb 28 11:07 linbocmd
    -rw-r--r--  1 root root    18769440 Feb 26 22:01 linbofs64.lz
    -rw-r--r--  1 root root          33 Feb 26 22:01 linbofs64.lz.md5
    -rw-r--r--  1 root root    17552980 Feb 26 22:00 linbofs.lz
    -rw-r--r--  1 root root          33 Feb 26 22:00 linbofs.lz.md5
    -rw-r--r--  1 root root    17236995 Feb 26 22:00 linbofs-np.lz
    -rw-r--r--  1 root root          33 Feb 26 22:00 linbofs-np.lz.md5
    -rw-r--r--  1 root root   180355072 Feb 26 22:02 linbo.iso
    -rw-r--r--  1 root root          33 Feb 17 13:08 linbo.md5
    -rw-r--r--  1 root root     3321456 Feb 17 13:07 linbo-np
    -rw-r--r--  1 root root          33 Feb 17 13:08 linbo-np.md5
    -rw-r--r--  1 root root          15 Feb 17 13:08 linbo-version
    drwxr-xr-x  5 root root        4096 Feb 26 23:06 linuxmuster-client
    drwxr-xr-x  2 root root        4096 Feb 26 21:59 linuxmuster-win
    lrwxrwxrwx  1 root root          24 Nov 18 14:40 log -> ../log/linuxmuster/linbo
    -rw-rw-r--  1 root root    15601723 Apr 25  2016 Logisim.rsync
    -rw-rw-r--  1 root root          30 Apr 25  2016 Logisim.rsync.desc
    -rw-rw-r--  1 root root         123 Apr 25  2016 Logisim.rsync.info
    -rw-------  1 root root         158 Apr 25  2016 Logisim.rsync.macct
    -rw-rw-r--  1 root root        1399 Apr 25  2016 Logisim.rsync.torrent
    drwxr-xr-x  7 root root        4096 Nov 20 17:45 mkubuntu4
    -rw-r--r--  1 root root         124 Jan 15 16:52 multicast.list
    -rw-r--r--  1 root root         124 Jan 15 16:30 multicast.list.old
    -rw-r--r--  1 root root         143 Feb 26 22:02 start.conf
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.51 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.52 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.54 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.55 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.56 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.57 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.58 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.59 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.60 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.61 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.62 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.63 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.64 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.66 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.67 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.68 -> start.conf.hyundai
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.69 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.1.70 -> start.conf.plasma1
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.6.2 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.17 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.18 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.19 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.20 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.21 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.22 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.23 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.24 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.25 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.26 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.27 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.28 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.29 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.30 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.41 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.42 -> start.conf.ganzneu
    lrwxrwxrwx  1 root root          18 Feb 27 23:06 start.conf-10.16.8.43 -> start.conf.ganzneu
    -rw-r--r--  1 root root         105 Sep  7 12:17 start.conf.default
    -rw-r--r--  1 root root        4363 Feb 28 08:50 start.conf.ganzneu
    -rw-r--r--  1 root root         838 Jan 19  2016 start.conf.gruppe1
    -rw-r--r--  1 root root        5306 Feb 26 23:00 start.conf.hyundai
    -rw-r--r--  1 root root        4106 Nov 27 19:47 start.conf.plasma1
    -rw-r--r--  1 root root        6707 Sep  4 13:22 start.conf.schuelerpc
    -rw-r--r--  1 root root        3553 Feb 26 22:54 start.conf.xenial
    drwxr-xr-x  2 root root        4096 Nov 18 14:38 torrentadds
    -rw-r--r--  1 root root          86 Jan 15 16:52 torrent-client.conf
    drwxr-xr-x  3 root root        4096 Nov 20 17:45 trusty

Daran erkenne ich nix Auffälliges…
Apropos Autostart: Da hab ich mich schon seit Erscheinen von linbo 2.3 gefragt, ob der Autostart-Mechanismus aus der start.conf (nur) mittels dem befehl import_workstations in die /var/linbo/boot/grub/[gruppe].cfg eingebaut wird ?

Grüßle,
Christoph

Tobias · 1. März 2017 um 07:32

Hallo Christoph,

kann es sein, dass linbo tut, was es soll, aber danach (wie in start.conf angewiesen) einen Autostart macht?
Es gibt eine explizite Option für „-p“ die heißt „-n“:

-n                 Bypasses a start.conf configured auto functions
                    (partition, format, initcache, start) on next boot.
                    To be used together with option -p.

Das löst nicht das Problem, dass „-c“ Befehle nach dem Aufwecken mit „-w“ scheinbar nicht beim Client abgesetzt werden.
Meldet denn linbo-remote -w 75 -c befehl auch OK oder failed?
VG, Tobias

Cgsman · 7. März 2017 um 22:01

Hallo,
Danke bislang für alle Hilfestellungen.
Ich melde mich wieder, wenn ich substantiell weiter gekommen bin und es etwas Berichtenswertes gibt! Grüße,
Christoph

baumhof · 7. März 2017 um 22:31

Hallo Christoph,

nach der Eingabe eines linbo-remote-Befehls mit -p und erfolgreicher
Rückmeldung, aber keiner Abarbeitung sieht das Verzeichnis so aus:
|22:25/0 server /var/linbo # ls -al
insgesamt 55559128

Daran erkenne ich nix Auffälliges…

… ich auch nicht …
Wir hatten es schon mal, dass jemand eine screen session auf einen
linbo-remote laufenden Client mittels
strg+c
abgebrochen hat und nicht mittels strg+a+d
Dann war der linbo-remote Betrieb für diesen Cleint gestört…

Apropos Autostart: Da hab ich mich schon seit Erscheinen von linbo 2.3
gefragt, ob der Autostart-Mechanismus aus der start.conf (nur) mittels
dem befehl |import_workstations| in die
|/var/linbo/boot/grub/[gruppe].cfg| eingebaut wird ?

ja: import ist nötig, wenn du es in die .cfg Datei nciht selber einträgst.
Trägst du selber ein und löschst die Zeile

### managed by linuxmsuter

dann wird die Änderung beim nächsten import Lauf zurückgesetzt.

LG

Holger

baumhof · 7. März 2017 um 22:35

Hallo Christoph,

Ich melde mich wieder, wenn ich substantiell weiter gekommen bin und es
etwas Berichtenswertes gibt! Grüße,

… jetzt müssen wir ein wenig weiter suchen.
Meine Ideen sind gerade folgende:

logdateien durchstöbern syslog, linbo logs …
mal einen Client in eine neue HWK verschieben, die es noch nicht
gibt. Beim import_workstations legt linbo die start.conf frisch an.
In diese start.conf dann von Hand die Partitionen aus der alten
übertragen und die Imagenamen.
Dann nochmal linbo-remote versuchen.
mal linbo purgen und wieder installieren.
Dabei ist zwar bei mir noch nie was schief gegangen, aber ein Backup ist
immer eine gute Idee

apt-get update
apt-get purge linuxmuster-linbo
apt-get install linuxmsuter-linbo

Vielelicht reißt das den tftp Dämon mit: der kommt aber auch wieder …

LG

Holger

Tobias · 8. März 2017 um 00:16

Hallo Christoph,

mal noch was ganz BAnales: hast du den Client auf PXE-Boot gestellt? Falls nein, dann bootet der Rechner immer von der Platte und linbo-remote Befehle kommen nie bei ihm an.
Linbo-remote steuert nur PXE-Rechner.

vG, Tobias

Cgsman · 8. März 2017 um 10:12

Hallole,
danke Tobias,natürlich, das war klar !
Aber hier, bei der Funktionalität mit der start.conf.irgendwas finde ich es problematisch - wenn auch “historisch” erklärbar - dass man dort einerseits Funktionen eintragen kann, die sofort wirken, sofern der client auf PXE-Booten eingestellt wurde, z.B. AutoInitCache=yes oder die Partitionierung.
Andererseits werden ganz offensichtlich nur bei dem Befehl “import-workstations” die GRUB-Startkonfigurationen aus der start.conf neu geschrieben. Das ist insofern verwirrend, weil man a) hier also in eine Art .ini-Datei etwas hineinschreibt, es aber durch das Abarbeiten eines Scriptes erst wirksam macht, während anderes sofort wirksam ist und b) der Befehl “import_workstations” nichts Inhaltliches mit dem Verändern der GRUB-Konfiguration zu tun hat.
Ich fände es besser und klarer, wenn man den Script-Teil, der die /var/linbo/boot/grub/heididei schreibt, in ein zweites Script auslagert, das man "write_boot_config heididei"taufen und für sich aufrufen könnte.
(Ich weiß nicht, ob so recht klar wird, was ich meine…)

L.G.
Christoph Gü.

baumhof · 8. März 2017 um 10:55

Hallo Christoph,

Aber hier, bei der Funktionalität mit der start.conf.irgendwas finde ich
es problematisch - wenn auch „historisch“ erklärbar - dass man dort
einerseits Funktionen eintragen kann, die sofort wirken, sofern der
client auf PXE-Booten eingestellt wurde, z.B. |AutoInitCache=yes| oder
die Partitionierung.
Andererseits werden ganz offensichtlich nur bei dem Befehl
„|import-workstations|“ die GRUB-Startkonfigurationen aus der start.conf
neu geschrieben. Das ist insofern verwirrend, weil man a) hier also in
eine Art .ini-Datei etwas hineinschreibt, es aber durch das Abarbeiten
eines Scriptes erst wirksam macht, während anderes sofort wirksam ist
und b) der Befehl „|import_workstations|“ nichts Inhaltliches mit dem
Verändern der GRUB-Konfiguration zu tun hat.
Ich fände es besser und klarer, wenn man den Script-Teil, der die
|/var/linbo/boot/grub/heididei| schreibt, in ein zweites Script
auslagert, das man "|write_boot_config heididei|"taufen und für sich
aufrufen könnte.
(Ich weiß nicht, ob so recht klar wird, was ich meine…)

ich habs verstanden

Dass die grub.cfg beim import_workstations geschreiben wird, ist ein
komfortfunktion: sie wurde als „aus der anderen Richtung“ gedacht.
Wir wollten nämlich, im Gegensatz zu früher, alles in einer Datei managen.
Dein Vorgehen und auch das „eine Datei“ Vorgehen haben Vorteile und
Nachteile.
Mein Vorschlag: mach doch immer ein import_workstations nach Änderungen
an der start.conf.
So mache ich das und so kommuniziere ich das auch

LG

Holger

Cgsman · 26. März 2017 um 21:37

So,
das Problem geht leider weiter:

Habe heute in der start.conf.<gruppe> alle Autostarts deaktiviert und in der /var/linbo/boot/grub/<gruppe>.cfg den default auf linbo (also 0) gestellt.

Dann die Rechner mit dem Kommando

linbo-remote -g <gruppe> -w 80 -c sync:1,sync:2,halt

gestartet.
(Heitere Erfahrung nebenbei: Verwendet man statt der Kommata ein Semikolon, wendet die bash den abschließenden halt-Befehl auf den Server an und fährt ihn brav herunter. Ist mir natürlich zweimal passiert…)

So, und nun schien es zu klappen: Rechner bleiben im Linbo stehen, die Schaltflächen sind ausgegraut - und dann passiert - NICHTS !

ABER: Wenn ich mich per linbo-ssh auf den Rechnern einlogge, zeigt die Prozessliste, dass die Sync-Befehle (angeblich) laufen, denn sie werden angezeigt und der linbo_wrapper weigert sich auch, diese Befehle nochmal anzunehmen - sie liefen ja schließlich.
Tatsache aber ist: Es tut sich nichts (die Festplatte zeigt keine Aktivität an !).
Das ist doch merkwürdig !
Vielleicht sollte ich tatsächlich linbo nochmal komplett nachinstallieren, wie von Dir, Holger, vorgeschlagen !

(…to be continued…)

Grüße,
Christoph G.

baumhof · 27. März 2017 um 06:45

Hallo Christoph,

|linbo-remote -g -w 80 -c sync:1,sync:2,halt|

gestartet.
(Heitere Erfahrung nebenbei: Verwendet man statt der Kommata ein
Semikolon, wendet die bash den abschließenden halt-Befehl auf den Server
an und fährt ihn brav herunter. Ist mir natürlich zweimal passiert…)

So, und nun schien es zu klappen: Rechner bleiben im Linbo stehen, die
Schaltflächen sind ausgegraut - und dann passiert - NICHTS !

… tatsächlich?

ABER: Wenn ich mich per |linbo-ssh| auf den Rechnern einlogge, zeigt die
Prozessliste, dass die Sync-Befehle (angeblich) laufen, denn sie werden
angezeigt und der linbo_wrapper weigert sich auch, diese Befehle nochmal
anzunehmen - sie liefen ja schließlich.

… und woraus schließen wir, dass linbo an dieser Stelle nciht recht hat?

Tatsache aber ist: Es tut sich nichts (die Festplatte zeigt keine
Aktivität an !).

je nach Cache der Platte und Geschwindigkeit des Netzwerkes blinkt die
Platte eher selten, so lange das Image gezogen wird…

Das ist doch merkwürdig !

… naja: nicht soo sehr…

Vielleicht sollte ich tatsächlich linbo nochmal komplett
nachinstallieren, wie von Dir, Holger, vorgeschlagen !

… ich würde warten.
Vielleicht klappt auch gerade einfach der torrent seed vom Server aus
nicht, weswegen die CLeints 120 Sekunden lang versuchen, das Image per
torrent zu bekommen und dann erst weiter machen: so lange passwirt am
Client tatsächlich „nichts“.

Also bitte mal folgendes machen:

Cleint wecken wie oben, also mit:
linbo-remote -g -w 80 -c sync:1,sync:2,halt
Aber ohne Semikola (ist mir auch schon passiert)
Cleint „betrachten“ mittels screen: das geht am Server so:
screen prozessID herausbekommen mittels:
linbo-remote -l

Auf Screen verbinden:
screen -r

Wichtig: screen nur verlassen mittels
strg+a+d
und nicht strg+c

Was steht da, während der Cleint „nichts“ macht?

Was steht den in den logs?

LG

Holger

Cgsman · 2. April 2017 um 21:05

Hallo, Holger,

so, jetzt hab ich das von Dir Vorgeschlagene realisiert - DU hast recht ! (Man kann das Problem als gelöst ansehen).

Erkenntnisse für (vielleicht nicht nur) mich:

Damit meine Rechner in Linbo stehenbleiben, ist es zwingend vonnöten, die Autostarts in der start.conf zu deaktivieren, den Autoinitcache in der start.conf zu aktivieren und dann ein import_workstations auszuführen - ODER in der .cfg unter /var/linbo/boot/grub/ den default auf 0 zu setzen, damit die Kisten in Linbo stehenbleiben und hier “auf ihren Meister warten”.
Wenn man zuguckt, sieht man dann die ausgegrauten Schaltflächen aller BS auf den LINBO-Bildschirmen, ABER KEINE MELDUNGEN in der Konsole darunter. (Zumindest bei mir bis zum ausgeführten initcache bleibt das schwarz).
Daher nahm ich fälschlicherweise an, dass sich da nichts tun würde.
Aber mit dem Beobachten der screens bekommt man genau gezeigt, was Sache ist. Dass dabei übrigens ein “ntfsclone” (oder war’s “ntfsresize” ?) sehr lange mit dem verdächtigen Attribut “D” (=“uninterruptable sleep”) zu sehen ist, wenn man sich mit linbo-ssh einloggt und die Prozessliste anzeigen lässt, hat dann wohl nichts Negatives zu bedeuten.

Super - Problem gelöst -
ein Trulala dem Holga’

Gruß Christoph Gü.