Ein Problem mit dem aktuellen Update habe ich aber auch:

pacman -Syu
[Paketupdate läuft...]
(105/121) Aktualisisere nano ... OK
(106/121) Aktualisiere openssh ... OK
Fehler: Konnte /var/cache/pacman/pkg/ nicht entfernen (Ist kein Verzeichnis)
(107/121) Aktualisiere pacman
Fehler: Konnte Datei /var/cache/pacman/pkg/pcre2-10blablubb.pkg.tar.gz nicht öffnen: Datei oder Verzeichniss nicht gefunden

Abruch, Fehler, usw.

Mein /var/cache/pacman/pkg war ein Symlink auf ein NFS-Share. Nach dem Abbruch war der Symlink entfernt und ein reguläres Verzeichnis pkg vorhanden - welches leer ist/war.
pacman hat sich also selbst - während des laufenden Updates - den Cache unterm Hintern weggeschossen.

Frage/Ursache/Bug halt: Warum verändert pacman das Cache-Dir (wenn es auch "nur" ein Symlink ist) anstatt ggf. nur auf die Existenz des Verzeichnisses zu prüfen? Gab es bei vorhergehenden Updates nicht (müßte also mit der Version pkgrel -4 auf -5 passiert sein)

Nachtrag:
Beim Reparieren habe ich aktuell noch ein Problem mit dem pcre2, welches beim Abruch wohl beschädigt ist und aktuell jeden weiteren pacman-Lauf behindert. Ursache ist das /var/lib/pacman/local/pcre2-blablubbb die desc und files Dateien fehlen. pcre2 muß ich per --force reinstallieren.

So, symlink zum Paketcache wieder hergestellt. pacman ist wieder/noch (openssl) lauffähig in dieser Sitzung.
Erneutes pacman -Syu würde nun weitermachen, allerdings ohne pacman (erneut, wg. obigem Abbruch) erneut zu installieren.
Also ein beherztes:
pacman -Syu pacman
(Warnung: pacman 5.0.1-5 ist aktuell -- Reinstalliere) => Also pacman ist schon aktuell, trotzdem weiter....
Und wupps:
Wieder ist der Symlink zum Paketcache weg, Abbruch.
Also das ist mit pkgrel -5 bei mir reproduzierbar.

Ich verzichte also auf das erneute (Re)installieren von pacman selbst, stelle meinen symlink zum Cache wieder her und fahre ein normales pacman -Syu, um die noch fehlenden Pakete nach dem obigen Abbruch zu upgraden.

Evtl. mal mit einem bind-Mount statt symlink versuchen für den Cache, ob sich pkgrel -5 da auch so benimmt. Aber hej, ein Symlink ist was ganz Sipmles ;-)

So, scheinbar alles wieder OK, ein pacman -Syu zeigt "nichts zu tun". Trotzdem hatte ich noch an mindest einem Paket Hand anzulegen, da dessen /var/lib/pacman/local/paketname/[desc, files] nicht vorhanden waren.
Ein pacman -Qk zeigt nichts auffälliges, bemägelt allerdings:
Warnung: pacman /var/cache/pacman/pkg (Datei-Typ stimmt nicht überein) => also mein "Symlink-Problem"

Kurzversion (obiges habe ich während des Problembehebens zusammengeschrieben <g>)

pacman 5.0.1-5 erzeugt ein Problem wenn der Paketcache (/var/lib/pacman.pkg/) kein reguläres Verzeichnis ist.

Wenn mit/seit pkgrl -5 während eines Updates auch pacman selbst updatet wird (wie aktuell beim openssl-SO-Bump) dann bricht das Systemupdate mit einem teilaktualisierten System ab, da der Inhalt des Paketcaches nicht mehr vorhanden ist. Bei mir: wenn der Paketcache z.B. ein Symlink ist.

Reproduzieren (ohne "Gefahr" wenn das System aktuell ist) z.B. mit:

mv /var/cache/pacman/pkg /var/cache/pacman/orig-pkg
ln -s /var/cache/pacman/orig-pkg /var/cache/pacman/pkg
ls /var/cache/pacman/pkg
(Cacheinhalt wird aufgelistet)

