# The binfmt-misc module needs to be configured in... [solved]

## josephg

i have been seeing this message at boot, and ignoring it for a while now. but i am learning lessons to not ignore everything.

the article on wikipedia makes me think i do not need it.

kernel docs make me think i might need it, as gentoo seems to be built on python. i don't use java, .net, emacs, lisp, etc.

```
CONFIG_BINFMT_MISC:

If you say Y here, it will be possible to plug wrapper-driven binary formats into the kernel. You will like this especially when you use programs that need an interpreter to run like Java, Python, .NET or Emacs-Lisp. It's also useful if you often run DOS executables under the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, available from <http://www.tldp.org/docs.html#howto>). Once you have registered such a binary class with the kernel, you can start one of programs simply by typing in its name at a shell prompt; Linux will automatically feed it to the correct interpreter.

You can do other nice things, too. Read the file <file:Documentation/binfmt_misc.txt> to learn how to use this feature, <file:Documentation/java.txt> for information about how to include Java support. and <file:Documentation/mono.txt> for information about how to include Mono-based .NET support.

To use binfmt_misc, you will need to mount it:

   mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc

You may say M here for module support and later load the module when you have use for it; the module is called binfmt_misc. If you don't know what to answer at this point, say Y.

Symbol: BINFMT_MISC [=m]

Type  : tristate

Prompt: Kernel support for MISC binaries

   Location:

      -> Executable file formats / Emulations

   Defined at fs/Kconfig.binfmt:158
```

do i need binfmt_misc?

1. if yes, how should i configure it?

2. if not, how should i remove it?Last edited by josephg on Fri Apr 21, 2017 10:58 am; edited 8 times in total

----------

## Perfect Gentleman

as Gentoo uses Python heavily, imo, yes, you need it

----------

## josephg

 *Perfect Gentleman wrote:*   

> imo, yes, you need it

 

then i guess you have it.. how have you configured it?

----------

## Perfect Gentleman

 *josephg wrote:*   

> then i guess you have it.. how have you configured it?

 

built in kernel, but really it doesn't matter

----------

## josephg

 *Perfect Gentleman wrote:*   

>  *josephg wrote:*   then i guess you have it.. how have you configured it? 
> 
> built in kernel, but really it doesn't matter

 

what doesn't really matter? my question is not about building modules vs in-kernel

i'm asking how to configure binfmt_misc in /etc/conf.d

----------

## Perfect Gentleman

 *josephg wrote:*   

> i'm asking how to configure binfmt_misc in /etc/conf.d

 

aaa, did nothing 'bout itLast edited by Perfect Gentleman on Tue Apr 18, 2017 2:55 pm; edited 2 times in total

----------

## cboldt

Where exactly, at boot, does this message pop up?  Are you on systemd or openrc?

I have the binfmt_misc loaded as a module, I run openrc, which runs /etc/init.d/binfmt at the "boot" stage.  My system has NO /etc/conf.d/binfmt, or /etc/conf.d/binfmt_misc.

The warning may be a cue to make sure the module is loaded, via /etc/conf.d/modules

My system DOES include a reference to binfmt_misc in /etc/conf.d/modules

From memory, the modules listed there are modules that otherwise aren't loaded "automagically" and are used by some service that is invoked when the system starts up.

```
# # # /etc/conf.d/modules

### For 3.0.6 kernel 111026 on T420 Thinkpad###

 

modules="configs"

modules="${modules} usb_storage"

modules="${modules} autofs4 cifs"

modules="${modules} drm"

modules="${modules} acpi-cpufreq cpufreq_ondemand cpufreq_performance"

modules="${modules} nls-iso8859-15 nls-ascii nls-iso8859-1 nls-cp437"

modules="${modules} pcmcia yenta-socket"

modules="${modules} sg"

modules="${modules} uvcvideo"

modules="${modules} binfmt_misc"        # <----  Lookee here

modules="${modules} ppp_generic"

modules="${modules} rfkill"

modules="${modules} nf-conntrack-ftp"
```

----------

## Perfect Gentleman

anyway binfmt_misc is loaded automatically

----------

## josephg

 *cboldt wrote:*   

> Where exactly, at boot, does this message pop up? Are you on systemd or openrc?

 

openrc shows this boot message just after

```
* Creating mtab symbolic link

* Mounting local filesystems ...
```

 *cboldt wrote:*   

> I have the binfmt_misc loaded as a module, I run openrc, which runs /etc/init.d/binfmt at the "boot" stage.  My system has NO /etc/conf.d/binfmt, or /etc/conf.d/binfmt_misc.

 

my system is exactly the same. i have no reference to binfmt_misc anywhere that i'm aware of, except

```
 $ /sbin/rc-update | grep binfmt

               binfmt | boot
```

wonder if i should disable this service

 *cboldt wrote:*   

> My system DOES include a reference to binfmt_misc in /etc/conf.d/modules

 

i have nothing in that file, as i find all modules that i need auto-loaded are already loaded. perhaps you should recheck yours too.Last edited by josephg on Wed Apr 19, 2017 9:24 am; edited 1 time in total

----------

## josephg

so i BINFMT_MISC=n and rebuilt my kernel. now i see no such boot warning. gentoo seems to be running fine too.Last edited by josephg on Fri Apr 21, 2017 11:00 am; edited 1 time in total

----------

## Sadako

I get the same warning upon boot, it's actually coming from /etc/init.d/procfs, however I've seen NO negative effects from not loading the module, I'm pretty damn sure it's not needed for gentoo in general or portage specifically.

Looking at /etc/init.d/procfs, it looks like the kernel adds the directory /proc/sys/fs/binfmt_misc/ even if it's only configured as a module and not loaded, and then when /etc/init.d/procfs checks for this directory it complains if the module isn't loaded, it's (IMO) mistakenly presuming you want or need it loaded simply because you enabled it as a module in the first place.

tl;dr: that warning is perfectly safe to ignore.

----------

## josephg

 *Sadako wrote:*   

> I get the same warning upon boot, it's actually coming from /etc/init.d/procfs, however I've seen NO negative effects from not loading the module, I'm pretty damn sure it's not needed for gentoo in general or portage specifically.
> 
> Looking at /etc/init.d/procfs, it looks like the kernel adds the directory /proc/sys/fs/binfmt_misc/ even if it's only configured as a module and not loaded, and then when /etc/init.d/procfs checks for this directory it complains if the module isn't loaded, it's (IMO) mistakenly presuming you want or need it loaded simply because you enabled it as a module in the first place.
> 
> tl;dr: that warning is perfectly safe to ignore.

 

thank you for confirming. i thought it was from the binfmt service, starting at boot. so i disabled it, and still kept getting that warning. i removed that module from kernel, and no such warning appears now. i don't notice any adverse effects either.

----------

## Perfect Gentleman

 *Quote:*   

> i don't notice any adverse effects either.

 

run emerge update to test

----------

## josephg

*deleted*Last edited by josephg on Sat May 06, 2017 7:26 pm; edited 1 time in total

----------

## josephg

feels good to clean my system  :Smile: 

my issue is resolved by:

BINFMT_MISC=N, and rebuild kernel

rc-update del binfmt bootLast edited by josephg on Fri Apr 21, 2017 11:02 am; edited 2 times in total

----------

## NeddySeagoon

josephg,

About the only use I know of BINFMT_MISC is to run a foreign chroot as documented in Compiling with qemu user chroot

The example given lets you run a 32 bit ARM chroot on your amd64 install.

Run might be a bit of an exaggeration as the ARM CPU doing the running is emulated in software, so its slow.

----------

## josephg

 *NeddySeagoon wrote:*   

> About the only use I know of BINFMT_MISC is to run a foreign chroot as documented in Compiling with qemu user chroot
> 
> The example given lets you run a 32 bit ARM chroot on your amd64 install.
> 
> Run might be a bit of an exaggeration as the ARM CPU doing the running is emulated in software, so its slow.

 

thank you NeddySeagoon for the confirmation. i can ease off now and not keep wondering if any issues i might have could be related. as yet, i have no issues.

wonder why gentoo starts binfmt service at boot? made me suspect binfmt was something core. i think it's unnecessary bloat. that scenario is so specific that one should read docs to get there.Last edited by josephg on Wed Apr 19, 2017 11:15 am; edited 1 time in total

----------

## khayyam

 *josephg wrote:*   

> wonder why gentoo starts binfmt service at boot? made me suspect binfmt was something core. i think it's unnecessary bloat. that scenario is so specific that one should read docs.

 

josephg ... along with binfmt_misc, there are a whole slew of other filesystems (securityfs, debugfs, configfs, efivarfs, cgroups, fusectl) that 'sysfs' will attempt to mount should they be present. It (or rather 'procfs') was started because you have it in the runlevel, and because you have binfmt_misc enabled in the kernel. I don't have either, knowing I didn't need binfmt_misc, or selinux (which 'procfs' also mounts similarly). The problem here is that basically openrc is doing "policy" in conjunction with "mechanism". When a user installs openrc they get all this policy enabled (whether they need it or not), they also get it re-enabled should they re-merge the package (ie, when the ncurses slot it updated), so basically, besides the buttons that can be tweeked in rc.conf, or conf.d, the user isn't deciding policy, and isn't supposed to understand what does what, interdependencies, necessity, etc.

best ... khay

----------

## josephg

 *khayyam wrote:*   

> I don't have either, knowing I didn't need binfmt_misc, or selinux (which 'procfs' also mounts similarly).

 

well, it might be good to know what is installed/running that we don't need. is there anything else i can remove or turn off? i'm still understanding what belongs to core gentoo and what doesn't.

 *khayyam wrote:*   

> When a user installs openrc they get all this policy enabled (whether they need it or not), they also get it re-enabled should they re-merge the package (ie, when the ncurses slot it updated), so basically, besides the buttons that can be tweeked in rc.conf, or conf.d, the user isn't deciding policy, and isn't supposed to understand what does what, interdependencies, necessity, etc.

 

i can probably understand about the user not deciding policy. but i certainly don't agree that users aren't supposed to understand what does what, interdependencies, necessity, etc. is this something to do with the current trend of dumbing down everything?

----------

## NeddySeagoon

josephg,

It's my view that its more about providing a system that actually boots without a new user needing to set up all the dependencies in the init system.

There is some line between the minimal actually needed and the default Gentoo provides. Whatever Gentoo provides by default, it won't suit everyone.

