Bug 986339 - starting systemd-binfmt.service on arm makes any exec fail on too many levels of symlinks
Summary: starting systemd-binfmt.service on arm makes any exec fail on too many levels...
Keywords:
Status: CLOSED DUPLICATE of bug 974804
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 19
Hardware: arm
OS: Linux
high
urgent
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-19 13:06 UTC by Pavel Holica
Modified: 2020-04-25 19:07 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-19 13:21:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Pavel Holica 2013-07-19 13:06:26 UTC
Description of problem:
I've installed Fedora 19 with default package set on calxeda system and in hangs during boot. After deep investigation, I've found, that this is caused by starting systemd-binfmt.service. After this service is started, any exec fail on too many levels of symlinks. It can be easily manually reproduced.

Version-Release number of selected component (if applicable):
systemd-204-9.fc19.armv7hl

How reproducible:
always

Steps to Reproduce:
1. Perform minimal installation
2. Install qemu-user package
3. run: systemctl start systemd-binfmt.service
4. bash

Actual results:
# systemctl start systemd-binfmt.service
# bash
-bash: /bin/bash: Too many levels of symbolic links

Expected results:
Bash is started

Additional info:

Comment 1 Michal Schmidt 2013-07-19 13:08:24 UTC
What are the contents of config files in the following directories?:

/etc/binfmt.d/
/run/binfmt.d/
/usr/lib/binfmt.d/

Comment 2 Pavel Holica 2013-07-19 13:13:58 UTC
Those files are from qemu-user-1.4.2-3.fc19.armv7h package

# find /etc/binfmt.d/
/etc/binfmt.d/

# find /run/binfmt.d/
find: ‘/run/binfmt.d/’: No such file or directory

# find /usr/lib/binfmt.d/
/usr/lib/binfmt.d/
/usr/lib/binfmt.d/qemu-sh4.conf
/usr/lib/binfmt.d/qemu-arm.conf
/usr/lib/binfmt.d/qemu-microblaze.conf
/usr/lib/binfmt.d/qemu-cris.conf
/usr/lib/binfmt.d/qemu-ppc64.conf
/usr/lib/binfmt.d/qemu-mips64.conf
/usr/lib/binfmt.d/qemu-sparc32plus.conf
/usr/lib/binfmt.d/qemu-ppc64abi32.conf
/usr/lib/binfmt.d/qemu-sparc.conf
/usr/lib/binfmt.d/qemu-sh4eb.conf
/usr/lib/binfmt.d/qemu-mips.conf
/usr/lib/binfmt.d/qemu-microblazeel.conf
/usr/lib/binfmt.d/qemu-s390x.conf
/usr/lib/binfmt.d/qemu-alpha.conf
/usr/lib/binfmt.d/qemu-ppc.conf
/usr/lib/binfmt.d/qemu-i386.conf
/usr/lib/binfmt.d/qemu-mipsel.conf
/usr/lib/binfmt.d/qemu-m68k.conf
/usr/lib/binfmt.d/qemu-sparc64.conf
/usr/lib/binfmt.d/qemu-armeb.conf
/usr/lib/binfmt.d/qemu-mips64el.conf

Comment 3 Michal Schmidt 2013-07-19 13:16:54 UTC
(In reply to Pavel Holica from comment #2)
> /usr/lib/binfmt.d/qemu-arm.conf

I suspect this tells the kernel to run ARM binaries through the QEMU emulator, which itself is an ARM binary, so it runs in the QEMU emulator, which itself ...

Comment 4 David Woodhouse 2013-07-19 13:21:56 UTC

*** This bug has been marked as a duplicate of bug 974804 ***

Comment 5 Pavel Holica 2013-07-19 13:26:14 UTC
Wow, you're right.

I've just did:
# mv /usr/lib/binfmt.d/qemu-arm* /root/
# systemctl unmask systemd-binfmt.service
# systemctl start systemd-binfmt.service
# bash

and it worked.

Comment 6 Richard W.M. Jones 2013-07-19 13:29:36 UTC
You should actually check if updating to qemu-1.4.2-4.fc19
fixes this, since this was fixed between -3 and -4.

Comment 7 Pavel Holica 2013-07-19 13:31:24 UTC
Thank you. I realized this at the moment I posted the comment and looked on bug 974804.

Comment 8 harrisbritt6904.0 2020-04-25 19:07:10 UTC Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.