You are not logged in.
Pages: 1
Topic closed
I'm stuck trying to figure out why pacman indicates there is no available disk space for installing packages, even though there is definitely available space.
For example, if I try to install the package, gdmap, I get the following output:
$ sudo pacman -S gdmap
resolving dependencies...
looking for conflicting packages...
Packages (1) gdmap-0.8.1-4
Total Download Size: 0.04 MiB
Total Installed Size: 0.27 MiB
:: Proceed with installation? [Y/n]
error: Partition / too full: 5132 blocks needed, 0 blocks free
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded.
And I could show a similar result for what happens when I try to do a system upgrade.
My web searches for this problem suggested looking at the output of df:
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
dev 2036398 438 2035960 1% /dev
run 2038042 654 2037388 1% /run
/dev/sda2 2413152 309069 2104083 13% /
tmpfs 2038042 176 2037866 1% /dev/shm
tmpfs 2038042 18 2038024 1% /sys/fs/cgroup
tmpfs 2038042 30 2038012 1% /tmp
/dev/sda3 11296768 31789 11264979 1% /home
/dev/loop1 12821 12821 0 100% /var/lib/snapd/snap/core/3887
/dev/loop0 1514 1514 0 100% /var/lib/snapd/snap/skype/13
tmpfs 2038042 20 2038022 1% /run/user/1000
In particular, the line indicating 13% for / seems to contradict what pacman is telling me. There are available inodes where / is mounted. Why doesn't pacman know this?
Last edited by eigenstryker (2018-04-04 17:17:06)
Offline
Pacman's complaining about free blocks, not inodes. Please post the output of
df -h
Also, please tell us what filesystem you have used as /.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Ah, I see. The distinction between inodes and blocks wasn't clear to me before. Here's the output:
$ df -h
Filesystem Size Used Avail Use% Mounted on
dev 7.8G 0 7.8G 0% /dev
run 7.8G 1.2M 7.8G 1% /run
/dev/sda2 36G 35G 0 100% /
tmpfs 7.8G 169M 7.7G 3% /dev/shm
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
tmpfs 7.8G 28K 7.8G 1% /tmp
/dev/sda3 169G 56G 105G 35% /home
/dev/loop1 82M 82M 0 100% /var/lib/snapd/snap/core/3887
/dev/loop0 104M 104M 0 100% /var/lib/snapd/snap/skype/13
tmpfs 1.6G 8.0K 1.6G 1% /run/user/1000
This does match what pacman is telling me. And regarding the filesystem: I believe the answer you're looking for is ext4.
Offline
I'm going to assume you know what you need to do next then.
https://wiki.archlinux.org/index.php/Li … ge_display
Please remember to mark your thread as solved.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Actually I am still confused. When I first got this complaint from pacman, I tried to ameliorate the problem by clearing some of the pacman cache, using
paccache -rk 2
This freed up about 200 megabytes. (I don't have the terminal output anymore to paste here, though.) But even after I did this, I got the same complaint about 0 blocks available.
Why didn't this make any blocks available?
(aside: sadly I'm unable download any disk space usage analyzers because of the exact problem I'm facing)
Offline
I'd say delete some files until dh -h shows 1 GB or so free and try again.
Offline
What was the output of df -h after you cleared some space?
If you know the blocksize of the filesystem you could see how many blocks of that size are available for instance for 4k blocks
df -b 4096
Edit:
stat -fc %s /
to get the blocksize of /
Last edited by loqs (2018-04-03 18:38:28)
Offline
What was the output of df -h after you cleared some space?
If you know the blocksize of the filesystem you could see how many blocks of that size are available for instance for 4k blocksdf -b 4096
Edit:
stat -fc %s /
to get the blocksize of /
Here's what I got:
$ stat -fc %s /
4096
$ df -B 4096
Filesystem 4K-blocks Used Available Use% Mounted on
dev 2036398 0 2036398 0% /dev
run 2038042 288 2037754 1% /run
/dev/sda2 9416774 9157814 0 100% /
tmpfs 2038042 65546 1972496 4% /dev/shm
tmpfs 2038042 0 2038042 0% /sys/fs/cgroup
tmpfs 2038042 7 2038035 1% /tmp
/dev/sda3 44194785 14563305 27369080 35% /home
/dev/loop1 20832 20832 0 100% /var/lib/snapd/snap/core/3887
/dev/loop0 26624 26624 0 100% /var/lib/snapd/snap/skype/13
tmpfs 407608 2 407606 1% /run/user/1000
I'm puzzled why the available blocks for / doesn't say 258960 ( = 9416774-9157814).
Both /dev/sda2 and /dev/sda3 have blocks not being accounted for in this table.
Offline
I'd probably account that to the fact that by default ext filesystems reserve 5% of the space as unusable to anything but the root user (and it doesn't show up as available in df) - this can be changed using the tune2fs -m switch.
Offline
Logfiles are known to cause space problems. i suggest you check the size of /var/log .
example :
]$ du -h /var/log
144M /var/log/journal/1d5478d7450747c0c8627f0d4aae7338
8.0K /var/log/journal/remote
144M /var/log/journal
80K /var/log/cups
168K /var/log/ConsoleKit
4.0K /var/log/speech-dispatcher
16K /var/log/clamav
4.0K /var/log/CCPD
4.0K /var/log/old
188M /var/log
$
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
my proposal:
paccache -rk 1
Also do a restart and a fsck check of the ext4 volume.
You can use a disk space tool from a life usb system - this can be an ubuntu life-cd as well :-)
Offline
Ok, my problem was solved by just continuing to free up more and more disk space. I think Slithery's reply,
I'd probably account that to the fact that by default ext filesystems reserve 5% of the space as unusable to anything but the root user (and it doesn't show up as available in df) - this can be changed using the tune2fs -m switch.
explains the confusion I was having about available blocks.
I freed up about 1GB by doing
paccache -rk 1
but this still wasn't enough; I finally realized my 16GB swapfile was on the same partition where / is mounted, and moving this to a different partition led to blocks being shown as available by df.
Thanks to everyone who helped!
Offline
Sorry for necroposting, but I just had this same problem and the fix has 2 steps:
1. Resize the / partition to accommodate the new packages
# fdisk /dev/the_disk
# Command (m for help): e
2. Resize the filesystem (ext4 in my case):
# resize2fs /dev/the_disk
Then retry the install command
Offline
Make that 3 steps as resizing partitions is risky and prone to cause data loss .
Step 0
backup your system
Closing this old thread.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Pages: 1
Topic closed