pkg und freebsd-update zerlegt - was tun? sqlite error

B

bsd4ever

Well-Known Member
Hallo,

auf meinem Hetzner Server hat sich pkg und freebsd-update zerlegt. Ich kann nicht genau sagen, wieso. Es war nur so, dass das Filesystem mal voll war...


pkg info
pkg: sqlite error while executing ALTER TABLE packages ADD licenselogic INTEGER NOT NULL DEFAULT(1); in file pkgdb.c:2343: no such table: packages
Zum Vergrößern anklicken....


# pkg update
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100% 163 B 0.2kB/s 00:01
Fetching packagesite.pkg: 100% 7 MiB 7.2MB/s 00:01
Processing entries: 63%
pkg: sqlite error while executing INSERT OR IGNORE INTO pkg_shlibs_required(package_id, shlib_id) VALUES (?1, (SELECT id FROM shlibs WHERE name = ?2)) in file update.c:220: database or disk is full
Processing entries: 100%
pkg: sqlite error while executing ROLLBACK TO SAVEPOINT REPO in file pkgdb.c:1147: no such savepoint: REPO
pkg: sqlite error while executing RELEASE SAVEPOINT REPO in file pkgdb.c:1147: no such savepoint: REPO
Unable to update repository FreeBSD
Error updating repositories!
Zum Vergrößern anklicken....

freebsd-update fetch
src component not installed, skipped
freebsd-update: Directory does not exist or is not writable: /var/db/freebsd-update
Zum Vergrößern anklicken....


# ll /var/db/pkg/
total 24
-rw-r--r-- 1 root wheel 158 Jan 24 17:33 FreeBSD.meta
-rw-r--r-- 1 root wheel 20480 Jan 24 17:19 local.sqlite
-rw-r--r-- 1 root wheel 0 Jan 24 17:33 repo-FreeBSD.sqlite-journal
Zum Vergrößern anklicken....
Wenn ich das alles in ein unterverzeichnis verschiebe, kommt bei pkg info keine Ausgabe und bei


pkg update
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100% 163 B 0.2kB/s 00:01
Fetching packagesite.pkg: 100% 7 MiB 7.2MB/s 00:01
Processing entries: 63%
pkg: sqlite error while executing INSERT OR REPLACE INTO deps (origin, name, version, package_id) VALUES (?1, ?2, ?3, ?4) in file update.c:175: database or disk is full
Processing entries: 100%
pkg: sqlite error while executing ROLLBACK TO SAVEPOINT REPO in file pkgdb.c:1147: no such savepoint: REPO
pkg: sqlite error while executing RELEASE SAVEPOINT REPO in file pkgdb.c:1147: no such savepoint: REPO
Unable to update repository FreeBSD
Error updating repositories!
Zum Vergrößern anklicken....

Alles, was ich dazu im inet gefunden habe, funktioniert bei mir nicht. Bei pkg install -y pkg kommt der selbe fehler. Ein Backup der installierten POrts/liste brauch ich auch nicht zu machen:

# pkg info
pkg: sqlite error while executing ALTER TABLE packages ADD licenselogic INTEGER NOT NULL DEFAULT(1); in file pkgdb.c:2343: no such table: packages
Zum Vergrößern anklicken....


# pkg shell
SQLite version 3.42.0 2023-05-16 12:36:15
Enter ".help" for usage hints.
sqlite> .database
main: /var/db/pkg/local.sqlite r/w
sqlite> .table
licenses pkg_licenses pkg_licenses_assoc
Zum Vergrößern anklicken....

/var/db/ports/ und /var/db/freebsd-update/ sind leer

# freebsd-update fetch
src component not installed, skipped
freebsd-update: Directory is not on a persistent filesystem: /var/db/freebsd-update
Zum Vergrößern anklicken....


# freebsd-version -kru
13.2-RELEASE-p8
13.2-RELEASE-p8
13.2-RELEASE-p9
Zum Vergrößern anklicken....


NAME USED AVAIL REFER MOUNTPOINT
box1zroot 41.7T 434G 140K /box1zroot
box1zroot/ROOT 13.8G 434G 140K none
box1zroot/ROOT/13.1-RELEASE-p1_2022-09-12_213216 11.6K 434G 4.86G /
box1zroot/ROOT/13.1-RELEASE-p2_2022-11-09_112102 11.6K 434G 5.10G /
box1zroot/ROOT/13.1-RELEASE-p3_2022-11-17_104811 11.6K 434G 5.12G /
box1zroot/ROOT/13.1-RELEASE-p4_2022-12-01_193244 11.6K 434G 5.12G /
box1zroot/ROOT/13.1-RELEASE-p5_2023-02-17_101316 11.6K 434G 5.35G /
box1zroot/ROOT/13.1-RELEASE-p7_2023-07-01_190733 11.6K 434G 5.64G /
box1zroot/ROOT/13.1-RELEASE-p8_2023-07-20_212530 11.6K 434G 6.30G /
box1zroot/ROOT/13.1-RELEASE_2022-08-10_113953 11.6K 434G 4.82G /
box1zroot/ROOT/13.2-RELEASE-p1_2023-07-20_214735 11.6K 434G 6.38G /
box1zroot/ROOT/13.2-RELEASE-p1_2023-08-02_211241 11.6K 434G 6.47G /
box1zroot/ROOT/13.2-RELEASE-p2_2023-09-07_162241 11.6K 434G 6.45G /
box1zroot/ROOT/13.2-RELEASE-p3_2023-10-04_171456 11.6K 434G 6.54G /
box1zroot/ROOT/13.2-RELEASE-p4_2023-11-10_232405 11.6K 434G 6.66G /
box1zroot/ROOT/13.2-RELEASE-p5_2023-12-08_221823 11.6K 434G 6.71G /
box1zroot/ROOT/13.2-RELEASE-p7_2024-01-21_011036 11.6K 434G 6.86G /
box1zroot/ROOT/default 13.8G 434G 6.87G /
box1zroot/tmp 232K 434G 232K /tmp
box1zroot/usr 20.1T 434G 140K /usr
box1zroot/usr/home 20.1T 434G 20.1T /usr/home
box1zroot/usr/ports 1.30G 434G 1.30G /usr/ports
box1zroot/usr/src 140K 434G 140K /usr/src
box1zroot/var 2.93M 434G 140K /var
box1zroot/var/audit 140K 434G 140K /var/audit
box1zroot/var/crash 140K 434G 140K /var/crash
box1zroot/var/log 1.02M 434G 1.02M /var/log
box1zroot/var/mail 1.37M 434G 1.37M /var/mail
box1zroot/var/tmp 140K 434G 140K /var/tmp
Zum Vergrößern anklicken....


Kann mir dabei jemand helfen?
Das wäre sehr cool

Danke und Grüße!
 
PS: Nun ist es mir wieder eingefallen: Ich hatte davor freebsd-update laufen lassen... ... install -> reboot und nochmal ..install. seitdem gecrasht....
Aber kein großer Versionssprung. 13.2 war es glaub davor auch schon.
 
schau mal in /var/backups - da sollten Backups der sqlite Datenbank liegen, in der Form pkg.sql.xz.X (X=lfd Nummer)

schieb die aktuell defekte sqlite db sicherheitshalber mit mv oder cp weg (z.B. mv /var/db/pkg/local.sqlite /var/db/pkg/local.sqlite.BAK) und kopier eins der Backups aus /var/backups rein:

Code: 
xzcat /var/backups/pkg.sql.xz.X | sqlite3 /var/db/pkg/local.sqlite
 
da ist leider auch relativ wenig drin

/var/backups # ll
total 12
-rw-r--r-- 1 root unbound 199 Jan 24 12:00 forward.conf.20240124.120032
-rw-r--r-- 1 root wheel 162 Jun 20 2022 resolv.conf.20240124.120032
-rw-r--r-- 1 root wheel 308 Mar 6 2021 resolvconf.conf.20240124.120032
Zum Vergrößern anklicken....
 
oh, dann kannst du das natürlich nicht machen;

hast du ZFS als Filesystem? wenn ja, hast dann ggf vielleicht nen Snapshot der sqlite db von vor dem Event?
 
siehe oben:

box1zroot/ROOT/13.2-RELEASE-p7_2024-01-21_011036 11.6K 434G 6.86G /

weiss aber nicht genau wie ich das restore usw....
 
bsd4ever schrieb:
weiss aber nicht genau wie ich das restore usw....
Zum Vergrößern anklicken....
das ist auch wahrscheinlich eher nicht zielführend, denn du hast (laut deiner Ausgabe von oben) nur Snapshots des ROOT-Pools gemacht aber alle anderen Datasets irgendwie ignoriert. Oder, was wahrscheinlich eher der Fall ist: du hast überhaupt keine snapshots selbst gemacht, sondern nur freebsd-update hat welche angelegt.

Was da noch dooferweise hinzu kommt, ist ja ein wackeliger Zustand des Systems. Wir wissen ja nun nicht, ob der freebsd-update erfolgreich gelaufen ist oder dein System auch an anderen Stellen nachhaltig zerstört wurde.

Spontan halte ich da eine Neuinstallation für sinnvoll und auch am schnellsten.

Solltest du einen snapshot haben, den wir nun nicht sehen, kannst du den unter dem jeweiligen Verzeichnis (mountpoint) in .zfs/ finden und examinieren, also nachsehen, ob dort noch Daten vorhanden sind.
Gemäß deiner Ausgabe von oben, hast du das aber nicht.

Dann kommt an der Stelle immer der Rat: benutze deinen Backup.
Jehnun, wer hat schon Backups? Immer dann, wenn man die Mist-Dinger braucht, hat man natürlich grad keine.
Hat vielleicht dein Provider welche?
Keine Ahnung, aber ich vermute ja mal, dass die gemieteten Server in Wahrheit VMs sind und möglicherweise macht da der Provider irgendwelche Backups?
Ich weiß das wirklich nicht, aber, wenn du selbst keine hast, wäre das vielleicht zumindest noch eine Möglichkeit.


Dabei fällt mir gerade ein:
sind eigentlich deine Datasets alle gemounted, die gebraucht werden?
Was sagt in etwa:
Code: 
zfs list -t all -o name,creation,used,available,written,logicalused,usedbysnapshots,refer,mountpoint
das ist nun aus meinem Befehl heraus kopiert und enthält auch unwichtige Angaben und die aller unwichtigsten habe ich noch weggelassen.

edit:
nur Snapshots der ROOT-Pools -> nur Snapshots des ROOT-Pools
alle anderen Pools -> alle anderen Datasets
 
Zuletzt bearbeitet:
poste der Vollständigkeit halber mal bitte die Ausgabe von der Zeile was Pit oben geschrieben hatte, und/oder auch die Ausgabe von

Code: 
 zfs list -t snap


Wenn du einen gültigen Snapshot von vor dem Event hast, dann kannst du die originale Datei von diesem Zeitpunkt über den .zfs Ordner wieder herholen, einfach per cp:

Annehmend, dass dein Snapshot (von oben: box1zroot/ROOT/13.2-RELEASE-p7_2024-01-21_011036) das ganze "/" abdeckt, also mit "-r" erstellt wurde:

Code: 
cp /.zfs/var/db/pkg/local.sqlite /var/db/pkg/
 
danke euch. ich habe nun umount -f /var gemacht. nun ist das drunterliegende aus dem ROOTFS zu sehen. hatte mich schon gewundert dass var nur 32MB als tmpfs war. ich glaub das war einfach nur drübergelegt mit anderen daten.

nun funktioniert wieder alles!
 
so ganz fit ist das system aber noch nicht :(

# pkg update
Updating FreeBSD repository catalogue...
pkg: No SRV record found for the repo 'FreeBSD'
pkg: An error occured while fetching package
pkg: packagesite URL error for pkg+http://pkg.freebsd.org/FreeBSD:13:amd64/quarterly/meta.txz -- pkg+:// implies SRV mirror type
repository FreeBSD has no meta file, using default settings
pkg: packagesite URL error for pkg+http://pkg.freebsd.org/FreeBSD:13:amd64/quarterly/packagesite.pkg -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.freebsd.org/FreeBSD:13:amd64/quarterly/packagesite.txz -- pkg+:// implies SRV mirror type
Unable to update repository FreeBSD
Error updating repositories!
Zum Vergrößern anklicken....


# freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 13.2-RELEASE from update.FreeBSD.org... failed.
No mirrors remaining, giving up.

This may be because upgrading from this platform (amd64)
or release (13.2-RELEASE) is unsupported by freebsd-update. Only
platforms with Tier 1 support can be upgraded by freebsd-update.
See https://www.freebsd.org/platforms/ for more info.

If unsupported, FreeBSD must be upgraded by source.
Zum Vergrößern anklicken....
 
Evtl. sollte man das System mal neu aufsetzen, damit man einen sauberen Stand hat.
Eine Liste mit den (manuell) installierten Paketen kriegst Du mit
pkg prime-list > /path/to/backup_pkg_list
Das kannst Du dann auf dem neu installierten System einspielen mit:
xargs pkg install < /path/to/backup_pkg_list
Außerdem solltest Du natürlich /etc, /var , /usr/local/etc, /usr/local/var und ggf. /home sichern (ein Vollbackup wäre natürlich noch besser). Musst natürlich gucken, was Du dann daraus wirklich brauchst, damit Du nicht versehentlich kaputte Dateien einspielst. Das hängt dann aber sehr davon ab, was darauf läuft/laufen soll.

Alternativ dazu kann man aber vielleicht auch (dank Backup, Snapshot) komplett auf einen alten, intakten Stand zurück gehen und von dort aus dann weiter machen.

Denn selbst wenn Du jetzt das konkrete Problem mit dem pkg update anders gefixt kriegst, muss man ja immer noch damit rechnen, das da irgendwo korrupte Dateien lauern die dann im weiteren Verlauf Probleme machen oder gar Folgeschäden nach sich ziehen.
 
bsd4ever schrieb:
danke euch. ich habe nun umount -f /var gemacht. nun ist das drunterliegende aus dem ROOTFS zu sehen. hatte mich schon gewundert dass var nur 32MB als tmpfs war. ich glaub das war einfach nur drübergelegt mit anderen daten.

nun funktioniert wieder alles!
Zum Vergrößern anklicken....
ehrlich gesagt ist mir diese Erklärung schon ein wenig schräg vorgekommen. Ich versuche mal zu erklären, wieso. Vorweg aber: ich versuche mit meinen Gedanken nur zu helfen und will nicht besserwisserisch rüber kommen.
In https://www.bsdforen.de/threads/pkg...erlegt-was-tun-sqlite-error.36994/post-336221
hattest du dies eingestellt:
NAME USED AVAIL REFER MOUNTPOINT
box1zroot 41.7T 434G 140K /box1zroot
box1zroot/ROOT 13.8G 434G 140K none
box1zroot/ROOT/13.1-RELEASE-p1_2022-09-12_213216 11.6K 434G 4.86G /
box1zroot/ROOT/13.1-RELEASE-p2_2022-11-09_112102 11.6K 434G 5.10G /
box1zroot/ROOT/13.1-RELEASE-p3_2022-11-17_104811 11.6K 434G 5.12G /
box1zroot/ROOT/13.1-RELEASE-p4_2022-12-01_193244 11.6K 434G 5.12G /
box1zroot/ROOT/13.1-RELEASE-p5_2023-02-17_101316 11.6K 434G 5.35G /
box1zroot/ROOT/13.1-RELEASE-p7_2023-07-01_190733 11.6K 434G 5.64G /
box1zroot/ROOT/13.1-RELEASE-p8_2023-07-20_212530 11.6K 434G 6.30G /
box1zroot/ROOT/13.1-RELEASE_2022-08-10_113953 11.6K 434G 4.82G /
box1zroot/ROOT/13.2-RELEASE-p1_2023-07-20_214735 11.6K 434G 6.38G /
box1zroot/ROOT/13.2-RELEASE-p1_2023-08-02_211241 11.6K 434G 6.47G /
box1zroot/ROOT/13.2-RELEASE-p2_2023-09-07_162241 11.6K 434G 6.45G /
box1zroot/ROOT/13.2-RELEASE-p3_2023-10-04_171456 11.6K 434G 6.54G /
box1zroot/ROOT/13.2-RELEASE-p4_2023-11-10_232405 11.6K 434G 6.66G /
box1zroot/ROOT/13.2-RELEASE-p5_2023-12-08_221823 11.6K 434G 6.71G /
box1zroot/ROOT/13.2-RELEASE-p7_2024-01-21_011036 11.6K 434G 6.86G /
box1zroot/ROOT/default 13.8G 434G 6.87G /
box1zroot/tmp 232K 434G 232K /tmp
box1zroot/usr 20.1T 434G 140K /usr
box1zroot/usr/home 20.1T 434G 20.1T /usr/home
box1zroot/usr/ports 1.30G 434G 1.30G /usr/ports
box1zroot/usr/src 140K 434G 140K /usr/src
box1zroot/var 2.93M 434G 140K /var
box1zroot/var/audit 140K 434G 140K /var/audit
box1zroot/var/crash 140K 434G 140K /var/crash
box1zroot/var/log 1.02M 434G 1.02M /var/log
box1zroot/var/mail 1.37M 434G 1.37M /var/mail
box1zroot/var/tmp 140K 434G 140K /var/tmp
Zum Vergrößern anklicken....
Da ist zu sehen, dass du Datasets für /var, /var/log usw benutzt und dass diese auch einen mountpoint besitzen.
Ob sie tatsächlich auch gemountet waren, wissen wir nun natürlich nicht, denn es nicht ganz klar, in welchem Zustand dein System gehangen hat.

Nun mag man mich eines besseren belehren. Aber, wenn ich Datasets benutze und diese auch im laufenden System gemounted habe, dann sollten ALLE Aktionen immer innerhalb von diesen laufen. Sprich, du solltest dann kein /var im rootfs haben, das du alternativ benutzen kannst, um Fehler wett zu machen. Wenn es im rootfs ein /var gibt, sollte das eigentlich leer sein, weil es nur der reine Mountpoint ist, auf dem normalerweise ja dein Dataset eingebunden wird.

Kein Update, das ich bisher gemacht habe, hat jemals versucht, quasi böswillig an meinem gemounteten System vorbei zu installieren. Außer, wenn ich da Fehler gemacht habe oder vielleicht mal (früher, vor ZFS) ein Dateisystem beschädigt gewesen ist und ich das nicht merkte.
Auch innerhalb FreeBSD gab es nie ein Update, das mir plötzlich neue Datasets aufgezwungen hätte.

Kurzum, die Strategie zur Fehlerbehebung hinterlässt bei mir einige Fragen und ein seltsam ungutes Gefühl. Ich glaube, dass es normalerweise keinen Erfolg haben kann, Ein Dataset mal kurz zu umounten:
bsd4ever schrieb:
umount -f /var
Zum Vergrößern anklicken....
Und dann aus dem ROOTFS wieder herzustellen?
 
stimmt. daran lags. irgendwas hat das verstellt gehabt .. mh.

ist es normal dass die 15 snapshots nahc / gemountet sind? (s. erstes posting)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben