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 => RESOLVEDResolution: (none) => FIXEDCC: (none) => thierry.vignaud
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.
fixed in my latest updates.
Please see attachment 13862 [details] from bug 31982 If I'm reading it correctly, the rpm db gets converted ok, but not until it caused the first 3132 packages to be skipped leaving an upgrade hanging.
CC: (none) => tarazed25
Severity: normal => criticalCC: (none) => friTarget Milestone: --- => Mageia 9
(In reply to Dave Hodgins from comment #19) > Please see attachment 13862 [details] from bug 31982 > > If I'm reading it correctly, the rpm db gets converted ok, but not until > it caused the first 3132 packages to be skipped leaving an upgrade hanging. It also seems that preparing kernel symbols failed (bad exit status: 130) but I guess that it's totally unrelated. OTOH it might show another bug?
CC: (none) => filip.komar
CC: (none) => tmb
Thierry, can you look for this blocker bug ?
CC: (none) => mageia
(In reply to Dave Hodgins from comment #19) > Please see attachment 13862 [details] from bug 31982 > > If I'm reading it correctly, the rpm db gets converted ok, but not until > it caused the first 3132 packages to be skipped leaving an upgrade hanging. I don't think you are reading it correctly. Len chose the option to download all packages before installing. On the first pass, all priority packages, including urpmi and gurpmi, were downloaded and installed. urpmi then restarted, at which point the mga9 version of urpmi is being used. That downloaded all the files, repeatedly and unnecessarily warning about the bdb_ro database for every package downloaded, then converted the database to sqlite before starting to install packages. It then stalled, which is the subject of bug 31982, but, as far as I can see, is unrelated to this bug. As per comment 18, I believe this bug is fixed.
It is fixed, had a bunch of updates, everything ok.
Soo closing.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Change media from mga8 to cauldron and did a urpmi.removemedia -y Debug Backport Testing 32bit drakrpm-edit-media --expert to enable update remaing media. urpmi --downloader wget --wait-lock --replacefiles --auto-update --auto --download-all and saw numerous warning: Found bdb_ro lines grep bdb_ro install_updates.log | wc -l 2325 Just one example http://mirror.math.princeton.edu/pub/mageia/distrib/cauldron/x86_64/media/core/release/perl-Sub-Quote-2.6.8-1.mga9.noarch.rpm warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend. Posted to [qa-discuss] Ready to release the rc iso images? and David W. Hodgins suggested I modify this bug report.
Resolution: FIXED => (none)CC: (none) => bittwister2Status: RESOLVED => REOPENED
BTW was this supposed to be fixed for DNF too? problem: https://forums.mageia.org/en/viewtopic.php?t=14988
See comment 22. If you use --download-all, you will get lots of unnecessary warnings during the download phase, but the database is converted before the packages are installed.
Ah good. And DNF is good, using our method in release notes; Answering myself: (Morgan Leijström from comment #26) > BTW was this supposed to be fixed for DNF too? > problem: https://forums.mageia.org/en/viewtopic.php?t=14988 (Neal Gompa from comment #8) > For DNF users, we already recommend the "system-upgrade" method, which > transparently handles this correctly.
Keywords: (none) => IN_RELEASENOTES9