Unable to DL RPM's from update repositorys

I have had the same problem (with the same files as listed in the examples here) since upgrading to 11.4.
Using zypper upgrade, or Yast doesn’t seem to make any difference, the download stalls. It would appear from the messages that a partial file is downloaded in some examples, but the directory entry stored on the system shows 0 bytes.

The error message using zypper update shows only a partial file specification, for example:
./suse/i586/qt3-3.3.8b-111.1.i586.rpm

full file description example:
http://download.opensuse.org/distribution/11.4/repo/oss/suse/i586/qt3-devel-3.3.8b-111.1.i586.rpm

It is not possible to download the file on the target 11.4 system using Firefox. The download stalls. However, it is possible to use this same full file specification listed in the zypper update to download the file from Firefox on another computer, in my case, a SuSE 11.2 machine.

It is then possible to copy the file from the other system into a directory tree that reflects the shortened path as shown above, and from top of the directory tree run “zypper refresh”, followed by “zypper update” to install the file. If “zypper update” is not run from the directory at the top of the directory tree, zypper attempts to download the file, which fails. I have noticed in a couple of instances that zypper downloads the file, but is able to do so and complete the installation without stalling if the file is already on the system as described.

By this time, a number of sub-directories have been created to hold update files:
./Essentials/i586/
./rpm/i586
./suse/i586 ./suse/i686/ ./suse/noarch/

Searching the internet using a search engine shows similar problems with earlier SuSE versions (and other varieties of Linux). However, I have been unable to find any resolution. Search using the terms ‘SuSE 11.4 Download (curl) error for: Can’t provide’. My apologies if that leads to a goose chase, but it lead me to comments regarding this issue from other users.

HTH

Bill

I’m using ethernet and to my knowledge, not overclocking.

This is the first time I’ve used wireshark so tell me if you need different info, but here are some sample packets.
Packets from while it is downloading the file:


  213 17.514447   131.111.179.140       137.205.124.72        TCP      58601 > http [SYN] Seq=0 Win=4380 Len=0 MSS=1460 SACK_PERM=1 TSV=24125462 TSER=0 WS=6
    221 17.522968   137.205.124.72        131.111.179.140       TCP      http > 58601 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSV=2585606910 TSER=24125462 WS=2
    222 17.523100   131.111.179.140       137.205.124.72        TCP      58601 > http [ACK] Seq=1 Ack=1 Win=4416 Len=0 TSV=24125464 TSER=2585606910
    225 17.526418   131.111.179.140       137.205.124.72        HTTP     GET /mirrors/download.opensuse.org/distribution/11.4/repo/oss/suse/noarch/konqueror-plugins-lang-4.3.1-11.14.2.noarch.rpm HTTP/1.1 
    232 17.534939   137.205.124.72        131.111.179.140       TCP      http > 58601 [ACK] Seq=1 Ack=352 Win=6864 Len=0 TSV=2585606913 TSER=24125465
    237 17.543465   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]
    238 17.543568   131.111.179.140       137.205.124.72        TCP      58601 > http [ACK] Seq=352 Ack=1449 Win=7296 Len=0 TSV=24125469 TSER=2585606915
    239 17.543580   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]
    240 17.543626   131.111.179.140       137.205.124.72        TCP      58601 > http [ACK] Seq=352 Ack=2897 Win=10176 Len=0 TSV=24125469 TSER=2585606915
    245 17.552220   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]
    246 17.552268   131.111.179.140       137.205.124.72        TCP      58601 > http [ACK] Seq=352 Ack=4345 Win=13120 Len=0 TSV=24125471 TSER=2585606917
    247 17.552343   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]
    248 17.552374   131.111.179.140       137.205.124.72        TCP      58601 > http [ACK] Seq=352 Ack=5793 Win=16000 Len=0 TSV=24125471 TSER=2585606917
    249 17.552467   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]
    250 17.552515   131.111.179.140       137.205.124.72        TCP      58601 > http [ACK] Seq=352 Ack=7241 Win=18880 Len=0 TSV=24125471 TSER=2585606917
    251 17.552587   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]
    252 17.552742   131.111.179.140       137.205.124.72        TCP      58601 > http [ACK] Seq=352 Ack=8689 Win=21760 Len=0 TSV=24125471 TSER=2585606917
    253 17.561403   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]

Once it starts hanging:



