Der Parameter "skip-bdb" aus der /etc/mysql/my.cnf, welcher standardmäßig bei Debian ausgerollt wird, ist seit MySQL 5.0 deprecated. Verwendet man diesen Parameter mit MySQL 5.1, so startet der Daemon nicht. Das wird dann zum Problem, wenn man die my.cnf lokal modifiziert hat und dann mit unmaintained Repository auf 3.0 aktualisiert, da die alte Konfig behalten wird und während des Updates der neue MySQl Daemon gestartet wird. Der Updatevorgang schlägt dann fehl und hinterlässt einen inkostistenten Status. Es sollte daher zuvor im Preup der Parameter entfernt werden. Siehe auch: http://bugs.mysql.com/bug.php?id=50336
Noch eine Anpassung.
Patch für UCS 3.0-0: 7.0.127-2/23_preup_bug_27686.patch Ich habe den Check in 3.0-2 nicht übernommen, da der Fix nur einmal angewendet werden muss (MySQL 5.0 -> 5.1). Somit ist er in 3.0-2 nicht mehr notwendig.
(In reply to comment #2) > Ich habe den Check in 3.0-2 nicht übernommen, da der Fix nur einmal angewendet > werden muss (MySQL 5.0 -> 5.1). Somit ist er in 3.0-2 nicht mehr notwendig. Der Patch wurde doch noch übernommen, da MySQL in UCS 3.0-2 von unmaintained nach maintained wandert. Somit wird MySQL in einem Standardszenario erst bei UCS 3.0-2 aktualisiert (ohne unmaintained)
Der Text wurde nochmal angepasst und das grep auf den Filter '\<skip-bdb\>' abgepasst. Die Änderung wurde sowohl in 3.0-2 als auch im Patch gegen 3.0-0 vorgenommen. Der Patch ist testweise auf apt.knut.univention.de eingespielt.
braucht es einen Eintrag in Changelog? (der fehlt nämlich) OK, Update -> 3.0-0 (apt.knut.univention.de) * Update mit original my.cnf klappt * Update mit angepasster my.cnf mit skip-bdb wird verweigert * Update mit angepasster my.cnf (ohne skip-bdb) klappt OK, Update -> 3.0-2 (apt.knut.univention.de) * Update mit angepasster my.cnf mit skip-bdb wird verweigert * Update mit angepasster my.cnf (ohne skip-bdb) klappt
(In reply to comment #5) > braucht es einen Eintrag in Changelog? (der fehlt nämlich) fixed
OK
Close old bug reports