Created attachment 886732 [details] emerge --info gns3-server busybox Upon attempting to start some (most?) docker containers (tested with Chromium and Mikrotik WinBox guests), the gns3server process encounters the following error: `ERROR docker_vm.py:498 exec /gns3/init.sh: no such file or directory` The GUI only reports the latter part of the error, `exec /gns3/init.sh: no such file or directory`. I have first encountered this bug in net-misc/gns3-server-2.2.43, and it is present in net-misc/gns3-server-2.2.45 today. I do not know when it first appeared. The cause is line 58 in the ebuild: `ln -s /bin/busybox "${D}$(python_get_sitedir)/gns3server/compute/docker/resources/bin/busybox" || die` This creates a symlink pointing to the system /bin/busybox. When creating a docker guest, "$(python_get_sitedir)/gns3server/compute/docker/resources" gets used as a volume and is bind-mounted to the container's /gns3 directory. When starting the container, the entrypoint /gns3/init.sh gets executed, which lists the interpreter /gns3/bin/busybox, i.e. the symlink still pointing to the path /bin/busybox. If the container does not contain such a file, the above error is produced. Replacing the symlink "$(python_get_sitedir)/gns3server/compute/docker/resources/bin/busybox" with a copy of /bin/busybox resolves the issue.
(In reply to Krystof Pistek from comment #0) > Created attachment 886732 [details] > emerge --info gns3-server busybox > > Upon attempting to start some (most?) docker containers (tested with > Chromium and Mikrotik WinBox guests), the gns3server process encounters the > following error: > > `ERROR docker_vm.py:498 exec /gns3/init.sh: no such file or directory` > > The GUI only reports the latter part of the error, `exec /gns3/init.sh: no > such file or directory`. > > I have first encountered this bug in net-misc/gns3-server-2.2.43, and it is > present in net-misc/gns3-server-2.2.45 today. I do not know when it first > appeared. The cause is line 58 in the ebuild: > > `ln -s /bin/busybox > "${D}$(python_get_sitedir)/gns3server/compute/docker/resources/bin/busybox" > || die` > > This creates a symlink pointing to the system /bin/busybox. When creating a > docker guest, "$(python_get_sitedir)/gns3server/compute/docker/resources" > gets used as a volume and is bind-mounted to the container's /gns3 directory. > > When starting the container, the entrypoint /gns3/init.sh gets executed, > which lists the interpreter /gns3/bin/busybox, i.e. the symlink still > pointing to the path /bin/busybox. If the container does not contain such a > file, the above error is produced. > > Replacing the symlink > "$(python_get_sitedir)/gns3server/compute/docker/resources/bin/busybox" with > a copy of /bin/busybox resolves the issue. I have the same problem. Your workaround of replacing the busybox symlink worked for me. Thank you.
Hmm, i've looked at the sources and saw the handling with busybox changed with commit: https://github.com/GNS3/gns3-server/commit/e5c8ae4bde2e6eac92e1b3b6e3bdf470956feb85 and again with commit: https://github.com/GNS3/gns3-server/commit/1a53c9aabf5ae60358496325f06550388ac12c65 It looks like we are not required to copy busybox to the install sources anymore. Afaics because of the second commit it would copy the busybox binary at runtime. I'm going to add an PR with the latest version soon - 2.2.46 should have this change included.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=38c14c19d694d7390584237519146d02bbf135cd commit 38c14c19d694d7390584237519146d02bbf135cd Author: Michael Mair-Keimberger <mmk@levelnine.at> AuthorDate: 2024-05-05 12:26:54 +0000 Commit: Conrad Kostecki <conikost@gentoo.org> CommitDate: 2024-05-05 18:56:05 +0000 net-misc/gns3-server: version bump (2.2.46) Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at> Bug: https://bugs.gentoo.org/926187 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> net-misc/gns3-server/Manifest | 1 + net-misc/gns3-server/gns3-server-2.2.46.ebuild | 68 ++++++++++++++++++++++++++ 2 files changed, 69 insertions(+)
ping, any information if the new version work without the workaround for docker images?
(In reply to Michael Mair-Keimberger (iamnr3) from comment #4) > ping, any information if the new version work without the workaround for > docker images? Oops, sorry, completely forgot about this since I haven't needed to use gns3 for the last while. Yes, it seems 2.2.46 handles this at runtime and works correctly (I can see the server copying the binaries in the logs when I start the first container). Thanks!
