GELÖST: Update 6.3.2.1 löscht Dateien und bricht ab

Shopware 6 (German) Administration
1

Hallo Leute,

ich wollte heute das aktuelle Update einspielen, da ich den Shop erst noch im Aufbau habe und teste.

Leider bricht das Update jedesmal vor der Datenbank-Migration ab (Dialog: 1/3 Dateien werden überschrieben), weil das Update einfach so Vendor-Dateien löscht und dann prüft, ob diese da sind.
Das habe ich jetzt mit Dateien im Ordner /vendor/monolog und /vendor/mtdowling durch und habe vorher immer geprüft, ob die Dateien vor dem Update auch wirklich da waren.

Ist das bekannt?
Kann man das Update auch ander einspielen?

 

Error
Received an error message.
URL: unpack?offset=0&total=0
Message: Internal Server Error

Please try to fix this error and restart the update.
Response
{"code":0,"message":"The file \"vendor\/mtdowling\/jmespath.php\/src\/JmesPath.php\" was not supposed to exist.","file":"\/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/knplabs\/gaufrette\/src\/Gaufrette\/Filesystem.php","line":63,"trace":"#0 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/src\/Steps\/UnpackStep.php(111): Gaufrette\\Filesystem->rename('files\/update\/fi...', 'vendor\/mtdowlin...')\n#1 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/src\/Controller\/BatchController.php(90): Shopware\\Recovery\\Update\\Steps\\UnpackStep->run(0, 3806)\n#2 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/src\/app.php(91): Shopware\\Recovery\\Update\\Controller\\BatchController->unpack(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#3 [internal function]: Closure->{closure}(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Array)\n#4 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/Handlers\/Strategies\/RequestResponse.php(40): call_user_func(Object(Closure), Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Array)\n#5 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/Route.php(281): Slim\\Handlers\\Strategies\\RequestResponse->__invoke(Object(Closure), Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Array)\n#6 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/MiddlewareAwareTrait.php(117): Slim\\Route->__invoke(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#7 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/Route.php(268): Slim\\Route->callMiddlewareStack(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#8 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/App.php(503): Slim\\Route->run(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#9 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/src\/app.php(66): Slim\\App->__invoke(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#10 [internal function]: Closure->{closure}(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Object(Slim\\App))\n#11 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/DeferredCallable.php(57): call_user_func_array(Object(Closure), Array)\n#12 [internal function]: Slim\\DeferredCallable->__invoke(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Object(Slim\\App))\n#13 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/MiddlewareAwareTrait.php(70): call_user_func(Object(Slim\\DeferredCallable), Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Object(Slim\\App))\n#14 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/MiddlewareAwareTrait.php(117): Slim\\App->Slim\\{closure}(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#15 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/App.php(392): Slim\\App->callMiddlewareStack(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#16 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/App.php(297): Slim\\App->process(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#17 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/index.php(36): Slim\\App->run()\n#18 \/var\/www\/web749\/html\/public\/recovery\/update\/index.php(6): require_once('\/var\/www\/web749...')\n#19 {main}"}

 

2

Habe frische Shopware 6 6.3.2.0 gehabt, bei mir lief das Update so durch.

Dh. er löscht dieses, während er das Update durchführt? 

Sieht aus, als wenn das alles sein könnte… hast du berechtigungen von Verzeichnissen andes als Default?

Welche Umgebung hast du?

(meine: Debian 10, PHP 7.3.19,  Apache/2.4.38, MariaDB 10.3.23, Krnl Debian 4.19.132-1 (2020-07-24) x86_64)

3

Ich habe auch frisch die 6.6.3.2.0 installiert, welche bei mir beim Hoster läuft (PHP 7.4.3, MySQL 5.7.29, Apache).

Sschreibrechte sind alle i.O. und wurden nicht geändert (Verz. 755).

4

Hm, puh… 

Da ich ganz frisch hier in der Shopware Sache bin, kann ich dir da nicht weiterhelfen. Das müsste sich ein Admin / Dev anschauen.

Ich würde ein Ticket beim Bug Tracker aufmachen

5

Warum nicht einfach die Datei manuell löschen und Update nochmal ausführen?

6

Welche Datei manuell löschen?

Das Problem kommt bei jedem Updateversuch?

Habe es schon 3x probiert.

7 
"The file \"vendor\/mtdowling\/jmespath.php\/src\/JmesPath.php\" was not supposed to exist."

Da Ist ja der Fehler, wenn die Datei nicht existieren sollte, würde ich die mal manuell löschen.

8

Wenn sie nicht existiert soll ich sie löschen?

Wie das, wenn sie nicht existiert?

Der Updateprozess löscht sie doch selber und meldet danach, das sie fehlt.

9

Kann mann denn das Update auch anders als über den Updatemanager einspielen?

10

PROBLEM GELÖST!!!

Nach langem hin und her habe ich das Problem lösen können.

Es lag am aktiven OP-Cache von PHP 7.4.
Nachdem dies deaktiviert lief das Update problemlos durch.