View Single Post
Old 08-27-2012, 08:10 AM   #3
knc1
Embedded Cheerleader
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 6,457
Karma: 5840130
Join Date: Feb 2012
Device: Too many.
Quote:
Originally Posted by twobob View Post
add notes here
Why would you mount binfmt_misc anywhere other than: /proc/sys/fs/binfmt_misc?

I am not saying that it might not work, just that I have never seen or heard of it being done.

Let me guess - -
I have been seeing repeated cases of script writers here that are being falsely influenced by that lab126 provided login message.

The message about the **root file system** being mounted ro and that they provided a complicated script to enter the command: mount -o remount,ro /
or
mount -o remount,rw /
Duh...

**root filesystem**
The read-write property does not propagate to other file systems, it is a property of the mount point.

**/proc** is another file system.
In fact, enter just the empty command:
mount
and be presented with the current list of mount points.
Each with their independent read-write property.
(or: cat /proc/self/mounts - which is always correct, even if /etc/mtab is read-only or not otherwise current.)

Included in the returned information will be the setting of the read-write property of each mount point listed.

That above concerns real file systems. In the case of the virtual file systems (/sys, /proc, /debugfs, <others>) - they also follow the semantics of real file systems but provide their own ways of doing so.

Translation: You can write (or mount things) to the parts of /proc that are intended to be written to (or mounted on) by how /proc is coded.

So if your mounting binfmt_misc under /mnt/us to avoid calling the lab126 script mntroot - you really don't have to do that.
The mntroot script has no more effect on /proc than it does on /var/local.

- - - -

Hmm...
Just re-read my post above. Maybe I should spend some more time on re-writing it into something with less offensive wording.
I will work on that.

- - - -

PS1: With 2.6.26 I think the kernel is new enough that you don't have to mount binfmt_misc - the module will "auto mount" when it loads.
I.E: When the module is not loaded, there is no binfmt_misc under /proc/sys/fs
When the module is loaded, that directory suddenly appears.

PS2: You have Linux Mint-13 (or Mint-12) on you dev system - -
browse /proc/sys/fs/binfmt_misc and you should find the names of things that are already registered. (python2.7, jar, wine, arm ...) by the distribution's provided start-up scripting.

as in:
Code:
core2quad ~ $ cat /proc/sys/fs/binfmt_misc/qemu-arm
enabled
interpreter /usr/bin/qemu-arm-static
flags: OC
offset 0
magic 7f454c4601010100000000000000000002002800
mask ffffffffffffff00fffffffffffffffffeffffff
Which is how your Mint-{12,13} system manages to run arm native code on a x86 processor.

Last edited by knc1; 08-27-2012 at 08:13 AM.
knc1 is offline   Reply With Quote