{"id":169,"date":"2022-11-06T19:05:48","date_gmt":"2022-11-06T19:05:48","guid":{"rendered":"https:\/\/pii.icu\/blog\/?p=169"},"modified":"2022-11-06T19:19:28","modified_gmt":"2022-11-06T19:19:28","slug":"recovering-corrupted-firefox-database","status":"publish","type":"post","link":"https:\/\/pii.icu\/blog\/2022\/11\/recovering-corrupted-firefox-database\/","title":{"rendered":"Recovering a corrupted Firefox database"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Recently when developing my kernel module I experienced multiple crashes, mostly as a result of giving bad pointer to some kernel function which resulted in random writes to crucial kernel memory. That manifested as kernel crashing at some point of time in the future, locking up the system completely. Well, reboot and no big deal, right? Except when file system data gets corrupted. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">At some point I noticed Firefox acting weirdly. It didn&#8217;t remember new visited links and other small issues like that. Moreover when trying to show history it showed up as empty (which does pose a problem as I was trying to find a site I visited), and trying to clear history did nothing either. At this point I was pretty sure something weird was going on as some parts of Firefox clearly remembered history, so I decided to do a check on the SQLite database <code>places.sqlite<\/code> that Firefox uses to record history, download, bookmarks and etc. Nowadays Firefox locks the database so when trying to open it Firefox should be closed first (or it also could be copied). <\/p>\n\n\n\n<pre class=\"wp-block-code\"><code lang=\"\" class=\"\">&gt; cd ~\/.mozilla\/firefox\/<i>profile<\/i>\/\n&gt; sqlite3 places.sqlite\nsqlite&gt; PRAGMA integrity_check;\n*** in database main ***\nPage 1040: btreeInitPage() returns error code 11\nPage 1041: btreeInitPage() returns error code 11\nRuntime error: database disk image is malformed (11)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Oops, no wonder it didn&#8217;t work properly. Though apparently Firefox didn&#8217;t care much as it said nothing. So I tried to recover and rebuild the database by running:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code lang=\"\" class=\"\">&gt; mv places.sqlite places.sqlite.old\n&gt; sqlite3 places.sqlite.old '.recover' &gt; places.sql\n&gt; sqlite3 -init places.sql places.sqlite<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">I did take a look at the generated SQL and everything seemed to be in order. However, when launching Firefox this time around it moved the new <code>places.sqlite<\/code> to <code>places.sqlite.corrupt<\/code> and generated a new database. So there was still something missing in the <code>places.sql<\/code> that made Firefox reject it, but I couldn&#8217;t see anything wrong in the SQL statements.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">After doing some searching on the net I came across <a href=\"https:\/\/superuser.com\/questions\/111998\/how-do-i-repair-a-corrupted-firefox-places-sqlite-database\">this superuser post<\/a> that immediately showed where the issue was: Firefox is using <code>PRAGMA user_version<\/code> to store a schema version and as it didn&#8217;t see a proper version it decided that the database was corrupted. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I&#8217;m running Firefox 105 so I get:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code lang=\"\" class=\"\">&gt; sqlite3 places.sqlite.old 'PRAGMA user_version;'\n69<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">So I prepended <\/p>\n\n\n\n<pre class=\"wp-block-code\"><code lang=\"sql\" class=\"language-sql\">PRAGMA user_version = 69;\nPRAGMA journal_mode = truncate;\nPRAGMA page_size = 32768;\nVACUUM;\nPRAGMA journal_mode = wal;\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">to <code>places.sql<\/code> and generated a new SQLite database. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And hurray, this time everything worked (except the missing history earlier from the day that has now disappeared from existence.)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Recently when developing my kernel module I experienced multiple crashes, mostly as a result of giving bad pointer to some kernel function which resulted in random writes to crucial kernel memory. That manifested as kernel crashing at some point of time in the future, locking up the system completely. Well, reboot and no big deal, &#8230; <a title=\"Recovering a corrupted Firefox database\" class=\"read-more\" href=\"https:\/\/pii.icu\/blog\/2022\/11\/recovering-corrupted-firefox-database\/\" aria-label=\"More on Recovering a corrupted Firefox database\">Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[6],"tags":[],"class_list":["post-169","post","type-post","status-publish","format-standard","hentry","category-computers"],"_links":{"self":[{"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/posts\/169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/comments?post=169"}],"version-history":[{"count":15,"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/posts\/169\/revisions"}],"predecessor-version":[{"id":188,"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/posts\/169\/revisions\/188"}],"wp:attachment":[{"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/media?parent=169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/categories?post=169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pii.icu\/blog\/wp-json\/wp\/v2\/tags?post=169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}