Yep, I agree, it’s a problem with Maya and ADesk, RHEL is just an os with updates, so ADesk should adapt to it…
Not to worry, Houdini works perfectly and that’s all that matters to me, I can access all my old scene files using the Vm.
I merely wanted to ask if anyone else here, had any issues with Maya and 8.7 and if so, was there a workaround, but no worries, life goes on…
i installed Maya 2023 on Rocky linux 9. i had some problems, i just fix 1 of them, but there it is more around Arnold pluggin. i am trying to fix them
O.K.
Glad to report that I have tracked down the culprit, I used the command:
$ sudo strace -f -s999 -v /usr/autodesk/maya2023/bin/maya
and got the readout which contained the reference to:
“/lib64/libmd.so” which was a link to libmd.so.0.0.5
So I renamed libmd.so.0.0.5 to libmd.so.0.0.5-0000 and Maya 2023 started as normal.
It appears that Maya has it’s own versions of libmd.so, so I wonder why it is trying to use the system’s version,
Anyway, happy days again, so frustrating when this stuff happens…
Not a good idea, since anything else on your system that relies on that will now be broken because you just renamed a system-wide library. You should open a bug or report it to Autodesk to get them to fix their app properly.
Alternatively, attempt to remove it:
dnf remove libmd
and see if it’s going to uninstall just itself or a whole load of other apps to find out what kind of severity you are facing. If it removes itself, then at least the library is removed and doesn’t exist on your system. If it wants to remove half of your installed system as well, then that is a much bigger problem. I would expect since libmd shows as being part of EPEL that your KDE install has pulled this in, which means your KDE desktop relies on it and might now be unstable due to you renaming the library.
What you can also do, is add a library path to Maya, so let’s assume Maya has /usr/autodesk/maya2023/lib directory, you could do:
LD_LIBRARY_PATH=/usr/autodesk/maya2023/lib /usr/autodesk/maya2023/bin/maya
that way you force Maya to use it’s own lib directory first without it searching in /usr/lib and finding the system-wide conflict.
ldd /usr/autodesk/maya2023/bin/maya
should show the libs (including path) that the binary ‘maya’ will directly link on runtime.
Since the maya has its own copy of Qt, it must somehow already find those libs before systems Qt (if any). How then it manages to find systems libmd first?
I only renamed it to see if it had any effect on Maya, after this I renamed it back and then un-installed it which took out a good chunk of Gnome (gdm), I then had no screen and a reboot took me back to the terminal login where I reinstalled gdm which gave me my Gnome Desktop again but no login gui, now when I boot I get to the terminal where I can login which then calls KDE, not too much of an inconvenience, but I did like the gui as a login screen.
Gnome comes from Rocky’s own repos. The libmd (library that provides message digest functions from BSD systems) is in EPEL. Nothing on Rocky’s own repos depends on anything in EPEL. Therefore, the removal of libmd should not have affected gnome. (EPEL does have additional packages for gnome, but they are not essential.)
One can use dnf history to check what packages were affected by (dnf) transactions and even ‘undo’ transactions.
I’m just telling you what happened, the uninstall took out a good chunk of Gnome making it unable to boot into Gnome, I reinstalled gdm to get to Gnome to repair the KDE boot, I don’t even use Gnome, but it’s good to have it there as a backup window manager.
Hi Tony,
In reply to your post. I also have a similar set up to yourself Houdini, Maya Substance painter etc all on my Mac but I now have a rocky Linux partition on my Mac too.
So my question to you is how easy was it to keep up all these apps? Do they crash? How easy was the install? Etc
Regards
Luke
GDay Djdoogle123, They are rock solid and never crash, I spend many hours daily on Rocky (8.7) using Houdini and SPainter without any issues at all, I am rendering in both Arnold and Karma XPU without any problems.
Hey Tony thanks for the reply! That’s great to hear…isn’t there some issues with shared libraries etc?
Everyone who I have spoken to says rocky is terrible choice.
But from what you say it sounds like the right one.
How was installation process for each of these pieces of software?
And what made you go with rocky?
Regards,
D
I started with fedora, then went with Centos and then on to Rocky, I believe in with sticking with what you know and what works, there may be a few dep that you have to get sorted, but that’s nothing unusual with Linux, all I can say is that Rocky does all that I need and I am happy with it.
That’s exactly my thoughts but seeing as 8.7 is old kernel does it work with Houdini 19.5 and Maya 2023.3 etc?
Yes, they work perfectly.
Awesome! I don’t understand why more people with DCC’s dont use Rocky 8.7 as a daily driver, it’s a no brainer for me.
Will, maya run on rocky 9?
Yes Maya 2024, Houdini, all work fine on Rocky 9 without having to do anything strange. see Rocky (VFX Reference Platform) Status
1 Like
Hi, I think the problem is updating 8.6 to 8.7 break the file link,for example libssl.so.10 libcrypto.so.10 libpcre16.so.0, by default maya use these files provided by system path /usr/lib64/, the updating action maybe update these files too, so maya2023 start crash happen.
I use rocky linux 8.7,and install maya 2019 2022 and 2024,every of them porfect ruuning on my system, so i think the rocky linux 8.7 is not the point of problem. after i installed maya, i do some link job like this as often :
sudo ln -s /opt/Autodesk/Adlm/R14/lib64/libssl.so.1.0.2 /usr/autodesk/maya2019/lib/libssl.so.10
sudo ln -s /opt/Autodesk/Adlm/R14/lib64/libcrypto.so.1.0.2 /usr/autodesk/maya2019/lib/libcrypto.so.10
sudo ln -s /usr/lib/x86_64-linux-gnu/libtiff.so.5.3.0 /usr/lib/x86_64-linux-gnu/libtiff.so.3
sudo ln -s /usr/lib/x86_64-linux-gnu/libtbb.so.2 /usr/lib/x86_64-linux-gnu/libtbb_preview.so.2
sudo ln -s /usr/lib/x86_64-linux-gnu/libpcre16.so.3 /usr/autodesk/maya2019/lib/libpcre16.so.0
Of cause, this way depend on your state of your system(the system provide files of these are not rigth version as often, so i use /opt/Autodesk/Adlm/R14/filename### to do soft link, and libtiff,libtbb,libpcre16,these downloaded by internet )hope this replay can help you.
And at last, i suggest you use the autodesk customized rocky linux8.7,it design for flame, many package are include in it, easy to install maya ,houdini, nuke etc.
A better solution to the problem is to export the LD_LIBRARY_PATH before running the app. For example:
export LD_LIBRARY_PATH=/opt/Autodesk/Adlm/R14/lib64:/usr/autodesk/maya2019/lib/:$LD_LIBRARY_PATH
that will ensure it finds it’s own libraries before the system ones. You can in fact add that to .bashrc or .bash_profile in your home directory which will set that every time you login to your system.
Then you won’t get symlinks overwritten all the time when the system is upgraded since you won’t need to create them.
1 Like
If one has environment-modules (or Lmod from EPEL) installed, then one can create a modulefile.
A modulefile (in tcl format):
#%Module 1.0
#
module-whatis "Maya 2023"
prepend-path LD_LIBRARY_PATH /usr/autodesk/maya2019/lib
prepend-path LD_LIBRARY_PATH /opt/Autodesk/Adlm/R14/lib64
The additional benefit of environment modules is that the values are not hardcoded into
environment (LD_LIBRARY_PATH) on login, but can be loaded and unloaded on need.
One can modify other environment variables in modulefile too. For example:
append-path PATH /usr/autodesk/maya2023/bin
1 Like