Updating Mandriva

[edwardp]

On my Pentium system (166 MHz Intel/MMX, 256 Mb RAM), when Mandriva is updating, the process where it is reading the packages database takes a good 15 minutes or so before it finishes and the available updates are then displayed. For a system with such a slow CPU, is that long processing time for this particular process, normal? It works, but I'm just curious.

 

In comparison, my 500 MHz K6-2 system (also has 256 Mb RAM) takes no more than three minutes to complete the same process. Both systems download the smaller synthesis.hdlist.cz file.

[pmpatrick]

I think that hdlist.cz is a compressed file. Decompressing is a cpu intensive task. On a P1, you will probably peg the cpu usage at 100% doing any type of compression/decompression. Couple that with the slow hard drive I/O on a typical P1 and you probably have your explanation. By way of example, on my old 500MHz P3, creating a gziped tar archive of a few 100MB will completely peg the cpu for several minutes. It would probably take forever on a 166MHz P1.

[ianw1974]

Your problem is most likely because of easyurpmi and not using the compressed indexes. If your system is configured for hdlist.cz, these are large with all package info. Normally, main and contrib are about 25MB each in size. This can take a while to process.

 

I would suggest removing your sources for main and contrib, and then re-add these again, but on the easyurpmi screen, there is a tick box for compressed index just after the mirror selection boxes. Tick this, and then you'll use synthesis.hdlist.cz instead, which is a lot smaller, normally about 700kb.

[pmpatrick]

Open a console and run:

 

$ top

 

which will give you an ongoing printout of ram and cpu usage. On a P4 3.2GHz with 1GB of ram, when I hit the install software button in mcc, the cpu pegs at 90% for several seconds until the software selection screen comes up. I can only imagine what it does on a P1. Reading the availble software database is apparently very cpu intensive. ian's suggestion may help since you are dealing with a much smaller file, KBs instead of MBs.

[edwardp]

Thanks for the replies.

 

Both systems download synthesis.hdlist.cz for updates, but after it was installed, it used the regular hdlist.cz by default and I now wonder whether those larger files may still have remained and perhaps were still being used for some reason. I timed this process on the P1 last night and it took 20 minutes between the time it began processing that file to the point when the available updates appeared.

 

Ran urpmi.removemedia -a and added them in again. Right after it (the P1) began reading the packages database, I opened a Konsole and ran top, the CPU percentage varied but it peaked at 97.1%. This time, it only took 7 minutes on the P1, which is a lot better. :)

 

Even though it only takes a few minutes on the K6-2 to do the same, I am going to repeat the removal/add process with the K6-2 in the event that what I described above (old hdlist.cz files) could also be occurring on the K6-2.

[edwardp]

After removing the media entries and adding them in, the K6-2 took only 1 minute to complete the reading of the packages database. This is also an improvement. :)

[edwardp]

The improvement was short-lived. There were new updates since last night and today, the same process took 17 minutes. It's really back to where it was, even after the above was performed.

[ianw1974]

Can I ask exactly what command you are using that is taking so long?

[edwardp]

• Mandriva Linux Control Center
  Software Management
  Look at available updates and apply any fixes...
  

is what I do on both systems to download/install updates.

 

I've never used a command line (via Konsole) to update.

[ianw1974]

Try doing it this way. We can get timings on the command from the system, than manually timing it:

 

time urpmi.update -a

 

that command updates your media repositories. Then try:

 

time urpmi --auto-select

 

then when asked to continue with y/n, say no, and we'll see how long it took to read the repositories before attempting to download the updates. No need to test downloading, as this can vary from speed of internet links and amount of packages to download.

[michaelcole]

I do the manual update of the compressed versions in the background in the morning.

 

Later if i want to run an actual update of the system i run

 

urpmi -v --auto-select

 

There is the other command you can use which is

 

urpmi -v --auto-update

 

this will first update the lists then do the software updates.

 

I think the speeds may have changed as the number of packages and dependencies have increased.

 

Each time it has to check that the updates will not break what you have previously installed, more installed will take longer, also more updates will be available.

 

If you have multiple computers to upgrade often it may be better to run rsync and bring all the files you may need down closer so as the Internet is only used once.

 

I have an exclusion file which helps in this (Don't download all languages.)

 

Also with rsync you can set a bandwidth limit so as not to stress out your connection or the other end.

 

Only problem with this is you need quite a bit of space on the hard disk.

[edwardp]

time urpmi.update -a

17.06user 1.68system 0:26.86elapsed 69%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (57major+23109minor)pagefaults 0swaps

 

time urpmi --auto-select

131.16user 4.28system 2:34.89elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8major+11309minor)pagefaults 0swaps

 

For both main and updates, synthesis.hdlist.cz was downloaded.