KDE-Forum.org

Quoted from "aciel"

I have the same issue. It may be because I already had MySQL installed. Perhaps it has a password?

Source code

1 2 3 4 5 6 7 8

cat ~/.local/share/akonadi/db_data/mysql.err 090207 14:42:03 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. InnoDB: File name ./ibdata1 InnoDB: File operation call: 'create'. InnoDB: Cannot continue operation.

Note that my home directory is automounted remotely. root does not have write access to my home for security reasons. This may be related, or maybe not.

Quoted

The warning against sharing a data directory among servers also applies in an NFS environment. Allowing multiple MySQL servers to access a common data directory over NFS is a very bad idea.

• The primary problem is that NFS is the speed bottleneck. It is not meant for such use.
  
• Another risk with NFS is that you must devise a way to ensure that two or more servers do not interfere with each other. Usually NFS file locking is handled by the lockd daemon, but at the moment there is no platform that performs locking 100% reliably in every situation.
  

Make it easy for yourself: Forget about sharing a data directory among servers over NFS. A better solution is to have one computer that contains several CPUs and use an operating system that handles threads efficiently.

Quoted from "flambard"

Same here, seems Akonadi cannot create an innoDB. I looked at the directory and there is no "ibdata1".
simply touching one into existance gets the complaint that the size does not match expected size. So innoDB creation seems the issue. I also have an nfs-home dir and no access for root to the given path.

Quoted from "aciel"

I have the same issue. It may be because I already had MySQL installed. Perhaps it has a password?

Note that my home directory is automounted remotely. root does not have write access to my home for security reasons. This may be related, or maybe not.

Quoted

I don't like a database server because of backups/running on NFS/etc.
See section "Deployment Issues" above, we are aware of that and working on it. Some of these, like backup/restore are already implemented. But please be aware that most of this issues also existed before (eg. with KMail's custom binary indexes).

Quoted

How do I completely disable Akonadi startup?
If you already have applications natively using Akonadi, you of course can't disable Akonadi startup. Mailody and KPilot are applications that are already based on Akonadi, for example.
Other applications, like KAddressbook and KOrganizer, are not based on Akonadi yet, at the time of writing. Instead, they use the old KResource framework for storing contacts, calendars and notes. During the KDE 4.2 beta time, these KResources were automatically migrated to Akonadi-based KResources, the so-called Akonadi compatibility resources. Therefore, applications like KAddressbook and KOrganizer would use Akonadi indirectly through KResources, and therefore would start the Akonadi server when being started. Note that the same situation applies for KMail, which uses addressbook functionality also based on KResources.
If Akonadi doesn't start up correctly for you, the following should help you to disable Akonadi startup and use your old KResources again.
First, disable automatic migration like described in the above FAQ entry. Then, open System Settings, go to the Advanced tab and open the KDE Resources config panel. There, you can configure which type of KResources are used for contacts, calendars and notes. If the migration to Akonadi was successful, you'll probably only see the Akonadi Compatibility Resource as an active resource, and all others disabled.
To disable Akonadi startup, enable your old resources again, then disable and delete the Akonadi compatibility resource.