Volunteering For Testing

Actually, it did… but I’ve discovered another glitch:

Apparently, Gwenview will initially allow me to view about a dozen or so (exact number to be verified later) photos from my phone, but once that number is reached, no further photos can be opened individually, although I can see the entire collection in browse mode.

And I can still continue to open any of the individual photos that I had already opened prior to reaching the limit.

I will retrieve and send the exact error message later on.

Here is the error message:

Loading ‘f778d38098862a4cff3131ae6699ee59.jpg’ failed
Loading meta information failed.

Interestingly, the “<” and “>” keys function in Gwenview individual mode if the target directory is on a hard disk, but they don’t on the phone

Bug report with as much detail as you can provide including omv-bug-report.log.xz.

Will do.

Ben:

Sorry about the lapse in activity/communications; I’ve been extremely busy with other work.

I did get the notice yesterday announcing the release of Lx 4.0 Beta, so I proceeded to download the file from SourceForge.

(By some fortunate coincidence, my installed Lx 4.0 Alpha version failed during the download of the Beta file…

…ever run out of gas as you pull up to the pump? :grinning_face_with_smiling_eyes:)

Anyway, Beta downloaded & written to thumb drive via Rosa, loaded live version = OK, installed from Beta live version via the install option = OK (using it now to write this.)

QUESTION:

Discover shows a mere 1,315 update files totaling approximately 1.1GB waiting, if prior experience is any indication, to mercilessly mutilate my installation. (Presumably without update progress status indicators, of course!)

(“The optimist asked for a taste of the pessimist’s wine…” - from Hallowed Be Thy Name by Emerson Lake & Palmer, lyrics by Peter Sinfield https://youtu.be/q8cjlvI6wIY)

Last time I attempted the Alpha version update, you suggested I use this command in Konsole, which I did:

$ sudo dnf --refresh upgrade

The resulting screen output was so large a file that apparently it exceeded some size limit; I was unable afterward to scroll the screen display up to the beginning of the file, as it had been overwritten, at least as far as the display screen was able to show.

This time I want to direct the output to be simultaneously displayed on the screen as well as written to a file, and as much fun as this purports to be ("Masochist: “Beat me.”… Sadist: “No.”), I only want to do it once, if at all possible.

I have found a potential solution in the CLI “tee” command; however, there appears to be some discussion about the intricacies of how the resulting combination of stdout and stderr will be chronologically displayed, with several complex options suggested.

I don’t know how familiar you are with this command, or to what extent it may make any difference, but if so:

Since I want to obtain full, accurate, detailed (and especially useful!) information regarding the progress of this update process, what command string(s) would you consider the optimally preferred choice for debugging purposes?

I appreciate your assistance with this, Ben, and I respect your opinion.

I really do want to obtain and address every last bit of relevant information so this upcoming release will be stable and optimized.

I know it’s only in Beta now, and I don’t mind tracing and correcting every fault detail, but I don’t want to do this incompletely and leave any stone unturned.

What do you think about the issue of stdout and stderr entries appearing out of chronological sequence in the output file?

Is this a concern?

Do you advise combining them into a single file?

Any other thoughts and/or suggestions?

Your thoughts would be greatly appreciated.

I’m eager to dive into this… this version so far looks really good!

Thanks, Ben

Sincerely,

Michael Orlando

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