Auf dem Gerät ist kein Speicherplatz mehr verfügbar - df sagt aber das Gegenteil

[henfri]

Hallo,

ich habe einen neuen Kernel kompiliert:

ver="6.3.3"
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-$ver.tar.xz
xz -v -d linux-$ver.tar.xz
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-$ver.tar.sign
gpg --verify linux-$ver.tar.sign
tar xvf linux-$ver.tar
cd linux-$ver
cp -v /boot/config-$(uname -r) .config
CONFIG_SYSTEM_TRUSTED_KEYRING=n >> .config
CONFIG_SYSTEM_TRUSTED_KEYS="" >> .config
make menuconfig
make bindeb-pkg

#installieren
dpkg -i ./*6.3.3*.deb*

Das führt aber leider zu diesem Fehler

Entpacken von linux-image-6.3.3-dbg (6.3.3-1) ...
dpkg: Fehler beim Bearbeiten des Archivs ./linux-image-6.3.3-dbg_6.3.3-1_amd64.deb (--install):
 Extrahierte Daten für »./usr/lib/debug/lib/modules/6.3.3/kernel/net/802/mrp.ko« können nicht nach »/usr/lib/debug/lib/modules/6.3.3/kernel/net/802/mrp.ko.dpkg-new« kopiert werden: Es konnte nicht geschrieben werden (Auf dem Gerät ist kein Speicherplatz mehr verfügbar)
dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet

Die Platte ist aber nicht voll:

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            3,8G       0  3,8G    0% /dev
tmpfs           773M     85M  689M   11% /run
/dev/nvme0n1p2   40G     35G  2,3G   94% /
tmpfs           3,8G    260K  3,8G    1% /dev/shm
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           4,0M       0  4,0M    0% /sys/fs/cgroup
tmpfs           3,8G     24M  3,8G    1% /tmp
/dev/nvme0n1p3  199G     73G  124G   38% /srv/dev-disk-by-uuid-b4c59765-5685-4439-x
/dev/nvme0n1p5  1,7T    1,5T  190G   89% /srv/dev-disk-by-id-nvme-Lexar_SSD_NM620_2TB_x-part5
/dev/sda1        11T    9,2T  1,9T   84% /srv/dev-disk-by-label-DataPool1
/dev/sda1        11T    9,2T  1,9T   84% /srv/dev-disk-by-label-DataPool1/Backups
/dev/nvme0n1p3  199G     73G  124G   38% /srv/dev-disk-by-uuid-b4c59765-5685-4439-a886-x/docker-container/btrfs
tmpfs           773M       0  773M    0% /run/user/1000

Auch sind noch genug inodes frei:

Dateisystem     Inodes IBenutzt   IFrei IUse% Eingehängt auf
udev            980596      509  980087    1% /dev
tmpfs           988759     1550  987209    1% /run
/dev/nvme0n1p2 2621440   507341 2114099   20% /
tmpfs           988759       53  988706    1% /dev/shm
tmpfs           988759        7  988752    1% /run/lock
tmpfs             1024       19    1005    2% /sys/fs/cgroup
tmpfs           988759      138  988621    1% /tmp

Mit dd kann ich auch ohne Probleme die Platte vollschreiben.

Im sylog und dmesg finde ich auch keinen Fehler.
Fsck von / habe ich auch gemacht (von einem Stick aus)

Woran kann es noch liegen?

Gruß,
Hendrik

Ergänzung (19. Mai 2023)

Hat sich erledigt...

Während des Entpackens läuft die Platte voll. Danke aber fürs zuhören ;-)

 

[Markchen]

👍