Linbo 4/Linbo GUI: Image kann nicht hochgeladen werden / Kein Image gefunden

garblixa · 29. Dezember 2021 um 14:47

Hallo,

ich erstelle ein neues Image mit „Erstellen und Hochladen“. Das Image wird im Cache erstellt, aber nicht hochgeladen. Wenn ich das Image nachträglich hochladen will, erscheint bei „Hochzuladendes Image“ → Kein Image gefunden.

Linbo 4.0.4-0

devices.csv

# grep r012-pc01 /etc/linuxmuster/sophomorix/default-school/devices.csv
fachraum-s;r012-pc01;win10_sata_s;D8:50:E6:BF:F2:AA;10.0.11.6;;;;classroom-studentcomputer;;1;;;;;

start.conf.win10_sata_s

[LINBO]
Server = 10.0.0.1
Group = win10_sata_s
...
[OS]
Name = Windows 10
Version = 21H2
Description = Windows 10 21H2
IconName = win10.svg
Image =
BaseImage = win10_21H2_s.qcow2
Boot = /dev/sda3
Root = /dev/sda3
Kernel = auto
Initrd =
Append =
StartEnabled = yes
SyncEnabled = yes
NewEnabled = yes
Autostart = no
AutostartTimeout = 5
DefaultAction = start
Hidden = yes

/cache auf r012-pc01

drwxr-xr-x    6 root     root          4096 Dec 29 15:38 .
drwxr-xr-x   18 root     root           560 Dec 29 15:38 ..
drwxrwxr-x    4 root     root          4096 Dec 29 13:24 boot
-rw-rw-r--    1 root     root            26 Dec 29 15:38 hostname
drwxr-xr-x    2 root     root          4096 Dec 29 15:38 icons
-rw-rw-r--    1 root     root         25526 Dec 29 15:38 image.log
-rw-rw-r--    1 root     root            54 Dec 29 15:37 image.status
-rw-r--r--    1 root     root        984928 Dec 29 15:19 ipxe.efi
-rw-r--r--    1 root     root         46042 Dec 29 15:38 linbo.log
-rw-r--r--    1 root     root       3996672 Dec 28 20:19 linbo64
-rw-r--r--    1 root     root            33 Dec 28 20:19 linbo64.md5
-rw-r--r--    1 root     root      16836792 Nov 26 17:36 linbo_gui64_7.tar.lz
-rw-r--r--    1 root     root            33 Nov 26 17:36 linbo_gui64_7.tar.lz.md5
-rw-r--r--    1 root     root      23979696 Dec 29 15:19 linbofs64.lz
-rw-r--r--    1 root     root            33 Dec 29 15:19 linbofs64.lz.md5
drwxr-xr-x    2 root     root          4096 Dec 29 15:16 linuxmuster-win
drwx------    2 root     root         16384 Dec 29 13:24 lost+found
-rwxr-xr-x    1 root     root          1029 Dec 29 15:38 start.conf
-rw-r--r--    1 root     root           105 Dec 29 15:38 update.log
-rw-r--r--    1 root     root     12095258624 Dec 29 15:37 win10_21H2_s.qcow2
-rw-rw-r--    1 root     root             0 Dec 29 15:37 win10_21H2_s.qcow2.complete
-rw-rw-r--    1 root     root             0 Dec 29 13:53 win10_21H2_s.qcow2.desc
-rw-rw-r--    1 root     root           156 Dec 29 15:37 win10_21H2_s.qcow2.info
-rw-rw-r--    1 root     root        923008 Dec 29 15:38 win10_21H2_s.qcow2.torrent

Info:
Das Image wurde von einem PC aus einer anderen Gruppe erstellt und auf r012-pc01 eingespielt. Vielleicht ist das relevant.

Wer kann bei der Fehlersuche helfen?

Danke!

Viele Grüße
Klaus

baumhof · 29. Dezember 2021 um 21:25

Hallo Klaus,

das:

und das

bekomme ich in meinem Kopf nicht so recht zusammen.
Wurde das Image den nun auf dem Client erstellt oder wurde es auf einem anderen Client erstellt? Wenn „auf einem anderen“ wie ist es dann auf den Client gekommen?

Wenn es auf dem Client war: lief das Erstellen den sauber durch? Ist noch Platz im Cache?

LG

Holger

dorian · 30. Dezember 2021 um 10:38

Hi,

Dass bei „Hochzulandedes Image“ nichts auftaucht liegt daran, dass da noch nach cloop geflitert wird:

github.com

linuxmuster/linuxmuster-linbo-gui/blob/be6b354fc4d6fcc5aa04e97cd5ffb25a8b293515/sources/backend/linboconfigreader.cpp#L136

    
      
          QRegExp *removePartition = new QRegExp("[0-9]{1,2}");
          QString hd = config->cachePath();
          // e.g. turn /dev/sda1 into /dev/sda
          hd.remove( *removePartition );
          config->_hddSize = this->backend->_executeCommand(true, "size", hd).replace("\n", "");
          
          
// Load all existing images
          QStringList existingImageNames = this->backend->_executeCommand(true, "listimages", config->cachePath()).split("\n");
          for(QString existingImageName : existingImageNames) {
              existingImageName = existingImageName.split("/").last();
              if(!existingImageName.endsWith(".cloop"))
                  continue;
          
          
    LinboImage* existingImage = nullptr;
              if(!existingImageName.isEmpty() && !config->_images.contains(existingImageName)) {
                  existingImage = new LinboImage(existingImageName, this->backend);
                  config->_images.insert(existingImageName, existingImage);
              }
              else if(config->_images.contains(existingImageName)) {
                  existingImage = config->_images[existingImageName];
              }

Das wird in der nächsten Gui version behoben.

VG, Dorian

baumhof · 30. Dezember 2021 um 10:51

Lieber Klaus,

ich möchte mich an der Stelle mal für deinen Beitrag bedanken: du bist gerade der, der die ganzen BUGs in linbo 4.0 Testing findet und dann nicht nur meldet, sondern immer mit fundierter Fehlermeldung.

Vielen Dank
LG

Holger

garblixa · 30. Dezember 2021 um 12:14

Hallo zusammen,

Holger, @baumhof danke für Deine Rückfragen in der ersten Antwort und für Deine Anerkennung in der zweiten

In meiner Beschreibung war ich zu ungenau, darum war es schwer verständlich, tut mir leid. Ich versuche es mit einer genauerem Ablauf nochmal. Ich habe den Vorgang in meiner Testumgebung nochmal nachgestellt und kann es hier nicht reproduzieren. Nächsten Montag habe ich wieder Gelegenheit das auf dem Produktivsystem(lmn71 Testing ) nochmal zu probieren.

Es gab 2 Probleme:

Erstellen+Hochladen hat das Image zwar im Cache erstellt, aber nicht hochgeladen. Freier Speicher war genug da. So bin ich vorgegangen:

Es gibt 2 Gruppen: win10_sata_s, SATA PC und win10_nvme_s, NVME PC. Beide sollen das Image win10_21H2_s.qcow2 bekommen.
Der PC in win10_nvme_s wird mit Linbo partitioniert und Windows installiert
Ein Image win10_21H2_s.qcow2 wird vom PC aus der Gruppe win10_nvme_s erstellt und hochgeladen.
Das Image win10_21H2_s.qcow2 wird einem PC der Gruppe win10_sata_s zugewiesen und der PC geklont, neu gestartet, Treiber installiert.
Nun wird mit diesem PC aus win10_sata_s ein neues Image erstellt. D.h. das Image win10_21H2_s.qcow2 soll überschrieben werden.
Der Prozess startet und das Image wird im Cache erstellt, aber nicht hochgeladen. Es gab unmittelbar nach dem erfolgreichen Erstellen des Images die Meldung, daß der Upload erfolgreich war, aber dieser hatte nicht stattgefunden. Auf dem Server unter images/win10_21H2_s wurde kein backup Verzeichnis erzeugt(dieses hatte noch nicht existiert) und das bestehende Image wurde auch nicht überschrieben.

Manuelles Hochladen war nicht möglich, da kein Image gefunden wurde
@dorian hat das im Post oben geklärt, vielen Dank!

Warum das jetzt im Produktivsystem nicht klappt und im Virtualbox Testsystem schon, weiß ich nicht.

Eventuell könnte es daran liegen:

Der Registry Patch war zum Zeitpunkt, als ich das Image auf dem PC in win10_nvme_s erstellt hatte noch nicht zugewiesen. D.h. der PC aus win10_sata_s hatte denselben Hostnamen als der PC aus win10_nvme_s, als er das Image erstellen und hochladen wollte.
Die Uhrzeit des PC aus win10_sata_s lag zum Zeitpunkt der Imageerstellung in der Zukunft.

Ich melde mich nächste Woche nochmal.

Danke und viele Grüße
Klaus

dorian · 30. Dezember 2021 um 19:05

Hi Klaus,

Danke für die ausführliche Erklärung. Ich kann das jetzt zwar nicht direkt nachvollziehen, aber ich habe inzwischen den kompletten Workflow im Backend neu programmiert. Daher gehe ich davon aus, dass das beim nächsten Update funktioniert.

Dieses Update wird aber im Moment noch davon blockiert, dass das Buildsystem von Linbo noch Ubuntu 18.04 ist:

VG,
Dorian

garblixa · 3. Januar 2022 um 14:57

Hallo Dorian,

danke für die Info!
Ich konnte das Problem heute in der Schule nicht mehr nachvollziehen. Evtl. ist auch nur der rsync Daemon nicht gelaufen, so daß der automatische Upload nicht gelaufen ist. Nach dem Neustart des Servers hat dann alles geklappt.

Der manuelle Upload wäre natürlich nach wie vor praktisch, aber Du bist da ja dran. Eine Neuprogrammierung des gesamten Backend Workflows hört sich zwar nach viel Änderung an und damit vielleicht auch wieder nach ein paar neuen Bugs. Aber ich bin da guter Dinge, daß ich das Testsystem weiterhin gut produktiv werde einsetzen können.

Viele Grüße
Klaus