needs systemd equivalent of /etc/init.d/qemu-binfmt to register foreign binary types to the proper qemu handlers. Reproducible: Always
After digging around, I've discovered that systemd itself already comes with the service files to provide this functionality, but Gentoo's ebuild does not provide the proper config files and paths that the service requires. The required service units are: proc-sys-fs-binfmt_misc.automount proc-sys-fs-binfmt_misc.mount systemd-binfmt.service Mounting the virtual file system is trivial, but the systemd-binfmt.service will fail to start up. It's contents are: =========================== [Unit] Description=Set Up Additional Binary Formats Documentation=man:systemd-binfmt.service(8) man:binfmt.d(5) Documentation=https://www.kernel.org/doc/Documentation/binfmt_misc.txt DefaultDependencies=no Conflicts=shutdown.target After=systemd-readahead-collect.service systemd-readahead-replay.service proc-sys-fs-binfmt_misc.automount Before=sysinit.target shutdown.target ConditionPathIsReadWrite=/proc/sys/ ConditionDirectoryNotEmpty=|/lib/binfmt.d ConditionDirectoryNotEmpty=|/usr/lib/binfmt.d ConditionDirectoryNotEmpty=|/usr/local/lib/binfmt.d ConditionDirectoryNotEmpty=|/etc/binfmt.d ConditionDirectoryNotEmpty=|/run/binfmt.d [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/lib/systemd/systemd-binfmt =========================== trying to start it currently produces logs similar to the following: start condition failed at Fri 2013-12-06 15:03:44 CST; 14s ago none of the trigger conditions were met
And after more reading, I've got to successfully setup the arm handler after creating a proper /etc/binfmt.d/arm.conf file. Perhaps all that needs to be done is have qemu-user ebuild create arch.example files in /etc/binfmt.d/ that could then be renamed to .conf files as needed. Still learning how to use systemd....
(In reply to Reuben Martin from comment #2) > And after more reading, I've got to successfully setup the arm handler after > creating a proper /etc/binfmt.d/arm.conf file. Perhaps all that needs to be > done is have qemu-user ebuild create arch.example files in /etc/binfmt.d/ > that could then be renamed to .conf files as needed. > > Still learning how to use systemd.... How are that config files generated? Are they "general" enough to be always installed or should be configured per system?
The config files shouldn't ever really change. It's similar to what is in /etc/init.d/qemu-binfmt, but is split out into individual files (one per arch / abi) and is just declarative rather than an imperative shell script. So in my case, I'm trying to set up support for arm, so in /etc/binfmt.d I created a file "arm.conf" that contains the following single line: :arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\x00\xff\xfe\xff\xff\xff:/usr/bin/qemu-static-arm-binfmt:P The systemd service then scans for .conf files in that directory (among others) and loads settings from any that are found. I imagine that it could be set so that the ebuild creates a bunch of arch_foo.example files that could then be renamed to .conf files depending on which abi the user wants to support. Supposedly this should at some point be part of app-emulation/qmeu instead of a split ebuild? Am I understanding that correctly? Not sure why that is not yet a standard part of qemu. I've enabled "static-user" for qemu, but the static userspace binaries for that package don't seem to work properly in conjunction with binfmt_misc.
How does it behave when various .conf files are available in that dir? For example, amd64.conf and arm.conf at the same time
It acts on any .conf file found in the target directory. (similar to how it acts on conf files in /etc/modules-load.d or /etc/tmpfiles.d for instance) The naming of the files doesn't matter, nor does the number of them. You can have a file named amd64.conf that sets up support for arm architecture. Or you can have a file named foobar.conf that enables support for PE executables via wine.
Ah, that is because I was thinking on simply installing files for all arches unconditionally, but maybe it doesn't work
(In reply to Pacho Ramos from comment #7) > Ah, that is because I was thinking on simply installing files for all arches > unconditionally, but maybe it doesn't work No, you could do that. Just have them commented out and leave it to the user to activate them. Another alternative would be to have all of them in a separate directory under /etc, and then create soft links to the ones you want to activate. That would make it simple it you wanted to use something like the eselect tool to activate them.
Or have an extra package that the user could pull in to install them, and have it choose the arches via USE flags.
(In reply to Michał Górny from comment #9) > Or have an extra package that the user could pull in to install them, and > have it choose the arches via USE flags. That looks fine to me, but I would prefer maintainer's opinion also to know what option does he prefer :/
qemu-user has been removed from the tree as its functionality has been superseded by the combined app-emulation/qemu package. if you find the qemu package does not support something that the qemu-user package did, please file a new bug explicitly detailing things so we can get it added.
