I'm followed step-by-step instructions on how to mount a JFFS2-filesystem and to my surprise succeeded. the steps were:

create a MTD node typing "mknod /dev/mtdblock0 b 31 0" (i don't have the slightest idea what this is, but i do as i'm told)

setup a loop device with "losetup /dev/loop0 rootfs.jffs2"

type "echo "/dev/loop0" > /sys/module/block2mtd/parameters/block2mtd" without knowing what its for

and finally "mount -t jffs2 /dev/mtdblock0 /mnt/jffs2/"

Only when I tried to reverse the process (umount and detach), i get an errors about not being able to umount/detach the file because they're being used.
finally (and this is what scares me), when I shut down my box, it says it can't umount the partition my home directory is on. i guess that's because the jffs2-file is right there, on my home partition.

I can ignore the message but get tons of "replaying transaction..." messages on the next boot and i don't feel comfortable with this.

my personal suspicion is that the one step i fail to successfully undo is the "echo "/dev/loop0" > /sys/module/block2mtd/parameters/block2mtd"-thingie. the problem with that is that i don't know what it is, what it does, what it's for. i tried to "echo "" > /sys/module/block2mtd/parameters/block2mtd" but that didn't change a thing.

what's the correct way to cleanly detach/umount the jffs2-file without getting into trouble?

and, as a 2nd question: while i do find documents about MTD in general, i'm not sure how it is needed to use the JFFS2-file. it's a file system, isn't it? why can't it be mounted to a loop device without the hassle?

Last edited by benny1967 on Mon Jun 16, 2008 8:13 pm; edited 1 time in total

If the umount command fails, it's almost assuredly because there's open files or directories within the mount (including any active shell sessions, or even graphical file managers - I've seen this with older konqueror). Also, mounting something else inside the mount will prevent the outer-most mount from being unmounted.

The lsof utility can be useful to determine what's preventing an umount. It can be used like:
lsof +D /mnt/jffs
to check every file/directory in /mnt/jffs against open files and report matches. The manpage warns that this will use a lot of time/memory if the directory to be searched has a lot of stuff in it. Alternately, you could run lsof by itself and grep the output.

If the umount command fails, it's almost assuredly because there's open files or directories within the mount (including any active shell sessions, or even graphical file managers - I've seen this with older konqueror). Also, mounting something else inside the mount will prevent the outer-most mount from being unmounted.

The lsof utility can be useful to determine what's preventing an umount. It can be used like:
lsof +D /mnt/jffs
to check every file/directory in /mnt/jffs against open files and report matches. The manpage warns that this will use a lot of time/memory if the directory to be searched has a lot of stuff in it. Alternately, you could run lsof by itself and grep the output.

fuser is also very helpful when you cannot unmount a filesystem. I use it all the time to figure out who is on my mount when needing to unmount

I was afraid I'd fuck up my home partition again, so I tried it all on a USB stick this time. (USB- stick is on /media/USB\ DISK/ - important for the last step - and: I'm right in this directory when doing all this, so some paths are relative)
The results are the same. First I do the following steps to mount the file:

(This is what would normally happen to my home partition when I shut down.)

Trying to find out what uses /media/USB\ DISK/ by using lsof +D as suggested reports - nothing.

From what I can tell the USB-Stick doesn't umount because it holds the initfs.jffs-file, and something thinks this file is still in use. This very something provents it from being detached from /dev/loop0. It doesn't show up in the lsof +D output, though. So I'm stuck with a loop device that I can't get rid of... and whenever I mount the JFFS2-file, I'm afraid to risk the integrity of the filesystem it happens to be on because it never gets umounted cleanly.

A couple thoughts: Try catting that file before you echo the name to it - maybe the initial setting can be restored to unlink the mtd device. Also, you could try linking it to /dev/null or something like that.

any more ideas? this is really annoying as I do a lot of this stuff recently to get into some other stuff by trial and error, so I do the whole procedure 10x a day or so... and it always leaves me with a 'broken' (=busy) loopback device.

Gotcha, it was probably overlooked as an unimportant limitation since loop backed mtd devices probably are only used for testing purposes. Using it as a module will probably be sufficient for what you want to do then. It just seems strange because the release code must be present (ie, the module can be unloaded without exploding things), but just not on an individual basis.