# Mysql 4.1.14-r1 update und Umlaute sind alle weg

## Makido

Nachdem ich gestern das Update via "emerge -avu world" von Mysql 4.1.14 auf 4.1.14-r1 gemacht habe und Mysql anschließend neu startete, sind auf allen Webseiten die Umlaute weg.

Hab etc-update natürlich gemacht und mir die configs alle nochmal genau angeguckt.

Es steht nichts von UTF-8 drinnen, sondern ist noch alles wie es sein soll auf latin1.

Auf einer Webseite die bei uns gehostet is, wird jetzt im Forum anstelle eines Umlautes ein " ? " eingesetzt, und alles was an umlauten da war wir falsch dargestellt... z.b. aus "Gästebuch" wurde "GÃ¤stebuch".

Das mit den Umlauten sieht man am besten auf www.sf-to.de , und auf www.vsgteam.de kann man oben noch eine nicht wirklich weiterhelfende fehlermeldung finden.

illegal mix of collations (latin1_swedish_ci,implicit) and (utf8_general_ci,coercible) for operation '='

Hat vielleicht jemand dasselbe Problem bzw. hatte das, und kann mir helfen eine Lösung zu finden?

Nicht mal ein Downgrade auf mysql-4.1.14 half.

Gruß,

Maik

----------

## wandra

ich habe das gleiche Problem und suche schon einen vollen tag nach der lösung ....

die daten sind richtig in der datenbank under werden utf-iesert ausgegeben ... great mist !!!

 *Makido wrote:*   

> Nachdem ich gestern das Update via "emerge -avu world" von Mysql 4.1.14 auf 4.1.14-r1 gemacht habe und Mysql anschließend neu startete, sind auf allen Webseiten die Umlaute weg.

 

Hab etc-update natürlich gemacht und mir die configs alle nochmal genau angeguckt.

Es steht nichts von UTF-8 drinnen, sondern ist noch alles wie es sein soll auf latin1.

Mod edit: Quote cleanup. --ian!

----------

## Makido

Hat niemand ne Lösung?

Denke nicht mal das es nur am Mysql-Update liegt... immerhin war der fehler ja beim Downgrade von Mysql noch da.

Gruß,

Maik

----------

## wandra

ja, das problem ist ziemlich frisch .... offensichtlich sollte man 

die updates nicht automatisch mitmachen ...

bin noch am suchen, sonst irgendwelche geschichtlichen auffälligkeiten ?

ww

----------

## Makido

Nein, sonst ist alles ok... aus nicht sql datenbanken stellt er die Sonderzeichen auch normal dar.

Ich werde aber nachher wenn mal weniger last aufm Server ist php neu emergen, vielleicht bringt das ja was?

Gruß,

Maik

----------

## ConiKost

Wieso macht ihr dann keinen BUG Report?

----------

## wandra

hat bei mir nix gebracht ... weiß noch immer nicht,

arum er die latin1 codierten datenbankinhalte plötzlich als utf8 raushaut ...

siehe http://www.lapalma24.org/

----------

## Makido

 *ConiKost wrote:*   

> Wieso macht ihr dann keinen BUG Report?

 

Würde ich ja machen, aber dazu muss man ja erstmal eingrenzen an was es liegen könnte.

Ich kann ja nicht einfach nen Mysql-Bug reinschieben wenn es an was anderem liegt?

Gruß,

Maik

----------

## wandra

hab mal dem 

Francesco Riosa <vivo@gentoo.org>

geschrieben, ob er eine idee hat ....

das killt echt meine nerven --- ww

----------

## wandra

also wenn ich auf der command-line 

mysql verwende, erfolgt die ausgabe richtig !

----------

## meax

bug 129716  :Sad: 

----------

## Darkmann

Gibt es schon irgenwas neues ?

Gruss Darkmann

----------

## s|mon

Hatte scheinbar das gleiche Problem und wurde freundlicherweise im irc channel #gentoo.de auf den Workaround verwiesen.

```

init-connect='SET NAMES latin1'

```

in der  [mysqld] Sektion der my.cnf. Es wurde noch gesagt das hätte was mit https://bugs.gentoo.org/show_bug.cgi?id=126054 zu tun. Aber für mich ist da jetzt der Zusammenhang nicht ersichtlich. Ich hoffe das dies auch euer Problem lößt.

Ach ja, kann es sein das es früher ein useflag uft8 für mysql gab und das jetzt nichtmehr da ist, weil ich habs früher immer mit -utf8 geemerged. 

Evtl hängt es damit zusammen. 

[edit1] 

Ich glaub ich versteh so langsam  :Wink: 

Das Client-Programm sollte in der my.cnf nachschauen welches Charset beim Zugriff verwendet werden sollte, tut dies aber nicht und nimmt das default aus mysql. Welches früher (useflag -utf8) auch noch latin1 (bei mir zumindest) war. 

Also würde das Problem bei den Client-Programmen liegen und man sollte zu diesen Bug-Reports erstellen ? 

Wäre nett wenn das jmd. bestätigen oder verneinen könnte.

Grüße, s|monLast edited by s|mon on Wed Apr 12, 2006 9:32 pm; edited 1 time in total

----------

## wandra

ja, die haben das default charset von latin1 auf utf8 gestellt ,

diese dillos, und die andern können das ausbaden ....

soll in mysql.eclass zu ändern sein ...

mals suchen, wo das herumliegt

----------

## ian!

Sieht ganz so aus, als ob bei der Anlage der Tables keine bzw. nur teilweise eine collation mitgegeben wurde. 

Siehe auch:

http://dev.mysql.com/doc/refman/4.1/en/charset-collation-charset.html

http://dev.mysql.com/doc/refman/4.1/en/show-create-database.html

http://dev.mysql.com/doc/refman/4.1/en/charset-table.html

Mit der Info sollte sich das fix beheben lassen. (Und vorher bitte an Backups denken.)

----------

## ian!

 *wandra wrote:*   

> ja, die haben das default charset von latin1 auf utf8 gestellt ,
> 
> diese dillos, und die andern können das ausbaden ....

 

Siehe: http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/mysql.eclass?rev=1.28&view=log

Da wurde in dieser Hinsicht nichts geändert.

 *wandra wrote:*   

> soll in mysql.eclass zu ändern sein ...
> 
> mals suchen, wo das herumliegt

 

 :Arrow:  /usr/portage/eclass/mysql.eclass

Aber ich möchte noch mal auf meinen vorigen Post hinweisen. Die Lösung bzw. der Fehler liegt nicht in der eclass.

----------

## Makido

Daaankkeee ^^ Es fuuuunktioniert!

Ich liebe die Gentoo-Community!  :Smile: 

Gruß,

Maik

----------

## wandra

Wie hats denn jetzt funktioniert .... !???

der freudenschrei ist ja toll , aber wie gehts jetzt .. ?

----------

## s|mon

Zuallerst Danke ian für den Tip, nur leider bin ich momentan auch ein wenig verwirrt von der ganzen Information. 

1. Der Workaround hilft bei mir.

2. Zu Collations & Charsets, wenn bei einer Tabelle  eine Collation angegeben ist, so ist ja Prinzipbedingt auch das Charset vorgegeben.

 Jetzt habe ich gerade mal mit "show table status from myDb" mir die Information zu den Tabellen meiner DB ausgeben lassen. Bei allen stand als Collation "latin_swedish_ci" womit ja eigentlich das Charset latin1 auch vorgegeben wäre.

3. Collation und Charset für die betreffende Datenbank (aus db.opt in /var/lib/mysql/myDB) sind ebenso:

 *Quote:*   

> default-collation=latin1_swedish_ci
> 
> default-character-set=latin1

 

