Bugzilla – Bug 308352
packages error updating from gnome single cd beta1
Last modified: 2019-02-08 15:15:14 UTC
Created attachment 162449 [details] Error screenshot I got some errors updating from beta 1 to beta 3 using the gnome cd. Also there was a problem writing the new grub conf. Attached you will find the yast logs an a screenshot with the update error. I had to click ignore a couple of times to complete the installation.
Created attachment 162450 [details] Yast logs.
Please for different bugs file different bug reports.
Actually this bug is for the packages problems. I already filled a bug before for grub, because it happened too with 10.2
The update fails due to a broken rpmdb. The error screen is full of: rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery @Sergio: You should run 'rpm --rebuilddb' (as root).
Zypp does no rebuildDatabase on update. Code is disabled.
I don't want to risk this for 10.3. Did the old code run for 10.2?
No, rebuilddb is disabled since 10.1.
OK, then move to 11.0 and change it early in the process.
Since libzypp-4.13.0 ZYpp::initializeTarget takes an additional option, telling whether to rebuild an existing rpm database before using it. Default is false. If pkg-bindings make this option available in YAST, YAST is able to control this. It might make sense to ask the user whether a rebuild should be done on upgrade, because it easily takes 5 or more minutes. @Zypper: zypper could offer some rebuilddb command/option for convenience.
(In reply to comment #10 from Michael Andres) > @Zypper: zypper could offer some rebuilddb command/option for convenience. the -b and -B option should be able to do this, see zypper help refresh -b, --force-build Force rebuild of the database. -B, --build-only Only build the database, don't download metadata.
Jano: This is not about the rebuild of the cache (solv files now) or the repo metadata. It's about rebuilding the rpm database (what rpm --rebuilddb is doing). That's a separate thing, and not one that normally should be done, and hence should not be part of other options.
Ah, i see. Thanx. OK then, no work for me :O)
I just have added Pkg::TargetRebuildInit(string root) function in SVN which rebuilds the RPM DB before initializing the target. Reassigning to installation/update maintainer... The question is whether we need to rebuild the DB in every update. But I don't know how to detect whether the DB is broken or not. See comment #10.
I think it's well invested time for the user to avoid problems, so I would do it on every distribution update.
rpm -qa | wc -l -> 1339 # This can be used to get some progress: # rpm -vv --rebuilddb 2>&1 | grep "adding \".*\" to Name index\." rpm -vv --rebuilddb 2>&1 | grep "adding \".*\" to Name index\." | wc -l -> 1339 time rpm -vv --rebuilddb 2>/dev/null 1>/dev/null real 0m31.996s user 0m22.229s sys 0m6.844s AMD Athlon(tm) 64 Processor 3000+ So, on every upgrade ... but it will take some time ... Lado, does your function provide some progress or is there any callback I could reconfigure to fit the installation dialogs?
With cold caches (or other disk activity fighting for resources) it's _much_ slower: # time rpm --rebuilddb real 5m2.725s user 0m37.014s sys 0m8.329s With not too cold caches, but some other activity on this machine after the above it still takes 2 minutes: # time rpm --rebuilddb real 2m18.374s user 0m33.714s sys 0m6.964s
OK, so the question is whether we're able to find out that the database is broken and rebuild it only if it is. Mls is maintainer or rpm.
To comment #16: libzypp already provides rebuild callbacks, the standard yast callbacks open a popup with a progress bar. You are free to define your own functions...
How should rpm find out in advance that its database is broken?
Well it's a database :) Databases can (sometimes) check their consistency. OK, so we have to either call 'rebuilddb' for every upgrade or for none as there is no way to find out the rpm db status.
Generally --rebuilddb only rebuilds indices from the package headers (that are stored in /var/lib/rpm/Packages). If that file is already broken, --rebuilddb won't help anyway I think (you would need to dump and load the contents). I think the easiest situation how to detect a situation where --rebuilddb still helps is in the error code returns of the various rpmdb functions. They will return DB_RUNRECOVERY in that case. I don't know if only rpmdbOpen can return that code, or also other functions. Probably you also need to intercept the external rpm calls and parse its output messages for "DB_RUNRECOVERY", as the zypp code still might be able to open the Packages db without trying the indices, but the external rpm call will access those, and in case they are corrupted, you need to do something about it.
This sounds like a work for zypp maintainers.
*** Bug 461204 has been marked as a duplicate of this bug. ***
I have no way to check in the code if this was changed thus updating codestream to Tumbleweed for maintainers to review.
DUPLICATE *** This bug has been marked as a duplicate of bug 536846 ***