Du bist nicht angemeldet.

#1 13.03.2021 18:53:35

T-matze
Mitglied

[solved] Update-Fehler mit npm bzw. apm: "existiert im Dateisystem"

Hallo zusammen,

seit einigen Tagen kann ich kein pacman -Syu mehr durchlaufen lassen, weil es immer mit einer langen Liste an gleichlautenden Fehlern abbricht:

 apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/node_modules/(und dann geht der Pfad in vielen Varianten weiter) existiert im Dateisystem. 

Leider hat mich die Suche nach diesem Output weder mit der deutschen Erklärung noch meinem Versuch einer englischen Variante (exists in file system) zu einem für mich verständlichen Ergebnis gebracht.
Mein Vanilla Arch ist eigentlich immer auf dem aktuellen Stand (ca. alle 1-2 Wochen upgedated).
uname -r erzählt mir 5.11.1-arch1-1

Welche Infos braucht Ihr zur Eingrenzung des Fehlers?

Vielen Dank für jede Hilfe!
T-matze

Beitrag geändert von T-matze (15.03.2021 01:52:33)

Offline

#2 13.03.2021 19:09:43

schard
Moderator

Re: [solved] Update-Fehler mit npm bzw. apm: "existiert im Dateisystem"

Du hast offensichtlich NPM Module an Pacman vorbei installiert.
Du solltest diese Dateien löschen und das per Pacman installieren.

Offline

#3 14.03.2021 13:24:07

T-matze
Mitglied

Re: [solved] Update-Fehler mit npm bzw. apm: "existiert im Dateisystem"

Danke, schard, für die Einschätzung und den Lösungsvorschlag.

Bewusst habe ich die NPM-Module nicht separat installiert, aber die kamen wohl mit einem anderen Programm mit und ich habe mal, als es da Meldungen gab, "sudo npm update" oder so was ausgeführt. Wie ich inzwischen an manchen Orten gelesen habe, soll man npm updates und installs nicht mit sudo ausführen, weil das Probleme nach sich ziehen kann. Quod erat demonstrandum.

Auf Deinen Vorschlag hin habe ich also zuerst das Verzeichnis /usr/lib/node_modules/npm/ und dann noch /usr/lib/node_modules/atom-package-manager/ umbenannt (damit sie nicht mehr gefunden werden, aber wiederhergestellt werden könnten, falls erforderlich) und dann das Update nochmal durchlaufen lassen, in der Hoffnung, dass die jetzt fehlenden Abhängigkeiten wieder regulär von Pacman installiert werden. Ich verwende trizen als wrapper, um das AUR mit einzubeziehen. Mit "trizen -Syu | tee mitschrieb.log" habe ich die Ausgabe gleich in eine Datei abgezweigt, was sich jetzt als hilfreich erweist.

"nach-npm-umbenennen.log" sieht so aus:

:: Pacman command: /usr/bin/sudo /usr/bin/pacman -Syu
:: Synchronisiere Paketdatenbanken...
 core.db downloading...
 extra.db downloading...
 community.db downloading...
 multilib.db downloading...
:: Starte vollständige Systemaktualisierung...
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Paket (213)                                     Alte Version     Neue Version      Netto-Veränderung

core/acl                                        2.2.53-3         2.3.0-1                    0,00 MiB
extra/alsa-card-profiles                        1:0.3.22-1       1:0.3.23-1                 0,00 MiB
community/android-udev                          20201003-1       20210302-1                 0,00 MiB
community/apm                                   2.6.1-1          2.6.1-2                   19,93 MiB
community/aqbanking                             6.2.5-1          6.2.10-1                   0,06 MiB
community/atom                                  1.54.0-1         1.55.0-1                  -2,39 MiB
core/attr                                       2.4.48-3         2.5.0-1                    0,00 MiB
core/audit                                      3.0-1            3.0.1-1                    0,03 MiB
extra/breeze                                    5.21.1-1         5.21.2-1                   0,00 MiB
core/btrfs-progs                                5.10.1-2         5.11-1                     0,01 MiB
extra/chromium                                  88.0.4324.182-1  89.0.4389.90-1             7,56 MiB
... und so weiter ... 
extra/xfce4-cpufreq-plugin                      1.2.4-1          1.2.5-1                    0,01 MiB
extra/xfce4-netload-plugin                      1.3.2-2          1.4.0-1                   -0,01 MiB
extra/xfce4-systemload-plugin                   1.2.4-1          1.3.0-1                    0,03 MiB
extra/xfce4-time-out-plugin                     1.1.1-1          1.1.2-1                    0,00 MiB
extra/xorgproto                                 2020.1-1         2021.3-1                   0,02 MiB
community/youtube-dl                            2021.02.22-1     2021.03.03-1               0,04 MiB
core/zstd                                       1.4.8-1          1.4.9-1                    0,01 MiB

