Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

overlayfs: missing upperdir or lowerdir or workdir Unable to mount directory #1

Closed
xiangzhai opened this issue Nov 12, 2014 · 5 comments
Labels

Comments

@xiangzhai
Copy link

Hi Matthias,

I built the 3.18 for my ArchLinux box

Linux archlinux 3.18.0-rc4 #2 SMP Wed Nov 12 15:03:39 CST 2014 x86_64 GNU/Linux

There are installed in Limba /opt/software

$ lipa list
[libfoo-1.0] Limba Foo Library 1.0
[foobar-1.0] Limba FooBar 1.0

Then I tried to runapp foobar-1.0:

  1. cd limba/build/tools/runapp
  2. sudo ./runapp foobar-1.0:

It thrown overlayfs's error

overlayfs: missing upperdir or lowerdir or workdir Unable to mount directory

So I just monkey patch the https://github.com/ximion/limba/blob/master/tools/runapp/runapp.c

-       tmp = g_strdup_printf ("lowerdir=%s,upperdir=%s", LI_SW_ROOT_PREFIX, main_data_path);
+       tmp = g_strdup_printf ("lowerdir=%s,upperdir=%s,workdir=/root", LI_SW_ROOT_PREFIX, main_data_path);

I am not familiar with overlayfs right now, and I will read Kernel's Document about it, but perhaps someone please give me some advice, thanks a lot!

Regards,
Leslie Zhai

@ximion ximion added the bug label Nov 12, 2014
@ximion
Copy link
Owner

ximion commented Nov 12, 2014

I don't want to jump to conclusions too fast, but this might be a kernel bug...
The code there says:

    if (!ufs->config.upperdir || !ufs->config.lowerdir ||
        !ufs->config.workdir) {
            pr_err("overlayfs: missing upperdir or lowerdir or workdir\n");

And an upper and lowerdir are given... (I am also looking at https://lkml.org/lkml/2014/11/10/129 right now)
One question: Does /opt/swroot exist? (did you run sudo make install?)
Also, the command to run FooBar should be something like:

runapp foobar-1.0:/bin/foo

(if installed, the binary is suid-root and drops privileges as soon as possible - so no need for an explicit sudo)
If instlled using sudo lipa install, you should also have a link to it in your desktops application menu ;-)

@xiangzhai
Copy link
Author

Hi @ximion

Sorry for my late reply, I have to look after my wife she is pregnant ;)

Does /opt/swroot exist?

Yes, it exist!

tree -d /opt/
/opt/
├── software
│   ├── foobar-1.0
│   │   └── data
│   │       ├── bin
│   │       ├── etc
│   │       ├── lib
│   │       └── share
│   │           ├── applications
│   │           ├── info
│   │           └── man
│   │               └── man1
│   └── libfoo-1.0
│       └── data
│           └── lib
└── swroot

Also, the command to run FooBar should be something like: runapp foobar-1.0:/bin/foo

I am sorry I have bad habit: I often prefer to run lipa, lipkgen and runapp under ./build/tools/subdirectory directly ;P Because I failed to lipkgen build so I simply added some DEBUG info to li-installer.c, li-package.c, etc. And you helped me to figure it out ;) http://blog.tenstral.net/2014/11/introducing-limba-a-software-installer-experiment.html

And an upper and lowerdir are given... (I am also looking at https://lkml.org/lkml/2014/11/10/129 right now)

_the patch is for the kernel`s git_ it might be not suitable for 3.18.0-rc4

emm, I am reading the linux-3.18-rc4/Documentation/filesystems/overlayfs.txt
in the Directories section, it suggests mount like that:

mount -t overlayfs overlayfs -olowerdir=/lower,upperdir=/upper,\                 
workdir=/work /merged

So I simply added workdir=/root, it is a MONKEY patch ;P

diff --git a/tools/runapp/runapp.c b/tools/runapp/runapp.c                         
index 8a70b41..6261c90 100644                                                      
--- a/tools/runapp/runapp.c                                                        
+++ b/tools/runapp/runapp.c                                                        
@@ -146,7 +146,8 @@ mount_overlay (const gchar *pkgid)                             
            goto out;                                                              
        }                                                                          
    }                                                                              
-   tmp = g_strdup_printf ("lowerdir=%s,upperdir=%s", LI_SW_ROOT_PREFIX, main_data_path);
+   tmp = g_strdup_printf ("lowerdir=%s,upperdir=%s,workdir=/root", LI_SW_ROOT_PREFIX, main_data_path);
+   printf("DEBUG: %s %s, %d %s\n", __FILE__, __func__, __LINE__, tmp);         
    res = mount ("", LI_SW_ROOT_PREFIX,                                            
                 "overlayfs", MS_MGC_VAL | MS_RDONLY | MS_NOSUID, tmp);            
    g_free (tmp);

Finally it worked ;)

runapp foobar-1.0:/bin/foo
DEBUG: /home/project/xiangzhai/limba/tools/runapp/runapp.c mount_overlay, 150 lowerdir=/opt/swroot,upperdir=/opt/software/foobar-1.0/data,workdir=/root
foobar version 1.0.0
Hello World from libfoo!

'Configuration' file /opt/swroot/etc/foo-config:
Bla bla bla.

Press ENTER to exit this program.

But I need to be familiar with overlayfs by reading the doc and source code, thanks for your reply ;)

Regards,
Leslie Zhai

@ximion
Copy link
Owner

ximion commented Nov 13, 2014

Looks like workdir is sometimes needed and sometimes not - I still need to figure oit how to reproduce this issue, but in any case, adding a workdir for compatibility seems to be an appropriate fix...
And yes, the kernel patch is for the next release (but it's something I am looking forward to).
To increase verbosity, the --verbose flag or the environment variable G_MESSAGES_DEBUG=all could be useful.

I'll come up with a fix which includes a workdir soon.

ximion added a commit that referenced this issue Nov 13, 2014
This should close bug #1
Also improve the runapp code slightly.
@ximion
Copy link
Owner

ximion commented Nov 13, 2014

Can you please pull Git master, recompile Limba again (ensure that it picks up the right headers accompanying your 3.18 kernel), and see if this issue is fixed?
I tried this on a Fedora and Debian machine, using the 3.18 kernel and a 3.16 kernel with the OverlayFS module loaded, and it seems to work.
(Although checking the kernel version at runtime would be more flexible - that's something to do in future, or drop support for pre-3.18 kernels entirely)

@xiangzhai
Copy link
Author

Hi @ximion

This issue fixed ;)

I tried this on a ArchLinux box, using the 3.18.0-rc kernel with the _overlayfs_ built-in

Thanks for your great job ;)

Regards,
Leslie Zhai

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants