Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index


I installed a new RHEL 8.5 instance on a laptop.
LO 7.3 did not crash after installation.
It looks like moving from 7.2.5 to 7.3  or some problem with leftover files
in the RHEL upgrade caused the issue.



On Tue, Feb 8, 2022 at 10:30 AM Thomas Stephen Lee <>

On Tue, Feb 8, 2022 at 9:42 AM Michael D. Setzer II <>

On 7 Feb 2022 at 21:24, Andrew Pitonyak wrote:

From:                   "Andrew Pitonyak"
Date sent:              Mon, 07 Feb 2022 21:24:32 -0500
Copies to:              "Dave Barton" <>,
To:                     "Michael D. Setzer II"
Subject:                Re: [libreoffice-users] LibreOffice 7.3 not
working on Fedora

On Monday, February 07, 2022 20:20 EST, "Michael D. Setzer II" <> wrote:
 =On 7 Feb 2022 at 17:17, Dave Barton wrote:</div>
Subject:          Re: [libreoffice-users] LibreOffice 7.3 not
working on Fedora 34??
From:        0;    Dave Barton <>
Date sent:      Mon, 7 Feb 2022 17:17:07 +0000

On 06/02/2022 22:28, Jean-Baptiste Faure wrote:

Le 03/02/2022 à 10:56, Michael D. Setzer II a écrit :
Yesterday, Downloaded and installed and it reports a
crash, but just gives option to submit it, but no details.
Come up in safe mode, but opening calc just drops to
command prompt.
Tried running with strace, and don't see anything that
looks like error.</font>
Have the Fedora 34 regular latest version running fine,
and have the had 7.2.x versions up to 7.2.5 and both work
Thought perhaps having 7.2.5 and 7.3 caused issue, so
uninstalled both, and then reinstalled 7.3, but same
results.> >> Have uninstalled 7.3, and put the 7.2.5 back, and it
working.> >> Only tested with Calc, so not sure if 7.3 had other
working?> >> Don't know what it actual submitted with the error it
found, or if includes any way to contact me of issue?
Thanks.> >>

Seems like this bugreport:

Best regards.> > JBF


This bug has been reported in the forums of a number Linux distros.
issue is very random and appears to only arise in some hardware

For example, I run PCLinuxOS with either Intel or AMD based hardware
a number of machines and I cannot reproduce the crash. For others
near equivalent hardware and software environments to mine, the
crash is
100% reproducible.>
This is going to be a difficult one for the devs to track down.

Did notice something in message log file.
If run libreoffice7.3 but don't try calc there is nothing,
but if try calc and it crashes the log has these lines??

Feb  8 11:04:04 setzconote audit[513755]: ANOM_ABEND auid=1000 uid=0
gid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
pid=513755 comm="soffice.bin" exe="/opt/libreoffice7.3/program/soffice.bin"
sig=4 res=1
Feb  8 11:04:05 setzconote abrt-server[513792]: Package
'libreoffice7.3' isn't signed with proper key

Unfortuantely, the lines on abrt at time don't seem to show anything
to me.
Feb  8 11:04:05 setzconote abrt-dump-journal-oops[2039]:
abrt-dump-journal-oops: Found oopses: 1
Feb  8 11:04:05 setzconote abrt-dump-journal-oops[2039]:
abrt-dump-journal-oops: Creating problem directories
Feb  8 11:04:05 setzconote abrt-server[513792]: Package
'libreoffice7.3' isn't signed with proper keyFeb  8 11:04:05 setzconote
abrt-server[513792]: 'post-create' on
'/var/spool/abrt/ccpp-2022-02-08-11:04:05.227869-513755' exited with 1
Feb  8 11:04:05 setzconote abrt-server[513792]: Deleting problem
directory '/var/spool/abrt/ccpp-2022-02-08-11:04:05.227869-513755'
Feb  8 11:04:06 setzconote abrt-server[513791]: Can't find a
meaningful backtrace for hashing in '.'</font>
Feb  8 11:04:06 setzconote abrt-server[513791]: Preserving oops '.'
because DropNotReportableOopses is 'no'</span>
Feb  8 11:04:06 setzconote abrt-notification[513811]: System
encountered a non-fatal error in ??()
Feb  8 11:04:06 setzconote abrt-dump-journal-oops[2039]: Reported 1
kernel oopses to Abrt


 What I am about to say has no bearing on anything related to reality,
but, this is what I had to do to make VMWare work on Fedora after I built
my own  binaries. The likliehood that this will work for you is very small

I think you will need to create a password for signing. I do not
remember when, but, just think of a password and write it down or something.

(1) Generate a key, but do NOT use CN=VMware, use something like
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER
-out MOK.der -nodes -days 36500 -subj "/CN=VMware/"

(2) Import said key
mokutil --import MOK.der

(3) Sign the file of importance. In my case it was vmmon and vmnet (I
ran this twice) for oyu it is probably soffice.bin
/usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv
./MOK.der $(modinfo -n vmmon)

Will this work? Probably not. If you are using Fedora, why not just
use the version in the repo?

I only mention all this because if it were me I would try it, but I am
on Fedora 35 now and I am using the version from the fedora repo.


Thanks for info, but I'm just installing from the rpm files
included in the libreoffice downloads, so not building
anything from source? Not sure if perhaps they used a
Fedora 35 key for the rpm that is not compatible with
Fedora 34. I build kernels from source for my g4l project.
Just strange that calc seems to fail, but others work.
Something that some libreoffice developer might know.

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:

 Michael D. Setzer II - Computer Science Instructor
 Guam - Where America's Day Begins
 G4L Disk Imaging Project maintainer

This is not just Fedora.
I am facing the same problem in RHEL 8.5 installed using RPMS.


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.