Hi,

on a MGA9x64 machine there shows up the following problem:

- /etc/urpmi/urpmi.cfg seems to be OK
and is like the ones on other machines

- when doing a urpmi --auto-update
it looks like:

$ urpmi --auto-update
medium "Core Release" is up-to-date
medium "Core Updates" is up-to-date
medium "Core Backports" is up-to-date
medium "Nonfree Release" is up-to-date
medium "Nonfree Updates" is up-to-date
medium "Nonfree Backports" is up-to-date
medium "Tainted Release" is up-to-date
medium "Tainted Updates" is up-to-date
medium "Tainted Backports" is up-to-date

where the above are the repos not remarked out with 'ignore' in urpmi.cfg.

But when the bottom is reached, urpmi process goes to 100%, i.e., it eats
up a whole cpu core, the fan blows and nothing goes ahead.

Someone already had this type of problem and knows how to solve?
Rebuild the rpm db?

Thanks!

Best regards,

Markus

On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:

> Hi,
>
> on a MGA9x64 machine there shows up the following problem:
>
> - /etc/urpmi/urpmi.cfg seems to be OK
> and is like the ones on other machines
>
> - when doing a urpmi --auto-update
> it looks like:
>
> $ urpmi --auto-update
> medium "Core Release" is up-to-date
> medium "Core Updates" is up-to-date
> medium "Core Backports" is up-to-date
> medium "Nonfree Release" is up-to-date
> medium "Nonfree Updates" is up-to-date
> medium "Nonfree Backports" is up-to-date
> medium "Tainted Release" is up-to-date
> medium "Tainted Updates" is up-to-date
> medium "Tainted Backports" is up-to-date
>
> where the above are the repos not remarked out with 'ignore' in urpmi.cfg.

That can be confirmed by showing "urpmq --list-media active".

> But when the bottom is reached, urpmi process goes to 100%, i.e., it eats
> up a whole cpu core, the fan blows and nothing goes ahead.
>
> Someone already had this type of problem and knows how to solve?
> Rebuild the rpm db?

As root, "rpm --rebuilddb".

Regards, Dave Hodgins

On Fri, 09 Feb 2024 21:28:06 -0500 David W. Hodgins wrote:

> On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler
> <no_reply@dipl-ing-kessler.de> wrote:
>
>> Hi,
>>
>> on a MGA9x64 machine there shows up the following problem:
>>
>> - /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
>> machines
>>
>> - when doing a urpmi --auto-update it looks like:
>>
>> $ urpmi --auto-update medium "Core Release" is up-to-date medium "Core
>> Updates" is up-to-date medium "Core Backports" is up-to-date medium
>> "Nonfree Release" is up-to-date medium "Nonfree Updates" is up-to-date
>> medium "Nonfree Backports" is up-to-date medium "Tainted Release" is
>> up-to-date medium "Tainted Updates" is up-to-date medium "Tainted
>> Backports" is up-to-date
>>
>> where the above are the repos not remarked out with 'ignore' in
>> urpmi.cfg.
>
> That can be confirmed by showing "urpmq --list-media active".
>
>> But when the bottom is reached, urpmi process goes to 100%, i.e., it
>> eats up a whole cpu core, the fan blows and nothing goes ahead.
>>
>> Someone already had this type of problem and knows how to solve?
>> Rebuild the rpm db?
>
> As root, "rpm --rebuilddb".
>
> Regards, Dave Hodgins

Thanks!

Though, problem still persists.

What I've done so far:

- tried 'rpm --rebuilddb'

Same behaviour, 'urpmi --auto-update' leads to urpmi hanging after last
repo with 100% CPU load, and

when using mcc ==> update, then drakrpm-update hangs, also 100% CPU load.

- deleted /etc/urpmi and selected different repo mirror in mcc

Same as above.

- checked every package with 'drak' in the name:

LIST=`rpm -qa | grep -i drak`
for i in $LIST ; do echo $i ; rpm -V $i ; done

and everything seems OK

- tested if updates are found anyway:

uninstalled muse 4.2.1 from core:updates and
installed muse 4.1.0 from core:release instead

