Mageia forum

I tried to update 2010.2 to Beta2 just to end up reinstalling Beta2 from scratch. The problem in short was that Mageia, as well as Mandriva, lacks simple upgrade process or instructions which upgrade ONLY THE ESSENTIAL libraries and tools.
CentOS does it using following:

Code: Select all

yum clean all
yum update glibc\*
yum update yum\* rpm\* pyth\*
yum clean all
yum update mkinitrd nash
yum update selinux\*
yum update
shutdown -r now

After this the essential libraries are upgraded and system is still operational. So my suggestion: find a way to do this. Urpmi currently does this poorly and tries to upgrade everything with almost one pass.

Actually urpmi has a priority list, from /usr/lib/perl5/vendor_perl/5.12.3/urpm/select.pm (in the urpmi package):

Code: Select all

my $default_priority_list = 'rpm,perl-URPM,perl-MDV-Distribconf,urpmi,meta-task,glibc,aria2';

if urpmi sees an update for any of those packages (or itself) it installs it/them first (updating any of their deps too). After that urpmi restarts itself and recomputes the updates. So in fact it's not all done in one go (it even updates glibc, perl, rpm without having to specify them manually on the cli like the code snippet you posted).

ONLY THE ESSENTIAL libraries and tools.

Another idea than ahmad's : actually magiea, as mandriva, have very clean dep trees (better than any redhat i know (from 9, and 4.x, to 5.4), normal [not critic] redhat certainly have others [as the excellent anaconda, with many hack facilitated, and now cobbler wui combined with others tools, and more] tools. So, never mind. Actually i could do, very effectively : urpmi --no-suggests basesystem-minimal, for example. and have finest granularity on install system, with, as you say "ONLY THE ESSENTIAL libraries and tools."

does not make me say that I did not say:p (i love Redhat, and Fedora, and use them everyday) but simply, on this precise point, rpm dep tree on mdv and mga give facilities to control base install.

So, could you please test the other face of this coin ? Try --no-suggests and use skip.list. This is not the same way, but if you need to have granularity on update control, then you need to have granularity of installation control, before. No ?

charcler, user.

Ok. I did not know that there is this "urpmi --no-suggest basesystem-minimal" possibility. Maybe it could be documented better Anyway, I've used Mandriva and now Mageia since before y2k and there has always been this problem. What I'd like to see is that whenever I get huge list of upgradeable packages on version upgrade I could just do "basesystem-minimal" and continue from there. This time I ended up having urpmi at 100% cpu without no hint on what it was doing and no way to bypass the problem.

I am not really understanding part of the problem:
You say that you want to have something like "basesystem-minimal" when doing a release upgrade - what will you do with the rest of the old system?
Urpmi does just what it should do: upgrade all installed packages to their new versions. If you do not want that, what will you do with the old versions on your system? urpmi will try to update them every time you want to do an update run.

I understand the need to keep old versions of single applications (when the new version does not work) but that is usually just one or a handful - you can add them to the skip list.

The idea is to have first a small upgrade which keeps the system in a bootable and working state and then upgrade the rest. I do want to upgrade whole system but doing it as one pass seems to fail all too often. Usually this happens with systems that does not have graphical console rather they are in a server use and upgraded via network access.

Yes, I know that sometimes you need several passes of urpmi to go through the whole system upgrade. But where is the problem with that? Another point: if you upgrade only a part some of the older (not updated) packages may not work correctly. IOW: I see no benefit in that.

Besides: we ran Mandriva on our mandrivauser.de server for almost 5 years - each time we did a system update we tested it on a local "mirror" first and fixed arising problems before we upgraded the real server.

You can use 'urpmi --auto-update --no-install', it'll download everything but won't install them, then in a second pass 'urpmi --auto-update' to actually install the packages.

Note that urpmi caches the rpms in /var/cache/urpmi/* , so make sure you have enough free HDD space.

wobo wrote:Yes, I know that sometimes you need several passes of urpmi to go through the whole system upgrade. But where is the problem with that? Another point: if you upgrade only a part some of the older (not updated) packages may not work correctly. IOW: I see no benefit in that.

The problem was that sometimes, as with now upgrading from MDV to MGA urpmi got stuck in some loop showing 100% processor usage. It does not help to run urpmi multiple times as every time it just cannot do what it is supposed to. Hence, I'm forced to do it in pieces but I'd like to have some help with that i.e. first upgrade essentials and then continue from that. That is what the yum stuff in my first post does.

urpmi consuming 100% of your CPU is obviously a bug, can you see if any other process is consuming the CPU?

No, by using htop/top I could tell for sure it was urpmi.

Which package is it installing when it goes haywire? Any other processes, post installation scripts running? anything taking a considerable amount of CPU/RAM?

FWIW, you can set the package installation transactions, using --split-length:

--split-length count
Split urpmi's operation in small transactions of at least count packages. The default is 8 and setting this value to 0 just disables splitting in small transactions.

Nice, always learning something new. I did not know this --split-length option. Next upgrade will test that. It might be the solution for my "essential packages" only problem. What it comes to RAM and CPU: no problem there. I've tested upgrade with no other processes running i.e. from command line with two ttys open (one for upgrade, one for htop/top). Filesystems not even close to full, and upgrade started straight after reboot.