Rpm-db broken?

[Markus Robert Kessler]

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

[David W. Hodgins]

Post by Markus Robert Kessler
Hi,
- /etc/urpmi/urpmi.cfg seems to be OK
and is like the ones on other machines
- when doing a urpmi --auto-update
$ 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".

Post by Markus Robert Kessler
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

[Markus Robert Kessler]

On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler

Hi,
- /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
machines
$ 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

[Markus Robert Kessler]

Post by Markus Robert Kessler

On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler

Hi,
- /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
machines
$ 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.
- 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.
LIST=`rpm -qa | grep -i drak`
for i in $LIST ; do echo $i ; rpm -V $i ; done
and everything seems OK
uninstalled muse 4.2.1 from core:updates and installed muse 4.1.0 from
core:release instead
'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

[Markus Robert Kessler]

On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler

Hi,
- /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
machines
$ 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

[Jim]

Post by Markus Robert Kessler

On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler

Hi,
- /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
machines
$ 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.
- 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.
LIST=`rpm -qa | grep -i drak`
for i in $LIST ; do echo $i ; rpm -V $i ; done
and everything seems OK
uninstalled muse 4.2.1 from core:updates and
installed muse 4.1.0 from core:release instead
'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.

[Markus Robert Kessler]

Post by Jim

Post by Markus Robert Kessler

On Fri, 09 Feb 2024 20:21:50 -0500, Markus Robert Kessler

Hi,
- /etc/urpmi/urpmi.cfg seems to be OK and is like the ones on other
machines
$ 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.
- 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.
LIST=`rpm -qa | grep -i drak`
for i in $LIST ; do echo $i ; rpm -V $i ; done
and everything seems OK
uninstalled muse 4.2.1 from core:updates and installed muse 4.1.0 from
core:release instead
'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
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

[David W. Hodgins]

On Sat, 10 Feb 2024 11:14:27 -0500, Markus Robert Kessler <***@dipl-ing-kessler.de> wrote:
<snip>

Post by Markus Robert Kessler
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
rpm -e urpmi --nodeps
it complained, but the whole urpmi.* package was removed.
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

[Markus Robert Kessler]

Post by David W. Hodgins
On Sat, 10 Feb 2024 11:14:27 -0500, Markus Robert Kessler
<snip>

Post by Markus Robert Kessler
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
rpm -e urpmi --nodeps
it complained, but the whole urpmi.* package was removed.
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