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
vagrant-spk enter-grain: Value too large for defined data type #213
Comments
This involves way too much magic for me to even guess what's happening here. Asheesh is likely the only person on the planet who understands how enter-grain works. :/ And that is one heck of a command that crashed it. |
Hey @ocdtrekkie, did you hear anything from the core / old Sandstorm guys about that issue? It would be great to have the |
@JamborJan While the vagrant-spk devs are aware of current progress, I haven't actually discussed any of the work with them. (The only actually discussed topic was the copyright PR.) I haven't actually looked at enter-grain at all, but I could probably at least take a gander. I kinda wonder if it's possible to break up that command a bit or test individual pieces of it to try and isolate what's going on. |
Hey all - I do remember a bunch of how Having said that: @kentonv , do you recognize this error message at all?
I wonder if that comes, indirectly, from the FUSE filesystem...? |
For what it's worth: I wrote You can see a process ID in the above printout. You could try:
where you replace |
Hey @paulproteus , Thanks for your help. It somehow works even if it is not straight forward:
I can then navigate around but as soon as I use tab to autocomplete paths and filenames I get:
Does that help somehow? For now it's kind of okay to use this workaround. I know that there is currently nobody available but it would be cool if this feature could be properly wrapped in a spk command again. |
@JamborJan If we have a working command, it isn't shockingly hard to wrap things in vagrant-spk commands. See my recent #236. The same code which grabs the PID for enter-grain can be used to assemble nsenter. But my guess is if you're hitting that same error message when using nsenter, there's some issue that affects both nsenter and enter-grain that needs to be fixed. |
https://groups.google.com/d/msg/sandstorm-dev/GslQeMhNGSg/91I1dkcTBQAJ A app developer expressed how big of a stumbling block this error and errors like it are to sandstorm. |
Hi @rainbowjaw , I think the problem relates to GoogleContainerTools/distroless#225 . Perhaps it's true that we're using a 32-bit userland in the Debian VM, but that the filesystem uses 64-bit inode numbers. (In my opinion, this is a really weird possibility.) I'd be happy to remote-pair-program on this for an hour or two with someone if they want to try to take a look themselves and have me looking over their shoulder. Email me if you want that: asheesh@asheesh.org Best wishes! Asheesh. |
I know @JamborJan is out of the Sandstorm market at the moment. But perhaps @kpreid would be interested in this offer! |
Sorry, I have no experience with Linux container programming and I don't think I could efficiently get up to speed on it (and I have too many projects already). Hence my suggesting that someone else ought to do it! I'd be interested in contributing towards a bounty though. |
I just hit this today. I think I can fix it. |
@abliss That would be really cool. Especially since I am going to try to wrap up a new vagrant-spk release soon. |
I suspect that GoogleContainerTools/distroless#225
may be a red herring: it seems to be a busybox bug
https://bugs.busybox.net/show_bug.cgi?id=11651 which in turn seems to be a
uclibc bug regarding 64-bit inodes. However, the sandstorm issue reproduces
even with low inode numbers and even using a `mkdir` that is not using busybox or uclibc at all.
I think we may be closer to
https://bugzilla.kernel.org/show_bug.cgi?id=183461 , which is a kernel
bug(?) about the mkdir() syscall specifically in the case of a tmpfs inside
a user namespace when uid and gid are unmapped. That does appear to match
our situation.
A simple workaround is to use /var/tmp, instead of /tmp, to house
vagrant-spk inside the vm. This seems to fix `enter-grain` for me.
|
Housing it in /tmp, which is a tmpfs, runs afoul of this kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=183461 Fixes sandstorm-io#213 .
NB enter-grain still has other issues, likely also related to the unmapped uid. e.g. /proc is not mounted, so |
@abliss, I had marked this issue as part of my 1.0 milestone since you seemed optimistic you could fix it. I want to do this next release soon, so I don't want to feature creep it, but it may be worthwhile to chat about what the next version after 1.0 should look like. |
JamborJan commentedMar 12, 2018
I have pulled the latest release of vagrant-spk and also checked that my vagrant config file is up to date. When using
vagrant-spk enter-grain
I get the following error. I'm working on the Worpress on Sandstorm app.The text was updated successfully, but these errors were encountered: