http://bugzilla.opensuse.org/show_bug.cgi?id=1169569
http://bugzilla.opensuse.org/show_bug.cgi?id=1169569#c3
Ralf Czekalla changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 - None |P1 - Urgent
CC| |ralf@czekalla.com
--- Comment #3 from Ralf Czekalla ---
Yamashita, I can confirm, this was not cause by a broken SSD.
I had the same problem yesterday on my KVM-virtualized openSUSE 15.2beta
installation on a proper M.2 NVMe module.
Luckily this is my only BTRFS installation I have since years and I could - the
first time - benefit from its snapshots. (My first BTRFS installation some
years ago broke horribly and never tried it again, but with this beta).
So I rolled back to the snapshot before the zypper dup and
libgcrypt20...12.8.rpm or so and the error was gone.
I now locked both libgcrypt and its hmac for the time being and hope for an
early fix.
Before, I had the experience as if this could be simply a wrong installation
order.
I checked the zypper cache and the hmac was gone and seemed to be active
already in the background with every installed package and prevented every
other option to reinstall the cached libgcrypt20_13.2.rpm again.
BTW, I could do no other package installation, no new login etc. on that
installation. It won't even boot much more than some 1-2 seconds after grub2.
So it was totally broken! Have you tested to execute that 'rpm -e' in that
situation. Haven't thought about that option yesterday because I assumed this
hmac is viral for an installation.
Best regards
Ralf
--
You are receiving this mail because:
You are on the CC list for the bug.
