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

Error encountered when using CAPD on btrfs: Error response from daemon: Duplicate mount point: /dev/mapper #8317

Closed
cannonpalms opened this issue Mar 20, 2023 · 7 comments · Fixed by #8376
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@cannonpalms
Copy link
Contributor

cannonpalms commented Mar 20, 2023

What steps did you take and what happened?

I'm having difficulties running CAPD/the Tilt local development environment. When I deploy a workload cluster, the DockerCluster controller immediately errors with the following message:

failed to create load balancer: error creating container \"capi-quickstart-lb\": Error response from daemon: Duplicate mount point: /dev/mapper

I first reported this issue in a Slack thread where @killianmuldoon kindly helped to identify that the problem is reproducible with the btrfs docker storage driver but not with the overlay2 docker storage driver.

This suggests to me that the issue is unlikely to be within CAPD itself, but more likely a lower layer like kind or docker. However, this can serve as a helpful tracking issue for the issue that bubbles to the surface when attempting to use CAPD.

What did you expect to happen?

Expected a workload cluster named capi-quickstart-cluster to be created.

Cluster API version

v1.3.5

Kubernetes version

1.26

Anything else you would like to add?

No response

Label(s) to be applied

/kind bug
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Mar 20, 2023
@fabriziopandini
Copy link
Member

/triage accepted

I have recently aligned the flags used to create containers between kind and CAPD (#8157), and this included also a change for btrfs
@cannonpalms could you check with latest rc release?

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Mar 20, 2023
@cannonpalms
Copy link
Contributor Author

cannonpalms commented Mar 26, 2023

Hi @fabriziopandini, the same issue occurs on v1.4.0-rc.1. ISTM (and my opinion is an uneducated one) that both CAPD AND kind are adding the /dev/mapper bind/mount point now. Perhaps CAPD can remove its workaround for btrfs support and defer to kind?

I will test a build that does this and report back.

cannonpalms added a commit to cannonpalms/cluster-api that referenced this issue Mar 26, 2023
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317
@cannonpalms
Copy link
Contributor Author

Simply removing CAPD's explicit bind/mount worked just fine... Please see the linked PR and tell me where I'm going wrong in my thinking here. I don't think we need to bind/mount anymore now that kind does it for us.

@fabriziopandini
Copy link
Member

commented on the PR

@ipetrov117
Copy link

Hit the same issue when deploying a product using CAPD on an OS with the BTRFS filesystem. From the information here and in the PR I figure that just removing the second bind/mount in the code is enough. Is that the case?

@killianmuldoon
Copy link
Contributor

From the information here and in the PR I figure that just removing the second bind/mount in the code is enough. Is that the case?

As far as I found in my local testing that fixed the issue. If @cannonpalms is happy with it, it would be good if you could pick up the PR.

@ipetrov117
Copy link

From the information here and in the PR I figure that just removing the second bind/mount in the code is enough. Is that the case?

As far as I found in my local testing that fixed the issue. If @cannonpalms is happy with it, it would be good if you could pick up the PR.

Alright, I will take a stab at the PR when I have some free time in the upcoming days.

cannonpalms added a commit to cannonpalms/cluster-api that referenced this issue Nov 14, 2023
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317
cannonpalms added a commit to cannonpalms/cluster-api that referenced this issue Jan 16, 2024
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317

chore: PR feedback

Removes the now-unused function mountDevMapper(...)

chore: fix ci lint

fix: restore missing storage consts
cannonpalms added a commit to cannonpalms/cluster-api that referenced this issue Feb 1, 2024
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317

chore: PR feedback

Removes the now-unused function mountDevMapper(...)

chore: fix ci lint

fix: restore missing storage consts
cannonpalms added a commit to cannonpalms/cluster-api that referenced this issue Feb 1, 2024
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317

chore: PR feedback

Removes the now-unused function mountDevMapper(...)

chore: fix ci lint

fix: restore missing storage consts

chore: fix bad rebase

mountDevMapper() is unused
kranurag7 pushed a commit to kranurag7/cluster-api that referenced this issue Feb 22, 2024
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317

chore: PR feedback

Removes the now-unused function mountDevMapper(...)

chore: fix ci lint

fix: restore missing storage consts

chore: fix bad rebase

mountDevMapper() is unused
kranurag7 pushed a commit to kranurag7/cluster-api that referenced this issue Feb 22, 2024
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317

chore: PR feedback

Removes the now-unused function mountDevMapper(...)

chore: fix ci lint

fix: restore missing storage consts

chore: fix bad rebase

mountDevMapper() is unused
Dhairya-Arora01 pushed a commit to Dhairya-Arora01/cluster-api that referenced this issue May 25, 2024
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317

chore: PR feedback

Removes the now-unused function mountDevMapper(...)

chore: fix ci lint

fix: restore missing storage consts

chore: fix bad rebase

mountDevMapper() is unused
Dhairya-Arora01 pushed a commit to Dhairya-Arora01/cluster-api that referenced this issue May 25, 2024
Support for btrfs/zfs was upstreamed to kind in kubernetes-sigs/kind#1464, removing the need
for us to hack support in ourselves.

Helps kubernetes-sigs#8317

chore: PR feedback

Removes the now-unused function mountDevMapper(...)

chore: fix ci lint

fix: restore missing storage consts

chore: fix bad rebase

mountDevMapper() is unused
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants