Morning folks, Would this list be the best place to post feedback regarding the test build of the update stack packages you posted yesterday Andreas? Or is it better moved to bugzilla...? If so I can move all this to bugzilla with logs etc. Here are my observations so far anyway. 1. The 10.1 release update stack successfully installed the test builds after I added the URL as a YUM service via zen-updater. However the whole upgrade took an extremely long time ( 15 minutes approx ). I was unable to determine why it was taking so long, i dont *think* it was the downloading... 2. Adding services via rug is just fine, and as per the 10.1 release builds ZYPP services are synced with YaST, YUM services are not. Adding services via zen-updater, same as rug, it works and the synching is the same. 2. Adding a larger service such as main online installation from mirror( inst-sources ) is much smoother. The service itself was added to the list in yast inst_sources almost instantaneously and unlilke the 10.1 release the catalog was not immediately downloaded but was only fetched when the finish button was pressed. At a rough guess I would say the whole process of adding the main installation source is 50% quicker now. 3. ZMD scheduling seems to be a bit broken now. It appears that the service refresh happens at the same time as the hourly maintenance, even though it is scheduled for the next day. Once the full service refresh and maintenance has run ( hourly by default it seems ) the schedule is reset with an updated time for the service refresh 24 hours later and 1 hour later for the maintenance. Of course the service refresh still happens one hour later and another new time i scheduled for it. This has the side effect of a full service refresh will run if my system is booted outside of the hourly maintenance window, parse-metadata and update-status hogging 100% CPU for a few minutes on boot. If i reboot my system inside the hourly maintenance window this does not happen.
Graham Anderson wrote:
This has the side effect of a full service refresh will run if my system is booted outside of the hourly maintenance window, parse-metadata and update-status hogging 100% CPU for a few minutes on boot. If i reboot my system inside the hourly maintenance window this does not happen.
viz bug 177758, a "few" minutes may turn into 30. FMF
On Wed, May 24, 2006 at 10:34:15AM +0100, Graham Anderson wrote:
Morning folks,
Would this list be the best place to post feedback regarding the test build of the update stack packages you posted yesterday Andreas? Or is it better moved to bugzilla...? If so I can move all this to bugzilla with logs etc.
Perhaps as not to clutter bugzilla first things here and if something interesting comes up, people can ask to move that to bugzilla. My experience: This is how most likely an avarge user will see what is going on. I am not a KDE user, nor do I have any real understanding of zen, as I always used YaST and YOU. I hope that some steps I do are extremely stupid, as they will be the steps that Joe Sixpack will also do and perhaps come up with the same questions. I did the update with the updater in the KDE taskbar. At the end I got that zmd was not running. This took very long. Next I noticed that the updater icon was gone. I did a `rczmd restart` and still no icon in the taskbar. As I have no idea how (or if) the icon should come back, I did a reboot. After the update the taskbar again showed the icon. I then added Packman and Guru with YaST as FTP. I then added the same as http with the Software updater icon in the KDE taskbar. I also tried to add the repo from Robert Schiele and that did not work. I will see the others later if they work or not. `rug sl` gave me a time of 1.086 seconds (previously 12 minutes) Just to be sure that there was nothing left in a cache, I rebooted. Then it took about 2.4 seconds. I will leave the machine on for a few hours and see if there is any change -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html
Today I went outside. My pupils have never been tinier...
On Wed, May 24, 2006 at 12:12:38PM +0200, houghi wrote:
`rug sl` gave me a time of 1.086 seconds (previously 12 minutes) Just to be sure that there was nothing left in a cache, I rebooted. Then it took about 2.4 seconds. I will leave the machine on for a few hours and see if there is any change
Waited more then one hour. and ran rug sl again. parse-metadata took 85-95% of the CPU. zmd the rest till 99%. The time it took i just saw 'Waking up ZMD' and no real indication something was going on. The time it took now was 7.21 minutescrontab I will see what putting it in crontab every 20 minutes does. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html
Today I went outside. My pupils have never been tinier...
On 24 May 2006 at 14:10, houghi wrote:
On Wed, May 24, 2006 at 12:12:38PM +0200, houghi wrote:
`rug sl` gave me a time of 1.086 seconds (previously 12 minutes) Just to be sure that there was nothing left in a cache, I rebooted. Then it took about 2.4 seconds. I will leave the machine on for a few hours and see if there is any change
Waited more then one hour. and ran rug sl again. parse-metadata took 85-95% of the CPU. zmd the rest till 99%. The time it took i just saw 'Waking up ZMD' and no real indication something was going on. The time it took now was 7.21 minutescrontab
Try this next time: Get the process id of the "hanging" process (using "ps"). Then try a "strace -p <PID>" and see what's going on. Maybe you should use "ltrace" instead if nothing shows up.
I will see what putting it in crontab every 20 minutes does.
Regards, Ulrich
participants (4)
-
Frank-Michael Fischer -
Graham Anderson -
houghi -
Ulrich Windl