(FFM-6483) Wider linux kernel support #129
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue
When running an ubuntu 20.04 image on a centos7 machine with linux kernel 3.10 we run into this fairly common linux kernel issue of
error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
. This comes when launching our pushpin dependency.This errors on kernel versions 3.10 because that kernel is incompatible with libQt5Core.so.5 which is only compatible with kernels 3.17 and above. These
.note.ABI
tags trigger compatibility checks by the linker when loaded. Stripping this tag out only disables the check by the dynamic linker for the kernel version to be at least as high and has no other effects. See this discussion and the many pr's that reference it. This and a multitude of forums/articles/github issues all had this same suggested workaround to remove these tags and prevent the kernel refusing to start over incompatibilities in parts of OS libraries we don't need or use.Other changes
Also bumped our pushpin version and we now pull the focal version instead of the bionic one to be consistent, though both work fine.
Note
The only thing I'm unclear on and investigating is why this is an issue with ubuntu:20.04 but wasn't with ubuntu:18.04 for us, it's more for curiosity because the proposed solution I have here seems to be the standard workaround on every repo I've seen encounter it. It appears the answer is that some of these OS level dependencies changed between these ubuntu OS versions and that's why it's now being pulled into the dynamic linker when running on ubuntu:20.04 when it wasn't on ubuntu:18.04 and triggering this issue.
Testing
Tested that this new image runs successfully on centos7 machines with a linux 3.10 kernel as well as on regular aws linux2 AMI