Gesamtgröße der installierten Pakete:  3163,32 MiB
Größendifferenz der Aktualisierung:      32,04 MiB

Prüfe Schlüsselring...
Prüfe Paketintegrität...
Lade Paket-Dateien...
Prüfe auf Dateikonflikte...
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/AUTHORS existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/CHANGELOG.md existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/CONTRIBUTING.md existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/LICENSE existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/README.md existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/bin/node-gyp-bin/node-gyp existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/bin/node-gyp-bin/node-gyp.cmd existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/bin/npm existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/bin/npm-cli.js existiert im Dateisystem
... und so weiter ...
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/node_modules/yargs/package.json existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/node_modules/yargs/yargs.js existiert im Dateisystem
apm: /usr/lib/node_modules/atom-package-manager/node_modules/npm/package.json existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.
 1. electron9: 9.4.3-1 ==> 9.4.4-2

Okay, also noch das Verzeichnis atom-package-manager umbenannt, dann das nächste Update geloggt, "nach-apm-umbenennen.log" sieht so aus:

:: Pacman command: /usr/bin/sudo /usr/bin/pacman -Syu
:: Synchronisiere Paketdatenbanken...
 core.db downloading...
 extra.db downloading...
 community.db downloading...
 multilib.db downloading...
:: Starte vollständige Systemaktualisierung...
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Paket (213)                                     Alte Version     Neue Version      Netto-Veränderung

core/acl                                        2.2.53-3         2.3.0-1                    0,00 MiB
extra/alsa-card-profiles                        1:0.3.22-1       1:0.3.23-1                 0,00 MiB
community/android-udev                          20201003-1       20210302-1                 0,00 MiB
community/apm                                   2.6.1-1          2.6.1-2                   19,93 MiB
community/aqbanking                             6.2.5-1          6.2.10-1                   0,06 MiB
community/atom                                  1.54.0-1         1.55.0-1                  -2,39 MiB
core/attr                                       2.4.48-3         2.5.0-1                    0,00 MiB
... kennen wir ja schon ...
community/xapp                                  2.0.5-1          2.0.7-1                    0,01 MiB
extra/xfce4-cpufreq-plugin                      1.2.4-1          1.2.5-1                    0,01 MiB
extra/xfce4-netload-plugin                      1.3.2-2          1.4.0-1                   -0,01 MiB
extra/xfce4-systemload-plugin                   1.2.4-1          1.3.0-1                    0,03 MiB
extra/xfce4-time-out-plugin                     1.1.1-1          1.1.2-1                    0,00 MiB
extra/xorgproto                                 2020.1-1         2021.3-1                   0,02 MiB
community/youtube-dl                            2021.02.22-1     2021.03.03-1               0,04 MiB
core/zstd                                       1.4.8-1          1.4.9-1                    0,01 MiB

Gesamtgröße der installierten Pakete:  3163,32 MiB
Größendifferenz der Aktualisierung:      32,04 MiB

Prüfe Schlüsselring...
Prüfe Paketintegrität...
Lade Paket-Dateien...
Prüfe auf Dateikonflikte...
Überprüfe verfügbaren Festplattenspeicher...
:: Starte pre-transaction hooks...
(1/3) Removing linux initcpios...
(2/3) Remove DKMS modules
==> dkms remove --no-depmod -m rtl8822bu -v 20180723 -k 5.10.19-1-lts
==> dkms remove --no-depmod -m rtl8822bu -v 20180723 -k 5.11.1-arch1-1
==> depmod 5.11.1-arch1-1
==> depmod 5.10.19-1-lts
(3/3) Unregistering Haskell modules...
:: Verarbeite Paketänderungen...
Aktualisiere attr...
Aktualisiere acl...
Aktualisiere alsa-card-profiles...
Aktualisiere zstd...
Aktualisiere e2fsprogs...
Aktualisiere audit...
Aktualisiere device-mapper...
Aktualisiere cryptsetup...
Aktualisiere android-udev...
Aktualisiere nodejs...
Aktualisiere npm...
Aktualisiere apm...
Aktualisiere gnutls...
Aktualisiere gwenhywfar...
Aktualisiere aqbanking...
Aktualisiere dconf...
Aktualisiere xorgproto...
Aktualisiere libx11...

