On updating older cauldron to latest state shows the following error: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend. After this, install fails until rpmdb --rebuilddb is called. I assume this has to be triggered in post install section...
Converting should be triggered automatic on next reboot. I don't know if converting can be done during the pkg installation and between transactions.
(In reply to Jani Välimaa from comment #1) > Converting should be triggered automatic on next reboot. > > I don't know if converting can be done during the pkg installation and > between transactions. Maybe someone of the rpm stack maintainers can tell, assigning to them.
Assignee: bugsquad => rpmstackCC: (none) => marja11
It's not safe to do it in between transactions either. If doing online upgrade, please reboot immediately after or run "rpm --rebuilddb".
CC: (none) => ngompa13
How will upgrades from Mageia 8 to 9 be handled?
CC: (none) => davidwhodgins
My understanding is that recent urpmi do it on startup (http://gitweb.mageia.org/software/rpm/urpmi/commit/?id=c338043e44c14fc023e6386cf62c0acf97da51be) so after rpm + urpmi etc are updated in the priority upgrade, on restarting the new urpmi would do it
CC: (none) => pterjan
Ah sorry, that code is only when using a chroot.
what about using the same mechanism, that restarts urpmi after initial change of basic packages. The current situation for an update is, that after installing basic updates (rpm, perl, ...) urpmi restarts and afterwards urpmi fails to install anything due to readonly rpmdb. So, if rpmdb --rebuilddb is triggered afterwards, everything should be fine.
(In reply to Dave Hodgins from comment #4) > How will upgrades from Mageia 8 to 9 be handled? We should adjust our documentation so that people know to do system upgrades in a single transaction for URPMI and to reboot *immediately* afterward. That's the safest way to handle an online system upgrade. For DNF users, we already recommend the "system-upgrade" method, which transparently handles this correctly. The issue here is Cauldron-to-Cauldron. People don't generally reboot immediately with stuff that feels like small updates, even if they're fairly major.
The "least experienced" users will upgrade using mgaapplet when it prompts them that a new release is available. It does not use a single transaction.
could mageia-prepare-upgrade (used in mga3 for the usr move) help ?
(In reply to Dave Hodgins from comment #9) > The "least experienced" users will upgrade using mgaapplet when it prompts > them > that a new release is available. It does not use a single transaction. That sounds like something we should fix, then.
Using a single transaction requires a lot more free space. There has to be a better way.
(In reply to Dave Hodgins from comment #12) > Using a single transaction requires a lot more free space. There has to be > a better way. No. A single transaction ensures everything is properly replaced in one go, which eliminates large classes of issues when doing upgrades. For system upgrades, there's a lot less value in the split transactions because the dependency web forces a lot of it to be upgraded together anyway. But because inter-application dependencies are rarely specified at the RPM level, split upgrades tend to subtlety break things. We already tell people to download everything in advance, which forces the free space to be allocated anyway. Going to a single transaction is not worse.
(In reply to Pascal Terjan from comment #6) > Ah sorry, that code is only when using a chroot. That's now fixed in git, it works in all case, even when not using --(urpmi-)-root.
Status: NEW => RESOLVEDCC: (none) => thierry.vignaudResolution: (none) => FIXED
Reopening due to bug 31024
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Priority: Normal => release_blocker
Currently rpmdb --rebuilddb --define "_db_backend sqlite" has to be run manually during upgrades from m8 to m9.
Still an issue in today's test of an upgrade using my aarch64 rpi 4b.