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=36687 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. -- Chris