So, there is at least one candidate that can be updated. But:

'urpmi --auto-update' doesn't find the updated package,
and also mcc ==> update does not find it.

The funny thing is, that mcc ==> install and remove software
shows both candidates, muse 4.1.0 which is still installed, and, ready for
upgrading muse 4.2.1

Strange.

What makes me nervous is that it seems that I will no longer be informed
about bugfixes to install. That decreases security drastically.

Best regards,

Markus

On Fri, 09 Feb 2024 21:28:06 -0500 David W. Hodgins wrote:

> On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler
> <no_reply@dipl-ing-kessler.de> wrote:
>
>> Hi,
>>
>> on a MGA9x64 machine there shows up the following problem:
>>
>> - /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
>> machines
>>
>> - when doing a urpmi --auto-update it looks like:
>>
>> $ urpmi --auto-update medium "Core Release" is up-to-date medium "Core
>> Updates" is up-to-date medium "Core Backports" is up-to-date medium
>> "Nonfree Release" is up-to-date medium "Nonfree Updates" is up-to-date
>> medium "Nonfree Backports" is up-to-date medium "Tainted Release" is
>> up-to-date medium "Tainted Updates" is up-to-date medium "Tainted
>> Backports" is up-to-date
>>
>> where the above are the repos not remarked out with 'ignore' in
>> urpmi.cfg.
>
> That can be confirmed by showing "urpmq --list-media active".
>
>> But when the bottom is reached, urpmi process goes to 100%, i.e., it
>> eats up a whole cpu core, the fan blows and nothing goes ahead.
>>
>> Someone already had this type of problem and knows how to solve?
>> Rebuild the rpm db?
>
> As root, "rpm --rebuilddb".
>
> Regards, Dave Hodgins

Thanks!

Though, problem still persists.

What I've done so far:

- tried 'rpm --rebuilddb'

Same behaviour, 'urpmi --auto-update' leads to urpmi hanging after last
repo with 100% CPU load, and

when using mcc ==> update, then drakrpm-update hangs, also 100% CPU load.

- deleted /etc/urpmi and selected different repo mirror in mcc

Same as above.

- checked every package with 'drak' in the name:

LIST=`rpm -qa | grep -i drak`
for i in $LIST ; do echo $i ; rpm -V $i ; done

and everything seems OK

- tested if updates are found anyway:

uninstalled muse 4.2.1 from core:updates and
installed muse 4.1.0 from core:release instead

So, there is at least one candidate that can be updated. But:

'urpmi --auto-update' doesn't find the updated package,
and also mcc ==> update does not find it.

The funny thing is, that mcc ==> install and remove software
shows both candidates, muse 4.1.0 which is still installed, and, ready for
upgrading muse 4.2.1

Strange.

What makes me nervous is that it seems that I will no longer be informed
about bugfixes to install. That decreases security drastically.

Best regards,

Markus

On Sat, 10 Feb 2024 12:53:38 -0000 (UTC) Markus Robert Kessler wrote:

> On Fri, 09 Feb 2024 21:28:06 -0500 David W. Hodgins wrote:
>
>> On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler
>> <no_reply@dipl-ing-kessler.de> wrote:
>>
>>> Hi,
>>>
>>> on a MGA9x64 machine there shows up the following problem:
>>>
>>> - /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
>>> machines
>>>
>>> - when doing a urpmi --auto-update it looks like:
>>>
>>> $ urpmi --auto-update medium "Core Release" is up-to-date medium "Core
>>> Updates" is up-to-date medium "Core Backports" is up-to-date medium
>>> "Nonfree Release" is up-to-date medium "Nonfree Updates" is up-to-date
>>> medium "Nonfree Backports" is up-to-date medium "Tainted Release" is
>>> up-to-date medium "Tainted Updates" is up-to-date medium "Tainted
>>> Backports" is up-to-date
>>>
>>> where the above are the repos not remarked out with 'ignore' in
>>> urpmi.cfg.
>>
>> That can be confirmed by showing "urpmq --list-media active".
>>
>>> But when the bottom is reached, urpmi process goes to 100%, i.e., it
>>> eats up a whole cpu core, the fan blows and nothing goes ahead.
>>>
>>> Someone already had this type of problem and knows how to solve?
>>> Rebuild the rpm db?
>>
>> As root, "rpm --rebuilddb".
>>
>> Regards, Dave Hodgins
>
> Thanks!
>
> Though, problem still persists.
>
> What I've done so far:
>
> - tried 'rpm --rebuilddb'
>
> Same behaviour, 'urpmi --auto-update' leads to urpmi hanging after last
> repo with 100% CPU load, and
>
> when using mcc ==> update, then drakrpm-update hangs, also 100% CPU
> load.
>
>
> - deleted /etc/urpmi and selected different repo mirror in mcc
>
> Same as above.
>
>
> - checked every package with 'drak' in the name:
>
> LIST=`rpm -qa | grep -i drak`
> for i in $LIST ; do echo $i ; rpm -V $i ; done
>
> and everything seems OK
>
>
> - tested if updates are found anyway:
>
> uninstalled muse 4.2.1 from core:updates and installed muse 4.1.0 from
> core:release instead
>
> So, there is at least one candidate that can be updated. But:
>
> 'urpmi --auto-update' doesn't find the updated package,
> and also mcc ==> update does not find it.
>
> The funny thing is, that mcc ==> install and remove software shows both
> candidates, muse 4.1.0 which is still installed, and, ready for
> upgrading muse 4.2.1
>
> Strange.
>
> What makes me nervous is that it seems that I will no longer be informed
> about bugfixes to install. That decreases security drastically.

Next, I installed yum, containing dnf, and this is the result:

$ dnf check-update
Last metadata expiration check: 0:05:59 ago on Sa 10 Feb 2024 14:40:59
CET.

canberra-common.x86_64 0.30-18.1.mga9
updates-x86_64
canberra-gtk.x86_64 0.30-18.1.mga9
updates-x86_64
cpupower.x86_64 6.6.14-2.mga9
updates-x86_64
filezilla.x86_64 3.66.4-1.mga9
updates-x86_64
kernel-desktop.x86_64 6.6.14-2.mga9
updates-x86_64
kernel-desktop-latest.x86_64 6.6.14-2.mga9
updates-x86_64
kernel-userspace-headers.x86_64 6.6.14-2.mga9
updates-x86_64
lib64bpf1.x86_64 6.6.14-2.mga9
updates-x86_64
lib64canberra-gtk3_0.x86_64 0.30-18.1.mga9
updates-x86_64
lib64canberra0.x86_64 0.30-18.1.mga9
updates-x86_64
lib64gnutls30.x86_64 3.8.0-2.2.mga9
updates-x86_64
lib64pam0.x86_64 1.5.2-5.1.mga9
updates-x86_64
muse.x86_64 4.2.1-1.mga9
updates-x86_64
pam.x86_64 1.5.2-5.1.mga9
updates-x86_64
rosegarden.x86_64 22.06-2.mga9
mageia-x86_64
virtualbox-kernel-desktop-latest.x86_64 7.0.14-42.mga9
updates-x86_64

This one finds all possible update candidates. So, it looks as if the rpm
database is OK.

So, well, I could use yum / dnf from now on, but I'd like to know what
happens here.

Thanks,
best regards,

Markus

On Sat, 10 Feb 2024 12:54:08 -0000 (UTC), Markus Robert Kessler wrote:

