Checking output prior to continuation of update to Lx 4.0

Development Development Testing
1

Hi.
Followed the update method suggested by Rugyada, obtained this output:

[michael@michael-ms7721 ~]$ sudo dnf clean all
[sudo] password for michael:
1159 files removed
[michael@michael-ms7721 ~]$ dnf clean all
0 files removed
[michael@michael-ms7721 ~]$ sudo dnf --refresh upgrade 2>&1 | tee konsole_02-update.log
OpenMandriva Cooker - x86_64 - Updates 118 B/s | 344 B 00:02
OpenMandriva Cooker - x86_64 1.7 MB/s | 15 MB 00:08
OpenMandriva 4.0 - x86_64 117 B/s | 169 B 00:01
Failed to synchronize cache for repo ‘openmandriva-x86_64’
OpenMandriva 4.0 - x86_64 - Updates 116 B/s | 169 B 00:01
Failed to synchronize cache for repo ‘updates-x86_64’
Ignoring repositories: openmandriva-x86_64, updates-x86_64
Dependencies resolved.

Are the “failed to synchronize cache” messages critical to address before proceeding with the update?

NOTE:
I did find this reference, but I wanted to confirm with those familiar with this release to be sure:

1 Like
2

No it’s a minor, annoying bug not solved yet :roll_eyes:
You can just ignore the ‘warning’.

1 Like
3

Thank you.

Proceeding with upgrade.

Install 7
Upgrade 876
Remove 1

TTYL

1 Like
4

Ok, completed.

Here is the bottom of the console output:

Verifying : kernel-release-desktop-latest-4.20.8-1.x86_64 1772/1772
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing ‘dnf clean packages’.
Executing systemd preset on: mdmonitor.service
Traceback (most recent call last):
File “/usr/bin/dnf”, line 58, in
main.user_main(sys.argv[1:], exit_code=True)
File “/usr/lib/python3.7/site-packages/dnf/cli/main.py”, line 193, in user_main
if exit_code:
File “/usr/lib/python3.7/site-packages/dnf/cli/main.py”, line 64, in main
return _main(base, args, cli_class, option_parser_class)
File “/usr/lib/python3.7/site-packages/dnf/cli/main.py”, line 99, in _main
return cli_run(cli, base)
File “/usr/lib/python3.7/site-packages/dnf/cli/main.py”, line 123, in cli_run
ret = resolving(cli, base)
File “/usr/lib/python3.7/site-packages/dnf/cli/main.py”, line 168, in resolving
except dnf.cli.CliError as exc:
File “/usr/lib/python3.7/site-packages/dnf/cli/cli.py”, line 225, in do_transaction
tid = super(BaseCli, self).do_transaction(display)
File “/usr/lib/python3.7/site-packages/dnf/base.py”, line 882, in do_transaction
tid = self._run_transaction(cb=cb)
File “/usr/lib/python3.7/site-packages/dnf/base.py”, line 1031, in _run_transaction
self._verify_transaction(cb.verify_tsi_package)
File “/usr/lib/python3.7/site-packages/dnf/base.py”, line 1069, in _verify_transaction
self.history.end(rpmdbv, 0)
File “/usr/lib/python3.7/site-packages/dnf/db/history.py”, line 504, in end
bool(return_code)
File “/usr/lib64/python3.7/site-packages/libdnf/transaction.py”, line 758, in endTransaction
return _transaction.Swdb_endTransaction(self, dtEnd, rpmdbVersionEnd, state)
RuntimeError: TransactionItem state is not set: cups-drivers-capt-0.1-19:2015.0.x86_64
[michael@michael-ms7721 ~]$

Please advise.
Thanks.

1 Like
5

Please post code as code, it matters. (Use this Icon </>).

Now the explanation as far as I understand this after considerable conversation with developers. This is simply and only an incorrectly named package. There is nothing wrong with the package itself, regardless of whether you have the old version or the new version the only difference would be that the package got rebuilt to correct the naming with no other changes.

The only actual error is this.

Which is an incorrectly named package. OM Lx 4 packages are not supposed to be named “2015”. On my system that package is now:

$ rpm -qa cups-drivers-capt
cups-drivers-capt-0.1-24.x86_64

If you want to correct that:

$ sudo rpm -e --nodeps cups-drivers-capt
$ sudo dnf install cups-drivers-capt

