Ok il problema si è risolto in questo modo. Stop del service mysql poi: 1. fare il cp con l'opzione -a (grazie Marco) di /var/lib/mysql in /home (prima l'avevo messa in /home/mioutente/.db/mysql e dava problemi, anche con -a) 2. rinominare la folder /var/lib/mysql in /var/lib/mysql.bkp 3. modificando le voci datadir e tmpdir in /etc/mysql/my.conf a questo punto riavviato il demone tutto sembrerebbe funzionare. Senza fare la 2 mi dava il problema sul database anche se mi pare molto strano... Adesso posso provare ad integrare il vecchio dumped db nel nuovo... Grazie a tutti dell'aiuto ^^ @ Roberto: la /var/lib non la posso montare in RAM e voglio minimizzare l'accesso in lettura e scrittura al raid, e spostare quindi il db nell'LVM. Cosa intendi tu con > spostare i servizi e non i file ? A proposito (@ Marco), sono passato alle chiavette usb perchè il mio serverino, che uso per imparare e giochicchiare è a costo zero, era (e in parte è) costruito con parti di recupero. Questa è la quarta versione. Le prime due sono morte con i loro hdd di sistema (il raid1 l'ho implementato nella 3 versione). Questa versione introduce LVM (perchè prima non potevo formattare gli hdd con i films). Ho finito gli hdd "spare parts" e statisticamente mi pare molto difficile che le due chiavette si rompano (perchè si romperanno) contemporaneamente. Il raid dovrebbe avvisarmi del failure e quindi permettermi di sostituire quella rotta e fare il resync del raid prima che tutto il sistema se ne vada a farsi fo**ere, al costo di 6€ (il costo della key, molto inferiore rispetto ad un hdd, inoltre mi libero i preziosissimi slot sata). L'unico problema per ora è stato il boot, ci mettono un po' troppo tempo a costruire il raid, ma ho risolto con rootdelay nelle opzioni di boot. Comunque grazie ancora -- distinti saluti, ------------ Matteo Ragni ------------ <aka: nirvana1289> # reply to: nirvana1289@xxxxxxxx GPG Public Key: 0x0141EDBD238098A0 @ pgp.mit.edu gpg --keyserver pgp.mit.edu --recv-key 0x0141EDBD238098A0