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.