# Can't start paraview in Fedora 37

**URL:** https://discourse.paraview.org/t/cant-start-paraview-in-fedora-37/11418
**Category:** ParaView Support
**Created:** [February 15, 2023, 6:53pm UTC](https://discourse.paraview.org/t/cant-start-paraview-in-fedora-37/11418 "2023-02-15T18:53:37Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![bloodpressure](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/b/5fc32e/32.png) [@bloodpressure](https://discourse.paraview.org/u/bloodpressure)
#### Post date: [February 15, 2023, 6:53pm UTC](https://discourse.paraview.org/t/cant-start-paraview-in-fedora-37/11418/1 "2023-02-15T18:53:37Z")

</div>

Hi,

I am having trouble starting paraview in Fedora 37. I have tried installing from the repo and downloading the binaries. This gives me two separate errors. In the installation from the fedora repo:

> paraview: symbol lookup error: /usr/bin/…/lib64/paraview/libvtkFiltersParallelDIY2.so.1: undefined symbol: \_ZN20vtkDIYGhostUtilities29InflateBoundingBoxIfNecessaryEP10vtkDataSetR14vtkBoundingBox

And from the bindary:

> qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “” even though it was found.  
> This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

error: exception occurred: Subprocess aborted

I have gone down the rabbit hole on xcb and Qt for that second error, but did not find a solution. My issue seems to be the same as this one:

> [@Paraview on Fedora 36 does not start.](https://discourse.paraview.org/t/paraview-on-fedora-36-does-not-start/10112/7):
>
> SOLVED. The bug was that, after installing Fedora 36, an outdated user PATH had been reused, instead of appending the user definitions to the new Fedora 36 default PATH. Advice: pay attention to the user environment in the updates, upgrades, or migrations. Thank you very much for your assistance. Regards. Jorge.

However, I don’t understand what was done in that case to actually solve the issue. If anyone has any ideas that would be great.

Thanks

---

<div class="post-metadata">

### Author: ![wascott](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/w/8e8cbc/32.png) [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [February 16, 2023, 12:12am UTC](https://discourse.paraview.org/t/cant-start-paraview-in-fedora-37/11418/2 "2023-02-16T00:12:02Z")

</div>

Hi bloodpressure. Great name, by the way. My guess is exactly what the SOLVED paragraph states. I believe ParaView doesn’t need a path variable, so kill yours. As I don’t know what shell you are using, I will assume it is bash.  
export PATH=  
pathToParaView/paraview

If that doesn’t work, try something like  
export PAHT=/  
pathToParaView/paraview

---

<div class="post-metadata">

### Author: ![bloodpressure](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/b/5fc32e/32.png) [@bloodpressure](https://discourse.paraview.org/u/bloodpressure)
#### Post date: [February 16, 2023, 1:27am UTC](https://discourse.paraview.org/t/cant-start-paraview-in-fedora-37/11418/3 "2023-02-16T01:27:56Z")

</div>

Well, thanks for the response. I wish I could say I thought of that pun when I chose the name, but in reality it was just the thing at the top of my mind at the time…

So based on your comment, I think I have identified the problem. You are correct that I am using bash. I commented out all the lines in my .bashrc that were non-standard, which were for Julia, FDS (fire dynamics simulator), VisIt, and openfoam. After logging back in, both versions of paraview were working again! It turned out that something in the FDS scripts was breaking things:

```auto
#source ~/FDS/FDS6/bin/FDS6VARS.sh 
#source ~/FDS/FDS6/bin/SMV6VARS.sh

```

This was surprising to me, because FDS doesn’t use paraview, and I didn’t have any mention of paraview anywhere in my .bashrc. Those two .sh files make multiple export commands, and none of them involve paraview as far as I can tell.

I did try

> export PATH=“/usr/bin/paraview:$PATH”

but no luck.

So for now, I will just not expect paraview and FDS to coexist together peacefully and only use them in separate sessions. Solution found, the mystery continues…

Thanks-

---

<div class="post-metadata">

### Author: ![wascott](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/w/8e8cbc/32.png) [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [February 16, 2023, 2:31am UTC](https://discourse.paraview.org/t/cant-start-paraview-in-fedora-37/11418/4 "2023-02-16T02:31:20Z")

</div>

Glad it worked.

PATH (and LD\_LIBRARY\_PATH) does more than just say “Go find ParaView somewhere here”. It can also say “go search here for libraries or system stuff”. And, that’s the danger of EVER putting commands like you have in your bashrc. You don’t know what those scripts are running. My guess is they are messing with PATH, or LD\_LIBRARY\_PATH, or somesuch, and you were picking up a non standard library. Anyway, glad you figured it out.

---

<div class="post-metadata">

### Author: ![bloodpressure](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/b/5fc32e/32.png) [@bloodpressure](https://discourse.paraview.org/u/bloodpressure)
#### Post date: [February 17, 2023, 12:08am UTC](https://discourse.paraview.org/t/cant-start-paraview-in-fedora-37/11418/5 "2023-02-17T00:08:00Z")

</div>

Yes, that is interesting - these sorts of source commands in the .bashrc seem to be common for installing packages like openFoam and FDS, but I never really appreciated how different that is from simply adding the binaries directories for things like julia and paraview. Guess that’s why I am not a developer!

Thanks again-