Bug 269810
| Summary: | ports-mgmt/pkg: how to restore pkg database | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | mfv |
| Component: | Individual Port(s) | Assignee: | freebsd-pkg (Nobody) <pkg> |
| Status: | Open --- | ||
| Severity: | Affects Some People | CC: | pkg |
| Priority: | --- | Keywords: | needs-patch |
| Version: | Latest | Flags: | grahamperrin:
maintainer-feedback?
(pkg) |
| Hardware: | Any | ||
| OS: | Any | ||
| URL: | https://docs.freebsd.org/en/books/handbook/book/#pkgng-backup | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271534 | ||
|
Description
mfv
2023-02-24 21:20:57 UTC
I'm aware of this: xzcat /var/backups/pkg.sql.xz | pkg shell pkg-shell(8) <https://man.freebsd.org/cgi/man.cgi?query=pkg-shell&sektion=8&manpath=freebsd-ports> > … Extreme care should be taken when using this command. … Hello Graham, Thanks for the quick response. I tried: 'xzcat /var/backups/pkg.sql.xz | pkg shell' but ended up with the exact same result. Here is a directory listing of /var/db/pkg: -rw-r--r-- 1 root wheel 158 2023.Feb.16 19:56:30 FreeBSD.meta -rw-r--r-- 1 root wheel 58,900,480 2023.Feb.25 08:53:06 local.sqlite -rw-r--r-- 1 root wheel 63,741,952 2023.Feb.23 13:13:34 local.sqlite.one -rw-r--r-- 1 root wheel 54,980,608 2023.Feb.16 19:56:30 repo-FreeBSD.sqlite -rw-r--r-- 1 root wheel 0 2023.Feb.18 09:46:13 repo-FreeBSD.sqlite-journal -r--r--r-- 1 root wheel 7,449,709 2023.Feb.25 07:51:28 vuln.xml -r--r--r-- 1 root wheel 6,316,391 2020.Aug.25 16:53:50 vuln.xml.org local.sqlite.one is the original file and local.sqlite was created by the xzcat command. There original file is 4,841,472 bytes larger than the file created by '/usr/local/etc/periodic/daily/411.pkg-backup'. Let me know if I should send additionl data/information. Cheers ... Marek (In reply to mfv from comment #2) Maintainer feedback requested. (I took the bug from a documentation perspective, feel free to retake it.) the fact that the new db is smaller means nothing, the original one has lived for a while and may benefit from a vaccum for example to release free blocks if needed. xzcat /var/backups/pkg.sql.xz | pkg shell is the right way to retore a corrupted db. btw to not use sqlite, but use pkg shell this is important because pkg shell do set some pragma in the db. Thank you, Mark. Now, a quick test (not intending to change the assignee): - if change occurs, it might be a bug - if no change, please ignore me (apologies for the noise) … (In reply to Graham Perrin from comment #6) Yep, sorry. Today (and on the 20th) I forgot the limitations of auto-assignment. Re: bug 266910 comment 2, ☑ Reset Assignee to default – the default is not the maintainer. Back closer to topic, in an effort to avoid confusion: removal of <https://github.com/freebsd/freebsd-doc/pull/117> from the See Also field of this bug report was not specific to this report. This one removal was, naturally, consequent to a broader request for (indiscriminate) closure of all my PRs in that area. ---- Back on topic, for readers who may be unfamiliar with features of GitHub: .diff and .patch files do remain available, as shown below (their URLs are disallowed for See Also purposes). <https://github.com/freebsd/freebsd-doc/pull/117.diff> <https://github.com/freebsd/freebsd-doc/pull/117.patch> ---- Looking ahead, more generally: Bugmeister might like to advise whether it's appropriate to have the 'needs-patch' keyword in situations such as this, where a patch file is available but not directly attached. Reports with no non-obsolete patch attached can _not_ be found by queries such as this: <https://bugs.freebsd.org/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=all%20open%20reports%20with%20a%20non-obsolete%20patch%2C%20by%20assignee> > all open reports with a non-obsolete patch, by assignee For readers to _not_ misconstrue needs-patch as no-patch, my instinct is to misuse the deprecated 'patch' keyword ;-) Yep, the one that I long ago batch-applied before the deprecated keyword was marked as such. Oops. Of course, I'll not apply it :-) This discussion can continue in private. No rush. Thanks. |
