Volunteering For Testing

Hi,

Forget Discover or any GUI, simply none of them is properly working at best.

Anyway…
Big update right now does not really make much sense, Beta ISO is just around 1 week old so you should not have too much to update.

For my own updates instances, I use the commands:

$ sudo dnf clean all
$ dnf clean all
$ sudo dnf --refresh upgrade 2>&1 | tee konsole_01-update.log

(next will be:
$ sudo dnf --refresh upgrade 2>&1 | tee konsole_02-update.log
etc, as I want to keep trace of every update)

Also, before the very first update I run:
# rpm -e --nodeps openmandriva-repos-4.0-0.0.11.x86_64
accordingly to the output of
rpm -qa|grep repos-4.0

Hope it helps.
:wave:

OK, thanks.

If I understand you correctly, I would perform the following command sequence:

  1. # rpm -e --nodeps openmandriva-repos-4.0-0.0.11.x86_64

$ sudo dnf clean all

1. ```
$ dnf clean all

$ sudo dnf --refresh upgrade 2>&1 | tee konsole_01-update.log


This would yield the standard output on screen display as well as in the files:

1. `rpm -qa|grep repos-4.0`
1. ```
01-update.log

02-update.log

1. `(etc.)`

The resulting files would be presumably sufficient to proceed with any necessary diagnostic action.

Your post looks a bit messed because of the editor formatting, but I think you got it.

First grep repos-4.0 for the right rpm file name to remove
then remove package by rpm command as root, since we need to keep deps in system, otherwise with dnf remove all repos will go :slight_smile:
then clean the cache
finally run the upgrade command whose output will be written in a file in your home.

Note: the above is my own procedure. May be worth of a try.
It never gave me any problem. YMMV :wink:

Here’s what I got:

[michael@michael-pc ~]$ rpm -e --nodeps openmandriva-repos-4.0-0.0.11.x86_64
error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied)
[michael@michael-pc ~]$ \

rpm -e --nodeps openmandriva-repos-4.0-0.0.11.x86_64
error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied)
[michael@michael-pc ~]$ sudo rpm -e --nodeps openmandriva-repos-4.0-0.0.11.x86_64

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

[sudo] password for michael:
[michael@michael-pc ~]$ sudo rpm -e --nodeps openmandriva-repos-4.0-0.0.11.x86_64
error: package openmandriva-repos-4.0-0.0.11.x86_64 is not installed
[michael@michael-pc ~]$ rpm -e --nodeps openmandriva-repos-4.0-0.0.11.x86_64
error: package openmandriva-repos-4.0-0.0.11.x86_64 is not installed
[michael@michael-pc ~]$

Ofc you cannot run rpm -e --nodeps.. ..
as user.

Do:
rpm -qa|grep repos-4.0
See if openmandriva-repos-4.0 package is installed.

For first command string run as root I got this:

[michael@michael-pc ~]$
[michael@michael-pc ~]$ su
Password:
[root@michael-pc michael]# rpm -e --nodeps openmandriva-repos-4.0-0.0.11.x86_64
error: package openmandriva-repos-4.0-0.0.11.x86_64 is not installed
[root@michael-pc michael]#

Ok, so you don’t have the release repos flooding your cooker repositories. Good.
Go ahead with cleaning, and with upgrade :slight_smile:

Okay, thanks…

…here goes!

.

Post-edit: Since you have already started go ahead and finish updates exactly as @rugyada described. That is an excellent procedure for testers. (I’ll be adopting that myself.)

No, If you just installed Beta you can not have 1,315 updates. Something is wrong. Also on the Beta ISO Discover is not used for updating. If you are clicking on the system tray update icon and it opens Discover something is completely wrong.

The updater in use on the Beta is called:

plasma-pk-updates.x86_64 : Plasma applet for system updates using PackageKit

Post-edit: The Beta x86_64 ISO can be identified at the very top line of the Grub2 menu where it will say:

Welcome to OpenMandriva Lx 4.0 x86_64 plasma BUILD ID: 2416

The “BUILD ID: 2416” is the key identifier of all OM ISO’s. You need to verify that on the ISO you installed from. Also do checksums match. Good testing procedure for ISO’s means we always verify checksums of any new download. (Yes, even if downloaded and checked previous, if you download again, check it again, always.)

OK, thanks.

I’ll investigate and report later.

1 Like

FWIW: I just did an install of 2416 in VBox and there are 103 updates. So something close to that number is appropriate.

1 Like

Ben:

I re-ran the Build 2416 Beta installation; there must have previously been some mixup because this time only showed 129 files to upgrade.

I then ran the same four CLI command strings as before, everything completed successfully generating only two potential “warning” log entries:

  1. 2/10/19 9:09 PM warning: /var/cache/dnf/cooker-x86_64-7333483a21d6139e/packages/busybox-static-1.30.0-1-omv4000.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID bf81de15: NOKEY
  2. 2/10/19 9:09 PM warning: /etc/default/grub created as /etc/default/grub.rpmnew

Other than those two entries, there were no indications of any problems during the uggrade.

Thank you and everyone else for your assistance with this.

Now I am ready to check out system functionality with application programs that I typically use.

I will keep you posted as I find further results.

Later.

Michael Orlando

1 Like

See this. It’s telling us do not update until developers finish the Qt5 and related upgrade/rebuilds which is a lengthy process.

So if your system is working OK at the moment, don’t update anything until developers tell us is OK.

1 Like

Thanks for the heads up.

My installation did develop problems as well, so I wiped the drive and reinstalled this morning.

It now says 209 files to update, but I’ll wait for the go ahead.

Later…

1 Like

Should be OK to update again.

Ok, thanks.

I’ll try it and let you know.

MRO

This is old enough to be closed now. If there are any issues or anything to report otherwise (we can hope!) please open a separate thread or if it is a real problem open a bug report.

We have to enforce the concept of:

One issue = one thread

We also have to get users to open bug reports if they believe they have a bug. Developers want bug reports for real bugs not forum threads.