Closed fexofenadine closed 3 years ago
appears similar to this issue
Meanwhile a workaround:
Found this solution here: https://github.com/binhex/arch-qbittorrentvpn/issues/5
Meanwhile a workaround:
1. Attach to docker container 2. apt update 3. apt install binutils 4. strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Found this solution here: binhex/arch-qbittorrentvpn#5
This worked, thank you!
Update: as some reported it could be due to kernel 3.1x, my nas Synology DS1815 happens to be on kernel 3.10.105 as well.
We've been unable to replicate this issue within the team and it's not failing our smoke tests here: https://ci-tests.linuxserver.io/linuxserver/qbittorrent/latest/index.html
We've been unable to replicate this issue within the team and it's not failing our smoke tests here: https://ci-tests.linuxserver.io/linuxserver/qbittorrent/latest/index.html
Your tests are on an image of ubuntu18.04 and we are talking about an image of ubuntu20.04. We know that image of ubuntu18.04 works as is stated in the first post.
Our container is on 20.04 and those test results are of the latest image.
Wait I see the confusion, one moment
I see the results are all OK. I can't figure out the problem but I am guessing it is something to do with Synology. It might be the kernel for some reason. Although I use the latest DSM 6.2.3-25426 Update 3, the kernel in this DSM is only 3.10.105 and since docker shares some functions between container and host it might not be compatible and we can't do anything about that probably. Of course, this is only a guess and if someone has more knowledge about that please share.
I'm encountering the same issue, also with a fully up to date Synology DS1817+ (running DSM 6.2.3-25426 Update 3).
# docker version
Client:
Version: 18.09.8
API version: 1.39
Go version: go1.11
Git commit: bfed4f5
Built: Fri Mar 13 06:46:11 2020
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 18.09.8
API version: 1.39 (minimum version 1.12)
Go version: go1.11
Git commit: 3a371f3
Built: Fri Mar 13 06:44:35 2020
OS/Arch: linux/amd64
Experimental: false
The workaround @nhsqr posted is working for me, too. My workaround for now might be to incorporate those into a startup script for the container. I really appreciate your looking into this, @j0nnymoe, as well for the image itself! I'm not a container expert by any means, but please let me know if I can help test or provide more information.
I'll try on my Syno (and qnap for good measure) when I get a free moment (if not it'll be the weekend) and see if I can replicate. :+1:
Getting same issue on Centos7. Following fixes it.
Meanwhile a workaround:
- Attach to docker container
- apt update
- apt install binutils
- strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Found this solution here: binhex/arch-qbittorrentvpn#5
I'm also seeing the same when running the container on CentOS 7.9.2009, kernel 3.10.0-1160.15.2.el7.x86_64 (Docker version 20.10.3, build 48d30b5). The strip
allowed qbittorrent to start for me as well.
https://github.com/binhex/arch-qbittorrentvpn/issues/3#issuecomment-451459254
Issue appears to be that the OS kernel is lower than 3.15, and Qt 5.10 uses the renameat2 system call which is only available since kernel 3.15
I'm on kernel 3.10.108 incidentally
binhex/arch-qbittorrentvpn#3 (comment)
Issue appears to be that the OS kernel is lower than 3.15, and Qt 5.10 uses the renameat2 system call which is only available since kernel 3.15
I'm on kernel 3.10.108 incidentally
If this is the case, because Synology DS1815+ probably won't receive any more kernel updates, I might have to move this docker from DSM's built-in docker to one in a VM that has a v4+ kernel.
have the same issue on latest image
/usr/bin/qbittorrent-nox: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
Meanwhile a workaround:
1. Attach to docker container 2. apt update 3. apt install binutils 4. strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Found this solution here: binhex/arch-qbittorrentvpn#5
This worked, thank you!
Worked for me also
BTW there is no such problem in linuxserver/qbittorrent:unstable-4.4.0202012311433-7161-a579b4a51ubuntu18.04.1-ls148 image
I can confirm this problem occurs on CentOS 7.9 (and likely other RHEL derivatives)
I'm having the same problem on CentOS 7.9 too. Had to roll back the docker image.
Meanwhile a workaround:
- Attach to docker container
- apt update
- apt install binutils
- strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Found this solution here: binhex/arch-qbittorrentvpn#5
I can confirm I was having the same problem on my Synology DS3617xs and this resolved the issue. Linux MySyno 3.10.105 #25426 SMP Tue May 12 04:53:17 CST 2020 x86_64 GNU/Linux
Workaround
Downgrade back to version-14.3.3.99202101191832-7248-da0b276d5ubuntu18.04.1
I can also confirm that the downgrade resolves the issue as well.
Meanwhile a workaround:
- Attach to docker container
- apt update
- apt install binutils
- strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Found this solution here: binhex/arch-qbittorrentvpn#5
I can confirm I was having the same problem on my Synology DS3617xs and this resolved the issue. Linux MySyno 3.10.105 #25426 SMP Tue May 12 04:53:17 CST 2020 x86_64 GNU/Linux
Workaround
Downgrade back to version-14.3.3.99202101191832-7248-da0b276d5ubuntu18.04.1
I can also confirm that the downgrade resolves the issue as well.
Tried this downgrade, but my data didn't load in. I had to install the unstable image.
Same problem here, Synology DS3617xs Solved with the above apt install binutils etc.. Question is, what happens if we update the image next time. Do I need to redo this fix then?
So, this looks like an issue for anyone runnning a V3 kernel. First option for non syno users, Upgrade to a more modern kernel. For syno users, we will see if we can find a solution.
First option for non syno users, Upgrade to a more modern kernel.
CentOS and other EL derivatives are very popular among those seeking stability and long-term patch support. While EL8 with kernel 4.18 is an option right now, a lot of us are holding off upgrading due to the CentOS 8 early EOL and CentOS Stream drama playing out. It would be great if you could at least continue to support EL7 (kernel 3.10) until Rocky Linux 8 comes out and offers us a more desirable upgrade path.
can the .note.ABI-tag section be removed from libQt5Core.so.5 in the base image without impacting people on higher kernels? If the file can't be edited directly, then can the strip be included in the makefile?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Activity
I just noticed that the qBittorrent devs reduced the version requirement of Qt down to 5.11 in today's release. Would that possibly fix this or does Qt absolutely have to be lower than 5.10 to get rid of the problematic kernel function call?
I'm on Synology DSM 7.0 beta which is linux kernel 3.10.108, so I've been using the workaround as well. Very painful to have to keep track of it so closely...
The Synology kernel version isn't linked to the DSM version so much as the hardware. My DS916+ is running
3.10.105
while my DS918+ us running 4.4.59+
, both are running DSM 6.2.4.
The problem is I've no idea what impact removing the ABI-tag will have on people running 4.x+ kernels, which is the vast majority of our users and we don't want to cause them issues in service of fixing this.
As a workaround you can use our customisation logic to automate the strip on image update.
The Synology kernel version isn't linked to the DSM version so much as the hardware. My DS916+ is running
3.10.105
while my DS918+ us running4.4.59+
, both are running DSM 6.2.4.The problem is I've no idea what impact removing the ABI-tag will have on people running 4.x+ kernels, which is the vast majority of our users and we don't want to cause them issues in service of fixing this.
As a workaround you can use our customisation logic to automate the strip on image update.
The kernel is tied to the hardware of Synology. This is definetly good to know. I also didn't know about the customisation logic and it works perfectly. Thank you!
Edit:
Just to clarify - I made this very short script
#!/usr/bin/bash
apt update
apt install -y binutils
strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
And I put it in directory /config/custom-cont-init.d/script.sh
And that was it! :)
So I consider this issue closed.
The Synology kernel version isn't linked to the DSM version so much as the hardware. My DS916+ is running
3.10.105
while my DS918+ us running4.4.59+
, both are running DSM 6.2.4. The problem is I've no idea what impact removing the ABI-tag will have on people running 4.x+ kernels, which is the vast majority of our users and we don't want to cause them issues in service of fixing this. As a workaround you can use our customisation logic to automate the strip on image update.The kernel is tied to the hardware of Synology. This is definetly good to know. I also didn't know about the customisation logic and it works perfectly. Thank you!
Edit: Just to clarify - I made this very short script
#!/usr/bin/bash
apt update
apt install -y binutils
strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
And I put it in directory /config/custom-cont-init.d/script.sh And that was it! :) So I consider this issue closed.
What am I missing?
[custom-init] files found in /config/custom-cont-init.d executing [custom-init] script.sh: executing... E: Invalid operation update Reading package lists... 0%
Reading package lists... 0%
Reading package lists... 50%
Reading package lists... Done
Building dependency tree... 0%
Building dependency tree... 0%
Building dependency tree... 50%
Building dependency tree... 50%
Building dependency tree
Reading state information... 0%
Reading state information... 1%
Reading state information... Done
E: Unable to locate package binutils /config/custom-cont-init.d/script.sh: line 4: strip: command not found [custom-init] script.sh: exited 127
Make sure you're using an editor that uses Linux line terminators and not Windows.
@hakonstickler maybe some weird input/character issue. I did my script in vim through putty and it works fine.
This basically solved my issue, thank heavens. Now I don't have to worry about fixing it every morning, lol.
edit: @TheSpad beat me to it by a few seconds, but there you go. We're in agreement.
Going to close this as we have a decent workaround. If people have issues with implementing it please feel free to visit our Discord or Forums for assistance.
I followed nhsqr's workaround described above but was encountering errors attempting to install binutils
due to an inability to resolve domain names.
Temporary failure resolving 'ppa.launchpad.net'
I had to create a /etc/docker/daemon.json
file on the CentOS 7 host containing the qbittorrent docker container with contents of
{"dns": ["8.8.8.8"]}
to enable DNS resolution which made nhsqr's workaround work for me.
As mentioned above the workaround is to add the file custom-cont-init.d/script.sh
to the host directory that you map to the /config/
volume in the container. custom-cont-init.d/script.sh
should be executable and contain
#!/usr/bin/bash
apt update
apt install -y binutils
strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
So for example if your docker-compose file contains
volumes:
- /path/to/qbittorrent/config:/config
You'd create the directory /path/to/qbittorrent/config/custom-cont-init.d
and the file /path/to/qbittorrent/config/custom-cont-init.d/script.sh
#!/bin/bash
FILE=/usr/bin/strip
if test -f "$FILE"; then
echo "strip already installed, exiting"
exit 0
fi
echo "installing binutils"
apt update
apt install -y binutils
echo "stripping tag from libQt5Core.so.5"
strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
installs on first boot then prevents reinstall after the first boot
would it be possible to do a dummy guide for some of us synology dummies? not sure where/how to implement the workaround: is it in docker or is it by using something like putty to ssh into the synology - I can ssh into my synolgy but nervous about running commands as I know very little about Linux?
One of your container's mount points will be to a /config folder. Wherever you have linked that to in your synology (something like /volume1/docker/qbittorrent/config maybe), create a folder called custom-cont-init.d, and place the code above into a file with the suffix "*.sh".
One of your container's mount points will be to a /config folder. Wherever you have linked that to in your synology (something like /volume1/docker/qbittorrent/config maybe), create a folder called custom-cont-init.d, and place the code above into a file with the suffix "*.sh".
Success - just had to use a text editor that did the Linux EOL, and it worked THANX!
Meanwhile a workaround:
- Attach to docker container
- apt update
- apt install binutils
- strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Found this solution here: binhex/arch-qbittorrentvpn#5
I can confirm I've had the same issue and this fixed it. Watchtower is set to monitor this container and not update.
Is this on the radar to get fixed?
Meanwhile a workaround:
- Attach to docker container
- apt update
- apt install binutils
- strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Found this solution here: binhex/arch-qbittorrentvpn#5
I can confirm I've had the same issue and this fixed it. Watchtower is set to monitor this container and not update.
Is this on the radar to get fixed?
It's not something we can fix, it's an upstream incompatibility with very old kernel versions.
One thing - would it be worth adding the note about the script to the Linuxserver docs page to make it more discoverable?
@Webreaper we can look at putting something in the application notes, even if it's just a link to the comment here :) .
PR'd #130 / #131
The work around mentioned above seems to no longer be working as the current versions of this docker image no longer contain apt
and so installing binutils
to get strip
doesn't work.
Changing this to use apk add binutils
instead of apt
just reveals that the file being stripped doesn't exist
strip: '/usr/lib/x86_64-linux-gnu/libQt5Core.so.5': No such file
However without it the UI now seems to work. I see this error in the logs but I don't know if it's related
QIODevice::write (QTcpSocket): device not open
The work around mentioned above seems to no longer be working as the current versions of this docker image no longer contain
apt
and so installingbinutils
to getstrip
doesn't work.Changing this to use
apk add binutils
instead ofapt
just reveals that the file being stripped doesn't existstrip: '/usr/lib/x86_64-linux-gnu/libQt5Core.so.5': No such file
However without it the UI now seems to work. I see this error in the logs but I don't know if it's related
QIODevice::write (QTcpSocket): device not open
I've been using the ”apt command“ to resolve errors before, but after a recent re-installation of the container's latest version and resetting the /config folder, I found that the apt command is no longer necessary and I can just use it normally without any Problem. I am using synology DSM 6.2.3, my kernel version is 3.10.105.
The container has since been rebased to alpine, so apt is replaced with apk.
Expected Behavior
Start container, access UI
Current Behavior
UI never loads, error
/usr/bin/qbittorrent-nox: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
appears repeatedly in log.Steps to Reproduce
latest
/version-14.3.3.99202101191832-7248-da0b276d5ubuntu20.04.1
imageEnvironment
OS: GNU/Linux synology_avoton_1515+ 3.10.108 CPU architecture: x86_64 How docker service was installed: Synology docker package
Workaround
Downgrade back to version-14.3.3.99202101191832-7248-da0b276d5ubuntu18.04.1