Adventures with Binfmt_misc...

[twobob]

OR perhaps the title should be...

"Twobob once again messes around with something he barely understands"

So anyways. THIS FILE IS FOR A 3. Just to be clear.

Check if we have Kernel Support
root@kindle:root> zcat /proc/config.gz | grep -i binfmt_misc

# CONFIG_BINFMT_MISC is not set

Nope.. So we need a module as we can load those...

Get Thing. I will attach the kindle 2.6.26-rt-lab126 3.3 version that I splattered through BuildRoot. Using the 2006q3 CS TC and the right kernel headers in place. (Thanks Niluje, Knc1)

Just some extra info: (notice the MAGIC is revealed here)

Spoiler:

root@kindle:root> readelf -a /mnt/us/modules/binfmt_misc.ko
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 8900 (bytes into file)
Flags: 0x4000000, Version4 EABI
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 23
Section header string table index: 20

No version information found in this file.
Attribute Section: aeabi
File Attributes (none shown)

Also there are no dependencies : )

Insert module

example:
insmod /path/to/somewhere/onfat/module/binfmt_misc.ko
(mine is on /mnt/us/modules/binfmt_misc.ko) so I go

root@kindle:root> insmod /mnt/us/modules/binfmt_misc.ko

Check it's loaded

root@kindle:root> lsmod

Spoiler:

Module Size Used by
binfmt_misc 8552 0
g_ether 21096 0
option 12512 2
usbserial 27756 5 option
ehci_hcd 38880 1 option
usbcore 136388 4 option,usbserial,ehci_hcd
ar6000 161076 0
ppp_async 8612 1
crc_ccitt 1856 1 ppp_async
ppp_generic 19252 5 ppp_async
slhc 5984 1 ppp_generic
volume 8900 1
fiveway 23552 1
mxc_keyb 15904 1
uinput 7776 0
fuse 48348 2
arcotg_udc 38628 1 g_ether
mwan 7324 2 ehci_hcd,ppp_async
eink_fb_shim 118588 0
eink_fb_hal_broads 397532 0
eink_fb_hal 59764 8 eink_fb_shim,eink_fb_hal_broads

Mount it somewhere

mkdir /mnt/us/proc/sys/fs/binfmt_misc

(or wherever you want it, I'm going to try that)

Check it's mounted

Spoiler:

root@kindle:root> mount
rootfs on / type rootfs (rw)
/dev/root on / type ext3 (ro,noatime,nodiratime,data=ordered)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev type tmpfs (rw,mode=755)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
shm on /dev/shm type tmpfs (rw)
rwfs on /mnt/rwfs type tmpfs (rw,size=32768k)
rwfs on /var type tmpfs (rw,size=32768k)
/dev/mmcblk0p2 on /var/local type ext3 (rw,sync,errors=continue,data=ordered)
fsp on /mnt/us type fuse.fsp (rw,nosuid,nodev,noatime,user_id=0,group_id=0)
fsp on /opt/amazon/screen_saver/600x800 type fuse.fsp (rw,nosuid,nodev,noatime,user_id=0,group_id=0)
/dev/loop/0 on /mnt/base-us type vfat (rw,noexec,noatime,nodiratime,fmask=0022,dmask=002 2,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8)
usbfs on /proc/bus/usb type usbfs (rw)
none on /mnt/us/proc/sys/fs/binfmt_misc type binfmt_misc (rw)

/mnt/us/proc/sys/fs/binfmt_misc should now contain two files:

register and status

I'll continue this when I have more. We are going to use this to do some loading wangles with a bit of luck and further reading on my part. Thought I would share my experiences so far.

REFS: http://www.kernel.org/doc/Documentation/binfmt_misc.txt
http://en.wikipedia.org/wiki/Binfmt_misc
And one from Knc1 that I'm still looking for... TBC...

[twobob]

KNc advises me I we are better off using tcc. So I've ripped *this posts* stuff out... cheers

[knc1]

Originally Posted by twobob

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:

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.

[twobob]

Hi Mate. Yeah. I wrote this TRIED to write this so that everyone could understand follow it.

Should have said maybe "It is a generalisation of the mechanism that allows us to run shell scripts by starting the file with "#!/bin/sh"."

EDIT: I also should have said MY WAY IS VERY RARELY THE "RIGHT" WAY

Didn't jump into WHAT it might be good for yet. or how to use it.

Didn't mount it under proc because that would require me creating a folder under the non FAT partition (and also on a minuscule level affecting space available), just seeing if this can be avoided is all. That is the only reason. It was just my preference. I was seeing if it would work completely separated is all...

Unsure if you noticed I did include the output of a single mount command with the relevant rw shown. I did not however put the output of trying to mount it in /proc - which would have complained about needing the folder first. obviously.

Perhaps I should have done and a bit of blurb about what I was doing in terms of the separation.

http://wiki.luajit.org/Linux-binfmt_misc - here is a simple example of binfmt_misc being used for the interested reader (and me)

Okay auto-mounting, that's helpful. I suppose the mount point is auto-created then?
I'll have to read up on that. or just test. ; )

I'm attempting to find the docs you pointed me at, at the moment : )
apologies if you think my approaches are a bit non-standard.

That would be a complete lack of knowledge. Ah well, I get results in the end.
What do you reckon to the other low-hanging fruit toy? Any usage Mr?

Cheers. If you think I should change something in the top post just let me know what and I'll get it done. Cheers again : )

[knc1]

Just test, that is probably the quickest.
Try listing /proc/sys/fs before doing the insmod and after doing the insmod.

I don't think you have to create the directory (which is part of the module code) and I don't think you have to mount it (it did have to be mounted in the kernel 2.4.x days).

And I expect that a rmmod will make it all go away again.

You should find the "binfmt_misc" directory in the source code for the module as something like:
const char = "binfmt_misc"
Possible hidden inside a macro.

In the article linked to about luajit, I don't see any mkdir or mount commands.
But they are not clear about what parts of the system setup their distribution had automated for them. (The author might not even have known about distribution specific automation.)

[twobob]

Originally Posted by knc1

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:

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.

PS1 didn't happen, otherwise I would not have added the bit about mounting it manually. I'll go check that again...

Cheers I tried PS2 when we talked about it before. Yep. : ) excellent.

When attempting to discuss and describe these "things" (especially in topposts) in very rough layman's terms, there is a distinct possibility that the finer details are skipped over and in doing so: It probably makes me sound as though I have never read anything about them before.

Rest assured I read as much as I can before these posts. At least two or three separate references. That doesn't make my posts any "Righter" just more-informedly "Wrong"

thanks for the extra details, I will skip ahead to some usage then.

[knc1]

PS1 didn't happen? Well, ok, kernel is older than the making it "auto-mount" by itself change.

You should still be able to mount it at: /proc/sys/fs/binfmt_misc
And you don't need to test if it is already mounted, you can just mount it again, which should turn into a no-op if already mounted.

[twobob]

root@kindle:root> umount /mnt/us/proc/sys/fs/binfmt_misc
root@kindle:root> rmmod binfmt_misc
root@kindle:root> ls /proc/sys/fs/*

Spoiler:

/proc/sys/fs/aio-max-nr /proc/sys/fs/inode-state
/proc/sys/fs/aio-nr /proc/sys/fs/lease-break-time
/proc/sys/fs/dentry-state /proc/sys/fs/leases-enable
/proc/sys/fs/dir-notify-enable /proc/sys/fs/nr_open
/proc/sys/fs/file-max /proc/sys/fs/overflowgid
/proc/sys/fs/file-nr /proc/sys/fs/overflowuid
/proc/sys/fs/inode-nr /proc/sys/fs/suid_dumpable

/proc/sys/fs/inotify:
max_queued_events max_user_instances max_user_watches

/proc/sys/fs/mqueue:
msg_max msgsize_max queues_max

/proc/sys/fs/nfs:
nfs_congestion_kb nlm_tcpport nsm_local_state
nfs_mountpoint_timeout nlm_timeout nsm_use_hostnames
nlm_grace_period nlm_udpport

root@kindle:root> insmod /mnt/us/modules/binfmt_misc.ko
root@kindle:root> ls /proc/sys/fs/*

Spoiler:

/proc/sys/fs/aio-max-nr /proc/sys/fs/inode-state
/proc/sys/fs/aio-nr /proc/sys/fs/lease-break-time
/proc/sys/fs/dentry-state /proc/sys/fs/leases-enable
/proc/sys/fs/dir-notify-enable /proc/sys/fs/nr_open
/proc/sys/fs/file-max /proc/sys/fs/overflowgid
/proc/sys/fs/file-nr /proc/sys/fs/overflowuid
/proc/sys/fs/inode-nr /proc/sys/fs/suid_dumpable

/proc/sys/fs/inotify:
max_queued_events max_user_instances max_user_watches

/proc/sys/fs/mqueue:
msg_max msgsize_max queues_max

/proc/sys/fs/nfs:
nfs_congestion_kb nlm_tcpport nsm_local_state
nfs_mountpoint_timeout nlm_timeout nsm_use_hostnames
nlm_grace_period nlm_udpport

I'll see what a strace turns up

[knc1]

At the worst, it only makes you sound like lab126 - who often skips over the finer details in their shipped products.

[twobob]

Ah righto.

Okay then. I just NEVER EVER change ANYTHING that I can avoid that is not on FAT.

EVER.

Then if it bricks? well don't blame me. I always think.

I am particularly suspect of putting stuff in /var

So apologies if my paranoia is a bit too complete.

thanks for the double mount info. I will have a play with creating the folders in proc then.

Is there some disadvantage to using FAT then? ho hum.

[knc1]

Originally Posted by twobob

root@kindle:root> umount /mnt/us/proc/sys/fs/binfmt_misc
root@kindle:root> rmmod binfmt_misc
root@kindle:root> ls /proc/sys/fs/*

root@kindle:root> insmod /mnt/us/modules/binfmt_misc.ko
root@kindle:root> ls /proc/sys/fs/*


I'll see what a strace turns up

Now that is really strange.
No need to do an strace - it is what it is.

Continue by trying to create the directory /proc/sys/fs/binfmt_misc

[twobob]

root@kindle:fs> strace -o /mnt/us/binfmt_misc.strace.txt mkdir binfmt_misc

mkdir: cannot create directory 'binfmt_misc': No such file or directory

err.? what?

Spoiler:

execve("/bin/mkdir", ["mkdir", "binfmt_misc"], [/* 26 vars */]) = 0
brk(0) = 0x7e000
uname({sys="Linux", node="kindle", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001b000
open("/mnt/us/usr/lib/libz.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\35 4\27\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=143358, ...}) = 0
mmap2(NULL, 162384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40025000
mprotect(0x40045000, 28672, PROT_NONE) = 0
mmap2(0x4004c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f) = 0x4004c000
close(3) = 0
...
set_tls(0x4001ced0, 0x4001ced0, 0x40024058, 0x4001d5a8, 0x40) = 0
mprotect(0x40219000, 8192, PROT_READ) = 0
mprotect(0x400f5000, 4096, PROT_READ) = 0
mprotect(0x40059000, 4096, PROT_READ) = 0
getuid32() = 0
umask(0) = 022
umask(022) = 0
mkdir("binfmt_misc", 0777) = -1 ENOENT (No such file or directory)
umask(022) = 022
brk(0) = 0x7e000
brk(0x9f000) = 0x9f000
write(2, "mkdir: cannot create directory '"..., 72) = 72
exit_group(1) = ?
+++ exited with 1 +++

No directory called that? err well. Duh?

Um. thoughts anyone?
root@kindle:fs> cat /proc/self/mounts

Spoiler:

rootfs / rootfs rw 0 0
/dev/root / ext3 ro,noatime,nodiratime,data=ordered 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
shm /dev/shm tmpfs rw 0 0
rwfs /mnt/rwfs tmpfs rw,size=32768k 0 0
rwfs /var tmpfs rw,size=32768k 0 0
/dev/mmcblk0p2 /var/local ext3 rw,sync,errors=continue,data=ordered 0 0
fsp /mnt/us fuse.fsp rw,nosuid,nodev,noatime,user_id=0,group_id=0 0 0
fsp /opt/amazon/screen_saver/600x800 fuse.fsp rw,nosuid,nodev,noatime,user_id=0,group_id=0 0 0
/dev/loop/0 /mnt/base-us vfat rw,noexec,noatime,nodiratime,fmask=0022,dmask=0022 ,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8 0 0
usbfs /proc/bus/usb usbfs rw 0 0

[knc1]

That seems reasonable (on my desktop machine):

core2quad ~ $ ls -ld /proc/sys/fs
dr-xr-xr-x 0 root root 0 2012-08-25 21:02 /proc/sys/fs

Only the /proc file system code can create a directory there, no "w" permission for anyone.

[twobob]

root@kindle:fs> ls -ld /proc/sys/fs
dr-xr-xr-x 0 root root 0 Aug 27 11:14 /proc/sys/fs/

Okay. Are you presuming I haven't simply tried mounting it?

EDIT:

root@kindle:fs> mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
mount: mount point /proc/sys/fs/binfmt_misc does not exist

Or am I missing something blindingly obvious again?


errr... wait a minute..

lstat64("/etc/mtab", {st_mode=S_IFLNK|0777, st_size=12, ...}) = 0
stat64("/sbin/mount.binfmt_misc", 0xbed50740) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
mount("none", "/proc/sys/fs/binfmt_misc", "binfmt_misc", MS_MGC_VAL, NULL) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
lstat64("/proc/sys/fs/binfmt_misc", 0xbed50818) = -1 ENOENT (No such file or directory)
write(2, "mount: mount point /proc/sys/fs/"..., 59) = 59
exit_group(32) = ?
+++ exited with 32 +++

Hookaay... I think I see the issue. (goes looking around for things)

the failure to find this bit of code doesn't explain why I get no complaint on FAT though
(I don't think)

[knc1]

Durn! This system just swallowed my reply. Grumble, will try once more.

I wrote "I don't understand why ..."
But now I think I can guess ...

The lab126 kernel was build without binfmt_misc selected in the configuration.
The "usual" presumption is that will cause only the module code not to be built.

My new guess -
That config option eleminated some of the supporting /proc code also.

Which would mean that the way you found to make it work, as shown in your top post, is the way it has to be done.