> On Fri, 09 Feb 2024 21:28:06 -0500 David W. Hodgins wrote:
>
>> On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler
>> <no_reply@dipl-ing-kessler.de> wrote:
>>
>>> Hi,
>>>
>>> on a MGA9x64 machine there shows up the following problem:
>>>
>>> - /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
>>> machines
>>>
>>> - when doing a urpmi --auto-update it looks like:
>>>
>>> $ urpmi --auto-update medium "Core Release" is up-to-date medium "Core
>>> Updates" is up-to-date medium "Core Backports" is up-to-date medium
>>> "Nonfree Release" is up-to-date medium "Nonfree Updates" is up-to-date
>>> medium "Nonfree Backports" is up-to-date medium "Tainted Release" is
>>> up-to-date medium "Tainted Updates" is up-to-date medium "Tainted
>>> Backports" is up-to-date
>>>
>>> where the above are the repos not remarked out with 'ignore' in
>>> urpmi.cfg.
>>
>> That can be confirmed by showing "urpmq --list-media active".
>>
>>> But when the bottom is reached, urpmi process goes to 100%, i.e., it
>>> eats up a whole cpu core, the fan blows and nothing goes ahead.
>>>
>>> Someone already had this type of problem and knows how to solve?
>>> Rebuild the rpm db?
>>
>> As root, "rpm --rebuilddb".
>>
>> Regards, Dave Hodgins
>
> Thanks!
>
> Though, problem still persists.
>
> What I've done so far:
>
> - tried 'rpm --rebuilddb'
>
> Same behaviour, 'urpmi --auto-update' leads to urpmi hanging after last
> repo with 100% CPU load, and
>
> when using mcc ==> update, then drakrpm-update hangs, also 100% CPU load.
>
>
> - deleted /etc/urpmi and selected different repo mirror in mcc
>
> Same as above.
>
>
> - checked every package with 'drak' in the name:
>
> LIST=`rpm -qa | grep -i drak`
> for i in $LIST ; do echo $i ; rpm -V $i ; done
>
> and everything seems OK
>
>
> - tested if updates are found anyway:
>
> uninstalled muse 4.2.1 from core:updates and
> installed muse 4.1.0 from core:release instead
>
> So, there is at least one candidate that can be updated. But:
>
> 'urpmi --auto-update' doesn't find the updated package,
> and also mcc ==> update does not find it.
>
> The funny thing is, that mcc ==> install and remove software
> shows both candidates, muse 4.1.0 which is still installed, and, ready for
> upgrading muse 4.2.1
>
> Strange.
>
> What makes me nervous is that it seems that I will no longer be informed
> about bugfixes to install. That decreases security drastically.

I speculate the problem might be in corruption of urpmi, or less likely
in rpm or urpmi.update and associated files.

Perhaps reinstall urpmi and maybe urpmi.update and rpm
with options --downgrade and --replacepackages ? e.g. for urpmi:

urpmi --downgrade --replacepackages urpmi

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely
expects users to be computer friendly.

On Sat, 10 Feb 2024 15:41:25 -0000 (UTC) Jim wrote:

> On Sat, 10 Feb 2024 12:54:08 -0000 (UTC), Markus Robert Kessler wrote:
>
>> On Fri, 09 Feb 2024 21:28:06 -0500 David W. Hodgins wrote:
>>
>>> On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler
>>> <no_reply@dipl-ing-kessler.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> on a MGA9x64 machine there shows up the following problem:
>>>>
>>>> - /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
>>>> machines
>>>>
>>>> - when doing a urpmi --auto-update it looks like:
>>>>
>>>> $ urpmi --auto-update medium "Core Release" is up-to-date medium
>>>> "Core Updates" is up-to-date medium "Core Backports" is up-to-date
>>>> medium "Nonfree Release" is up-to-date medium "Nonfree Updates" is
>>>> up-to-date medium "Nonfree Backports" is up-to-date medium "Tainted
>>>> Release" is up-to-date medium "Tainted Updates" is up-to-date medium
>>>> "Tainted Backports" is up-to-date
>>>>
>>>> where the above are the repos not remarked out with 'ignore' in
>>>> urpmi.cfg.
>>>
>>> That can be confirmed by showing "urpmq --list-media active".
>>>
>>>> But when the bottom is reached, urpmi process goes to 100%, i.e., it
>>>> eats up a whole cpu core, the fan blows and nothing goes ahead.
>>>>
>>>> Someone already had this type of problem and knows how to solve?
>>>> Rebuild the rpm db?
>>>
>>> As root, "rpm --rebuilddb".
>>>
>>> Regards, Dave Hodgins
>>
>> Thanks!
>>
>> Though, problem still persists.
>>
>> What I've done so far:
>>
>> - tried 'rpm --rebuilddb'
>>
>> Same behaviour, 'urpmi --auto-update' leads to urpmi hanging after last
>> repo with 100% CPU load, and
>>
>> when using mcc ==> update, then drakrpm-update hangs, also 100% CPU
>> load.
>>
>>
>> - deleted /etc/urpmi and selected different repo mirror in mcc
>>
>> Same as above.
>>
>>
>> - checked every package with 'drak' in the name:
>>
>> LIST=`rpm -qa | grep -i drak`
>> for i in $LIST ; do echo $i ; rpm -V $i ; done
>>
>> and everything seems OK
>>
>>
>> - tested if updates are found anyway:
>>
>> uninstalled muse 4.2.1 from core:updates and installed muse 4.1.0 from
>> core:release instead
>>
>> So, there is at least one candidate that can be updated. But:
>>
>> 'urpmi --auto-update' doesn't find the updated package,
>> and also mcc ==> update does not find it.
>>
>> The funny thing is, that mcc ==> install and remove software shows both
>> candidates, muse 4.1.0 which is still installed, and, ready for
>> upgrading muse 4.2.1
>>
>> Strange.
>>
>> What makes me nervous is that it seems that I will no longer be
>> informed about bugfixes to install. That decreases security
>> drastically.
>
> I speculate the problem might be in corruption of urpmi, or less likely
> in rpm or urpmi.update and associated files.
>
> Perhaps reinstall urpmi and maybe urpmi.update and rpm with options
> --downgrade and --replacepackages ? e.g. for urpmi:
>
> urpmi --downgrade --replacepackages urpmi
>
> Cheers!
>
> jim b.

