quartus libprotobuf.so.14 requirement

And 10 minutes later I found the problem with this one.

Half the libraries are not set with other rx permission in the quartus/ linux64 folder..

Fixed with sudo chmod o+rx *so* on that folder.

Now I'm just getting a core dump after resolving all libs ... yay not...

ok and 5 minutes after that I just did a chgrp -R [user group] * on opt/altera/ and that seems to have fixed things.

Installer needs to set permissions a bit better...

Which OS that you are using?

Do you see any error message during the Quartus installation, that indicate libprotobuf.so.14 is required?

Could you help to share the details steps-by-steps or screenshot on how you resolve this issue?

This is so I can feedback this issue to the engineering team.

Best Regards,

Richard Tan

Hi,

Do you able to provide information based on my latest reply?

Best Regards,

Richard Tan

Hi Richard

I installed it on RHEL 9.

The problem came down to the quartus installer not setting permissions correctly.

All the libraries were there (in quartus flatpak library folders).

It seems to set a lot of the permissions for libraries etc to user only, in this case the owner was root as they performed the installation.

However all things things that need to be executed including libraries should be set with 555 permissions so other users can read and execute them.

Config/data files etc files should be set with 644 permissions.

Hmm... As of now, RHEL 9 is not yet officially supported for Quartus. So I not sure if this might be the root cause.

https://www.intel.com/content/www/us/en/support/programmable/support-resources/design-software/os-support.html

Do you observe the same behavior when you try to install in RHEL 8.6, which is officially supported?

Best Regards,

Richard Tan

Hi Richard

I installed RHEL8.6 in a VM to check if the same permissions issue occurred installing it on there.

And yep there are a pile of library .so files that don't end up having other rx permissions set.

This means that only the owner/installer can run quartus after the installation.

Image attached showing one such lib of many.

So to get things to run for other users you need to go and set o+rx on all the appropriate library and script / binaries etc..

or change the group of the entire tree to something each user is a member of.

This is rather unusual behavior.

Analogous to Install only for this user under windows vs the usual default of install for all users..

I think the installer just needs to be tweaked a bit to fix these bad permissions being set during install.

Cheers

Richard

Thank for the feedback on this permission issue.

The engineering team will fix this in the next Quartus Lite/Standard release. (fyi version 23.1std usually release on Q4'23).

As you have found the root cause and the solution for this issue, this will be useful for those who may come across this similar issue.

With that, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Thank you.

Best Regards,

Richard Tan

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

I found the following proposed workaround in the Intel FPGA knowledge base:

https://www.intel.com/content/www/us/en/support/programmable/articles/000093063.html?wapkw=libprotobuf.so.14

The workaround proposed there would work, but it's terrible from a security standpoint in that it leaves all the file permissions fully permissive, including write permissions for all. Yikes.

A better solution is as follows:

sudo chmod -R go=u-w <install_dir>

This changes the permissions for group and others to match those of the owner, except with no write permissions. Just as easy, just as effective at solving the original problem, and much better from a security standpoint.

Yikes! Whoever wrote that support article you mentioned needs to go and learn about security! That is like a 101 failure on any system.

The permission issue after the installer was a complete mess I actually found a few other instances the same as mentioned above.

I just did a very specific set of changes throughout the tree to make sure anything that needed execute had the execute flag turned on.

Also removed any write flags the same way you did, as I did notice that in a few places.

Hopefully Intel / Altera team can fix this up in the next installer to make things a bit smoother.

But other then these issues I can confirm it all seems to work fine on these later Centos / RHEL versions.

Cheers

RT