Basic setup fails in containers
alourie opened this issue · comments
Using either the clean system or running the example docker command fails as a bunch of repos can't be cloned:
have you really did a clean install? maybe you forgot a folder.. and do you really run your system as root?
rm -rf ~/.local/share/nvim ~/.config/nvim ~/.cache/nvimhave you really did a clean install? maybe you forgot a folder.. and do you really run your system as root?
rm -rf ~/.local/share/nvim ~/.config/nvim ~/.cache/nvim
Yeah, the above run is a clean docker run, meaning there's nothing in the root system....supposedly. The default root setup in alpine edge should not be having nvim folder in ~/.local/share ;-)
tested by creating a dockerfile
FROM alpine:edge
RUN apk add --no-cache neovim git bash
RUN git clone https://github.com/LazyVim/starter ~/.config/nvim
CMD ["/bin/bash"]podman build -f dockerfile -t lazy
podman run --rm -it lazyand started nvim. the whole installation went perfectly
tested with
FROM alpine:edge RUN apk add --no-cache neovim git bash RUN CMD ["/bin/bash"]after running i cloned starter
git clone https://github.com/LazyVim/starter ~/.config/nvimand started nvim. the whole installation went perfectly
I just did absolutely the same thing and it failed with the above error.
you could try again... i even add a little more info to my comment, and here is a video if you need more help to follow the steps https://asciinema.org/a/zYvFVP5bIPaowVKPiMe6yIMet
good luck
@alourie that's just not possible. Can you give me the exact docker/podman command you use that fails for you?
https://asciinema.org/a/1WvclBADVrdnLQlyamXIzpNJg
Just repeated the steps from @luxus
Updated the container to include gcc/g++, it only affects the compiler warnings, all the rest remains unchanged
Please try with the exact command from the README:
podman run -w /root -it --rm alpine:edge sh -uelic '
apk add git lazygit neovim ripgrep alpine-sdk --update
git clone https://github.com/LazyVim/starter ~/.config/nvim
cd ~/.config/nvim
nvim
'Is there anything special about your system/network I should know?
It seems that everything gets cloned/installed, but after that lazy doesn't seem to be able to detect it is installed.
After the installation fails, can you press <cr> on one of the failed entries and show me what it says?
I just pushed some changes to lazy.nvim that will no longer show those weird stack traces with nvim_set_option, but that probably doesn't fix whatever is happening here.
Can you run the exact podman command I posted and see what :mess shows now? A screencast would be very useful too.
@folke I have no idea what's going on: https://asciinema.org/a/IvfY87myVelZ3TBfjVsOzQbgL
I have no strange networking setup, all normal. It's fairly basic arch install, nothing out of the ordinary
And are the plugins effectively cloned? And those dirs are not empty?
And are the plugins effectively cloned? And those dirs are not empty?
Yes, all are appropriately cloned.
As a test, I've tried the same on a VM with PopOS running, and it worked fine, without any issues. So what would be different on a basic Arch install to cause it to fail???..... It runs in a container!! so I'm pretty stocked and don't understand what could go wrong.
I really don't understand as well. You're also the only person that reported this issue.
Did you do any custom configuration for podman on your system?
Maybe try updating podman?
But you say that the exact same thing happens when not running in a container right?
The problem you seem to have is that the internal lazy state doesn't think it is installed, which is superweird. It looks as if the spawned git process does not trigger the exit callback in libuv for some super weird reason. Or at least it doesn't return OK
I really don't understand as well. You're also the only person that reported this issue.
Did you do any custom configuration for podman on your system?
Maybe try updating podman?
But you say that the exact same thing happens when not running in a container right?
Now I think I've mischaracterized it ...I haven't tried running it natively on my system (for obvious reasons), all is in the containers. However, I tried multiple containers (alpine, ubuntu) with the same result, yes.
I'll try updating podman, however I don't think I have any custom configuration...
I was wrong about what failed.
It must be this part of the code that fails: https://github.com/folke/lazy.nvim/blob/666ed7bf73eb5895253c1155bd29270b066cbdac/lua/lazy/core/plugin.lua#L297
No idea why that would fail though
I'll try to follow that ....doesn't maybe root path is not properly detected, but why?
It is correctlt detected, since that same path is used to for the directory where the git clone happens and those files are there.
It looks as if the vim.loop.fs_scandir fails or does not return a type for the items.
Now that I think about it, another user did have something similar at some point and that was due to apparmor.
But of course aparrmor doesn't do anything in containers....
related: libuv/libuv#3555
This might be a luv issue
Can you disable selinux and try again? $ setenforce 0, you can obviously put it back after testing.
It seems that selinux is active for containers
Can you disable selinux and try again?
$ setenforce 0, you can obviously put it back after testing.It seems that selinux is active for containers
FWIW, I don't use selinux nor have it enabled. I'll see if I need to do it inside the container.
Could you try and run:
$ sudo podman run -it alpine ping 8.8.8.8and
$ sudo podman run -it alpine wget https://github.com/containers/libpodTo check if internet and dns is working properly from your pod man setup.
Internet is definately wworking for him. It's the Util.ls that fails for some reason after installing everything.
Yeah, there's no issue with "internet" in the container, as can be seen from the screen recordings above. I also don't run podman as sudo (and just to make sure, I did run it with sudo to test, still the same issue)
Internet is definately wworking for him. It's the
Util.lsthat fails for some reason after installing everything.
Utils.ls() is indeed incorrectly fetching some directories without the type. And it goes downhill from there.
What strange is that it behaves different on different hosts.
So it only has an empty type for some directories? So odd...
Most likely a bug in luv then, since type should always be available. Although one other user had similar issues, but that was with AppArmor.
Util.ls also seems to work for listing lazyvim.plugins, but seems to fail for listing the directories in the lazy data directory.
Phew.
I experimented a bit with the directories structure, and I have no idea why it doesn't work by default. However, if I mount a local directory for /root in the container, it works fine. 🤦
So....no issue?
Was the type file for those directories? I totally forgot I added smoething that returns file if it is nil. Think I'll just remove that and show an error instead.
I just added a work-around for the luv issue. Would be great if you could test one more time with podman. I think it should work now even when type is nil
I just added a work-around for the luv issue. Would be great if you could test one more time with
podman. I think it should work now even when type isnil
It's alive!
Yeah, it works now. Tested in alpine and ubuntu containers.
Thanks so much for the effort!
Was the type
filefor those directories? I totally forgot I added smoething that returnsfileif it isnil. Think I'll just remove that and show an error instead.
yes, the type was nil. For some unclear reason, as the docs for uv say it should be (string, string) or nil or fail. So go figure.
good to know it works now. It's not ideal, since the fix is to to extra fs_stat calls when type is nil, but at least it will work now in those situations. Hpefully it will evenyually be fixed in libuv