... aha, er macht also endlich was ...

Aktualisiere xapp...
Aktualisiere xfce4-cpufreq-plugin...
Aktualisiere xfce4-netload-plugin...
Aktualisiere xfce4-systemload-plugin...
Aktualisiere xfce4-time-out-plugin...
Aktualisiere youtube-dl...
:: Starte post-transaction hooks...
( 1/20) Creating system user accounts...
( 2/20) Reloading system manager configuration...
( 3/20) Creating temporary files...
( 4/20) Reloading device manager configuration...
( 5/20) Arming ConditionNeedsUpdate...
( 6/20) Updating module dependencies...
( 7/20) Install DKMS modules
==> dkms install --no-depmod -m rtl8822bu -v 20180723 -k 5.11.6-arch1-1
==> dkms install --no-depmod -m rtl8822bu -v 20180723 -k 5.10.23-1-lts
==> depmod 5.10.23-1-lts
==> depmod 5.11.6-arch1-1
( 8/20) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'default'
  -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts.img
==> Starting build: 5.10.23-1-lts
  -> Running build hook: [base]
ln: die symbolische Verknüpfung '/tmp/mkinitcpio.aOWOYI/root/usr/bin/lsmod' konnte nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
ln: die symbolische Verknüpfung '/tmp/mkinitcpio.aOWOYI/root/usr/bin/modprobe' konnte nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
ln: die symbolische Verknüpfung '/tmp/mkinitcpio.aOWOYI/root/usr/bin/modinfo' konnte nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/sbin/blkid' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/lib/libblkid.so.1' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/sbin/mount' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/lib/libmount.so.1' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/lib/libblkid.so.1' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/lib/librt.so.1' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/sbin/switch_root' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/init_functions' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/init' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
  -> Running build hook: [udev]
install: das Verzeichnis '/tmp/mkinitcpio.aOWOYI/root/usr/lib/systemd' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar

... Mist, was ist jetzt schon wieder los? Kein Platz mehr??? ... 

install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/lib/libcom_err.so.2' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/lib/libblkid.so.1' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/lib/libuuid.so.1' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/usr/lib/libe2p.so.2' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
ln: die symbolische Verknüpfung '/tmp/mkinitcpio.aOWOYI/root/usr/bin/fsck.ext2' konnte nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
ln: die symbolische Verknüpfung '/tmp/mkinitcpio.aOWOYI/root/usr/bin/fsck.ext3' konnte nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
==> WARNING: No fsck helpers found. fsck will not be run on boot.
/usr/lib/initcpio/functions: Zeile 628: /tmp/mkinitcpio.aOWOYI/root/config: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
tee: /tmp/mkinitcpio.aOWOYI/root/buildconfig: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
cp: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/crc32c_generic.ko.xz' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
cp: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/ext4.ko.xz' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
cp: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/sr_mod.ko.xz' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
cp: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/mmc_block.ko.xz' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
cp: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/serio_raw.ko.xz' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
cp: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/xhci-pci-renesas.ko.xz' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
cp: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/crc16.ko.xz' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar

... okay, dasselbe Problem bei install, ln und cp ...

xz: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/virtio_blk.ko.xz: Datei oder Verzeichnis nicht gefunden
xz: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/cdrom.ko.xz: Datei oder Verzeichnis nicht gefunden
xz: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/firewire-sbp2.ko.xz: Datei oder Verzeichnis nicht gefunden
xz: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/xhci-pci.ko.xz: Datei oder Verzeichnis nicht gefunden
xz: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/usb-storage.ko.xz: Datei oder Verzeichnis nicht gefunden
xz: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/firewire-core.ko.xz: Datei oder Verzeichnis nicht gefunden
xz: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/rtsx_pci.ko.xz: Datei oder Verzeichnis nicht gefunden
xz: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/kernel/crc32c-intel.ko.xz: Datei oder Verzeichnis nicht gefunden
==> Generating module dependencies
install: reguläre Datei '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/modules.builtin' kann nicht angelegt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
/usr/lib/initcpio/functions: Zeile 811: /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/modules.order: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
depmod: WARNING: could not open modules.order at /tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts: No such file or directory
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.dep.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.dep.bin.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.alias.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.alias.bin.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.softdep.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.symbols.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.symbols.bin.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.builtin.bin.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.builtin.alias.bin.133880.995424.1615664971, 301, 644): No space left on device
depmod: ERROR: openat(/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts, modules.devname.133880.995424.1615664971, 301, 644): No space left on device
rm: das Entfernen von '/tmp/mkinitcpio.aOWOYI/root/lib/modules/5.10.23-1-lts/modules.!(*.bin|devname|softdep)' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
==> Creating zstd-compressed initcpio image: /boot/initramfs-linux-lts.img
==> WARNING: errors were encountered during the build. The image may not be complete.
==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'fallback'
  -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts-fallback.img -S autodetect
==> Starting build: 5.10.23-1-lts
  -> Running build hook: [base]

... Für depmod dasselbe Problem, nur diesmal auf englisch. Und xz soll wohl etwas komprimieren? xz und rm klappt natürlich nicht, wenn die Datei nicht angelegt werden konnte...

depmod: ERROR: openat(/tmp/mkinitcpio.5C6jto/root/lib/modules/5.11.6-arch1-1, modules.devname.138372.842831.1615664981, 301, 644): No space left on device
rm: das Entfernen von '/tmp/mkinitcpio.5C6jto/root/lib/modules/5.11.6-arch1-1/modules.!(*.bin|devname|softdep)' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
==> Creating zstd-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> WARNING: errors were encountered during the build. The image may not be complete.
( 9/20) Reloading system bus configuration...
(10/20) Warn about old perl modules
(11/20) Probing GDK-Pixbuf loader modules...
(12/20) Registering Haskell modules...
(13/20) Updating GIO module cache...
(14/20) Compiling GSettings XML schema files...
(15/20) Probing GTK3 input method modules...
(16/20) Updating icon theme caches..
(17/20) Updating pacman-mirrorlist with reflector and removing pacnew...
[2021-03-13 20:49:53] WARNING: failed to rate http(s) download (https://archlinux.thaller.ws/community/os/x86_64/community.db): Download timed out after 5 second(s).
[2021-03-13 20:49:58] WARNING: failed to rate http(s) download (https://mirror.chaoticum.net/arch/community/os/x86_64/community.db): Download timed out after 5 second(s).
[2021-03-13 20:50:04] WARNING: failed to rate http(s) download (https://mirror.ubrco.de/archlinux/community/os/x86_64/community.db): Download timed out after 5 second(s).
[2021-03-13 20:50:10] WARNING: failed to rate http(s) download (https://mirror.selfnet.de/archlinux/community/os/x86_64/community.db): Download timed out after 5 second(s).
[2021-03-13 20:50:15] WARNING: failed to rate http(s) download (https://ftp.halifax.rwth-aachen.de/archlinux/community/os/x86_64/community.db): Download timed out after 5 second(s).
[2021-03-13 20:50:20] WARNING: failed to rate http(s) download (https://mirror.pseudoform.org/community/os/x86_64/community.db): Download timed out after 5 second(s).
[2021-03-13 20:50:27] WARNING: failed to rate http(s) download (https://mirror.pkgbuild.com/community/os/x86_64/community.db): Download timed out after 5 second(s).
[2021-03-13 20:50:32] WARNING: failed to rate http(s) download (https://mirror.wtnet.de/arch/community/os/x86_64/community.db): Download timed out after 5 second(s).
[2021-03-13 20:50:37] WARNING: failed to rate http(s) download (https://phinau.de/arch/community/os/x86_64/community.db): Download timed out after 5 second(s).

... Das Image ist wohl nicht vollständig; verständlich, bei den ganzen Fehlermeldungen. Warum aber die Timeouts bei den Mirrors aufgetreten sind, weiß ich nicht. ...

[2021-03-13 20:53:03] WARNING: failed to rate http(s) download (https://mirror.fsrv.services/archlinux/community/os/x86_64/community.db): Download timed out after 5 second(s).
(18/20) Updating the info directory file...
(19/20) Updating the desktop file MIME type cache...
(20/20) Updating the MIME type database...
 1. electron9: 9.4.3-1 ==> 9.4.4-2

Aha, jetzt war also nicht genug Speicherplatz im /tmp vorhanden. "df -h" zeigt mir, dass auf Root und Home noch reichlich Platz ist, aber /tmp zu 95% verwendet wird. (Warum wird der swapfile nicht vollständig genutzt? Der ist auch noch halb leer, als ich in htop nachschaue.) Als Lösung habe ich mit "sudo mount --bind /tmp ~/Public" das temporäre Verzeichnis an einen Ort mit genug freiem Speicherplatz gemounted, um dann das Update nochmal ohne das Speicherplatzproblem durchlaufen zu lassen. 

"nach-tmp-mount.log" sieht so aus:

:: Pacman command: /usr/bin/sudo /usr/bin/pacman -Syu
:: Synchronisiere Paketdatenbanken...
 core.db downloading...
 extra.db downloading...
 community.db downloading...
 multilib.db downloading...
:: Starte vollständige Systemaktualisierung...
 Es gibt nichts zu tun
 1. electron9: 9.4.3-1 ==> 9.4.4-2

Also alles hübsch, hat das Update vorher doch geklappt? (Hier kommt der Noob in mir durch...)
Ein Neustart hat mich dann eines Besseren belehrt: Grub kommt noch, dann aber scheitert der Aufruf des Kernels und ich komme nicht weiter. Weder der normale Linux-Kernel, noch der LTS-Kernel, noch einer der Fallbacks kann starten.

Also habe ich zunächst mit der letzten ISO, die ich sowieso auf dem Stick hatte, Arch Linux gestartet, um dann per "arch-chroot" in das bereits installierte System zu kommen und nochmal ein Update mit jetzt nicht zu vollem Speicher durchlaufen zu lassen (hat nichts anderes bewirkt, als im letzten Log gezeigt). Na gut, dann muss ich eben "mkinitcpio" nochmal händisch anstoßen, damit die initramfs gebaut werden. Hat aber nicht geklappt, weil die verwendete ISO zu alt war. Also habe ich auf einem anderen Rechner die aktuelle ISO runtergeladen und auf den Live-Stick geschoben (Ventoy machts möglich), um dann mit dem aktuellen Arch arbeiten zu können. Jetzt erzählt er mir aber, wenn ich das installierte System mounten möchte:

mount: /mnt: unknown filesystem type 'ext4'

was ich nicht nachvollziehen kann, da ich mich ja bereits unter Arch befinde und das also ext4 kennen sollte. Auch die unter https://superuser.com/questions/1238598 … t4#1258837 genannte Lösung kann ich nicht anwenden, weil ich, um linux neu installieren zu können, ja erstmal das System mounten können müsste...

Jetzt gerade bin ich mit einem Livesystem (Kali) hierher gekommen, um die Logs und meine Überlegungen posten zu können. Bitte gebt mir Tipps, wie ich entweder aus dem Livesystem heraus oder von der Konsole nach Starten der Arch-ISO mein System wieder zum Laufen bringe. Ist die Idee, mit "mkinitcpio -P" die initramfs neu schreiben zu lassen, richtig? Oder muss ich eine Stufe vorher ansetzen und den Linux-Kernel neu instalieren, weil dort das Update am vermeintlich fehlenden Speicher gescheitert ist? Oder habe ich mich gedanklich völlig verlaufen?

Vielen Dank und einen schönen Sonntag
T-matze

Offline

#4 14.03.2021 15:03:02

T-matze
Mitglied

Re: [solved] Update-Fehler mit npm bzw. apm: "existiert im Dateisystem"

Okay, ein kleines Update:

Der Fehler mit dem nicht erkannten ext4 Filesystem besteht beim aktuellen Versuch nicht mehr, warum auch immer. Ich kann die aktuelle ISO starten und das installierte System mounten, per arch-chroot hineinwechseln und ein Update durchführen.

"pacman -Syyy" und "pacman -Syu" sind fehlerfrei durchgelaufen, haben diesmal aber mit linux oder linux-lts nichts gemacht.
"pacman -R linux-lts" gefolgt von "pacman -S linux-lts" hat zunächst den LTS-Kernel rausgeschmissen und dann neu installiert, anschließend habe ich dasselbe für den "normalen" Kernel wiederholt.

Voller Erwartung habe ich neu gestartet, leider mit unverändertem Misserfolg.
Nach einem erneuten arch-chroot ins installierte, aber nicht startfähige System habe ich dann noch "mkinitcpio -P" ausgeführt, wenngleich ich annehmen muss, dass dies bei der Neuinstallation der Linux-Kernel ja bereits ausgeführt worden war. Das lief auch ohne Fehlermeldung durch. Dennoch komme ich beim Neustart nicht weiter als bisher.

Wer kann mir bitte die Tomaten von den Augen nehmen?

Vielen Dank und LG
T-matze

Offline

#5 14.03.2021 18:32:29

GerBra
Mitglied

Re: [solved] Update-Fehler mit npm bzw. apm: "existiert im Dateisystem"

T-matze schrieb:

Okay, ein kleines Update:

Der Fehler mit dem nicht erkannten ext4 Filesystem besteht beim aktuellen Versuch nicht mehr, warum auch immer. Ich kann die aktuelle ISO starten und das installierte System mounten, per arch-chroot hineinwechseln und ein Update durchführen.

Hast du eine separate Partition für /boot und vergessen, diese vor dem arch-chroot/mkinitcpio einzubinden?
Wenn ja, dann ist die Vorarbeit nach dem ISO-Boot:
mount /dev/sdXY /mnt (für dein /)
mount /dev/sdXX /mnt/boot (für dein /boot, bzw. schau in der /mnt/etc/fstab nach wie dein /boot normalerweise eingehängt wird)
Dann arch-chroot /mnt und darin per mkinitcpio die initramfs-Images erstellen.

//Edit: noch zwei Anmerkungen
a) Swap-Speicher ist nur zum Ausgleich von mangelndem Arbeitsspeicher zuständig, nicht für fehlenden Speicherplatz in den Dateisystemen (hier greift höchstens die sog. Root-Reserve, wenn eingerichtet).
b) /tmp sollte eigentlich ein tmpfs sein mit der Größe von 50% deines Arbeitsspeichers, also bei heutigen Rechnern eigentlich ausreichend für sowas wie mkinitcpio...

Beitrag geändert von GerBra (14.03.2021 18:58:42)

Offline

#6 15.03.2021 01:02:32

T-matze
Mitglied

Re: [solved] Update-Fehler mit npm bzw. apm: "existiert im Dateisystem"

Hi GerBra,

danke fürs Mitdenken und den Tipp mit der Boot-Partition. Ich habe da jetzt mal aufgeräumt, weil ich tatsächlich ein kleines Durcheinander hatte: Es existiert eine dezidierte Boot-Partition, die aber laut fstab nicht eingebunden wurde. Vor dem arch-chroot hatte ich sowohl die Root- als auch die Boot-Partition gemountet, also hat die Boot-Partition während des mkinitcpio das in Root ebenfalls vorhandene Verzeichnis boot verdeckt und das Update abbekommen. Beim Neustart wurde die Partition dann laut fstab nicht wieder eingebunden, so dass das "veraltete" boot-Verzeichnis der Root-Partition angesprochen wurde und nichts starten konnte. Da muss man auch erstmal drauf kommen... Danke. Jetzt ist das Verzeichnis geleert und die Partition per fstab dort eingebunden. Nach einem nochmaligen grub-install und grub-mkconfig mit den jeweils passenden Flags startet mein System jetzt wieder brav.

Danke auch für die Erklärungen zum Swap und /tmp. Letzteres ist - wie von Dir beschrieben - ein tmpfs und hat die Hälfte meines RAM, ist aber nach einem Versuch, electron9 aus dem AUR upzudaten, auch schon wieder voll (weshalb das Update von electron9 gescheitert ist):

df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
dev             7,7G       0  7,7G    0% /dev
run             7,7G    1,3M  7,7G    1% /run
/dev/sda2       457G    200G  234G   47% /
tmpfs           7,7G       0  7,7G    0% /dev/shm
tmpfs           4,0M       0  4,0M    0% /sys/fs/cgroup
tmpfs           7,7G    7,4G  306M   97% /tmp
/dev/sda1       500M    107M  393M   22% /boot
/dev/sdb1       1,8T    665G  1,1T   39% /home
tmpfs           1,6G    132K  1,6G    1% /run/user/1000

Was kann ich (außer RAM aufrüsten) dagegen unternehmen?

OT: das eigentliche Problem dieses Threads ist gelöst, muss ich mit dieser Frage in einen eigenen Thread umziehen? /OT


//Edit:
Ich werde das Thema als gelöst markieren und meine vorletzte Frage selbst beantworten:

Auf https://aur.archlinux.org/packages/electron9/ bin ich hierzu fündig geworden.

jonathon commented on 2021-03-07 13:07
Please read the AUR wiki page before reporting issues.

If you are experiencing a build issue then ensure you are not using an AUR helper and are using a clean chroot.

You are effectively building Chromium from source and must have sufficient RAM/swap and disk space to do so. If you don't understand what "building from source" means, why you would do that, or simply don't have the time or resource to compile Chromium, then just use electron9-bin instead.



Ralf_Mardorf commented on 2021-03-12 05:03
Hi, using this PKGBUILD building electron 9.4.4-2 worked for me without a clean chroot. While I didn't use an AUR helper, I suspect an AUR helper can be used. However, assuming a tmpfs default size of half of the mentioned "32 GB RAM", an AUR helper unlikely can build electron in tmpfs. Building the package takes 29 GB on my machine. In my experiences swap isn't used, if tmpfs runs out of space, but it's possible to resize tmpfs. Maybe adding

tmpfs          /tmp            tmpfs nodev,nosuid,size=31G     0 0
to /etc/fstab works. The discontinued AUR helper yaourt provides a "--tmp /path/to/any/non-tmpfs/directory/" option. Btw. building on a SATA SSD with a Celeron G1840 2.80GHz dual-core and less than 8 GiB memory takes more than 19 hours.

Gut, also das Vergrößern des /tmp lässt sich über fstab bewerkstelligen.
Und wenn man sich den Ärger mit electron ersparen möchte, kann man auf electron-bin ausweichen.
Check.

Vielen Dank nochmal allen!

Beitrag geändert von T-matze (15.03.2021 01:51:03)

Offline

#7 15.03.2021 03:51:10

GerBra
Mitglied

Re: [solved] Update-Fehler mit npm bzw. apm: "existiert im Dateisystem"

Schön, daß dein System wieder läuft.

T-matze schrieb:

Danke auch für die Erklärungen zum Swap und /tmp. Letzteres ist - wie von Dir beschrieben - ein tmpfs und hat die Hälfte meines RAM, ist aber nach einem Versuch, electron9 aus dem AUR upzudaten, auch schon wieder voll (weshalb das Update von electron9 gescheitert ist):

df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
dev             7,7G       0  7,7G    0% /dev
run             7,7G    1,3M  7,7G    1% /run
/dev/sda2       457G    200G  234G   47% /
tmpfs           7,7G       0  7,7G    0% /dev/shm
tmpfs           4,0M       0  4,0M    0% /sys/fs/cgroup
tmpfs           7,7G    7,4G  306M   97% /tmp
/dev/sda1       500M    107M  393M   22% /boot
/dev/sdb1       1,8T    665G  1,1T   39% /home
tmpfs           1,6G    132K  1,6G    1% /run/user/1000

Was kann ich (außer RAM aufrüsten) dagegen unternehmen?

Zwei unterschiedliche Wege sehe ich:
a) Am /tmp rumfummeln
Hast du ja selber schon in den AUR-Kommentaren rausgefunden. Ich halte das aber eher für die zweitbeste Lösung. Ein größeres /tmp als tmpfs geht halt definitiv zu Lasten des Arbeitsspeichers wenn dieses /tmp mit Daten gefüllt wird. Dieser fehlt dann ggf. wieder für den Build-Vorgang. Ich würde da für den *einen* Vorgang nichts dran rütteln, genausowenig wie mehr RAM verbauen extra dafür.
Ich würde dann eher hingehen und das tmpfs für /tmp kurzfristig aushängen. Dein /tmp mit tmpfs hat z.Zt. max ~7,7G frei, deine Root-Partition(/) z.B. noch 234G.
Wenn du also /tmp aushängst gehen die Daten zum electron-Bau auch in das /tmp-Verzeichnis, belegt wird dann aber Speicherplatz von sda2.
Das Aushängen von /tmp ist allerdings etwas "tricky":
- es sollte kein User mehr angemeldet sein, ergo kein Windowmanager/Desktop laufen. Beim Aushängen werden bestehende Daten in /tmp einfach "vernichtet" (da ja ein volatiles Dateisystem).
- am besten nur als root auf einem TTY-Terminal angemeldet sein und das Aushängen vornehmen.
- weiterhin darauf achten, daß nach dem Aushängen /tmp noch den Berechtigungsstatus 1777 hat. Kann mit stat /tmp überprüft werden, ggf. mit chmod 1777 /tmp geändert werden. Dieser Zugriffstatus ist wichtig, damit alle User dort temporär ihre Temp-Daten sicher verwalten können.
- Danach können sich die User dann wieder anmelden und ihre Desktops starten.
- Nach dem electron-Bau müßte root dann nochmal alles unterhalb von /tmp löschen (damit der Platz auf sda2 wieder freigegeben wird) und nach einem Reboot würde per fstab dann /tmp wieder als tmpfs angelegt werden.

Alles in allem: Machbar, aber sehr umständlich für *eine* Aktion. Deshalb würde ich eher:

b) Das Verzeichnis (ggf. auch nur temporär) ändern, welches beim Paketbau so "vollgemüllt" wird.
Statt daß dafür eben das (beschränkte) /tmp genutzt würde biegt man das auf eine Partition mit ausreichend Platz.
Bei dir würden sich z.B. sda2(/) oder sdb1(/home) anbieten.
Also einfach als root ein Dir anlegen (z.B. auf sdb1/home):
mkdir /home/builddir
chmod 1777 /home/builddir
(1777 deshalb damit dein User beim Bauen genau die gleiche Berechtigungsstruktur vorfindet wie bei /tmp.

Bei makepkg ist dann das Vorgehen recht einfach. Es dreht sich hier um das sog. Builddir, wo makepkg also Sourcecode auspackt und Build-Daten(Kompiliertes) ablegt. Bei makepkg kann man das in der Config /etc/makepkg.conf temporär oder dauerhaft ändern oder per Umgebungsvariable BUILDDIR. Die Config oder die Umgebungsvariable sollte dann also nach /home/builddir zeigen.

Du verwendest ja trizen zum Bau von AUR-Paketen. Ich nutze das selbst nicht, habe aber eine Installation davon. Für trizen müßtest du in der Config $HOME/.config/trizen/trizen.conf die Variable clone_dir ändern. Per default ist das wohl:
clone_dir                  => "/tmp/trizen-DEINUSERNAME",
also ändern nach:
clone_dir                  => "/home/builddir",
Das kannst du temporär ändern eben für diesen electron-Build. Oder du lässt das generell so, d.h. die Build-Daten von allen per trizen gebauten Pakete gehen dann in dieses dedizierte Verzeichnis (entlastet also auch das /tmp und deinen Arbeitsspeicher).
Von Zeit zu Zeit kannst du eigentlich alles in /home/builddir/* löschen, diese Daten werden ja nach erfolgreichem Bauen nicht mehr benötigt.

Das (eigenes Build-Verzeichnis statt /tmp(tmpfs)) würde ich an deiner Stelle machen.

Eine "dritte" ganz kurzfristige Möglichkeit wäre:
Bei trizen ein Symlink auf ein Ziel wo Platz ist. Das würde dann ohne Änderung an Configs vonstatten gehen, wäre "einmalig" und nach einem Reboot wieder so wie es war.
Dafür wie oben z.B. das /home/builddir anlegen. Dann als dein User:

mkdir /home/builddir/trizen
rm -rf /tmp/trizen-DEINUSERNAME
ln -sf /tmp/trizen-DEINUSERNAME /home/builddir/trizen

Für trizen würde sich so nichts ändern, beim Bauen würde es weiterhin nach /tmp/trizen-DEINUSERNAME schreiben. Durch den Symlink werden die Daten real aber nach /home/builddir/trizen/* abgelegt, wo genügend Platz vorhanden ist.
Das wäre eine "schnelle" Lösung und hält nur bis zum Reboot.

Offline

#8 15.03.2021 18:09:37

T-matze
Mitglied

Re: [solved] Update-Fehler mit npm bzw. apm: "existiert im Dateisystem"

Wow, GerBra, eine solch ausführliche, informative und hilfreiche Antwort auf ein eigentlich "erledigtes" Thema - und das mitten in der Nacht!  O_o
Herzlichen Dank für die erhellenden Erklärungen und verschiedenen Lösungswege, ich bin begeistert.

Momentan läuft gerade noch die von mir gestern schon implementierte Variante a) mit einem Update für Electron9 durch - mit 100% Prozessorlast und vollständig ausgeschöpftem RAM und Swapfile (je 16 GB) und 18 GB belegtem tmpfs. Denn ich hatte das Update angestoßen, bevor ich Deine Anleitung gelesen habe. Diese Erfahrung bestätigt Deine Einschätzung, dass dies nicht der Weisheit letzter Schluss ist.

Variante b) klingt für mich auch viel besser, das werde ich gleich umsetzen. Und ein Eintrag in crontab kann ja bei jedem Systemstart und/oder Shutdown das Verzeichnis leeren, dann ist da auch immer aufgeräumt.

Nochmals herzlichen Dank für die tolle Hilfe zur Kernfrage und den "Nebenschauplätzen", das ist super!

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums