MicroOS dup issue > rpmpkg: detected non-zero blob
Hi, I have a VM running MicroOS. There's nothing critical on it. Recently dups have been failing due to 'rpmpkg: detected non-zero blob' - see snippet below. I assumed some package was borked and it'd eventually get fixed. (Read as: I ignored it until now.) Today it occurred to me that I might try to `transactional-update dup` The problem is still around. Running `zypper clean` did clear the cache but the problem continues. Noting in the bugs database. I don't mind opening a bug. I thought I'd check here in case I've missed something obvious ... Thx! --8-<---8-<---8-<---8-<---8-<-- . . . ( 23/238) Installing: python310-base-3.10.11-1.2.x86_64 [............... warning: rpmpkg: detected non-zero blob, trying auto repair error: python310-base-3.10.11-1.2.x86_64: install failed error: python310-base-3.10.10-2.2.x86_64: erase skipped error] Installation of python310-base-3.10.11-1.2.x86_64 failed: Error: Subprocess failed. Error: RPM failed: Command exited with status 1. Abort, retry, ignore? [a/r/i] (a): a Warning: %posttrans scripts skipped while aborting: kernel-firmware-usb-network-20230517-1.1.noarch.rpm ucode-intel-20230516a-1.1.x86_64.rpm Problem occurred during or after installation or removal of packages: Installation has been aborted as directed. Please see the above error message for a hint. 2023-06-02 10:17:27 Application returned with exit status 8. ERROR: zypper --no-cd dup on /.snapshots/20/snapshot failed with exit code 8! Use '--interactive' for manual problem resolution. Removing snapshot #20... 2023-06-02 10:17:27 tukit 4.2.1 started --- Pablo
Brushed up my web searching skills and ... `rpm --rebuilddb` solved it. https://forums.opensuse.org/t/zypper-error-rpmpkg-detected-non-zero-blob-try... --- pablo
Am 02.06.2023 um 21:11 schrieb Pablo Sanchez <pablo@blueoakdb.com>:
Brushed up my web searching skills and ... `rpm --rebuilddb` solved it.
I'm getting the "non-zero blob" issue regularly in a TW VM. There doesn't seem to be an issue with it, but rebuilddb only makes the messaga go away for the next or next couple of dups; then it comed back. Have a nice day, Berny
On 2023-06-02 17:53, Bernhard Völker wrote:
Am 02.06.2023 um 21:11 schrieb Pablo Sanchez <pablo@blueoakdb.com>:
Brushed up my web searching skills and ... `rpm --rebuilddb` solved it. I'm getting the "non-zero blob" issue regularly in a TW VM. There doesn't seem to be an issue with it, but rebuilddb only makes the messaga go away for the next or next couple of dups; then it comed back.
I ran `smartctl` and my drive looks good. This is the first time it's happened. I'll keep an eye on things. Thank you for responding. -pablo
On 03.06.2023 00:53, Bernhard Völker wrote:
Am 02.06.2023 um 21:11 schrieb Pablo Sanchez <pablo@blueoakdb.com>:
Brushed up my web searching skills and ... `rpm --rebuilddb` solved it.
I'm getting the "non-zero blob" issue regularly in a TW VM. There doesn't seem to be an issue with it, but rebuilddb only makes the messaga go away for the next or next couple of dups; then it comed back.
This message means that rpm found non-empty content of database where it was expected to be empty. It may indicate filesystem corruption or it may indicate some bug in rpm. If you can reliably reproduce it, you should certainly submit an issue on https://github.com/rpm-software-management/rpm.
On 2023-06-03 08:01, Andrei Borzenkov wrote:
On 03.06.2023 00:53, Bernhard Völker wrote:
Am 02.06.2023 um 21:11 schrieb Pablo Sanchez <pablo@blueoakdb.com>:
Brushed up my web searching skills and ... `rpm --rebuilddb` solved it.
I'm getting the "non-zero blob" issue regularly in a TW VM. There doesn't seem to be an issue with it, but rebuilddb only makes the messaga go away for the next or next couple of dups; then it comed back.
This message means that rpm found non-empty content of database where it was expected to be empty. It may indicate filesystem corruption or it may indicate some bug in rpm. If you can reliably reproduce it, you should certainly submit an issue on https://github.com/rpm-software-management/rpm.
On a MicroOS host this is particularly worrying as the rpmdb is in a read-only portion of the filesystem This means the window for any software-triggered corruption is relatively tiny, just the transactional-update happening once a day. Not impossible, but rather unlikely, especially with how many MicroOS users we have these days. Therefore it’s far, far more likely you have an issue causing real filesystem corruption to your root filesystem and this rpmdb error is just your canary in the coalmine making the wider issue more visible. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
participants (4)
-
Andrei Borzenkov -
Bernhard Völker -
Pablo Sanchez -
Richard Brown