Solved pkg error : pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path

What is this shit ?
I did
cd /var/db/pkg
rm -vfR *
pkg-static install -f pkg
pkg update -f
pkg upgrade

Error :
pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path

pkg: Repository FreeBSD cannot be opened. 'pkg update' required
pkg: No packages available to install matching 'geany' have been found in the repositories
 
Same here,I think there's a more global problem with the repo FreeBSD-ports.
Code:
# pkg upgrade
Updating FreeBSD-ports repository catalogue...
Fetching data.pkg: 100%   10 MiB  10.7MB/s    00:01   
Processing entries:  99%
pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path
pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path
pkg: sqlite error while executing INSERT OR REPLACE INTO packages (origin, name, version, comment, desc, arch, maintainer, www, prefix, pkgsize, flatsize, licenselogic, cksum, path, manifestdigest, olddigest, vital)VALUES (?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, ?14, ?15, ?16, ?17) in file update.c:158: not an error
Processing entries:  99%
Unable to update repository FreeBSD-ports
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Error updating repositories!
Checking for upgrades (8 candidates): 100%
Processing candidates (8 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
 
Freebsd coming as stable as linux ... What's even more i'm on quarterly ... So only security fixes.. ?
I'll just wait a bit before doing something wrong.
 
It looks like some already reported it, join them if you want:
 
$ doas pkg search bind-tools
Code:
pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path
pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path
pkg: sqlite error while executing INSERT OR REPLACE INTO packages (origin, name, version, comment, desc, arch, maintainer, www, prefix, pkgsize, flatsize, licenselogic, cksum, path, manifestdigest, olddigest, vital)VALUES (?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, ?14, ?15, ?16, ?17) in file update.c:158: not an error
bind-tools-9.20.17             Command line tools from BIND: delv, dig, host, nslookup...
 
It's for anything you do on pkg, so as currently pkg does not work because someone checked in something wrong on the pkg servers without checking or testing.
 
This means for pkg servers not the good procedures are in place , which is not bad , but terrible.
Luckely this did not happened for freebsd kernel & base sources.
 
It looks like some already reported it, join them if you want:
This is about FreeBSD version 14.3-RELEASE-p7.
And I have:
$ doas uname -aKU
Code:
FreeBSD none 15.0-RELEASE-p1 FreeBSD 15.0-RELEASE-p1 releng/15.0-n280999-7bceec30b351 GENERIC amd64 1500068 1500068
 
Side note, i use poudriere on quarterly pkg version was 2.2. When i use FreeBSD.conf on quarterly pkg version was 2.4.
I suppose a database migration is needed for the sqlite ports database.
 
In that case google A.I.,

In 2026, SQLite migrations are handled through several specialized techniques. Because SQLite has limited
ALTER TABLE support (only allowing adding/renaming columns and tables), more complex changes follow a specific multi-step pattern.

1. The Standard "Move and Replace" Pattern

For changes not supported by ALTER TABLE (like dropping columns, changing types, or adding constraints), follow this standard procedure to ensure data integrity:

  1. Backup: Always create a copy before starting (e.g., cp local.sqlite local.sqlite.bak).
  2. Start a Transaction: Wrap your commands to ensure atomicity.
  3. Create New Table: Define a new table with the updated schema.
  4. Copy Data: Use INSERT INTO new_table SELECT ... FROM old_table.
  5. Clean up: Drop the old table and rename the new one back to the original name.
2. Version Tracking with PRAGMA user_version

In 2026, it is standard practice to use the internal user_version field to track and apply incremental migrations:

  • Check Version: PRAGMA user_version;
  • Apply Change: Run the necessary SQL script.
  • Update Version: PRAGMA user_version = 2; (Incrementing after successful application).

3. Tool-Based Migrations

Instead of manual SQL, most modern FreeBSD and development workflows use migration engines:

  • sqlite-migrate / sqlite-utils: A popular CLI tool in 2026 for executing sequential migration files (e.g., 001_add_email.sql).
  • py-sqlite-migrate: Available via the FreeBSD ports tree (pkg install databases/py-sqlite-migrate) for Python-based migration management.

4. Direct Data Export/Import

If you need to move the entire database structure to a new file or system:

  • Export: sqlite3 old.db .dump > backup.sql
  • Import: sqlite3 new.db < backup.sql

Critical Safety for 2026

  • Foreign Keys: Turn them off (PRAGMA foreign_keys=off;) before complex migrations and back on afterward to avoid constraint errors during the table recreation process.
  • Idempotency: Design your scripts with IF NOT EXISTS so they can be safely re-run without causing errors
 
This is about FreeBSD version 14.3-RELEASE-p7.
And I have:
$ doas uname -aKU
Code:
FreeBSD none 15.0-RELEASE-p1 FreeBSD 15.0-RELEASE-p1 releng/15.0-n280999-7bceec30b351 GENERIC amd64 1500068 1500068

I don't think the version of FreeBSD you run matters that much, the issue here is more about pkg itself.
 
It's better to wait. For my concern, I will not complain, FreeBSD is a great open source piece of software and remind it's provided as-is. I would be much more aggressive on a Microsoft product, which IS 100% marketed, closed-bloated-AI. It's definitely counter-productive, in my opinion, to ask +1 hour free support from the BSD team ; the team is not meant for this and even corporate paid support don't go that fast.
Don't be so rude, that's useless, we're fine here :D
For emergency cases, target ports. Do work fine.
 
It's better to wait. For my concern, I will not complain, FreeBSD is a great open source piece of software and remind it's provided as-is. I would be much more aggressive on a Microsoft product, which IS 100% marketed, closed-bloated-AI. It's definitely counter-productive, in my opinion, to ask +1 hour free support from the BSD team ; the team is not meant for this and even corporate paid support don't go that fast.
Don't be so rude, that's useless, we're fine here :D
For emergency cases, target ports. Do work fine.
Yes it's true , my kernel is still working fine , my "base" is working fine , my currently installed ports are working fine. I'm even doing poudriere builds currently.
But a very small communication would be welcome. Even like saying "work in progress". That does not count much does not take time but is polite.
 
Well first you must locate the problem
- Is it in the kernel
- Is it in base
- Is it in ports

For problems in ports there is

https://bugs.freebsd.org/bugzilla/enter_bug.cgi?component=Individual Port(s)&product=Ports & Packages

For problems in base there is :

https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Base System


I don't know for problems in kernel.


[Note for me i was not sure if the problem here was in pkg(ports) or pkg-static(base)]

If you have a HIGHLY technical background , know what you are saying , understand you don't want to waste time/resources , you can go to the mailing lists.

https://lists.freebsd.org/

[I don't know if you must be invited ?]
As I'm mortal, read, no guru , i only go there to read.
 
Back
Top