Hi Jim, thanks for that great hint!

And, yes, it's clear, you cannot remove and reinstall the installer
itself, but, as long as you have an alternative app by hand, it can be
done this way - I did this:

rpm -e urpmi --nodeps

it complained, but the whole urpmi.* package was removed.

Then I reinstalled it this way:

yum install urpmi

Now, 'urpmi --auto-update' runs - and ends - properly :-)

Thanks again,
best regards,

Markus

On Sat, 10 Feb 2024 11:14:27 -0500, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:
<snip>
> Hi Jim, thanks for that great hint!
>
> And, yes, it's clear, you cannot remove and reinstall the installer
> itself, but, as long as you have an alternative app by hand, it can be
> done this way - I did this:
>
> rpm -e urpmi --nodeps
>
> it complained, but the whole urpmi.* package was removed.
>
> Then I reinstalled it this way:
>
> yum install urpmi
>
> Now, 'urpmi --auto-update' runs - and ends - properly :-)

Now that's bizarre. Does dmesg show any i/o errors?

Regards, Dave Hodgins

On Sat, 10 Feb 2024 11:54:00 -0500 David W. Hodgins wrote:

> On Sat, 10 Feb 2024 11:14:27 -0500, Markus Robert Kessler
> <no_reply@dipl-ing-kessler.de> wrote:
> <snip>
>> Hi Jim, thanks for that great hint!
>>
>> And, yes, it's clear, you cannot remove and reinstall the installer
>> itself, but, as long as you have an alternative app by hand, it can be
>> done this way - I did this:
>>
>> rpm -e urpmi --nodeps
>>
>> it complained, but the whole urpmi.* package was removed.
>>
>> Then I reinstalled it this way:
>>
>> yum install urpmi
>>
>> Now, 'urpmi --auto-update' runs - and ends - properly :-)
>
> Now that's bizarre. Does dmesg show any i/o errors?
>
> Regards, Dave Hodgins

Hi Dave,

$ dmesg | grep -i error
[ 7.966751] tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A
750->750000us B 2000->2000000us C 750->750000us D 750->750000us
$

that's all I get.

But, there are some severe issues with the graphics driver on that box:

$ lspci | grep -i graph
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (primary) (rev 03)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (secondary) (rev 03)

so, the machine crashes from time to time when under heavy graphics load.
I.e., when running games (supertuxkart in fullscreen) or watching ultra-HD
movies for a longer time.

Then the whole machine freezes, and, given that at the same time an update
is running, maybe an installation is only partly written and hence
corrupted. Maybe that could be the cause.

Thanks,
best regards,

Markus