Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#74239 - [libalpm] size calculation doesn't handle hard links
Attached to Project:
Pacman
Opened by Daniel Lopez (FelledTreeNo9) - Friday, 25 March 2022, 17:09 GMT
Opened by Daniel Lopez (FelledTreeNo9) - Friday, 25 March 2022, 17:09 GMT
|
DetailsI believe Pacman is counting files with hard links multiple times and may consequently error out claiming there's "not enough free disk space" while that is not true.
Test case: # Create and format a 700 MB partition $ dd if=/dev/zero of=test_partition.img bs=1M count=700 $ mkfs.ext4 test_partition.img # Mount the partition, install minimal utilities to it, and chroot into it $ mkdir mnt $ sudo mount test_partition.img mnt $ sudo pacstrap mnt coreutils bash pacman $ sudo arch-chroot mnt # Check disk space $ df -h # result: Looks like I have 234 MB free Filesystem Size Used Avail Use% Mounted on /dev/loop0 672M 390M 234M 63% / # Try to install mesa (use -dd to avoid pulling its many dependencies, just for the purposes of this test) $ pacman -Sdd mesa # result: looking for conflicting packages... Packages (1) mesa-21.3.7-2 Total Download Size: 16.63 MiB Total Installed Size: 97.66 MiB :: Proceed with installation? [Y/n] :: Retrieving packages... mesa-21.3.7-2-x86_64 16.6 MiB 4.40 MiB/s 00:04 [####################################################################] 100% (1/1) checking keys in keyring [####################################################################] 100% (1/1) checking package integrity [####################################################################] 100% (1/1) loading package files [####################################################################] 100% (1/1) checking for file conflicts [####################################################################] 100% (1/1) checking available disk space [####################################################################] 100% error: Partition / too full: 126102 blocks needed, 55449 blocks free error: not enough free disk space error: failed to commit transaction (not enough free disk space) Errors occurred, no packages were upgraded. -- So, a total installed size of 97 MB should easily fit in the free 234 MB, but it later refuses because of the block count comparison. With an ext4 block size of 4 KB, the "55449 blocks free" do approximately correspond to the free 234 MB, but the "126102 blocks needed" is nearly 500 MB. Mesa includes a bunch of files in /usr/lib/dri which are the same inode hard linked with different names. If I manually extract the package into a new folder, then the disk space used is: $ du -hs 98M . Which matches the "Total Installed Size". Whereas summing up the size of every file gives: $ find -type f -exec cat {} + | wc -c 495450540 ie. about 500 MB. The original context in which I encountered this was in Arch Linux ARM, where Mesa's true install size is 60 MB but the hard links take it to over 800 MB, making the problem even more pronounced. I did some spelunking with GDB and found that the blocks needed value is tallied up in calculate_installed_size() in lib/libalpm/diskspace.c. And I found this old bug and the fix that deals with the same issue in makepkg, though that is written in shell script: https://bugs.archlinux.org/task/64252 https://gitlab.archlinux.org/pacman/pacman/-/commit/0272fca993718460bf7ecb7fdc3ca7dad1c7e6cd |
This task depends upon