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

Docker Desktop 2.3.0 containers do not have sda devices #4570

Closed
ChristineTChen opened this issue May 15, 2020 · 3 comments
Closed

Docker Desktop 2.3.0 containers do not have sda devices #4570

ChristineTChen opened this issue May 15, 2020 · 3 comments

Comments

@ChristineTChen
Copy link

Description
After upgrading Docker Desktop to 2.3.0, containers do not have /dev/sda or /dev/sda1. We were relying on this for tests which broke in the CI due to Azure upgrading.

In the current upgraded version, containers now have /dev/vda and /dev/vda1.

Moved from moby/moby#40971

Steps to reproduce the issue:

  1. Upgrade Docker Desktop to 2.3.0
  2. Spin up a container docker run -it ubuntu bash
  3. in the container run: cat /proc/partitions

Describe the results you received:
No partitions called sda or sda1.

Describe the results you expected:

# cat /proc/partitions | grep sda
   8        0   62499840 sda
   8        1   62498816 sda1

Additional information you deem important (e.g. issue happens only occasionally):

If I downgrade to 2.2.0 , I see the expected results.

Output of docker version:

Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:21:11 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker info:

Client:
 Debug Mode: false

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 2
 Server Version: 19.03.8
 Storage Driver: overlay2
  Backing Filesystem: <unknown>
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.19.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 1.944GiB
 Name: docker-desktop
 ID: HVSM:YFQQ:XANW:L3AA:Y2WC:3JPT:JEO6:QCGS:3M2H:T4IR:64OU:EB5M
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 40
  Goroutines: 52
  System Time: 2020-05-15T02:19:03.263517619Z
  EventsListeners: 4
 HTTP Proxy: gateway.docker.internal:3128
 HTTPS Proxy: gateway.docker.internal:3129
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

Additional environment details (AWS, VirtualBox, physical, etc.):

@djs55
Copy link
Contributor

djs55 commented Jul 30, 2020

@ChristineTChen thanks for your report. We changed the virtual hardware device used in hyperkit from AHCI to virtio-blk, hence the change from sda to vda. This ought to be an invisible change in most use-cases. However we also had some low-level internal tests which peeked at the underlying disk device which we had to modify to look for either sda or vda to remain backwards compatible. I recommend that approach, if possible. If not, could you explain your use-case a bit more?

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Dec 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants