From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: /var/guix/db/db.sqlite corruption Date: Sat, 03 Aug 2019 02:28:01 -0700 Message-ID: <87pnlmiony.fsf@gmail.com> References: <87lfwbuj27.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:52084) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htqKh-0004y1-KH for help-guix@gnu.org; Sat, 03 Aug 2019 05:28:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1htqKg-00056g-5U for help-guix@gnu.org; Sat, 03 Aug 2019 05:28:11 -0400 In-Reply-To: <87lfwbuj27.fsf@gnu.org> (Mike Gerwitz's message of "Fri, 02 Aug 2019 21:36:00 -0400") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Mike Gerwitz Cc: help-guix@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Mike, Mike Gerwitz writes: > guix gc: error: executing SQLite query: malformed database image I've also seen this happen. I opened a bug report about it recently: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D36687 I don't have a solution, but I tried a similar work-around with similar results. Please see the bug report for details. > - Is there a way to regenerate the database? I don't think it can be regenerated from scratch. Some information, like which paths in the store are "valid", cannot be determined just by examining the contents of the store. > - What bad things could happen with what I just did? I don't know. Speaking on the side of caution, especially since you changed the ROLLBACK line to COMMIT, I think that all bets are off. I feel a little more comfortable the results of my own attempt, since I didn't have to make that change (my SQL dump ended with a COMMIT line). However, it's still concerning that we had to dump the database and restore it in order to "fix" it. Eventually I'll probably reinstall Guix just to be safe, but I take backups of my important data pretty frequently, so I'm not in a big rush. > [*]: Actually, I had some other bizarre issues. After I recreated the > DB, I started getting more generic I/O errors. There were no errors in > dmesg. But when I moved the file to a different location (e.g. my home > directory), it worked (via `sqlite3`). If I moved it back to > `/var/guix/db/db.sqlite`, I/O errors once again. If I ran `.dump` from > that dir, empty. If I moved it to my home dir and ran `.dump`, I got > the full dump. This problem didn't resolve until after a reboot. I > haven't seen anything like that before, and I don't want to > speculate. I should have tried flushing the kernel I/O cache before > rebooting to see if that would have fixed it. Did you remember to stop the guix-daemon and verify that no processes were accessing the database file when you did all of this? If not, then I wouldn't be surprised to see bizarre behavior. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAl1FU6EACgkQ3UCaFdgi Rp0wChAA2hrg8ohGW2LfQvSiPkmn8Hu1Xzd4oVcAb2m6hm7f9n66tP62qTI1rynM 5C005GK4p7To94BygCpEociXhyoM48UatoAZODfwvec2+X9909b+yC74o1iQMidT ELBsoTeAj2Sdu9YAIMpkpEDgoRkGtyT1TCl8K5JEL9/F4HE6Y5weGkMWYQa2Y25i MBgyT3S9QjyfT7b6VCSy3NmF0syY3pSLwmdTRIETYDLhCEBgNm7q6Sy3URLvEPSf iuazhtzdejSMCgW9P0nBcLw2RR4cU7YGD6rWMtpZsse6H0guoA4JilxAQ0JMrctH 2zGsyPxWvg1hX2HzdcDh3UNCSJCPgmw2IdnBErHSWeqpTm63pAn/WvAR8HRsz3uw 7gS+QI1NsmgtS/pfX0p5upWtCbES8vIz4lswtRZ4W8qI3y2mWyVE8rj8CxPGmkWp 0VIew133QXhYZ+lmiULjk4IHRh86n8eExCZCfoTTab/dK5MCwqc04urbX3jh+1Xx CfXTmwv9NfFsKaSNr49GeqKsDAMz+YHlr2yb41WOSSDbwOHUxB2VLgPwmQcWlrNa rEFZXNcRTAp/AXM7J7D8CLN549dTmbzq9OBk1FgGkxe6a5cHndIvRz6lfrGmYo04 4h/o4lcbV/IjGoBcn8SYyPXA4HHqua12tixy/3nef1zkRZlx7RY= =FJ3x -----END PGP SIGNATURE----- --=-=-=--