Should do that. I would like some feedback on this though as I’m still learning how to advise users when they see this error. For one did the above solution provide you with the correctly named package?

Post-edit: When I was going over this with @bero about 2 days ago there were more packages than ‘cups-drivers-capt’ there were 5 others tied to our ‘task-printing’. So I’d also like to know if more of the errors come up, we thought we had that fixed. This is the list:

pnm2ppa 
printer-tools (Renamed to printer-utils)
telepathy-haze 
cups-drivers-lbp660
cups-drivers-ptouch
cups-drivers-capt

All of these were rebuilt and now have correct naming as far as I know. These are all ancient packages that almost none of us are likely to be using. These may in the near future be removed from default package list. For most of us you could simply remove all 6 with ‘rpm -e --nodeps’ and move on without concern. In the unlikey event some of these turn out to be needed it is easy to re-install them.

1 Like
6

I’m replying in multiple posts because IMO there are 2 different questions to answer.

Now I would think the other question would be did or did not the update actually update anything. That would be easier to tell if we had all of the Konsole output with the commands used. If this is a lot of lines (more than say 20) give it a descriptive name and put it in a .txt file and attach the file here with the Upload Icon.

However if you have a long list of “Verifying” packages that does imply that the update largely succeeded. You can also tell if update succeeded by simply running the update command again. After any large update I always run update command again to be sure all updated packages got pulled in the first time.

I hope these two posts help and do not confuse anyone. If there is confusion or questions please ask.

1 Like
7

I agree with everything @ben79 wrote.

1 Like
8

@deltakprime I just did an update in VBox and got the exact same error as you did. I can confirm that users can just ignore this. All updates completed. This is the supposed error message:

The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Traceback (most recent call last):
  File "/usr/bin/dnf", line 58, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 192, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 167, in resolving
    base.do_transaction(display=displays)
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 225, in do_transaction
    tid = super(BaseCli, self).do_transaction(display)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 882, in do_transaction
    tid = self._run_transaction(cb=cb)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 1031, in _run_transaction
    self._verify_transaction(cb.verify_tsi_package)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 1069, in _verify_transaction
    self.history.end(rpmdbv, 0)
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 504, in end
    bool(return_code)
  File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 758, in endTransaction
    return _transaction.Swdb_endTransaction(self, dtEnd, rpmdbVersionEnd, state)
RuntimeError: TransactionItem state is not set: cups-drivers-capt-0.1-19:2015.0.x86_64

So if you then run ‘rpm -qa’ on the package mentioned we can see that it was in fact updated:

$ rpm -qa cups-drivers-capt
cups-drivers-capt-0.1-24.x86_64

And if we run the update command again there are no updates to process.

$ sudo dnf --refresh update
OpenMandriva Cooker - x86_64 - non-free                                                                                                                      3.8 kB/s | 1.5 kB     00:00    
OpenMandriva Cooker - x86_64 - Restricted                                                                                                                    4.0 kB/s | 1.5 kB     00:00    
OpenMandriva Cooker - x86_64                                                                                                                                 4.2 kB/s | 1.5 kB     00:00    
Dependencies resolved.
Nothing to do.
Complete!

Post-edit: FWIW: I confirm in several other ways that updates completed.

Aside: Why developers provide us with such error messages and/or warnings is beyond my comprehension. :thinking:

9

Thanks, Ben.

I haven’t noticed any other indications of errors.

Whatever the purpose may be, I don’t know either.

Is it possible that some kind of cookie-cutter cut and paste modular boilerplate code was lifted and inserted without consideration of potential irrelevance of this portion?

1 Like
10

Yes it is that combined with all the changes associated with changing from urpmi/rpm5 to dnf/rpm and some things needing to be cleaned up. Just for users to know that the trigger for that particular error is simply incorrectness in the package name, it does not indicate anything inherently wrong with the package listed. And how we are fixing those is simply by doing a rebuild on the packages affected one by one as we find them. The rebuild is simply to change the package name to correct syntax for current software. Hope this all makes some sense to users.

I guess this just gave me a good chance to practice my answer to this one. I suspect I’ll get to answer this one a few times after final release. :roll_eyes:

11

I’d say you’re getting the response pretty well down pat.

:+1::wink:

1 Like