| Summary: | rpmdb not converted on update to sqlite | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Marc Krämer <mageia> |
| Component: | RPM Packages | Assignee: | RPM stack maintainers <rpmstack> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | release_blocker | CC: | bittwister2, davidwhodgins, filip.komar, fri, mageia, mageia, marja11, ngompa13, pterjan, tarazed25, thierry.vignaud, tmb |
| Version: | Cauldron | Keywords: | IN_RELEASENOTES9 |
| Target Milestone: | Mageia 9 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | rpm.rpm | CVE: | |
| Status comment: | |||
|
Description
Marc Krämer
2021-08-12 12:31:21 CEST
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 =>
rpmstack 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 =>
RESOLVED
Dave Hodgins
2022-10-25 16:30:47 CEST
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
Morgan Leijström
2023-06-02 15:01:55 CEST
Severity:
normal =>
critical (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
Dave Hodgins
2023-06-02 17:39:38 CEST
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. CC:
(none) =>
mageia It is fixed, had a bunch of updates, everything ok. Soo closing. Status:
REOPENED =>
RESOLVED 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) 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. Status:
REOPENED =>
RESOLVED 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 |