pacman -Syu pacman
Warnung: pacman-5-0-1-5 ist aktuell -- Reinstalliere
....
Fehler: Konnte /var/cache/pacman/pkg/ nicht entfernen (Ist kein Verzeichnis)

ls /var/cache/pacman/pkg
(Cache ist nun "leer", pkg ist jetzt ein reguläres Verzeichnis anstatt des Symlinks => Bug)
(Wenn während dieses pacman-Laufs jetzt noch weitere Pakete anstünden würde das ein teilaktualisiertes System hinterlassen, da ja der Paketcache-Inhalt "weg" ist während des Vorgangs)

(Wiederherstellen des Ursprungs mit:)
rmdir /var/cache/pacman/pkg
mv /var/cache/pacman/orig-pkg /var/cache/pacman/pkg

Ich kann aktuell leider keinen Bugreport schreiben.

So, letzter Beitrag zum Monolog ;-)

Das (mein) "Problem" muß auch schon mit 5.0.1.4 bestanden sein, da der erste fehlgeschlagene Update-Lauf ja unter/mit dieser Version gelaufen ist. pkg-rel -5 war ja "nur" ein Rekompilieren wg. openssl-SO-Bump.
Mein pacman.log

...
[2016-07-10 13:28] [ALPM] upgraded pacman-mirrorlist (20160512-1 -> 20160703-1)
[2016-07-10 13:28] [ALPM] error: cannot remove /var/cache/pacman/pkg/ (Ist kein 
Verzeichnis)
[2016-07-10 13:28] [ALPM] upgraded pacman (5.0.1-3 -> 5.0.1-4)
[2016-07-10 13:28] [ALPM] upgraded pciutils (3.4.1-1 -> 3.5.1-1)
...
        (-3 nach -4 OK, trotz Symlink)
...
[2017-04-25 13:04] [ALPM] upgraded openssh (7.4p1-2 -> 7.5p1-2)
[2017-04-25 13:04] [ALPM] error: cannot remove /var/cache/pacman/pkg/ (Ist kein Verzeichnis)
[2017-04-25 13:04] [ALPM] upgraded pacman (5.0.1-4 -> 5.0.1-5)
[2017-04-25 13:04] [ALPM] transaction failed
... (Und eben neu hier Abbruch wg. fehlendem Paketcache)

Ich habe in den SVN-Changes jetzt nichts gesehen/verstanden, was dieses Verhalten bewirkt.

Aber ich finde es schade (fehlerhaft) wenn das Paketdir-Verzeichnis nun unbedingt ein reguläres Verzeichnis sein muß, bzw. das "Verhalten" (entfernen und neues, leeres Dir) während des Updatens.
Abhilfe werde ich wohl testen/überlegen:
a) extra NFS-Share für den Paketcache und diesen mounten
b) versuchen ggf. ein bind-mount

Aber ein Symlink ist halt so einfach und schnell ;-)

Hallo GerBra,

die Fehlermeldung kenne ich, auch ich habe auf diversen Rechnern diesen symlink gesetzt um die Pakete zentral zu verwalten. In meinem Fall wird sshfs und systemd-automount verwendet. Das pacman update auf die aktuelle Version iiegt jetzt ca. 4 Wochen zurück, aber besondere Probleme gab es deswegen bei mir nicht (keinerlei Änderungen). Ansonsten läuft auch alles bei den Updates weiter wie gewünscht. 😉

Gruß, LW

Also ich kann es weiterhin reproduzieren, und auch die --debug Ausgaben zeigen hier wie der Fehler passiert.
Kannst du testweise einfach mal pacman sich selbst aktualisieren lassen? Wie gesagt, es passiert nur wenn pacman upgradet/reinstalliert wird. Nicht bei "normalen" Updates von Paketen. Dem Cache passiert auch nichts, dem System nicht wenn es aktuell ist. Muß halt nur ggf. den Symlink wieder herstellen.

Das ist bei mir die Ausgangssituation:

# LANG=C ls -ld /var/cache/pacman/*
lrwxrwxrwx 1 root root 14 Apr 26 09:48 /var/cache/pacman/pkg -> /mnt/s01/pkg64

# LANG=C stat /var/cache/pacman/pkg
  File: /var/cache/pacman/pkg -> /mnt/s01/pkg64
  Size: 14        	Blocks: 0          IO Block: 4096   symbolic link
Device: 802h/2050d	Inode: 9568260     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-04-26 09:48:08.234586255 +0200
Modify: 2017-04-26 09:48:04.111378038 +0200
Change: 2017-04-26 09:48:04.111378038 +0200
 Birth: -

Jetzt simuliere ich ein Systemupdate (-Syu) inkl. des pacman-Paketes, indem ich pacman reinstalliere und zusätzlich ein neues Paket installiere. Letzteres, um den Punkt "hinterläßt ein teilaktualisiertes System" zu verdeutlichen.

Beide Pakete (pacman und pastebinit) sind im Cache vorhanden.

# LANG=C pacman -S pacman pastebinit
warning: pacman-5.0.1-5 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (2) pacman-5.0.1-5  pastebinit-1.5-1

Total Installed Size:  4.97 MiB
Net Upgrade Size:      0.55 MiB

:: Proceed with installation? [Y/n] y
(2/2) checking keys in keyring                         [#############################] 100%
(2/2) checking package integrity                       [#############################] 100%
(2/2) loading package files                            [#############################] 100%
(2/2) checking for file conflicts                      [#############################] 100%
(2/2) checking available disk space                    [#############################] 100%
:: Processing package changes...
error: cannot remove /var/cache/pacman/pkg/ (Not a directory)
(1/2) reinstalling pacman                              [#############################] 100%
error: could not open file /var/cache/pacman/pkg/pastebinit-1.5-1-any.pkg.tar.xz: No such file or directory
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

Wie man sieht, nach der Reinstallation des pacman-Paketes war der vormals intakte Cache weg/leer, was die weitere Transaktion (pastebinit) unmöglich macht (= teilaktualisiertes System, z.B. keine post-Hooks, usw).
Beim pastebinit Paket hat mir dieser Abbruch auch "kaputte" Metadaten in /var/lib/pacman/local/pastebinit-blablubb/ hinterlassen, welches ab hier weitere Arbeit mit pacman nicht möglich machen.

error: could not open file /var/lib/pacman/local/pastebinit-1.5-1/desc: No such file or directory
warning: could not fully load metadata for package pastebinit-1.5-1
error: failed to prepare transaction (invalid or corrupted package)

# touch /var/lib/pacman/local/pastebinit-1.5-1/{desc,files}
# pacman -R pastebinit

Ich stelle den Symlink zum Cache wieder her und starte erneut den Lauf mittels --debug Ausgabe:

# rmdir /var/cache/pacman/pkg/
# ln -s /mnt/s01/pkg64 /var/cache/pacman/pkg

# LANG=C pacman --debug -S pacman pastebinit 2>&1 | tee symlink-pacman.log

Das vollständige --debug Log ist hier zu finden:
https://pastebin.com/smnfDDNi

Zwei relevante Stellen in der debug-Ausgabe wo es wohl passiert sehe ich:

...
debug: installing packages
reinstalling pacman...
debug: reinstalling package pacman-5.0.1-5
debug: removing old package first (pacman-5.0.1-5)
debug: removing 349 files
debug: keeping directory /var/lib/pacman/ (contains files)
debug: keeping directory /var/lib/ (contains files)
debug: unlinking /var/cache/pacman/pkg/
error: cannot remove /var/cache/pacman/pkg/ (Not a directory)
debug: keeping directory /var/cache/pacman/ (contains files)
debug: keeping directory /var/cache/ (contains files)
debug: keeping directory /var/ (contains files)
....

Also wird /var/cache/pacman/pk hier entweder schon beim unlinken entfernt, bzw. versucht zu entfernen. Da eben "not an directory", sondern ein (symlink)-File. Der Inhalt wird nicht geprüft wie bei den regulären Dirs.

Letztendlich kritisch wird es dann weiter unten, wo der Inhalt des pacman.pkg.tar.xz neu entpackt wird:

debug: removing entry 'pacman' from 'local' cache
debug: extracting files
debug: opening archive /var/cache/pacman/pkg/pacman-5.0.1-5-x86_64.pkg.tar.xz
...
debug: action: leaving existing file in place  (<------ Kommentar: eben nicht!!!)
...
debug: extracting /usr/bin/pacman-db-upgrade
debug: extract: skipping dir extraction of /var/
debug: extract: skipping dir extraction of /var/cache/
debug: extract: skipping dir extraction of /var/lib/
debug: extract: skipping dir extraction of /var/lib/pacman/
debug: extract: skipping dir extraction of /var/cache/pacman/          (<-------- Bis hier OK)
debug: extract: overwriting file with dir /var/cache/pacman/pkg/      (<-------- Sehr bööööse!!!)
debug: extracting /var/cache/pacman/pkg/
debug: updating database
debug: adding database entry 'pacman'

pacman ersetzt nun also /var/cache/pacman/pkg mit dem *Inhalt* aus dem pkg.tar.gz und erzeugt so einen "leeren" Cache. Sieht man auch deutlich am timestamp dieses Cache-Dirs:

# LANG=C ls -ld /var/cache/pacman/*
drwxr-xr-x 2 root root 4096 Feb 11 12:49 /var/cache/pacman/pkg

Feb 11 12:49 ist exakt der Timestamp aus dem pkg.tar.xz

Und das passiert nur mir? Ein Symlink ist aus FS-Sicht immer ein "File", deshalb müßte das Unlinken/Entpacken ("not a dir") doch bei Dir (Euch) auch passieren. Ich könnte mir ad hoc nicht erklären, warum das nur bei mir so stattfinden sollte...

Das Erzeugen von z.B. Verzeichnissen durch einfaches Entpacken aus Archiven ist IMHO zumindest hier ohne weiter Prüfung nicht optimal, und führt bei lediglicher Prüfung von "directory" und "not empty" dann zu diesem Fehler.

LessWire schriebEin wesentlicher Unterschied ist, daß "/var/cache/pacman/pkg" bei mir der mountpoint ist, also kein symlink (sorry, oben von mir falsch beschrieben).(

OK, dann greift das Problem ja nicht, da pkg bei dir ein reguläres Directory ist (aus pacman Sicht), du mountest ja den Inhalt da rein.
Ich werde mir wohl wie weiter oben anders behelfen, v.a. weil ich wirklich nicht mehr sicher bin ob es nun seit pkgrel -4 passiert - seit wann ich den gemeinsamen Paketpool auf diesem Rechner verwende habe ich nicht dokumentiert. Obs also wirklich erst seit -4 auftritt.
Für nen Bugreport müßte ich meine alten Account wieder raussuchen, mal sehen (evtl. gab es ja schon mal was, ggf. mit Won't fix ;-)
Nicht dramatisch (wenn man es neudeutsch "händeln" kann), aber IMHO unsinnig weil: Programme haben (sym)links transparent zu folgen, außer es wäre ein Sicherheitsdingens...

GerBra(offline) schrieb ... Programme haben (sym)links transparent zu folgen, außer es wäre ein Sicherheitsdingens...

So ist es, evtl. sehen die Entwickler das aber doch als "Sicherheitsdingens" - it's a feature, not a bug. 🙂

Ich habe das Problem seit gestern nur beiläufig überflogen.
Ich vermute das Problem besteht darin, dass der Pfad /var/cache/pacman/pkg Als Ordnerpfad Bestandteil des Pacman-Pakets ist.
Deswegen funktioniert @LessWires Konfiguration mit Mountpoint auch, weil besagte Ordnerstruktur vorhanden ist.
@GerBras Konfiguration funktioniert hingegen nicht, da das letzte Element seines Pfades ein Symlink und kein Ordner ist → Konflikt.
Da es ein Symlink anstatt eines Ordners ist, löscht pacman ihn automatisch und ersetzt ihn durch den Ordner aus dem Paket.
Eine (Datei-) Konfliktwarnung gibt es nicht, da es sich ja um dasselbe Paket handelt, dem der Pfad gehört (pacman).
Kann man übrigens mit jedem x-beliebigen Paket nachvollziehen:

$ sudo mv /usr/include/bash /usr/include/my_custom_bash
$ sudo ln -s /usr/include/my_custom_bash /usr/include/bash
$ ls -l /usr/include/bash
lrwxrwxrwx 1 root root 27 26. Apr 14:31 /usr/include/bash -> /usr/include/my_custom_bash
$ sudo pacman -S bash
Warnung: bash-4.4.012-2 ist aktuell -- Reinstalliere
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Pakete (1) bash-4.4.012-2

Gesamtgröße des Downloads:           1,38 MiB
Gesamtgröße der installierten Pakete:  7,13 MiB
Größendifferenz der Aktualisierung:  0,00 MiB

:: Installation fortsetzen? [J/n] 
:: Empfange Pakete...
 bash-4.4.012-2-x86_64                                                                               1417,7 KiB  3,85M/s 00:00 [#############################################################################] 100%
(1/1) Prüfe Schlüssel im Schlüsselring                                                                                         [#############################################################################] 100%
(1/1) Überprüfe Paket-Integrität                                                                                               [#############################################################################] 100%
(1/1) Lade Paket-Dateien                                                                                                       [#############################################################################] 100%
(1/1) Prüfe auf Dateikonflikte                                                                                                 [#############################################################################] 100%
(1/1) Überprüfe verfügbaren Festplattenspeicher                                                                                [#############################################################################] 100%
:: Verarbeite Paketänderungen...
Fehler: Konnte /usr/include/bash/ nicht entfernen (Ist kein Verzeichnis)
(1/1) Installiere bash                                                                                                         [#############################################################################] 100%
:: Starte post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Updating the info directory file...
$ 

Der Folgefehler

GerBra(offline) schrieb

error: could not open file /var/cache/pacman/pkg/pastebinit-1.5-1-any.pkg.tar.xz: No such file or directory
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

entsteht übrigens daraus, dass der nun frisch durch den leeren Ordner aus dem Pacman Paket ersetzte pkg-cache nun leer ist.

Aller guten Dinge sind drei:
Es ist grundsätzlich keine gute Idee, die zu Paketen gehörenden Pfaden zu zweckentfremden, auch wenn es im Fall von @LessWire klappt.
Für euer Szenario würde ich sinngemäß folgendes Alias vorschlagen:

alias pacman="/usr/bin/pacman --cachedir /my/pkg/cache/on/nfs/share"

Warum passt ihr den Pfad nicht einfach in der pacman.conf an?

drcux schriebWarum passt ihr den Pfad nicht einfach in der pacman.conf an?

Super Hinweis. Noch viel besser als ein Alias.

Viele Wege führen nach Rom, danke Schard und drcux für die Hinweise.

Es gab schon einen (ähnlich gelagerten) Bugreport
https://bugs.archlinux.org/task/50298
mit close->Not a bug. Wenn ich einen schreibe endet der wohl genauso, bin noch am überlegen...

Ich halte es halt deswegen für einen Programmfehler, da pacman diese Situation wenn dann viel früher behandeln müßte - vor jeglicher Veränderung am System, anstatt aktuell holzhammerartig mitten im Updateprozeß - wenn es denn so wichtig ist, daß /var/cache/pacman/pkg einem bestimmten Regularium entsprechen muß. Diese "Bedingung" ist auch AFAIK nirgend dokumentiert und symlinks sind ein normales Werkzeug auf FS-Ebene.

GerBra(offline) schrieb Ich halte es halt deswegen für einen Programmfehler, da pacman diese Situation wenn dann viel früher behandeln müßte - vor jeglicher Veränderung am System, anstatt aktuell holzhammerartig mitten im Updateprozeß - wenn es denn so wichtig ist, daß /var/cache/pacman/pkg einem bestimmten Regularium entsprechen muß. Diese "Bedingung" ist auch AFAIK nirgend dokumentiert und symlinks sind ein normales Werkzeug auf FS-Ebene.

Ja, ich gebe dir Recht, Pacman müsste mit einer Fehlermeldung ala "/var.... ist ein Symlink, sollte ein Verzeichnis sein" abbrechen, aber ein Verzeichnis anzufassen, das zu einem Paket gehört, ist auch nicht nett.... ;-)
AFAIK kann man alle Arbeits-Verzeichnisse, die fest zu einem Paket gehören, in einer entsprechenden Config ändern, und nur das ist eigentlich der richtige Weg, ansonsten funktioniert ein Bind-Mount bei so etwas immer und ist zu bevorzugen.