Created attachment 441888 [details]
This problem happens to me when I first boot my new system. Everything works great except for python based scripts, e.g. emerge. Example below.
If I go boot from the installation media and enter my system via chroot, the wrapper script works fine. So does everything else.
If I bypass the wrapper script and use python with full path, then everything works fine after booting the new system and running systemd. Example below.
I have tried to re-emerge python-exec and portage. Both command runs as expected and reinstall their respective software. But it does not solve the problem.
generates the following output:
/usr/bin/emerge: line 11: from: command not found
/usr/bin/emerge: line 12: import: command not found
/usr/bin/emerge: line 14: try:: command not found
/usr/bin/emerge: line 15: from: command not found
/usr/bin/emerge: line 16: except: command not found
/usr/bin/emerge: line 17: syntax error near unexpected token `('
/usr/bin/emerge: line 17: ` EPYTHON = os.path.basename(sys.executable)'
erika ~ #
Workaround to avoid using the wrapper script:
# /usr/bin/python3.4 /usr/bin/emerge
generates the expected output:
emerge: command-line interface to the Portage system
emerge [ options ] [ action ] [ ebuild | tbz2 | file | @set | atom ] [ ... ]
emerge [ options ] [ action ] < @system | @world >
emerge < --sync | --metadata | --info >
emerge --resume [ --pretend | --ask | --skipfirst ]
[ --color < y | n > ] [ --columns ]
[ --complete-graph ] [ --deep ]
[ --jobs JOBS ] [ --keep-going ] [ --load-average LOAD ]
[ --newrepo ] [ --newuse ] [ --noconfmem ] [ --nospinner ]
[ --oneshot ] [ --onlydeps ] [ --quiet-build [ y | n ] ]
[ --reinstall changed-use ] [ --with-bdeps < y | n > ]
Actions: [ --depclean | --list-sets | --search | --sync | --version ]
For more help consult the man page.
The latter also works fine to emerge any software.
python-exec dependencies are like this:
# /usr/bin/python3.4 /usr/bin/emerge -pv python-exec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] dev-lang/python-exec-2.0.2:2::gentoo PYTHON_TARGETS="(jython2_7) (pypy) (pypy3) (python2_7) (python3_3) (python3_4) (python3_5)" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
* IMPORTANT: 10 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
$ head /usr/bin/emerge
I don't see how systemd could change anything here. Unless they magically break shebang support somehow.
# head /usr/bin/emerge
# (c) 2012 Michał Górny
# Released under the terms of the 2-clause BSD license.
# This is not the script you are looking for. This is just a wrapper.
# The actual scripts of this application were installed
# in subdirectories of /usr/lib/python-exec.
# You are most likely looking for one of those
Agree that it's strange, but that the difference. When I boot using systemd, the wrapper scripts gives the error.
This one's really weird. Could you try booting e.g. via init=/bin/bash and running the scripts? Note that you may need to do some mounts manually.
(In reply to Michał Górny from comment #3)
> This one's really weird. Could you try booting e.g. via init=/bin/bash and
> running the scripts? Note that you may need to do some mounts manually.
Perhaps getting closer.
Booting with init=/bin/bash as suggested recreated the problem. So that basically rules out systemd I will assume.
I booted with the install media and chrooted into the environment, and the problem is gone.
I'm still puzzled though, are there any kernel parameters that could cause python-exec to go wrong?
Any other differences from the chroot environment than the kernel I should check?
I think something is wrong with your kernel.
Did you accidentally disable CONFIG_BINFMT_SCRIPT?
(In reply to Mike Gilbert from comment #5)
> I think something is wrong with your kernel.
> Did you accidentally disable CONFIG_BINFMT_SCRIPT?
Yes, I did..
Sorry, enabled that and now everything works perfect. Please close.
Thanks a lot for the help!
Just to be clear, Python scripts seemingly worked on your system because bash has its own, fallback shebang parsing. Theoretically we could establish something similar in python-exec but I don't think there's a point.
We could also add the kernel check -- but then, shebang support is elementary to the point of random scripture randomly not working.