[pacman-dev] Weird download behavior today
Anyone else seeing weirdness? This is a relatively recent build of pacman-git, on i686, using mirrors.kernel.org as the first mirror. Note that the [core] repository line even got blown away in there, meaning it never hit 100% so we never output the \n character or something (it should be right where the [extra] stuff starts): $ pacSyu Password: :: Synchronizing package databases... testing 27.2K 94.3K/s 00:00:00 [---------------------------------------------------] 100% error: extra.db.tar.gz appears to be truncated: 464860/465084 bytesK 131.7K/s 00:00:00 [------------------------------------------------c ] 95% error: failed retrieving file 'extra.db.tar.gz' from mirrors.easynews.com : Requested Range Not Satisfiable error: failed retrieving file 'extra.db.tar.gz' from mirror.rit.edu : Requested Range Not Satisfiable error: failed retrieving file 'extra.db.tar.gz' from mirrors.gigenet.com : Not Found error: failed retrieving file 'extra.db.tar.gz' from archlinux.unixheads.org : Requested Range Not Satisfiable error: failed retrieving file 'extra.db.tar.gz' from mirrors.easynews.com : Requested Range Not Satisfiable error: failed retrieving file 'extra.db.tar.gz' from mirrors.portafixe.com : No address record error: failed to update extra (No address record) community-testing 2.7K 89.0K/s 00:00:00 [---------------------------------------------------] 100% :: Starting full system upgrade... 336.0K 129.5K/s 00:00:00 [----------------------------------------------C o ] 92% warning: archiso: local (0.8-1) is newer than extra (0.1-1) resolving dependencies... looking for inter-conflicts... Targets (1): ncmpcpp-0.5.4-1 Total Download Size: 0.21 MB Total Installed Size: 0.55 MB Proceed with installation? [Y/n] y :: Retrieving packages from community... error: failed retrieving file 'ncmpcpp-0.5.4-1-i686.pkg.tar.gz' from mirrors.kernel.org : Not Found ncmpcpp-0.5.4-1-i686 215.0K 67.2K/s 00:00:03 [---------------------------------------------------] 100% checking package integrity... (1/1) checking for file conflicts [---------------------------------------------------] 100% (1/1) upgrading ncmpcpp [---------------------------------------------------] 100% $ head /etc/pacman.d/mirrorlist # Server list generated by rankmirrors on 2009-01-04 # # Arch Linux repository mirrorlist # #Server = http://localhost:8954/search/$repo/os/i686 #Server = ftp://locke.suu.edu/linux/dist/archlinux/$repo/os/i686 Server = http://mirrors.kernel.org/archlinux/$repo/os/i686 Server = http://mirrors.easynews.com/linux/archlinux/$repo/os/i686 Server = http://mirror.rit.edu/archlinux/$repo/os/i686
On 15/06/10 09:08, Dan McGee wrote:
Anyone else seeing weirdness? This is a relatively recent build of pacman-git, on i686, using mirrors.kernel.org as the first mirror. Note that the [core] repository line even got blown away in there, meaning it never hit 100% so we never output the \n character or something (it should be right where the [extra] stuff starts):
<snip> I have been using pacman-git for the last few weeks and I have not run into this. Is this the bug about attempting to continue downloading a repo db but striking a different revision of the repo-db on the mirror from the one you started downloading? Having to fall back to the second mirror to get the update that you wanted indicates partial sync of a mirror there... Allan
On Mon, Jun 14, 2010 at 8:14 PM, Allan McRae <allan@archlinux.org> wrote:
On 15/06/10 09:08, Dan McGee wrote:
Anyone else seeing weirdness? This is a relatively recent build of pacman-git, on i686, using mirrors.kernel.org as the first mirror. Note that the [core] repository line even got blown away in there, meaning it never hit 100% so we never output the \n character or something (it should be right where the [extra] stuff starts):
<snip>
I have been using pacman-git for the last few weeks and I have not run into this.
Is this the bug about attempting to continue downloading a repo db but striking a different revision of the repo-db on the mirror from the one you started downloading?
Having to fall back to the second mirror to get the update that you wanted indicates partial sync of a mirror there...
I actually made sure I deleted out all of the DB files before I ran the -Syu this time, thus the reason it grabbed all of them (rm /var/lib/pacman/*.db.tar.gz), so there were definitely no partial DB files. -Dan
On Tue, Jun 15, 2010 at 04:17, Dan McGee <dpmcgee@gmail.com> wrote:
I actually made sure I deleted out all of the DB files before I ran the -Syu this time, thus the reason it grabbed all of them (rm /var/lib/pacman/*.db.tar.gz), so there were definitely no partial DB files.
Don't partial db files have .part suffix too (like packages)? In that case the rm command above doesn't delete partial files. -- Roman Kyrylych (Роман Кирилич)
On 15/06/10 18:21, Roman Kyrylych wrote:
On Tue, Jun 15, 2010 at 04:17, Dan McGee<dpmcgee@gmail.com> wrote:
I actually made sure I deleted out all of the DB files before I ran the -Syu this time, thus the reason it grabbed all of them (rm /var/lib/pacman/*.db.tar.gz), so there were definitely no partial DB files.
Don't partial db files have .part suffix too (like packages)? In that case the rm command above doesn't delete partial files.
Correct: allan@mugen /var/lib/pacman
ls -l total 1060 -rw-r--r-- 1 root root 372930 Jun 15 06:43 community.db.tar.gz -rw-r--r-- 1 root root 2729 Jun 15 06:43 community-testing.db.tar.gz -rw-r--r-- 1 root root 464860 Jun 15 03:45 extra.db.tar.gz -rw-r--r-- 1 root root 194560 Jun 15 18:35 extra.db.tar.gz.part drwxr-xr-x 513 root root 24576 Jun 15 17:51 local drwxr-xr-x 8 root root 4096 Jun 15 18:35 sync
sudo /home/arch/code/pacman/src/pacman/pacman -Syu :: Synchronizing package databases... kernel64 1.7K 404.4K/s 00:00:00 [######################] 100% testing 27.0K 39.3K/s 00:00:01 [######################] 100% core 36.2K 38.8K/s 00:00:01 [######################] 100% warning: resuming download of extra.db.tar.gz not possible; starting over extra 454.1K 100.5K/s 00:00:05 [######################] 100% community-testing 2.7K 15.2M/s 00:00:00 [######################] 100% community 364.2K 82.4K/s 00:00:04 [######################] 100% :: Starting full system upgrade...
This is the bug I thought Dan had struck (which Roman filed): http://bugs.archlinux.org/task/15657 But I tried replicating using the most out of date mirror I could find, stopping the extra repo download partway, and the switching to my usual up-to-date mirror: there is nothing to do And that seems fine.
On Tue, Jun 15, 2010 at 3:42 AM, Allan McRae <allan@archlinux.org> wrote:
On 15/06/10 18:21, Roman Kyrylych wrote:
On Tue, Jun 15, 2010 at 04:17, Dan McGee<dpmcgee@gmail.com> wrote:
I actually made sure I deleted out all of the DB files before I ran the -Syu this time, thus the reason it grabbed all of them (rm /var/lib/pacman/*.db.tar.gz), so there were definitely no partial DB files.
Don't partial db files have .part suffix too (like packages)? In that case the rm command above doesn't delete partial files.
Correct:
allan@mugen /var/lib/pacman
ls -l total 1060 -rw-r--r-- 1 root root 372930 Jun 15 06:43 community.db.tar.gz -rw-r--r-- 1 root root 2729 Jun 15 06:43 community-testing.db.tar.gz -rw-r--r-- 1 root root 464860 Jun 15 03:45 extra.db.tar.gz -rw-r--r-- 1 root root 194560 Jun 15 18:35 extra.db.tar.gz.part drwxr-xr-x 513 root root 24576 Jun 15 17:51 local drwxr-xr-x 8 root root 4096 Jun 15 18:35 sync
This is the bug I thought Dan had struck (which Roman filed): http://bugs.archlinux.org/task/15657
But I tried replicating using the most out of date mirror I could find, stopping the extra repo download partway, and the switching to my usual up-to-date mirror:
sudo /home/arch/code/pacman/src/pacman/pacman -Syu :: Synchronizing package databases... kernel64 1.7K 404.4K/s 00:00:00 [######################] 100% testing 27.0K 39.3K/s 00:00:01 [######################] 100% core 36.2K 38.8K/s 00:00:01 [######################] 100% warning: resuming download of extra.db.tar.gz not possible; starting over extra 454.1K 100.5K/s 00:00:05 [######################] 100% community-testing 2.7K 15.2M/s 00:00:00 [######################] 100% community 364.2K 82.4K/s 00:00:04 [######################] 100% :: Starting full system upgrade... there is nothing to do
And that seems fine.
We do a lot of checks of the times of the files in the download code so it shouldn't be likely that we are trying to finish an older db file with a newer one. It seems more like the remote server was playing with us as far as reported file size vs. what it sent us or something, but I'm not sure... -Dan
participants (3)
-
Allan McRae
-
Dan McGee
-
Roman Kyrylych