You are not logged in.
I have been having a really annoying problem for a while now. Every time I try to sync anything with pacman (package lists, updates, etc.) if a hiccup occurs in my Internet connection, the download is corrupted and I get the error: "Requested Range not Satisfiable". The only way to get around this is to manually delete the .part file in /var/cache/pacman/pkg, but for large packages it is basically impossible to update them, because the problem is bound to happen during the course of the download and I have to start anew.
Does anyone know why this is happening?
Last edited by egan (2009-10-05 14:10:43)
Offline
Maybe this will help:
Offline
Have you tried changing mirrors?
Offline
I had this problem and I deleted /var/lib/pacman/*.part
Try it.
EDIT: smartboyathome corrected me. it shoud be "/var/cache/pacman/*.part". sorry, wrote from memory
Last edited by SoleSoul (2009-10-12 20:48:56)
Offline
I had this problem and I deleted /var/lib/pacman/*.part
Try it.
Yes I know. But this is just a workaround for not incorrect download resume. And with larger packages, it is almost impossible to download it all without a lull in the connection. And then, even when I have already downloaded 98%, I have to start from scratch.
Changing mirrors did not help.
Offline
hey I got this error too, I don't have anything with the name *.part in the /var/lib/pacman directory, how would I solve this problem?
error: failed retrieving file 'python-2.6.3-1-i686.pkg.tar.gz' from archlinux.unixheads.org : Requested Range Not Satisfiable
warning: failed to retrieve some files from extra
error: failed to commit transaction (Requested Range Not Satisfiable)
Errors occurred, no packages were upgraded.
Offline
hey I got this error too, I don't have anything with the name *.part in the /var/lib/pacman directory, how would I solve this problem?
error: failed retrieving file 'python-2.6.3-1-i686.pkg.tar.gz' from archlinux.unixheads.org : Requested Range Not Satisfiable
warning: failed to retrieve some files from extra
error: failed to commit transaction (Requested Range Not Satisfiable)
Errors occurred, no packages were upgraded.
I don't know how to solve the problem, but if you need to update some packages in the mean time, you can sync them by themselves rather than doing a pacman -Su. There should be a .part file in the /var/lib/pacman/pkg for python in your case.
I would really like to fix this; it is becoming quite a hassle.
Offline
Set pacman to use wget or curl to download things, with XferCommand in pacman.conf.
Offline
unregistered wrote:hey I got this error too, I don't have anything with the name *.part in the /var/lib/pacman directory, how would I solve this problem?
error: failed retrieving file 'python-2.6.3-1-i686.pkg.tar.gz' from archlinux.unixheads.org : Requested Range Not Satisfiable
warning: failed to retrieve some files from extra
error: failed to commit transaction (Requested Range Not Satisfiable)
Errors occurred, no packages were upgraded.I don't know how to solve the problem, but if you need to update some packages in the mean time, you can sync them by themselves rather than doing a pacman -Su. There should be a .part file in the /var/lib/pacman/pkg for python in your case.
I would really like to fix this; it is becoming quite a hassle.
the only folders in /var/lib/pacman/ are local and sync
Last edited by unregistered (2009-10-04 08:16:54)
Offline
Set pacman to use wget or curl to download things, with XferCommand in pacman.conf.
This seems promising... I just wonder why I never got this problem before?
Offline
There's an API weirdness in libfetch. Our pacman devs assumed this part of the API made more sense than it does, and introduced a bug at 3.3.0 when switching to libfetch. You'll only trigger the bug if your network has trouble or your transfer otherwise stalls.
A fixed pacman should be appearing soon - I know the fix has been written. The use of an external downloader shouldn't be needed long.
Offline
There's an API weirdness in libfetch. Our pacman devs assumed this part of the API made more sense than it does, and introduced a bug at 3.3.0 when switching to libfetch. You'll only trigger the bug if your network has trouble or your transfer otherwise stalls.
A fixed pacman should be appearing soon - I know the fix has been written. The use of an external downloader shouldn't be needed long.
Cool. Thanks for the information.
Offline
There's an API weirdness in libfetch. Our pacman devs assumed this part of the API made more sense than it does, and introduced a bug at 3.3.0 when switching to libfetch. You'll only trigger the bug if your network has trouble or your transfer otherwise stalls.
A fixed pacman should be appearing soon - I know the fix has been written. The use of an external downloader shouldn't be needed long.
so does that mean I just have to wait for the update and everything would be restored to normal?
Offline
ataraxia wrote:There's an API weirdness in libfetch. Our pacman devs assumed this part of the API made more sense than it does, and introduced a bug at 3.3.0 when switching to libfetch. You'll only trigger the bug if your network has trouble or your transfer otherwise stalls.
A fixed pacman should be appearing soon - I know the fix has been written. The use of an external downloader shouldn't be needed long.
so does that mean I just have to wait for the update and everything would be restored to normal?
Well, you'll have to have some means of getting the updated pacman and/or libfetch installed, but you can always download those by hand once they're available.
(I don't know if there will also be a libfetch update in addition to pacman. I was under the impression that the pacman devs are trying to get the API of libfetch changed. Shining would know.)
Offline
Pacman -Sc
fixed it for me.. This was a package download I interrupted uncleanly (ctrl-z and closed console)
Careful what you wish, you might just get it!
Offline
(I don't know if there will also be a libfetch update in addition to pacman. I was under the impression that the pacman devs are trying to get the API of libfetch changed. Shining would know.)
No no, no need to change the API, it was entirely our fault. So only pacman needs to be updated, not libfetch.
The fix is really just this :
- size_t dl_thisfile = 0, nread = 0;
+ size_t dl_thisfile = 0;
+ ssize_t nread = 0;
I hope 3.3.2 can finally be released today (but it goes through testing repo first). It has been 3 days I have been saying that..
Now if you want the full story.
This is the standard fread interface :
size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);
fread() and fwrite() return the number of items successfully read or written (i.e., not the number of characters).
If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero).
And libdownload used fread.
Joerg (netbsd libfetch developer) finds this interface stupid because we cannot distinguish between error and end-of-file.
So he changed the interface completely on purpose with :
ssize_t fetchIO_read(fetchIO *, void *, size_t);
So it returns 0 for EOF, and -1 for errors.
However when switching from libdownload to libfetch, we completely overlooked that change, and we kept an unsigned size_t for the return of fetchIO_read. So when an error occured, fetchIO_read returned -1, but the code converted that to the biggest integer value instead.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Joerg (netbsd libfetch developer) finds this interface stupid because we cannot distinguish between error and end-of-file.
So he changed the interface completely on purpose with :ssize_t fetchIO_read(fetchIO *, void *, size_t);
So it returns 0 for EOF, and -1 for errors.
However when switching from libdownload to libfetch, we completely overlooked that change, and we kept an unsigned size_t for the return of fetchIO_read. So when an error occured, fetchIO_read returned -1, but the code converted that to the biggest integer value instead.
Thanks for the explanation. As an aspiring C-developer it is nice to see how errors in code such as these lead to bugs... this was well explained.
Offline
Maybe the problem below is related to this. In resume, I have 770M free and in this case, I need to download a total of ~217M to upgrade the system. But even after the first package downloaded, I got this error. bash is not that big. And after this, I have 0M of free space on /var.
Any hints? Thank you.
[internet@amparo02 var]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.9G 264M 1.5G 15% /
none 93M 144K 93M 1% /dev
none 93M 0 93M 0% /dev/shm
/dev/sda6 950M 132M 770M 15% /var
/dev/sda7 23G 19G 2.4G 89% /home
/dev/sda8 15G 3.5G 10G 26% /usr
[internet@amparo02 var]$ sudo pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
Targets (71): bash-4.0.033-1 bluez-4.54-1 db-4.8.24-1 libsasl-2.1.23-2
libetpan-0.58-2 claws-mail-3.7.2-3 device-mapper-2.02.53-1
libldap-2.4.18-1 dirmngr-1.0.2-2 dsniff-2.4b1-14
e2fsprogs-1.41.9-1 sqlite3-3.6.18-1 heimdal-1.2.1-7
libical-0.44-1 evolution-data-server-2.26.3-2 ekiga-3.2.5-2
libnet-1.1.4-1 ettercap-NG_0.7.3-13 fakeroot-1.13.1-1
perl-5.10.1-3 fvwm-devel-2.5.28-1 gconf-2.26.2-3
gnome-mplayer-0.9.8-2 gecko-mediaplayer-0.9.8-1
gnumeric-1.8.4-4 gnupg-1.4.10-2 gnupg2-2.0.13-2
gnuplot-4.2.6-1 gpm-1.20.6-3 groff-1.20.1-3 hunspell-1.2.8-2
imagemagick-6.5.6.1-1 iproute2-2.6.29-2 libcap-2.17-1
librep-0.90.2-1 lvm2-2.02.53-1 man-pages-3.23-1
maxima-5.19.2-3 mlocate-0.22.1-1 module-init-tools-3.10-2
mpd-0.15.4-1 ncmpc-0.15-2 nfsidmap-0.23-3 nicotine-1.2.12-3
octave-3.2.3-1 openbox-3.4.7.2-3 openvpn-2.1_rc19-4
pam-1.0.4-2 perl-berkeleydb-0.39-1 perl-html-parser-3.62-1
perl-www-curl-4.09-1 libnice-0.0.9-1
gstreamer0.10-python-0.10.16-1 python-2.6.3-2
farsight2-0.0.16-1 pidgin-2.6.2-3 qemu-0.11.0-1 qt-4.5.3-3
rxvt-unicode-9.06-3 sdparm-1.04-1 smbclient-3.3.7-2
sonata-1.6.2.1-1 taglib-1.6-1 terminal-0.4.1-1 tmux-1.0-1
tor-0.2.1.19-2 tzdata-2009n-1 wget-1.12-1 wireshark-1.2.2-1
xfce4-settings-4.6.3-1 xfconf-4.6.1-2
Total Download Size: 216.96 MB
Total Installed Size: 726.34 MB
Proceed with installation? [Y/n] y
:: Retrieving packages from core...
error: error writing to file '/var/cache/pacman/pkg/bash-4.0.033-1-i686.pkg.tar.gz': No space left on device
error: failed retrieving file 'bash-4.0.033-1-i686.pkg.tar.gz' from archlinux.c3sl.ufpr.br : Requested action aborted: local error in processing
error: failed retrieving file 'bash-4.0.033-1-i686.pkg.tar.gz' from archlinux.c3sl.ufpr.br : Requested Range Not Satisfiable
error: failed retrieving file 'bash-4.0.033-1-i686.pkg.tar.gz' from archlinux.unixheads.org : Requested Range Not Satisfiable
^C
Interrupt signal received
[internet@amparo02 var]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.9G 264M 1.5G 15% /
none 93M 144K 93M 1% /dev
none 93M 0 93M 0% /dev/shm
/dev/sda6 950M 950M 0 100% /var
/dev/sda7 23G 19G 2.4G 89% /home
/dev/sda8 15G 3.5G 10G 26% /usr
[internet@amparo02 var]$
Offline
Maybe the problem below is related to this. In resume, I have 770M free and in this case, I need to download a total of ~217M to upgrade the system. But even after the first package downloaded, I got this error. bash is not that big. And after this, I have 0M of free space on /var.
Any hints? Thank you.
pacman -Sc
pacman -U ftp://ftp.archlinux.org/testing/os/i686/pacman-3.3.2-1-i686.pkg.tar.gz
# or
pacman -U ftp://ftp.archlinux.org/testing/os/x86_64/pacman-3.3.2-1-x86_64.pkg.tar.gz
# enjoy
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Pacman 3.3.2 has a rather serious issue for me:
http://bugs.archlinux.org/task/16568
Microshaft delenda est
Offline
pacman -Sc pacman -U ftp://ftp.archlinux.org/testing/os/i686/pacman-3.3.2-1-i686.pkg.tar.gz # or pacman -U ftp://ftp.archlinux.org/testing/os/x86_64/pacman-3.3.2-1-x86_64.pkg.tar.gz # enjoy
Didn't find on .../testing/....
s/testing/current/g
Thank you.
Offline
I was able to fix it by running:
sudo rm /var/cache/pacman/pkg/*.part
Note that it points to /var/cache, not /var/lib like the post above.
Offline
The problem seems to be gone after the last pacman update...
Offline