[Desktop-packages] [Bug 1197193] Re: akonadi dead
I saw this but... Even if I knew what database was corrupted (and where it was), what would I do with the data once the tables had been dumped? I mean it isn't apparent that I would be able to reconstruct the akonadi databases in any meaningful way to get kmail and kpim working again with my data. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nvidia-graphics-drivers in Ubuntu. https://bugs.launchpad.net/bugs/1197193 Title: akonadi dead Status in “nvidia-graphics-drivers” package in Ubuntu: New Bug description: I rebooted my computer (at which point it was fine) on reboot nothing that requires akonadi works. I cannot access any of my email or my calendar which is pretty important to me. Everything hangs on starting Akonadi server... In the akonadi server conf I eventually get a load of errors (below): I'm guessing the DB is screwed and that likely means I'm screwed? whatever the problem the consequence seems pretty drastic and the fix beyond what is reasonable so this should (at the very least) be more robust! Any suggestions as to what I do next? Akonadi Server Self-Test Report === Test 1: SUCCESS Database driver found. Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration and was found on your system. File content of '/home//.config/akonadi/akonadiserverrc': [%General] Driver=QMYSQL SizeThreshold=4096 ExternalPayload=false ... Test 2: SUCCESS Test 3: SUCCESS Test 4: SUCCESS Test 5: ERROR MySQL server log contains errors. Details: The MySQL server error log file apos;a href='/home//.local/share/akonadi/db_data/mysql.err'/home//.local/share/akonadi/db_data/mysql.err/aapos; contains errors. File content of '/home//.local/share/akonadi/db_data/mysql.err': 130703 0:34:02 [Note] Plugin 'FEDERATED' is disabled. 130703 0:34:02 InnoDB: The InnoDB memory heap is disabled 130703 0:34:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins 130703 0:34:02 InnoDB: Compressed tables use zlib 1.2.7 130703 0:34:02 InnoDB: Using Linux native AIO 130703 0:34:02 InnoDB: Initializing buffer pool, size = 80.0M 130703 0:34:02 InnoDB: Completed initialization of buffer pool 130703 0:34:02 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 2607872694 130703 0:34:02 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 2613115392 InnoDB: Doing recovery: scanned up to log sequence number 2613499840 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 1480 row operations to undo InnoDB: Trx id counter is C6ED00 130703 0:34:02 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 8031, file name ./mysql-bin.21 InnoDB: Cleaning up trx with id C6BF11 130703 0:34:03 InnoDB: Waiting for the background threads to start 130703 0:34:04 InnoDB: 5.5.31 started; log sequence number 2613499840 130703 0:34:04 InnoDB: Assertion failure in thread 140228725671680 in file trx0purge.c line 840 InnoDB: Failing assertion: purge_sys-purge_trx_no = purge_sys-rseg-last_trx_no InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 23:34:04 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=0 max_threads=256 thread_count=0 connection_count=0 It is possible that mysqld could use up to
[Desktop-packages] [Bug 1197193] Re: akonadi dead
I've resorted to deleting everything in my home directory containing akonadi once all the directories were gone stuff started to work again. I had to reconfigure kmail to find my mail folders and I think I've lost my calender (since I'm using it as a front end for google calender I think I can get most of this back). I have no idea what the problem was but it is a bug that so much could be so fragile and that the recovery is so difficult. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nvidia-graphics-drivers in Ubuntu. https://bugs.launchpad.net/bugs/1197193 Title: akonadi dead Status in “nvidia-graphics-drivers” package in Ubuntu: New Bug description: I rebooted my computer (at which point it was fine) on reboot nothing that requires akonadi works. I cannot access any of my email or my calendar which is pretty important to me. Everything hangs on starting Akonadi server... In the akonadi server conf I eventually get a load of errors (below): I'm guessing the DB is screwed and that likely means I'm screwed? whatever the problem the consequence seems pretty drastic and the fix beyond what is reasonable so this should (at the very least) be more robust! Any suggestions as to what I do next? Akonadi Server Self-Test Report === Test 1: SUCCESS Database driver found. Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration and was found on your system. File content of '/home//.config/akonadi/akonadiserverrc': [%General] Driver=QMYSQL SizeThreshold=4096 ExternalPayload=false ... Test 2: SUCCESS Test 3: SUCCESS Test 4: SUCCESS Test 5: ERROR MySQL server log contains errors. Details: The MySQL server error log file apos;a href='/home//.local/share/akonadi/db_data/mysql.err'/home//.local/share/akonadi/db_data/mysql.err/aapos; contains errors. File content of '/home//.local/share/akonadi/db_data/mysql.err': 130703 0:34:02 [Note] Plugin 'FEDERATED' is disabled. 130703 0:34:02 InnoDB: The InnoDB memory heap is disabled 130703 0:34:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins 130703 0:34:02 InnoDB: Compressed tables use zlib 1.2.7 130703 0:34:02 InnoDB: Using Linux native AIO 130703 0:34:02 InnoDB: Initializing buffer pool, size = 80.0M 130703 0:34:02 InnoDB: Completed initialization of buffer pool 130703 0:34:02 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 2607872694 130703 0:34:02 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 2613115392 InnoDB: Doing recovery: scanned up to log sequence number 2613499840 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 1480 row operations to undo InnoDB: Trx id counter is C6ED00 130703 0:34:02 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 8031, file name ./mysql-bin.21 InnoDB: Cleaning up trx with id C6BF11 130703 0:34:03 InnoDB: Waiting for the background threads to start 130703 0:34:04 InnoDB: 5.5.31 started; log sequence number 2613499840 130703 0:34:04 InnoDB: Assertion failure in thread 140228725671680 in file trx0purge.c line 840 InnoDB: Failing assertion: purge_sys-purge_trx_no = purge_sys-rseg-last_trx_no InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 23:34:04 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388608
[Desktop-packages] [Bug 1197193] Re: akonadi dead
Now kmail won't even start: The error was: Failed to fetch the resource collection Failed to fetch the resource collection. kmail2(9986)/libakonadi Akonadi::SpecialCollectionsRequestJobPrivate::resourceScanResult: Failed to request resource akonadi_mixedmaildir_resource_0 : Failed to fetch the resource collection. kmail2(9986)/libakonadi Akonadi::SpecialCollectionsRequestJob::slotResult: Failed SpecialCollectionsRequestJob::slotResult Failed to fetch the resource collection. WTF am I supposed to do now? Id really rather not lose everything -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nvidia-graphics-drivers in Ubuntu. https://bugs.launchpad.net/bugs/1197193 Title: akonadi dead Status in “nvidia-graphics-drivers” package in Ubuntu: New Bug description: I rebooted my computer (at which point it was fine) on reboot nothing that requires akonadi works. I cannot access any of my email or my calendar which is pretty important to me. Everything hangs on starting Akonadi server... In the akonadi server conf I eventually get a load of errors (below): I'm guessing the DB is screwed and that likely means I'm screwed? whatever the problem the consequence seems pretty drastic and the fix beyond what is reasonable so this should (at the very least) be more robust! Any suggestions as to what I do next? Akonadi Server Self-Test Report === Test 1: SUCCESS Database driver found. Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration and was found on your system. File content of '/home//.config/akonadi/akonadiserverrc': [%General] Driver=QMYSQL SizeThreshold=4096 ExternalPayload=false ... Test 2: SUCCESS Test 3: SUCCESS Test 4: SUCCESS Test 5: ERROR MySQL server log contains errors. Details: The MySQL server error log file apos;a href='/home//.local/share/akonadi/db_data/mysql.err'/home//.local/share/akonadi/db_data/mysql.err/aapos; contains errors. File content of '/home//.local/share/akonadi/db_data/mysql.err': 130703 0:34:02 [Note] Plugin 'FEDERATED' is disabled. 130703 0:34:02 InnoDB: The InnoDB memory heap is disabled 130703 0:34:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins 130703 0:34:02 InnoDB: Compressed tables use zlib 1.2.7 130703 0:34:02 InnoDB: Using Linux native AIO 130703 0:34:02 InnoDB: Initializing buffer pool, size = 80.0M 130703 0:34:02 InnoDB: Completed initialization of buffer pool 130703 0:34:02 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 2607872694 130703 0:34:02 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 2613115392 InnoDB: Doing recovery: scanned up to log sequence number 2613499840 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 1480 row operations to undo InnoDB: Trx id counter is C6ED00 130703 0:34:02 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 8031, file name ./mysql-bin.21 InnoDB: Cleaning up trx with id C6BF11 130703 0:34:03 InnoDB: Waiting for the background threads to start 130703 0:34:04 InnoDB: 5.5.31 started; log sequence number 2613499840 130703 0:34:04 InnoDB: Assertion failure in thread 140228725671680 in file trx0purge.c line 840 InnoDB: Failing assertion: purge_sys-purge_trx_no = purge_sys-rseg-last_trx_no InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 23:34:04 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have
[Desktop-packages] [Bug 1197193] Re: akonadi dead
You may want to try this before giving up completely: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nvidia-graphics-drivers in Ubuntu. https://bugs.launchpad.net/bugs/1197193 Title: akonadi dead Status in “nvidia-graphics-drivers” package in Ubuntu: New Bug description: I rebooted my computer (at which point it was fine) on reboot nothing that requires akonadi works. I cannot access any of my email or my calendar which is pretty important to me. Everything hangs on starting Akonadi server... In the akonadi server conf I eventually get a load of errors (below): I'm guessing the DB is screwed and that likely means I'm screwed? whatever the problem the consequence seems pretty drastic and the fix beyond what is reasonable so this should (at the very least) be more robust! Any suggestions as to what I do next? Akonadi Server Self-Test Report === Test 1: SUCCESS Database driver found. Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration and was found on your system. File content of '/home//.config/akonadi/akonadiserverrc': [%General] Driver=QMYSQL SizeThreshold=4096 ExternalPayload=false ... Test 2: SUCCESS Test 3: SUCCESS Test 4: SUCCESS Test 5: ERROR MySQL server log contains errors. Details: The MySQL server error log file apos;a href='/home//.local/share/akonadi/db_data/mysql.err'/home//.local/share/akonadi/db_data/mysql.err/aapos; contains errors. File content of '/home//.local/share/akonadi/db_data/mysql.err': 130703 0:34:02 [Note] Plugin 'FEDERATED' is disabled. 130703 0:34:02 InnoDB: The InnoDB memory heap is disabled 130703 0:34:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins 130703 0:34:02 InnoDB: Compressed tables use zlib 1.2.7 130703 0:34:02 InnoDB: Using Linux native AIO 130703 0:34:02 InnoDB: Initializing buffer pool, size = 80.0M 130703 0:34:02 InnoDB: Completed initialization of buffer pool 130703 0:34:02 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 2607872694 130703 0:34:02 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 2613115392 InnoDB: Doing recovery: scanned up to log sequence number 2613499840 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 1480 row operations to undo InnoDB: Trx id counter is C6ED00 130703 0:34:02 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 8031, file name ./mysql-bin.21 InnoDB: Cleaning up trx with id C6BF11 130703 0:34:03 InnoDB: Waiting for the background threads to start 130703 0:34:04 InnoDB: 5.5.31 started; log sequence number 2613499840 130703 0:34:04 InnoDB: Assertion failure in thread 140228725671680 in file trx0purge.c line 840 InnoDB: Failing assertion: purge_sys-purge_trx_no = purge_sys-rseg-last_trx_no InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 23:34:04 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=0 max_threads=256 thread_count=0 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 568168 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer:
