• Rpm-db broken?

    From Markus Robert Kessler@2:250/0 to All on Sat Feb 10 01:21:50 2024
    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

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Sat Feb 10 02:28:06 2024
    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

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Markus Robert Kessler@2:250/0 to All on Sat Feb 10 12:53:38 2024
    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

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Markus Robert Kessler@2:250/0 to All on Sat Feb 10 12:54:08 2024
    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

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Markus Robert Kessler@2:250/0 to All on Sat Feb 10 13:49:53 2024
    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

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Jim@2:250/0 to All on Sat Feb 10 15:41:25 2024
    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.

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Markus Robert Kessler@2:250/0 to All on Sat Feb 10 16:14:27 2024
    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

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Sat Feb 10 16:54:00 2024
    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

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Markus Robert Kessler@2:250/1 to All on Sat Feb 10 19:02:19 2024
    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

    --- MBSE BBS v1.0.8.5 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)