Bug 1088560 - Installation processes at a certain point remain in a blocking state.
Installation processes at a certain point remain in a blocking state.
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Installation
x86-64 Fedora
: P5 - None : Minor (vote)
: ---
Assigned To: E-mail List
Jiri Srain
Depends on:
  Show dependency treegraph
Reported: 2018-04-07 17:52 UTC by Ricky Tigg
Modified: 2018-06-06 14:06 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
shundhammer: needinfo? (ricky.tigg)

Virtual machines performances (12.53 KB, image/png)
2018-04-07 17:52 UTC, Ricky Tigg

Note You need to log in before you can comment on or make changes to this bug.
Description Ricky Tigg 2018-04-07 17:52:13 UTC
Created attachment 766363 [details]
Virtual machines  performances

Eight installation attempts (3 from DVD, 5 from network). All failed; What a score 8/8. Installation process at a certain point remains in a blocking state (CPU usage 1–36 %, virtual memory used 1020–1135 MiB; see attachment) on the respective medias while the following steps are taking place:

- On DVD – Language, keyboard and license agreement.
- On network – Adding repository... Probe source type – Load data.

Five times out of eight digest verifications of available .rpm repository served by HTTP failed. How do you want me to consider such a protocol used that context? On the web site as well, all download mirrors are served relying on that very protocol. Secure reputation company has indeed; It seems to be a typical joke proper to Opensuse, not to typical German.

Snapshot 20180404. Tested on latest QEMU-KVM platform. Virtual setting are: 
CPUs: 2; Memory: 2048 MiB of 3096 MiB (total host); 
Disk bus: VirtIO, Storage, size: 20 GiB, format: qcow2; 
Disk bus (connected to installation media): IDE
Network: bridge VirtIO
Comment 1 Stefan Hundhammer 2018-04-09 09:40:57 UTC
This would be a really serious problem if we could reproduce it - but AFAIK we've never seen this before. So I can only assume that this is a network problem. 

We are doing literally hundreds of installations (both in automated test setups with openQA and manually) in all kinds of scenarios, so we can be very sure that this is not a general problem of the installation per se.

Having said this, AFAICS this is not a problem of the installer, but to dig deeper into it, we'd need y2logs from one (or, better yet, several) such failed attempts so we can at least identify the general area of the problem; with only that screenshot of CPU usage I am afraid we cannot do anything useful.

See also

Comment 2 Ricky Tigg 2018-04-09 13:51:51 UTC
Hi. Thanks for your prompt reaction. Please pay just a bit attention to the value specified regarding the Hardware:-class. Present context makes therefore a suggestion related to y2logs irrelevant. Is there yet any relevant target which from to dig?
Comment 3 Stefan Hundhammer 2018-06-06 14:06:29 UTC
No y2logs -> no basis for debugging anything. Sorry.