Users can read /etc/init.d/* to see all the scripts and turn on openRCs boot logging so see how things work.

Once you have done that, you can begin to remove things from runlevels or edit the scripts to remove/change dependencies.

There are some thing that con be changed in /etc/conf.d too.

Do keep some boot media to hand. If you mess up the startup, you may not get a login prompt.  

Its just another set of controls that users can operate to fine tune their systems.

----------

## khayyam

 *josephg wrote:*   

>  *khayyam wrote:*   I don't have either, knowing I didn't need binfmt_misc, or selinux (which 'procfs' also mounts similarly). 
> 
> well, it might be good to know what is installed/running that we don't need. is there anything else i can remove or turn off? i'm still understanding what belongs to core gentoo and what doesn't.

 

josephg ... that depends, some of these (like procfs, sysfs, etc) include a number of things (again, like cgroups, securityfs, debugfs, etc) and some of these may, or may not, be needed (ie, cgroups, which seems to be required by some recent portage FEATURES ... however, I'm not sure which portage version this involves), some of these filesystems are checked against the kernel for availability (as in the case of binfmt_misc, etc) and as they all fall under 'sysfs' they are all enabled based on that availability. So the idea of "core gentoo" may encompass a variety of things, dependent on the install. Whatever you do the next time you emerge openrc, or udev-init-scripts, those you've disabled will be enabled again, so you either need to pay attention to the fact, or simply go with whatever happens to be provided.  

 *josephg wrote:*   

>  *khayyam wrote:*   When a user installs openrc they get all this policy enabled (whether they need it or not), they also get it re-enabled should they re-merge the package (ie, when the ncurses slot it updated), so basically, besides the buttons that can be tweaked in rc.conf, or conf.d, the user isn't deciding policy, and isn't supposed to understand what does what, interdependencies, necessity, etc. 
> 
> i can probably understand about the user not deciding policy. but i certainly don't agree that users aren't supposed to understand what does what, interdependencies, necessity, etc. is this something to do with the current trend of dumbing down everything?

 

Well, I think it comes as part of providing "policy", for instance when re-merging the very same version of openrc due to the ncurses slot change, my rootfs failed to mount ro, figuring out a solution took way too much effort (especially as I was hampered by my thinking it couldn't possibly be related to the package itself, because it was the same package, and I spent a lot of time looking elsewhere). I still don't properly understand what happened, it turned out that 'root' was running before 'fsck' and so I needed to add 'need fsck' ... but I have no idea why that same version of openrc worked prior. Similarly, hwclock began failing at shutdown due, I assume, to some change in util-linux re /etc/adjtime, and currently "[ -e /proc/sys/kernel/hotplug ] && echo '' >/proc/sys/kernel/hotplug" hangs at shutdown, no idea why, and I've no clear idea what might have changed (as the very same stop() worked previously). It might be argued that all of this is due to my using a now depreciated version of openrc, but even if this were the case (and note fsck, root, hwclock, are all from that same version) it doesn't speak much in terms of the above "understanding". Having been reading up on the subject recently I intend to migrate to s6-rc as soon as I can find the time to do so.

 *NeddySeagoon wrote:*   

> It's my view that its more about providing a system that actually boots without a new user needing to set up all the dependencies in the init system.

 

OK, but when this goes awry, what then?

best ... khay

----------

## NeddySeagoon

khayyam,

When if goes awry, you get to keep the pieces, the same as you do in the rest of Gentoo.

I liken tinkering with the init system, any of them, to moving away from genkernel to configure, build and install kernels.

Be sure to write up how the migration to s6-rc goes. Its on my list of things to try too.

I'm still on openrc-0.17 and its getting to be more and more work to maintain everything in line with that.

----------

## khayyam

 *NeddySeagoon wrote:*   

> When if goes awry, you get to keep the pieces, the same as you do in the rest of Gentoo. I liken tinkering with the init system, any of them, to moving away from genkernel to configure, build and install kernels.

 

Neddy ... the point is, I expect that these pieces provide some clue to what happened, and in all three cases I provided above I've absolutely no idea. If I wanted that things might fail erratically, and without some clue as to why, I'd be using windows.

 *NeddySeagoon wrote:*   

> Be sure to write up how the migration to s6-rc goes.

 

Will do, I'd actually had an Alpine install with s6-rc booting, but trashed it as I'd needed to use the machine for another purpose, and was in such a rush I didn't think to make a backup :P

 *NeddySeagoon wrote:*   

> I'm still on openrc-0.17 and its getting to be more and more work to maintain everything in line with that.

 

Yeah, and 0.12.4 even more so, I've been putting off the inevitable because I've had too many other things I've had to deal with. When I've some time I intend to get a test machine up and running, not sure when that might happen though.

best ... khay

----------

## josephg

 *khayyam wrote:*   

>  *NeddySeagoon wrote:*   I'm still on openrc-0.17 and its getting to be more and more work to maintain everything in line with that. 
> 
> Yeah, and 0.12.4 even more so, I've been putting off the inevitable because I've had too many other things I've had to deal with. When I've some time I intend to get a test machine up and running, not sure when that might happen though.

 

when i switched openrc backend from sysvinit to runit and had some issues i took to #runit, they wondered why openrc using sysvinit is considered more efficient. apparently gentoo had a suspect maintainer for runit and also for openrc, s6, etc. i haven't been in this scene long enough to comment.

----------