462 17.633079   131.111.179.140       137.205.124.72        TCP      58601 > http [ACK] Seq=352 Ack=99913 Win=64128 Len=0 TSV=24125491 TSER=2585606937
    463 17.633229   137.205.124.72        131.111.179.140       TCP      [TCP Previous segment lost] [TCP segment of a reassembled PDU]
    464 17.633293   131.111.179.140       137.205.124.72        TCP      [TCP Dup ACK 462#1] 58601 > http [ACK] Seq=352 Ack=99913 Win=64128 Len=0 TSV=24125491 TSER=2585606937 SLE=107153 SRE=108601
    465 17.633348   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]
    466 17.633371   131.111.179.140       137.205.124.72        TCP      [TCP Dup ACK 462#2] 58601 > http [ACK] Seq=352 Ack=99913 Win=64128 Len=0 TSV=24125491 TSER=2585606937 SLE=107153 SRE=110049
    467 17.642033   137.205.124.72        131.111.179.140       TCP      [TCP segment of a reassembled PDU]
    468 17.642145   131.111.179.140       137.205.124.72        TCP      [TCP Dup ACK 462#3] 58601 > http [ACK] Seq=352 Ack=99913 Win=64128 Len=0 TSV=24125494 TSER=2585606937 SLE=107153 SRE=111497

In terms of hardware:
Processor: Intel Pentium 4 1.8Ghz
Graphics card: GeForce FX 5200
Network card: 3C905CX-TX/TM Fast ethernet link (used with the 3c59x driver)

On 2011-04-20 06:36, hbco2 wrote:
>
> I have had the same problem (with the same files as listed in the
> examples here) since upgrading to 11.4.

Please add all this info to the Bugzilla:

<https://bugzilla.novell.com/show_bug.cgi?id=688454>

The more people, the better.

Try if you can download in runlevel 3 or failsafe, and report that too.

A comment: If you configure repos to store what is downloaded, then all
updates end in “/var/cache/zypp/packages/”. You can do the download in
another machine, then copy the file to the expected directory (same as the
“alias” in zypper listing), and if you run zypper it should take the file
in the cache instead of attempting the download again.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

On 2011-04-20 15:36, esoltech wrote:
>
> I’m using ethernet and to my knowledge, not overclocking.
>
> This is the first time I’ve used wireshark so tell me if you need
> different info, but here are some sample packets.
> Packets from while it is downloading the file:

I’ll forward the link to the people asking this in the ML.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

On 2011-04-20 16:03, Carlos E. R. wrote:
> On 2011-04-20 15:36, esoltech wrote:
>>
>> I’m using ethernet and to my knowledge, not overclocking.
>>
>> This is the first time I’ve used wireshark so tell me if you need
>> different info, but here are some sample packets.
>> Packets from while it is downloading the file:
>
> I’ll forward the link to the people asking this in the ML.

They need the raw data from wireshark. You could activate it before the
download starts, and stop when you abort; then save the data as
“wireshark/tcpdump” type, which I’m told is the default. Then you could
upload that data to the bugzilla, I think.

To reduce the size of the capture do it with the simplest program; I’d
suggest wget, and everything network related stoped: stop kmail and
firefox, or whatever you use. It can be filtered, but they want the raw
data to be sure.

Do not type any password during the capture, just in case :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

Done and uploaded. :slight_smile:

Just to say that I’m heading off for Easter so I won’t be around for a week, but I very much appreciate the efforts to fix this problem both here and on bugzilla, and I’ll definitely be back to carry on trying to figure out the root cause after the holiday.

On 2011-04-21 15:06, esoltech wrote:
>
> Just to say that I’m heading off for Easter so I won’t be around for a
> week, but I very much appreciate the efforts to fix this problem both
> here and on bugzilla, and I’ll definitely be back to carry on trying to
> figure out the root cause after the holiday.

Ok, enjoy :slight_smile:

Just remember that now Bugzilla is more important than here.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

On 2011-04-21 16:20, Carlos E. R. wrote:

> Just remember that now Bugzilla is more important than here.

New suggestion there:

> Ok, let’s ensure it is not an already fixed possible kernel bug, can you
> install latest kernel from Kernel:HEAD repository ?

Can you try?


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

On 2011-04-21 16:50, Carlos E. R. wrote:
> On 2011-04-21 16:20, Carlos E. R. wrote:
>
>> Just remember that now Bugzilla is more important than here.
>
> New suggestion there:

Another suggestion: Try “noapic” in the kernel command line. When grub
starts, just type “noapic” and enter.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)