4. bei status steht (wie in der my.cnf angeben auch 

 *Quote:*   

> 
> 
> Server characterset:    latin1
> 
> Db     characterset:    latin1
> ...

 

Wohlgemerkt alles gleich, ob mit oder ohne der "init-connect" Option.

Kann da jemand noch einen Anstoss in die richtige Richtung geben? Weil so wie ich das sehe sind ja alle Collations gesetzt. 

Danke schonmal, s|mon

----------

## Makido

 *wandra wrote:*   

> Wie hats denn jetzt funktioniert .... !???
> 
> der freudenschrei ist ja toll , aber wie gehts jetzt .. ?

 

Ganz einfach mit dem Workaround wie s|mon hier geschrieben hat:

nano -w /etc/mysql/my.cnf

dann in der section [mysqld]

```

[mysqld]

character-set-server            = latin1

default-character-set           = latin1

...

```

einfach noch eine Zeile dazu " init-connect='SET NAMES latin1' ", das es so ausschaut:

```

[mysqld]

init-connect='SET NAMES latin1'

character-set-server            = latin1

default-character-set           = latin1

```

und dann mysql neu starten mit " /etc/init.d/mysql restart".

Das wars  :Smile: 

Gruß,

Maik

P.S. Soll natürlich hoffentlich keine Lösung von dauer sein!

----------

## wandra

tja, funktioniert bei mir auf http://www.lapalma24.org/ leider

so definitiv nicht ...

probiert jetzt recompilie mit modifiziertem mysql.eclass ...

kostet mich bald 24h ... der käse

----------

## s|mon

Ich kenn mich damit ja nicht besonders aus, aber eventuell hast du ein anderes Charset verwendet und müßtest  das natürlich anpassen.

Bzw. ich sehe gerade auf deiner Seite im Quellcode steht noch content="text/html; charset=UTF-8", kann es damit zu tun haben oder ist das schon korrekt?

----------

## wandra

alle db's bei mir stehen auf latin1 / latin1_swedish_ci

das hast historische gründe.

wordpress schreibt einfach utf8 rein, wurst wo

und wills auf dieselbe weise holen

und die hat sich mit der neuen subversion geändert

auf http://sos.primavista.net/ läuft typo3;

und kriegt einfach utf8 geschickt, obwohl latin1

drin ist 

wenn es nach dem recompile mit 

                                myconf="${myconf} --with-charset=latin1"

                                myconf="${myconf} --with-collation=latin1_swedish_ci"

in mysql.eclass auch net geht, i don't know

bei mir läuft php-4.2.2 , spielt wahrscheinlich auch eine rolle 

wichtigen progis immer zuerst 14d warten , und feedback ansehen

einmal denk ich mir , es wird schon gehen und aus ist es

----------

## Makido

Also ich hab unter " www.moppi.info " auch wordpress laufen, und es funktioniert seitdem ich das in die my.cnf geschrieben habe.

Nutze auch Php 4.x (weil die 5er auf einigen gehosteten seiten viele fehler macht).

Hast Du das USE-Flag "-utf8" auch in der make.conf?

Gruß,

Maik

----------

## wandra

ich tu's wieder rein - probiers noch mal

dann ins bett - kann nimmer -- wandra

Mod edit: Quote cleanup. --ian!

----------

## ian!

 *ian! wrote:*   

> Aber ich möchte noch mal auf meinen vorigen Post hinweisen. Die Lösung bzw. der Fehler liegt nicht in der eclass.

 

S.o. - Desweiteren habe ich den Threadtitel um das "solved" erleichtert, da einige scheinbar immer noch Probleme haben.

----------

## wandra

------- Comment #3 From Jakub Moc  2006-04-12 23:59 PST  [reply] -------

*** Bug 129762 has been marked as a duplicate of this bug. ***

------- Comment #4 From Luca Longinotti 2006-04-13 03:14 PST [reply] -------

All MySQL ebuilds from 4.1 up should now correctly use UTF8 as default charset

(the compiled in one). Now, you can overwrite that setting to whatever you want

in /etc/mysql/my.cnf, and the tools that correctly call and check my.cnf for

options will respect that, such as the mysqld itself, the mysql* tools. 

PHP

isn't one of those, PHP always only uses the compiled in character set, which

is UTF8 now (and this is correct as it's upstream's default). We are atm

working on a patch to PHP so that it will also check my.cnf and get the

default-character-set settings from there. I'll update the bug once those fixed

PHP ebuilds are ready, with directions to find them.

Best regards, CHTEKK.

----------

## s|mon

Ok, heisst das an den Tabellen ist wahscheinlich nichts falsch, sondern die Anwendungen (php,amarok,...) fragen nicht die Einstellungen in der my.cnf ab, sondern nehmen das einkompilierte charset?

Also liegt es an den Entwicklern dort das umzustellen?

----------

## wandra

die entwickler wollen bei mysql utf8 als standard;

mit diesem 'getarnten' minor release, der von latin1 auf

utf8 switched, haben sie php-applikationen ein osterei gelegt

die php-apps fragen nämlich die my.cnf settings nicht ab

und erwarten nach wie vor latin1, kriegen aber utf8 gefüttert

das problem brennt, wieso die mysql-4.1.14 gleich von

den servern verschwunden ist, ist bescheuert ...

man kann nicht mal zurück

andere solution bisher noch net in sicht

theoretisch db und tabellen inhalte umstellen auf utf8

nur wie get das schnell, sicher und verläßlich ?

ein ziemlicher schmarren, wie man in wien sagt ....

ww 

 *s|mon wrote:*   

> Ok, heisst das an den Tabellen ist wahscheinlich nichts falsch, sondern die Anwendungen (php,amarok,...) fragen nicht die Einstellungen in der my.cnf ab, sondern nehmen das einkompilierte charset?
> 
> Also liegt es an den Entwicklern dort das umzustellen?

 

----------

## wandra

das hab ich eben erhalten ... hoffe, es hilft !

15:00 - nach der dem compilieren und  mysql restart 

hat das bei mir das problem definitiv gelöst !!!

siehe http://www.lapalma24.org/ oder http://sos.primavista.net/

es folgen die beiden Lösungsansätze :

---------------------------------------------------------------------------------------

> i would like to revert to

> mysql-4.1.14 in the meantime , but emerge doesn't show that any more

> 

> i am a little bit disappointed -

> lot of troubles with my production sites

> 

> how can i get mysql-4.1.14 again ...

> mistakes can happen, i need a quick solution

> until the main issue is cleared

> 

> help appreciated, yours

> 

I've readded dev-db/mysql-4.1.14 to the tree, it's package masked so the 

procedure to emerge it is slightely more complex.

echo "=dev-db/mysql-4.1.14" >> /etc/portage/package.unmask

emerge =dev-db/mysql-4.1.14

that's all, the commit will take some time to propagate (hours)

If you're in a hurry, copy /usr/portage/dev-db/mysql somewhere,

set PORTDIR_OVERLAY to "somewhere",

download 

"http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/dev-db/mysql/mysql-4.1.14.ebuild"

put it in the overlay dev-db dir

run:

ebuild mysql-4.1.14.ebuild digest

emerge =dev-db/mysql-4.1.14

------- Comment #7 from chtekk@gentoo.org  2006-04-13 04:55 PST -------

(In reply to comment #6)

> any intermediate quick solution ?

4.1.14 is out of the servers as it has other problems and security issues. As a

temporary solution, you can do the following:

1) Open /usr/portage/eclass/mysql.eclass

2) Search for the following lines:

myconf="${myconf} --with-charset=utf8"

myconf="${myconf} --with-collation=utf8_general_ci"

and sobstitute them with:

myconf="${myconf} --with-charset=latin1"

myconf="${myconf} --with-collation=latin1_swedish_ci"

3) Save the file.

4) Emerge mysql-4.1.14-r1 again.

This should bring the situation back to the old one for now if you need to,

remember that the changes to mysql.eclass will be removed when you do your next

emerge --sync.

Best regards, CHTEKK.

------------------------------------

alte my.cnf nehmen ! 

bei mir ...

--------------------------------------------------------------------------------

# /etc/mysql/my.cnf: The global mysql configuration file.

# $Header: /var/cvsroot/gentoo-x86/dev-db/mysql/files/my.cnf-4.1,v 1.2 2005/07/26 17:14:23 vivo Exp $

# The following options will be passed to all MySQL clients

[client]

#password                                       = your_password

port                                            = 3306

socket                                          = /var/run/mysqld/mysqld.sock

[mysql]

character-sets-dir=latin1

default-character-set=latin1

[mysqladmin]

character-sets-dir=latin1

default-character-set=latin1

[mysqlcheck]

character-sets-dir=latin1

default-character-set=latin1

[mysqldump]

character-sets-dir=latin1

default-character-set=latin1

[mysqlimport]

character-sets-dir=latin1

default-character-set=latin1

[mysqlshow]

character-sets-dir=latin1

default-character-set=latin1

[myisamchk]

character-sets-dir=latin1

[myisampack]

character-sets-dir=latin1

# use [safe_mysqld] with mysql-3

[mysqld_safe]

err-log                                         = /var/log/mysql/mysql.err

# add a section [mysqld-4.1] or [mysqld-5.0] for specific configurations.

[mysqld]

#init-connect='SET NAMES latin1'

character-set-server            = latin1

default-character-set           = latin1

#character-set-system           = latin1

(......)Last edited by wandra on Thu Apr 13, 2006 2:58 pm; edited 1 time in total

----------

## toskala

heh, willkommen im club. hab letzte nacht auch erstmal geflucht.

my.cnf alles wieder auf latin1 gestellt und den init-connect='SET NAMES latin1' eingebaut, dann gings.

mit dem ding wurde echt mal wieder n bock geschossen.

----------

## s|mon

Naja kam halt ungünstig das die alte Version gleich draussen war (wenn auch begründet). Eventuell gabs ja wo nen Hinweis das hier was auf manche Leute zukommt. Habe leider nichts mitbekommen keine Warning/Info/Error Meldung im ebuild oder was im Newsletter. 

Bezüglich amarok hab ich mal einen Bugreport aufgemacht, mit der hoffentlich korrekten Information. http://bugs.kde.org/show_bug.cgi?id=125513

----------

## Makido

Das hab ich dir aber weiter vorne auch schon geschrieben mit dem Init-... und wo es hin muss.

(Nach s|mon's erleuchtendem text  :Wink: 

Da hättest Du ja eigentlich das "latin1" auch erkennen können  :Wink: 

Naja, aber auf dauer ist das doch im endeffekt auch keine wirkliche Lösung?

Gruß,

Maik

----------

## wandra

tja, wieso das mit dem Init-** bei mir nicht geklappt,

muss wohl in den sternen stehen bleiben ....

[quote="Makido"]Das hab ich dir aber weiter vorne auch schon geschrieben mit dem Init-... und wo es hin muss.

(Nach s|mon's erleuchtendem text  :Wink: 

Da hättest Du ja eigentlich das "latin1" auch erkennen können  :Wink: 

Naja, aber auf dauer ist das doch im endeffekt auch keine wirkliche Lösung?

nein, aber die koordination des zusammenspiels von mysql und php hätte man sich auch schon vorher in ruhe überlegen können ... sogesehen war der joke unnötig

utf8 ist schon gut, aber in einer übergangsphase MUSS einfach beides funktionieren,

ohne dass riesenbrösel entstehen .... 

und wenn schon nicht, dann hätte es eine warnung setzen müssen : vorsicht leute °

aber als minor update reinrutschen lassen ist eher übel ....

----------

## Makido

Das "reinrutschen lassen" wird wahrscheinlich auch der Grund sein warum viele leute Gentoo wieder aufgeben, denn es passiert ja nicht nur dieses eine mal... es ist zwar weniger geworden, aber einige Leute die den Portage-tree pflegen scheinen es amüsant zu finden das sie damit anderen Leuten ärger machen.

Vielleicht hat das ja auch mal konsequenzen für denjenigen welchen, der das in den tree gepflegt hat.

Jedenfalls lass ich nicht gerne mit mir Spielen.... Gentoo ist Super.... aber so läuft das nicht!

Gruß,

Maik

----------

## toskala

*gacker* ach... so langsam sehe ich gentoo wie eine alte ehe. die hat ihre macken aber man weiss wenigstens was man davon hat.

chin chin... die hoffnung stirbt zuletzt.

----------

## wols

Hallo,

ich habe das ganze Spiel auch hinter mir ohne diesen Thread gefundenzu haben (hätte mir Stress erspart).

Ich nutze WackoWiki (PHP) und hatte auch die UTF-Probleme trotz LATIN1-Einstellungen in my.cnf.

Die Wiki-Programmierer hatten schon früher darauf hingewiesen MySQL mit UTF erst zu unterstützen wenn MySQL-4.1 mehr verbreitet ist.

Ich war total erfreut als unter Gentoo der 4.0.25-r2-nach-4.1.14-Umstieg per Ebuild ohne Auswirkung aufs Wiki blieb (Dank vorhandener[!] USE -utf8 und latin1 in my.cnf.). Dann nach 'emerge -Du world' kam das mysql-4.1.14-r1 und die oben beschriebenen Probleme.

Ich finde es echt Scheisse das funktionierende 4.1.14.ebuild sofort verschwinden zu lassen!

Aus meiner Datensicherung hatte ich es wieder in meinen lokalen Portage-Baum kopiert und nach 'ebuild ... digest' alles wieder wie gewünscht.

Aber mal ehrlich, manchmal liegen doch ältere Ebuilds auch noch lange rum - hier wäre es sogar mehr als hilfreich gewesen.

Liest das der Entwickler (dem ich aber trotzdem für die Erstellung jedes weiteren Ebuilds danke!)?

----------

## franzf

http://www.gentoo.org/cgi-bin/viewcvs.cgi/

Da solltest du ALLE JEMALS ERSCHIENENEN ebuilds bekommen  :Wink: 

z.B. mysql hier

----------

## wols

Wow, Danke!

Wieder ein neues Bookmark für den SuSE-Umsteiger  :Smile: 

----------

## mneisen

Hallo,

eine alternative Lösung für das in diesem Thread beschriebene Problem findet sich auch hier:

Gentoo: PHP & MySQL-Updates machen Probleme

Mfg

Martin Eisenhardt

----------

