unionfs blocking mc subshells
Forum: Apps
Topic: unionfs blocking mc subshells
started by: mikshaw
Posted by mikshaw on Jan. 09 2008,16:54
Please be aware that I'm currently using DSL version 3.2 due to a recent harddrive failure that caused me to have to install from the most recent CD I'd burned (and I've been too lazy to upgrade back to 4.x), so this might not be an issue with the newer versions.In order for user dsl to use subshells in the midnight commander mydsl extension, dsl must have write access to /dev/ptmx, so I modify it from bootlocal. I did this again after reinstalling DSL, but found that neither dsl nor root could use subshells in mc, which meant the file permissions are not the issue (file permissions generally do not affect root). After pounding my head for an hour or so I realized that I wasn't using the "legacy" boot option as I had previously, and after rebooting with unionfs disabled the subshells worked as expected.
I noticed that with unionfs there is a /ramdisk/dev/ptmx, but the file permissions on that file were the same as those of /dev/ptmx, so I guess the permissions still had nothing to do with it in that case.
I'm wondering if anyone could explain, or at least give me some clue, what might be the issue with mc's subshells when using unionfs? I haven't yet had a use for unionfs, but probably will sometime in the future. If the subshells don't work, though, it won't be worth it for me...I use mc as much as any other application, and the subshells are invaluable to me.
Posted by roberts on Jan. 09 2008,17:08
I don't use mc so cannot be specific to your question. However, unionfs that is in DSL, and the last supporting the 2.4 kernel, is quite old and therfeore buggy when used in its full capacity, ie., many write/updates. My intent was to basically use unionfs as a read-only layer to expand the concept that I introduced with uci. Doing this provides easy access to many additional program layered like uci but not having to re-compile to be completely self-contained.
Posted by curaga on Jan. 09 2008,17:25
I don't know what to say, for that is the mechanism xterms use. And they worked in 3.2..
Posted by roberts on Jan. 09 2008,18:29
Since this is 3.x, are you sure it is not due to mc vs mc.bin, with mc.bin intercepting what you want to do?
Posted by mikshaw on Jan. 09 2008,19:02
I updated to 4.1 (haven't downloaded anything newer yet), and still get the same result.The mc/mc.bin isn't an issue. I run mc through a wrapper script that's located at the top of my PATH:
| Code Sample |
| if [ -x "/opt/mc/bin/mc" ]; then exec /opt/mc/bin/mc -b "$@" else exec mc.bin -b "$@" fi |
I suppose it's possible that it is a bug in unionfs, although I don't understand why there is a /ramdisk/dev/ptmx when /dev/ptmx is already writeable by default. Maybe it was created automatically when I modified the original? As I've said before, I don't understand how unionfs works, so this is a mystery to me.
In any case, I'm going to continue using legacy, possibly until it is no longer supported. The only thing I'd really like to try with it is xfree/xorg, but even that is in a very distant plan to be made into uci.
Posted by roberts on Jan. 19 2008,04:53
| Quote |
| In any case, I'm going to continue using legacy, possibly until it is no longer supported. The only thing I'd really like to try with it is xfree/xorg, but even that is in a very distant plan to be made into uci. |
I am still reading of the trials and tribulations of those who pursue unionfs/aufs even with 2.6 kernel and newer versions of these overlays and now another posixovl.
I too like and prefer my original concept (KISS) of self contained UCI. Perhaps I should generate a 2.6 kernel legacy edition. Can we go it alone with no overlays?
There are now other projects with similiar concepts to uci. Perhaps the chrooted builds of their self contained applications is worth a look.
Posted by curaga on Jan. 19 2008,10:07
I'd like to mention devicemapper. The LFS livecd is a great testing ground, because it really stresses the system with heavy compilations like gcc. They used unionfs before. And got several kernel panics.Currently they use device-mapper's snapshot. I've looked into that technology, and it really works. I've gotten no kernel panics or any problems at all with my 5+ system builds with LFS livecd as a host.
It's very good for an overlay; especially when it was not meant for that use.
This is also the system I will use, if I ever get the thing started
Posted by WDef on Jan. 24 2008,16:54
I know maintaining support for legacy has been a pain for you Robert; perhaps Mikshaw's issue with mc retroactively justifies your efforts. How difficult is it to continue to provide a legacy boot option? I mean, what are the downsides incurred?@Mikshaw: I'm not an mc man either. I suppose there is an mc support mail list where you might get some clue as to exactly what the issue is? There must be other systems running mc on top of unionfs.
Would seem perhaps extreme to throw out uniofs/aufs architecture altogether if legacy can switch it off.
Besides device-mapper I imagine fuse might also be used to provide a similar capability for self-contained apps, but I was told by someone who definitely would know that fuse is inefficient and slow.
Knoppix has been using aufs since 3.9 - how are they going with that?
Posted by lucky13 on Jan. 24 2008,17:35
| Quote |
| Would seem perhaps extreme to throw out uniofs/aufs architecture altogether if legacy can switch it off. |
Or make that a boot option to turn on unionfs and make "legacy" the default.
| Quote |
| Knoppix has been using aufs since 3.9 - how are they going with that? |
Unionfs is iffy on just about every implementation of it. Go through the FreeBSD changelogs and look how many times it's been added and removed. It's been re-implemented in 6.3, which for all I know means series of patches have been added to minimize some of the scary-frightening-proceed-with-caution warnings in the manpage.
Release note with brief notice of "new and improved" unionfs:
< http://www.freebsd.org/releases/6.3R/announce.html >
And from the manpage:
| Quote |
| BUGS THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. This code also needs an owner in order to be less dangerous - serious hackers can apply by sending mail to <hackers@FreeBSD.org> and announcing their intent to take it over. Without whiteout support from the file system backing the upper layer, there is no way that delete and rename operations on lower layer objects can be done. EROFS is returned for this kind of operations along with any others which would make modifications to the lower layer, such as chmod(1). Running find(1) over a union tree has the side-effect of creating a tree of shadow directories in the upper layer. FreeBSD 6.2 |
The execution is flawed. I love the concept, though.
Posted by curaga on Jan. 25 2008,22:59
Running find over a union tree creates a hang for me..
Posted by WDef on Jan. 26 2008,17:19
| Quote |
| Running find over a union tree creates a hang for me.. |
I don't think I've ever had hangs with find and unionfs.
What are you doing exactly?
Posted by curaga on Jan. 26 2008,19:11
A normal DSL 4.2.4 boot - with or without gnu-utils.unc and gcc1-with-libs.unc:find /usr -name whatever
hangs the find process, and also the shell where find is running (ie killing find doesn't help)