Bug 304266

Please attach yast2 logs 
http://en.opensuse.org/Bugs/YaST

(In reply to comment #1 from Katarina Machalkova)
> Please attach yast2 logs 
> http://en.opensuse.org/Bugs/YaST

attaching doesn't work:

File Too Large
The file you are trying to attach is 9813 kilobytes (KB) in size. Non-patch attachments cannot be more than 5120 KB.
We recommend that you store your attachment elsewhere on the web, and then insert the URL to it in a comment, or in the URL field for this bug.
Alternately, if your attachment is an image, you could convert it to a compressible format like JPG or PNG and try again.


voila: 
http://www.tat.physik.uni-tuebingen.de/~koenig/y2logs.tgz

you really should consider a larger attachment size limit for such yast logs !

(In reply to comment #2 from Harald Koenig)

right now this problem blocks my ability to really update/install and thus test 10.3:-(

if you have any idea how to workaround the situation _NOW_ I'd be very happy get/try some tricks!

topic: update existing 10.1 installation with both KDE and GNOME.

deleting whole gnome and many packages is not an option, neither is a new installation -- and time for conflict management should be less than one hour, please ;-)

The empty error message box is a known bug produced by a timeout. Bug 302496.
I had a look into the logfiles. The solver does many branches for resolvables which are available more than on time. I am working on a solution not branching for resolvables which are binary compatible.
Meanwhile I would suggest that you are using only ONE update repo. It should work much more faster then.

(In reply to comment #4 from Stefan Schubert)
> Meanwhile I would suggest that you are using only ONE update repo. It should
> work much more faster then.

indeed, not using the network repositories (DVD only, wasn't an option at my first try because that time I only had that single CD boot image...), performace is different (but still far from good IMHO)

I noticed that y2base runs with UTF-8 locale.  any chance to chance that (running C/POSIX locale without UTF-8)  for a timing test ?

maybe the UTF-8 performace in ticket #225618 may cause yast performace problems too ????


output of "ps" when I first get into the "installation summary/options" with network repos:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3008 47.1 44.3 276032 229028 tty1    Sl+  14:31   7:48 y2base installation ("initial") qt --noborder --auto-fonts --fullscreen

7+ cpu minutes just for startup, no interactive package selection yet!

after one selection of "pattern" and exit/cancel:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3008 53.6 44.4 276768 229524 tty1    Sl+  14:31  10:50 y2base installation ("initial") qt --noborder --auto-fonts --fullscreen


after some (unsuccessfull) conflict management:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3008 56.1 48.6 300096 251284 tty1    Rl+  14:31  38:04 y2base installation ("initial") qt --noborder --auto-fonts --fullscreen



interesting: yast startup to installation summary w/o network repos:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3007 29.3 33.8 223008 174736 tty1    Sl+  16:03   1:12 y2base installation ("initial") qt --noborder --auto-fonts --fullscreen


much better, but conflict management still is a pain (and again ends in timeout and empty screen for 10.1-update).

I had a look to your testcases and Yes it is really slow.
Currently I do not see why cause other system updates run much more faster.
But the testcase is a good starting point to find out.

> much better, but conflict management still is a pain (and again ends in timeout
> and empty screen for 10.1-update).
Thank you for your feedback. The empty popup has been fixed ( Bug 302496 )
Concerning speed:
- The solver has generated too much brunches for language packages. That I have 
  fixed. It is about 20 % faster now.
- The repo will not parsed correctly concerning filedependencies. This cause more
  solver branches that expected.

So I suggest, that we will try it with the next beta again.
Feel free to reopen the bug if you are still not satisfied with the solver performance. And give me a new testcase again.
Your machine is a nice "grass play area" to find such things. :-)

(In reply to comment #7 from Stefan Schubert)

> So I suggest, that we will try it with the next beta again.
> Feel free to reopen the bug if you are still not satisfied with the solver
> performance. And give me a new testcase again.

ok, here I am again (sorry:-(

last weekend I spend quite some time trying to update that 10.1 system to beta-3 -- still no way...  I still did not manage to even really start the update progress for my 10.1 system.


first I tried with DVD plus net repositories (without net, see below):  
getting into "installation settings" takes 7.5 cpu-minutes! 
click on "pattern selection" and just "accept" takes another 4.5 cpu-minutes,
up to now y2base used 12 cpu-minutes.

starting packages selection, the "autocheck" is selected, so the first 
dependency check is triggered immediately -- 2'50".
as before, it displays exactly one conflict (one of the java_1_5_0_* conflicts).
I selected "delete" and "try again" -- next 2'40" wait.
for 3-4 more java packages, itereate this loop, only one package a time :-(
after java, there are some (few) more conflict reports in one window, 
but still every loop takes almost 3 minutes.

trying to select "all architectures" doesn't make much difference, but this takes almost 4 minutes.
after many more delete/tryagain, I got the 1st "resolver timeout".
I doubled the timeouts 4 times from 30 secs up to 480 secs !!

finally I "cancel"ed this (almost?) infinite loop, displayed the "update problems" list and set all pkgs in this list to "delete" -- this didn't really help.

after quite more than 2 hours of cpu-time(!!) fo y2base I gave up with this setup :-(



next try: DVD, with net repos, and selected "delete unmaintained pkgs". IMHO this should (and in the past did ?!) avoid most/all such conflicts ?!? in my case I didn't see any difference (starting with java_1_5_0, ...). I did not test for another 2 hours of CPU time again;-)

next try: DVD, first with net repos (later again without net, then dvd-only) bur now I selected "only update installed pkgs" (no patterns) _and_ delete unmaintained pkgs. I would have expected a more or less clean 10.3-beta3 installation from these update settings (not at all what I really intended) -- but still I get into the same conflict loops. the only difference I've noticed: now the "update problems" pkgs are already selected as deleted -- but still not all of them and the java_1_5_0_ desaster and numerous other pkgs are still marked red in the installation overview.


my conclution:  right now it is _IMPOSSIBLE_ to update from 10.1 to 10.3 -- which is really *BAD*.


doing some quick tests with a 10.2 partition shows much less problems (still there are some weird/nasty conflicts which I'd like not to see at all;-).  I always advocated that friends shall _update_ their systems and not install everything from scratch with every new version.  now it looks like at least it's not possible anymore to ommit only one distribution (10.2) and directly switch from 10.1 to 10.3 without *major* PITA. IIRC these problems started with 10.2 (which otoh has quite nice new features) and now it got worse but not any better -- tooo bad...


> Your machine is a nice "grass play area" to find such things. :-)

I'm not really sure that it's just "my machine" ?!  this is just an old PC which acts as my play ground.  it's not heavily used and has a mostly "plain installation", not much own stuff and changes to the default system (but e.g. uses pkgs from packman).

I'm really afraid thinking about the update of my real work server (that one is big and not everything is plain "standard":).  the last update from 10.0 to 10.2  as a litte nightmware -- I'm not sure if I really want to step 10.3 at all if this doesn't get better....

but I'll cross fingers, wait and  see ;-)



I kept 2 y2logs.tgz (one for the 1st try, and one "without everything" IIRC) if you're interested (likly both are still too big for your attachment size limit?!):

-rw-r--r-- 1 harald users 11169792 Sep  9 14:15 y2logs.tgz-b3-1
-rw-r--r-- 1 harald users  6188892 Sep  9 15:40 y2logs.tgz-b3-2

Thank you for your hardheadness :-)
Yes, I would like to have these logfiles. Have you made a testcase too in order to reproduce these error ?

*** Bug 231296 has been marked as a duplicate of this bug. ***

voila:

http://www.tat.physik.uni-tuebingen.de/~koenig/y2logs.tgz-b3-1
http://www.tat.physik.uni-tuebingen.de/~koenig/y2logs.tgz-b3-2

(In reply to comment #11 from Harald Koenig)
> voila:
> 
> http://www.tat.physik.uni-tuebingen.de/~koenig/y2logs.tgz-b3-1
> http://www.tat.physik.uni-tuebingen.de/~koenig/y2logs.tgz-b3-2
> 

more (bad?) news trying again to update my 10.1 to 10.3-RC1 using DVD iso image without network connection...

still it takes 10+ minutes (AMD1200, 512MB) to get into package management and see 1st conflict list.

here is one new detail which might explain what's going wrong (or at least points to some problem):

first I set _all_ "update problem" pkgs to delete, then I checked for conflicts. 
after resolving the first 4..5 conflicts with java_1_5_0* I got a list of multiple conflicts.  I was surprised to see pkg names which I thought they should already be marked as deleted, so I pinked this one conflict (see attachment for full list)  and tried to check for details about this package:

from conflicts.txt:

faad2-devel has missing dependencies
    There are no installable providers of faad2 == 2.5-0.pm.2 for faad2-devel-2.5-0.pm.2.i586
    === faad2-devel-2.5-0.pm.2.i586 ===
        faad2-2.5-0.pm.2.i586 provides faad2 == 2.5-0.pm.2, but is scheduled to be uninstalled.
        faad2-devel-2.5-0.pm.2.i586 depends on faad2
        faad2-devel-2.5-0.pm.2.i586 is lacking the requirement faad2 == 2.5-0.pm.2
        There are no installable providers of libmp4v2-devel for faad2-devel-2.5-0.pm.2.i586
    (null)
    Conflict Resolution:
        ( ) delete faad2-devel
        ( ) Ignore this requirement just here


"chroot /mnt/ rpm -qa faad\*" on vc2 during the update shows

faad2-devel-2.5-0.pm.2
faad2-xmms-plugin-2.5-0.pm.2
faad2-2.5-0.pm.2


but in yast2 shearching for "faad" or "devel" I don't see the  faad2-devel pkg at all -- so maybe it's not "known" as beoing marked for delete because yast2 doesn't know it at all ?!?  

see attached screen shots for the search results for "faad" and "devel" pkgs (last one is sorted by pkg names -- no faad entry....)

again, you can find the testcase data here:

http://www.tat.physik.uni-tuebingen.de/~koenig/y2logs.tgz-faad2-devel



still 10.3-RC1 is the first and only SUSE release which I don't manage to even start an update from a "n-2" release -- that's more than disturbing!!!

Created attachment 174093 [details]
conflicts.txt-faad2-devel

Created attachment 174094 [details]
output of: rpm -qa faad2\*

Created attachment 174095 [details]
screen shot for faad search result

Created attachment 174096 [details]
screen shot for faad-devel (devel) search result

Created attachment 174097 [details]
screen shot update summary

(In reply to comment #17 from Harald Koenig)
> Created an attachment (id=174097) [details]
> screen shot update summary

different try in this 10.1 update disaster: a SUSE 10.1 x86_64 partition on my IBM T60 (2 GHz T7200, 2 GB ram) with a plain 10.1 installation (994 RPMs,no packman etc).

I booted from 10.3-GM x86_64 DVD, included network repos (oss and non-oss) for update, and the installation summary looked ok.

BUT then I tried to change the pattern selection -- very bad idea:
after selecting "extended base" pkgs weird conflicts showed up again.
I tried deleting a few problem pkgs, sometime selected "check all archs" and later I got a solver "timeout" again :-(

I increased the solver timeout to 240 secs (on a 2Ghz 2GB box!!) before I cancled that conflict test and gave up again:-(


anyone at SUSE ever tested an update from 10.1 to 10.3 with network  repos ????

small problem aside:  when starting another conflict test, the solver timeout still is set to 240 secs and there is _no_ way to stop this run.  you really have to wait the until timeout.  it would be nice if there would be a CANCEL button for this case! 
obviously it would be  even nicer if this problem would not happen at all;)

anyone at SUSE ever tested an update from 10.1 to 10.3 with network repos (e.g. trying to reproduce my reports or just in generic tests)????


y2logs.tgz available if needed (again 36 MB!!).


next I started another update on this partition without network repos. this time eveyrthing went fine -- I could select many more patterns, only two simple conflicts to resolve, update from 10.1 to 10.3 started ok.

bad news 1:  I can't reproduce this test on the T60 (but I still have the AMD1200 with 10.1 partition;)

bad news 2 (extra ticket coming):  the updated system does not boot anymore :-(
it hangs just after "GRUB loading stage2.."


hmmmmm....

Update from 10.1 to 10.3 is not supported.

But it is an interesting "battle field" for evaluating the solver limits:-)

(In reply to comment #19 from Stanislav Visnovsky)
> Update from 10.1 to 10.3 is not supported.

where and since when is this documented ?

thanks very much for telling me that *now* after spending *many* hours to fiugure out what's going wrong and hoping to give enough information and effort to SUSE to fix this problem before 10.3-GM :-(((

Created attachment 176677 [details]
A spurious missing dependency

I had some problems with the dependency solver when updating from opensuse 10.2 to 10.3, the main one was that some times yast was forgetting that some packages were already set for update, and displayed them as missing dependencies. I have attached a case that demonstrates the problem with readline.

At first I thought the dependency problems are caused by complex update configurations with many installation sources etc. But also installations with a minimum of complexity can cause very difficult dependency solution situations in openSUSE 10.3.

I tested the following:
1) Installation of openSUSE 10.3 with the following options:
   - openSUSE 10.3 DVD1 on a HTTP server
   - "minimum" system
   - an online update
2) Later I decided to install the pattern "X Window System" additional to the minimum system

After selecting the "X Window System" a dependency solving dialog was opened. 

I was supprised about so many dependency problem.

The YaST log file which was produced after selecting the pattern "X Window System" is attached. 

Created attachment 179497 [details]
Log files for installation of pattern "X Window System"

- zypper installation sources
- /var/log/YaST2/y2log
- rpm -qa

(In reply to comment #7 from Stefan Schubert)

> So I suggest, that we will try it with the next beta again.
> Feel free to reopen the bug if you are still not satisfied with the solver
> performance. And give me a new testcase again.
> Your machine is a nice "grass play area" to find such things. :-)

back to the old theread "update depencecy checking sux" :

update -- last weekend I've updated a copy of my 10.3 x64_64 real-work notebook system form 10.3 (current) to 11.0-beta using DVD5 image and it really worked like    a charm!!!

which means, only some 10 dependency conflicts (plenty of forein RPMs e.g. from packman, and own RPMs with different versions/requirements) which have been resolved in ~5 turns within less than 10 minutes -- GREAT !!!! 
(finally, after update nightmares with 10.2 and 10.3:-(((


I'm _really_ impressed about the new packaging/dependency system, thanks!


unfortuneately my old AMD1200 is out of operation right now (needed some "spare" parts -- maybe it's back for beta-2, cross fingers and stay tuned ;-))

So I suggest to close that bug. Thank you for your tenacity ;-)