opsi40-experimental opsi-linux-bootimage-20131121-1.1

[isy]

OPSI Host mit opensuse 12.1

Unsere alte miniroot (miniroot-20130207 (kernel 3.6.11) hat auf einem neuen Dell Latitude E7240 eth0 nicht mehr gefunden.
Wir haben dann mit opsi-linux-bootimage-20131121-1.1 aus dem experimental Repo Kernel 3.10.10 getestet.
Die miniroot bootet sauber durch, beim kopieren der winpe-Dateien trat allerdings folgender Fehler auf:

Die erste zu kopierende Datei (1,4MB) wurde so lange in sich selbst kopiert, bis die Partition voll war (4GB) - No space left on device.

Abhilfe: Im bootimage wird in der Funktion _transfer die bufferSize der Geschwindigkeit angepasst. Dabei scheint irgend etwas nicht zu funktionieren. Auskommentieren der Anpassung macht den Vorgang vielleicht langsamer - aber er läuft

diff miniroot-20131121/usr/share/pyshared/OPSI/Util/Repository.py miniroot-20131121/usr/share/pyshared/OPSI/Util/Repository.py.orig
376,380c376,380
< # self._calcSpeed(read)
< # if (self._dynamicBandwidth or self._maxBandwidth):
< # self._bandwidthLimit()
< # elif (self._currentSpeed > 1000000):
< # self._bufferSize = 262144
---
> self._calcSpeed(read)
> if (self._dynamicBandwidth or self._maxBandwidth):
> self._bandwidthLimit()
> elif (self._currentSpeed > 1000000):
> self._bufferSize = 262144

[ueluekmen]

Hi,

hast du auch eine Logdatei, die du uns zur Verfügung stellen kannst?

Die Stelle die du auskommentierst wurde frisch implementiert. Wir mussten darauf reagieren, da seit Kernel 3.7 eine Änderung im Cifs-Modul dafür sorgt, dass eine Kopieraktion abgebrochen wird. Das bedeutet, die Funktion ist nicht mehr gegeben. Wir würden der Sache aber gerne genauer nachgehen.

Also wenn du Log-Dateien hast, dann schicke Sie bitte gepackt an info(at)uib.de mit einer kleinen Referenz an diesen Thread. Betrifft das nur einen Client oder alle?

[isy]

Die Log-datei sieht recht gewöhnlich aus - bis zum Kopieren. Dann folgt:

[7] [Dez 10 16:44:53] Transfer in from <open file u'/mnt/opsi/install/win7-x64/winpe//boot/efisys_noprompt.bin', mode 'rb' at 0x8609e38> to <open file u'/mnt/hd/boot/efisys_noprompt.bin', mode 'wb' at 0x8609d88>, dynamic bandwidth False, max bandwidth 0 (Repository.py|343)
[7] [Dez 10 16:44:53] Filesize is: 1474560 (Repository.py|354)
[6] [Dez 10 16:56:50] Traceback: (Logger.py|742)
[6] [Dez 10 16:56:50] line 371 in '_transfer' in file '/usr/lib/pymodules/python2.6/OPSI/Util/Repository.py' (Logger.py|742)
[6] [Dez 10 16:56:50] ==>>> [Errno 28] No space left on device (Repository.py|389)
[2] [Dez 10 16:56:51] Traceback: (Logger.py|742)
[2] [Dez 10 16:56:51] line 1462 in '<module>' in file '/usr/local/bin/master.py' (Logger.py|742)
[2] [Dez 10 16:56:51] line 238 in '<module>' in file '/tmp/setup.py' (Logger.py|742)
[2] [Dez 10 16:56:51] line 562 in 'copy' in file '/usr/lib/pymodules/python2.6/OPSI/Util/Repository.py' (Logger.py|742)
[2] [Dez 10 16:56:51] line 727 in 'download' in file '/usr/lib/pymodules/python2.6/OPSI/Util/Repository.py' (Logger.py|742)
[2] [Dez 10 16:56:51] ==>>> Repository error: Failed to download '/mnt/opsi/install/win7-x64/winpe//boot/efisys_noprompt.bin' to '/mnt/hd/boot/efisys_noprompt.bin': [Errno 28] No space left on device (master.py|1510)
[7] [Dez 10 16:56:51] Backend: <OPSI.Backend.JSONRPC.JSONRPCBackend instance at 0x8abbaec> (master.py|1513)

Das Ganze auf einem ganz neuen Clienten und aber auch auf einem älteren Rechner, deer vorher durchgelaufen war. Ich hatte mir dann in einem versuch während des Kopiervorgangs die bufferSize ausgeben lassen und die ging nach dem 2. Packet auf den Maximalwert von 262144 und blieb dort, bis die 4GB gefüllt waren

Die Log-datei ist unterwegs...

[Arris]

Hallo zusammen,
wir habe hier das gleiche Problem, allerdings mit anderem Symptom.
Bis zu winpe kommen wir schon nicht weil sich die setup.py beim kopieren nach /tmp auf 28GB aufbläht und screen dann mit "out of memory" den dienst quitiert.

Als kleinen fix haben wir erstmal mit "find ./ -name Repository.py | cpio -o -A -H newc -O ../miniroot-20131121_orig" die nach isy's Vorgaben geänderte Repository.py ins cpio Archiv geschoben.

Das Archive zu entpacken und wieder neu mit cpio und bz2 zu erstellen ist uns zwar gelungen aber das image wollte nicht so recht arbeiten (failed to execute /init). Vermutlich ein fehlender/falscher cpio parameter.

Angenehmen Rutsch ins Neue Jahr!
Grüße
Arris

[ueluekmen]

Hallo zusammen,

frohes neues Jahr erst mal.

Wir haben letztes Jahr noch einen Fix gebaut, allerdings etwas anders als isy.

Es sieht so aus, als ob beim lesen des letzten Blocks unter umständen immer der letzte Block an die Datei geschrieben wird, solange bis das Filesystem vollläuft.

Allerdings ist das nur eine Vermutung, da wir das Problem zum einen nicht reproduzieren können und ausser in diesem Thread, dass Problem noch nirgends aufgetreten ist.

Den angesprochenen Fix haben wir mal jetzt hochgeladen, allerdings nicht in unseren normalen Repos. Ihr könnt euch das neue Paket unter folgender URL laden:

http://download.opensuse.org/repositori ... :/testing/

Die neue Version sollte 20131219-1 sein.

Wir bitten um Feedback, ob das Problem dadurch behoben wird, wenn ja, lassen wir diesen Fix in das nächste Release mit einfliessen.

Danke und Grüße
E. Ueluekmen

[Arris]

Ebenfalls frohes Neues!

Ich teste gerade mit opsi-linux-bootimage_20131219-1_all.deb und es funktioniert.

Zwischendurch hatten wir mal Version 20131216 aus dem Standardrepository die den Fehler auch zeigte.


Besten dank

Grüße
Gerd

[isy]

Hallo zusammen!

Wir sind leider jetzt erst dazu gekommen, das neue bootimage zu testen, aber der Fehler tritt nicht mehr auf )

Besten Dank und beste Grüße

isy

[ueluekmen]

Vielen Dank fürs Testen.

Wir bauen gerade an einem neuen opsi-linux-bootimage Paket, da ist der Fix enthalten.

Alle die das Problem haben bitte nur opsi-linux-bootimage >= 20131219-1 verwenden.