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

Using the App Catalog - HTTP Go Server #1612

Closed
teodora27 opened this issue Apr 28, 2024 · 1 comment · Fixed by #1613
Closed

Using the App Catalog - HTTP Go Server #1612

teodora27 opened this issue Apr 28, 2024 · 1 comment · Fixed by #1613
Assignees
Labels
kind/bug Something isn't working

Comments

@teodora27
Copy link

Describe the bug

Folowing the steps from https://unikraft.org/guides/using-the-app-catalog i got an error at this part HTTP Go Server.

Steps to reproduce

I have folowed the steps from this link https://unikraft.org/guides/using-the-app-catalog to this part "HTTP Go Server".
If i try this command kraft run -W -p 8080:8080 . i get an error

Expected behavior

what i get is:

teodora@teodora-VirtualBox:/catalog/examples/http-go1.21$ kraft run -W -p 8080:8080 .
W using hardware emulation
i using arch=x86_64 plat=qemu
<!> building rootfs x86_64 [0.0s]
i creating ephemeral buildkit container
W could not connect to BuildKit client '' is BuildKit running?
W
W By default, KraftKit will look for a native install which
W is located at /run/buildkit/buildkit.sock. Alternatively, you
W can run BuildKit in a container (recommended for macOS users)
W which you can do by running:
W
W docker run --rm -d --name buildkit --privileged moby/buildkit:latest
W export KRAFTKIT_BUILDKIT_HOST=docker-container://buildkit
W
W For more usage instructions visit: https://unikraft.org/buildkit
W
E creating buildkit container: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.45/networks": dial unix /va
E creating buildkit container: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.45/networks": dial unix /var/run/docker.sock: connect: permission denied: failed to create container
teodora@teodora-VirtualBox:
/catalog/examples/http-go1.21$ sudo kraft run -W -p 8080:8080 .
W detected invocation via sudo!
W
W mixing invocations of kraft with sudo can lead to unexpected behavior
W read more on how to use kraft without sudo at:
W
W https://unikraft.org/sudoless
W
W to hide and ignore this warning message, set the environmental variable:
W
W export KRAFTKIT_NO_WARN_SUDO=1
W
W using hardware emulation
i using arch=x86_64 plat=qemu
[] building rootfs x86_64 [36.6s]
i #14 writing config sha256:6259a070c27a4059e6b5a37b443474e1bf6d2a699fd20bdaeccfb77b02edf8ed
i #14 preparing build cache for export 0.1s done
i #14 writing config sha256:6259a070c27a4059e6b5a37b443474e1bf6d2a699fd20bdaeccfb77b02edf8ed done
i #14 writing cache manifest sha256:29dd3667c74510a077896bfc47c0224ade29338e1695fd2db32c2ce92035bd71 done
i #14 DONE 0.1s
ctrl+c to cancel
panic: assignment to entry in nil map

goroutine 291 [running]:
kraftkit.sh/internal/cli/kraft/run.(*RunOptions).prepareRootfs.func1({0x21dc8b8?, 0xc006b7d2f0?})
/__w/kraftkit/kraftkit/internal/cli/kraft/run/utils.go:401 +0x13b
kraftkit.sh/tui/processtree.(*ProcessTree).Init.(*ProcessTree).waitForProcessCmd.func2()
/__w/kraftkit/kraftkit/tui/processtree/processtree.go:329 +0xb4
github.com/charmbracelet/bubbletea.(*Program).handleCommands.func1.1()
/go/pkg/mod/github.com/charmbracelet/bubbletea@v0.25.0/tea.go:294 +0x29
created by github.com/charmbracelet/bubbletea.(*Program).handleCommands.func1 in goroutine 314
/go/pkg/mod/github.com/charmbracelet/bubbletea@v0.25.0/tea.go:293 +0x139
teodora@teodora-VirtualBox:~/catalog/examples/http-go1.21$

Which architectures were you using or does this bug affect?

x86_64

Which operating system were you using or does this bug affect?

No response

Relevant log output

No response

@teodora27 teodora27 added the kind/bug Something isn't working label Apr 28, 2024
@LucaSeri LucaSeri self-assigned this Apr 28, 2024
@nderjung
Copy link
Member

Hi, thanks for the bug report!

I think this was fixed in #1600. We just need to tag a new release for this to be upstream, I can do this later today. In the meantime time you can try the latest pre-release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants