[Docker Desktop] Linux Implementation

[grealish]

Tell us about your request
As there is a Docker Desktop for Windows and OSX, to complete the offer, a Linux build would be great, to complete the offer. As allot of us in the container community know there is allot of tools which basically address some of the same requirements. Non are complete, e.g Take VMware Workstation or player for linux, It was a quick bootstrap and enabled people to jump into the virtualization world quickly. People even installed it on nested VM's (which dev's had root access to) and they could work freely and effectively.

Which service(s) is this request for?
Docker Desktop

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Lower the bar of enabling developer to jump into containers,
Enable that docker desktop can be run on a remote ubuntu / centos system which developers would remote desktop into,

Are you currently working around the issue?
Many tools exist to have a developer workflow on a linux system, both locally and remote, however this require quite some knowledge upfront and not a fluid experience, many tools like, minishit, minikube, kind, and docker-compose and docker-ce sovle part of the developer experience.

Additional context
DRAFT WIP

[412PIT]

@grealish thank you for the feature idea! Could you comment on how many of your team members, friends, other developers you know use Linux on their local desktop/remote dev environment?

[AkihiroSuda]

How will this be different from plain Docker CE for Linux?

[grealish]

How will this be different from plain Docker CE for Linux?

It doesn't compare, unfortunately people starting off with docker-ce never really leave extend there experience into the cloud and have no nice UI overview.
Also it's a challenge for many to get minikube up, so a drop in .deb or .rpm that brings up a desktop app would solve this, For example, how would someone have this user experience on a ubuntu desktop/vm?

[ingshtrom]

To throw gas on the fire here, I would say that with the new user experience being moved towards Desktop this becomes more of a requirement than a nice to have.

[tao12345666333]

Personally, I prefer CLI.

Under Linux I use Docker CE.
Under Mac, I use Docker Desktop for Mac, but I use it from the command line, almost no UI.

I'm not sure what "Docker Desktop for Linux" will look like, or if anyone will use it.

There are some solutions available under Linux

• lazydocker - The lazier way to manage everything docker

• DockStation - Developing with Docker has never been so easy and convenient

• Portainer

[Vincent14]

Personally, I prefer CLI.

[...].

I'm not sure what "Docker Desktop for Linux" will look like, or if anyone will use it.

Docker started as a powerful tool designed for power-users only, and bring an easier access point on Mac & Win, where some people are less convenient with CLI. There is also less-experimented people on Linux and they are the target of this Desktop Client. As said previously, these users could remote control a Linux desktop to achieve the same goal with the benefits of a Linux environment.

[xinity]

Personally, I prefer CLI.

[...].
I'm not sure what "Docker Desktop for Linux" will look like, or if anyone will use it.

IMHO the problem is not if alternative exists, they do of course, and are doing a great job.
Main point here is to offer the same UX. To help on-boarding people without having to deal with their favorite operating system.

as @ndeloof said on twitter nowadays Docker Desktop doesn't only offer the docker cli and engine, it brings more and more useful features (seamless Kubernetes integration, docker hub integration in the UI, ...).

I really think this feature would be a game changer perhaps even a killer feature :)

[grealish]

Main point here is to offer the same UX. To help on-boarding people without having to deal with their favourite operating system.

Yes exactly, this is why I bring up the need now, when we have training/workshops having a solid and accessible user experience to on-board makes allot of great first impressions, especially getting developer to start working on refactoring there monolith into containers, Nivida for example JetPack SDK manager, this is a ubuntu GUI too to jump start people into the AI development experience and makes one getting setup effortless.

[jycamier]

Docker Desktop on linux may bring a good way to normalized a full update (docker + docker-compose + kubernetes). Moreover, the integration of Kubernetes is really simple and quite good.

[sudo-bmitch]

I'm not sure what "Docker Desktop for Linux" will look like, or if anyone will use it.

There are a variety of Desktop only features:

• Built in checking for updates
• New UI for managing deployed containers
• Certified Kubernetes easy install
• Enterprise features like application templates and app designer

The big one for me is a built in kubernetes environment on the desktop without needing kubeadm, kind, k3s, or any of the other more complex solutions.

[bhack]

Not super-fresh but.. https://www.linuxjournal.com/content/search-gui-docker

[SvenDowideit]

For us, Docker Desktop with UX feature parity on all 3 desktop platforms would give us a consistent platform to help users work on whatever host they're on at the time. We would need to be able to add menu items, and more UX for specific groups.
Essentially, its about adoption by users that are currently under-served - non-container natives that work on Linux, or Linux Desktop container natives that support OSX and Windows non-container natives

[ohnotnow]

We'd get value from docker desktop being ported to Linux. At the moment when we are getting people up to speed we have a constant 'If you're on Windows or Mac, click this, press that.... But if you're on Linux then ....'. Having one straightforward go-to set of instructions would help give us a nice consistent on-boarding process and help dev's and sysadmins share the same knowledge across platforms.

[ibnesayeed]

@412PIT: Could you comment on how many of your team members, friends, other developers you know use Linux on their local desktop/remote dev environment?

If you were to believe Stack Overflow Developer Survey 2020, almost 27% developers who responded to the survey use Linux as their primary operating system (almost same as MacOS).

[marchesir]

id love to see docker desktop Linux, but i use the CLI most of the time personally. Its not a deal breaker for me but would love to see it as it gives us on Linux an option and for Docker having 1 unified UI would be easier to manage but we need to be careful and not have poor performance as a result.

[jacobus]

Docker started on Linux, but now the Linux community needs to beg to have Docker tooling on par with Windows and Mac.

So sad.

[BenMorel]

A few months later... any update?

[JohnFajardo]

Dropping in to add to the request. Dev team of 88 people.

[erwanriou]

Just following this thread after the issue on Mac on the 3.2.0 Wanted to say here also that the only thing that retain me to use ubuntu is actually docker desktop that have an AMAZING KUBERNETES INTEGRATION. And i am really not super fond of minikube.

We would release a linux version that i would just sell my MAC and go back on my beloved ubuntu.

[kmanwar89]

I'm just getting started with Docker and, while I love the power and flexibility of the CLI, I don't think it's unreasonable to have a common toolset across all three OS's to help bring new users into the fray. If/when they decide they want to use the CLI, leave that decision up to the individual developer.

Cross-platform apps are very common these days, and with frameworks like Electron, there's little excuse to not have all three.

[MestreLion]

After 1 year, this is not even on the roadmap??? Not even with a "Investigating" status?

[SalahAdDin]

This never won't be, isn't it?

[shahidcodes]

It won't be, we are linux user, expected to work on cli. UI is only for Mac/Windows.

P.S. Pun Intended

[johnrggo]

Not sure if it matters to anyone but I did not have any issues running a few containers on Ubuntu 20.04 using Docker Desktop. Docs state 21.04 or 21.10 so apologies if I am going against the grain here.

@therealdandecker thanks for your feedback, docker desktop worked on my Ubuntu 20.04 (Elementary OS 6.1) and by setting the shared memory to 8GB. I can only start it from the terminal command and not from the Applications icon. I have yet to test it in the long run.

[elapuyade]

@kmanwar89 Regarding the requirement for DD4L itself, I'm not sure where they can be found. I'll pass this question up at docker.

Regarding your 2 scenarios, they actually fail for 2 different reasons:

Scenario 1 Ubuntu Desktop 21.10 VM - 8GB RAM:

Feb 7 11:01:40 ubuntu com.docker.backend[3284]: 2022/02/07 11:01:40 notifying bugsnag: /dev/shm has only 3957 MB free space, out of 3957 MB required for VM RAM

this stops because the system tells we have only 3957MB free in /dev/shm. According to the log, you have configured 3957MB for DD4L VM RAM as well, but as the check actually wants 100MB more, it fails. What is really strange is how your /dev/shm is 16GB in a machine with only 8GB. By default, /dev/shm should be sized to half the available RAM.

Scenario 2 with Ubuntu Desktop 21.10 VM - 16GB RAM:

Feb 7 11:07:29 ubuntu com.docker.backend[2190]: [038:11:07:29.328][I] using 3957 MB out of the free 7983 MB in /dev/shm for VM RAM

this is not the same log line. This now says it has 7983MB free in dev/shm, out of which it is going to use 3957MB for the VM RAM. This check is successful, but something else fails later. Unfortunately, we can't see what in the truncated logs. Just as strange, /dev/shm is still 16GB.

Kadar-Linux-Desktop is your Ubuntu Desktop 21.10 VM, in which you run DD4L, right?

[kmanwar89]

@kmanwar89 Regarding the requirement for DD4L itself, I'm not sure where they can be found. I'll pass this question up at docker.

Regarding your 2 scenarios, they actually fail for 2 different reasons:

Scenario 1 Ubuntu Desktop 21.10 VM - 8GB RAM:

Feb 7 11:01:40 ubuntu com.docker.backend[3284]: 2022/02/07 11:01:40 notifying bugsnag: /dev/shm has only 3957 MB free space, out of 3957 MB required for VM RAM

this stops because the system tells we have only 3957MB free in /dev/shm. According to the log, you have configured 3957MB for DD4L VM RAM as well, but as the check actually wants 100MB more, it fails. What is really strange is how your /dev/shm is 16GB in a machine with only 8GB. By default, /dev/shm should be sized to half the available RAM.

Scenario 2 with Ubuntu Desktop 21.10 VM - 16GB RAM:

Feb 7 11:07:29 ubuntu com.docker.backend[2190]: [038:11:07:29.328][I] using 3957 MB out of the free 7983 MB in /dev/shm for VM RAM

this is not the same log line. This now says it has 7983MB free in dev/shm, out of which it is going to use 3957MB for the VM RAM. This check is successful, but something else fails later. Unfortunately, we can't see what in the truncated logs. Just as strange, /dev/shm is still 16GB.

Kadar-Linux-Desktop is your Ubuntu Desktop 21.10 VM, in which you run DD4L, right?

Thanks for your response.

Re: Scenario 2 - I'm adding in the full logs as an attachment due to the length.

The Kadar-Linux-Desktop is my Linux Desktop, which is the host for the VM's, running VMWare Workstation Pro 16.

In summary, something is preventing DD4L from working unless/until I set the /dev/shm (and by extension, the allocated RAM through VMWare Workstation) to 16GB. Any other scenario I've tested so far seems to fail. More than happy to continue doing more troubleshooting - perhaps there is something fundamentally that I am missing here?
Docker Desktop Logs - 8 FEB 2022 - Ubuntu VM 16 GB RAM.txt

[aiordache]

Hi @kmanwar89. Thanks for helping to test this.
Would you mind trying to run again the setup that fails please? You can then check ~/.docker/desktop/log/host/com.docker.driver.amd64-linux.stderr.log for errors related to the VM boot. In case there is a problem with the shared memory, we should have an error logged there. Below is what gets logged on a successful boot:

....
com.docker.driver.amd64-linux.stderr: [040:10:29:41.203][I] Virtiofsd has started: /bin/sh -c /usr/share/docker-desktop/virtiofsd --socket-path=<HOME>/.docker/desktop/virtiofs.sock0 --socket-group=docker -o cache=auto -o source=/home
com.docker.driver.amd64-linux.stderr: [040:10:29:41.204][I] VM has started: qemu-system-x86_64 -accel kvm -cpu host -machine q35 -m 7872 -smp 4 -kernel /usr/share/docker-desktop/linuxkit/kernel -append page_poison=1 vsyscall=emulate panic=1 nospec_store_bypass_disable noibrs noibpb no_stf_barrier mitigations=off linuxkit.unified_cgroup_hierarchy=1   vpnkit.connect=tcp+bootstrap+client://gateway.docker.internal:34093/d0d57ae9e21a9897a21023deeb9564c923140d5b9743fd5f1ea3f01ae08aef63 console=tty0 -initrd /usr/share/docker-desktop/linuxkit/initrd.img -serial pipe:/tmp/qemu-console218367274/fifo -drive if=none,file=<HOME>/.docker/desktop/vms/0/data/Docker.raw,format=raw,id=hd0 -device virtio-blk-pci,drive=hd0,serial=dummyserial -netdev user,id=net0,ipv6=off,net=192.168.65.0/24,dhcpstart=192.168.65.9 -device virtio-net-pci,netdev=net0 -vga none -nographic -monitor none -object memory-backend-file,id=mem,size=7872M,mem-path=/dev/shm,share=on -numa node,memdev=mem -chardev socket,id=char0,path=<HOME>/.docker/desktop/virtiofs.sock0 -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=virtiofs0
com.docker.driver.amd64-linux.stderr: [040:10:29:41.204][I] created VM console
com.docker.driver.amd64-linux.stderr: [2022-02-09T09:29:41Z INFO  virtiofsd] Waiting for vhost-user socket connection...
com.docker.driver.amd64-linux.stderr: [2022-02-09T09:29:41Z INFO  virtiofsd] Client connected, servicing requests
com.docker.driver.amd64-linux.stderr: [040:10:30:08.753][I] proxy >> GET /containers/json?all=true
...

[elapuyade]

@kmanwar89

The Kadar-Linux-Desktop is my Linux Desktop, which is the host for the VM's, running VMWare Workstation Pro 16.

OK, so first regarding the /dev/shm settings: you checked/set it on your host (physical) machine. That machine has 32GB, and the default shm is 16GB, as you reported.
But as far as DD4L is concerned, only the VMWare ubuntu exists. DD4L will start its own VM inside the VMware VM. You must check/set /dev/shm size in the VMware ubuntu, not on your physical host.
We have seen that, when using a 16GB VMware VM, the ubuntu VM does have roughly 8GB (7983 MB) free space in its /dev/shm, as expected. In this case, the attached log seems to show normal DD4L function, until:

Feb 8 11:43:18 ubuntu com.docker.backend[2435]: [039:11:43:18.352][I] (b9f677fe) 216b10f3-BackendAPI S->C Go-http-client/1.1 GET /forwards/list (59.808µs): OK

at which point 20 seconds elapse with nothing and then:

DOCKER DESKTOP WAS STOPPED HERE

Feb 8 11:43:39 ubuntu kernel: [ 259.771155] perf: interrupt took too long (7577 > 5038), lowering kernel.perf_event_max_sample_rate to 26250
Feb 8 11:43:39 ubuntu kernel: [ 259.787661] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 7.554 msecs
Feb 8 11:43:39 ubuntu kernel: [ 259.788232] perf: interrupt took too long (13169 > 9471), lowering kernel.perf_event_max_sample_rate to 15000

nothing from DD4L (I presume it was killed ?), but some interesting logs from the ubuntu VM kernel that suggest some deeper resource issue in that VM.
To set aside any potential problem due to not enough physical RAM available leading to swap, let's try the following:

• Start the VMware Ubuntu VM with 8 GB.
• log into a shell in Ubuntu VM
• In Ubuntu VM, open ~/.docker/desktop/settings.json and set memoryMiB to 2048
• In Ubuntu VM, make sure /dev/shm free space is at least 2148 MB
• In Ubuntu VM, start DD4L

something is preventing DD4L from working unless/until I set the /dev/shm (and by extension, the allocated RAM through VMWare Workstation) to 16GB.

Also, I don't understand what you mean here. Which /dev/shm are you setting? You seem to say that you have at least one setup that works, but you never mentioned that before...

PS: Ahhh, after @aiordache answer, I realize the log you attached are from syslog and do not include DD4L VM process logs.

[patrickhousley]

I am currently running the tech preview on Manjaro, I know it's not a supported platform. Just wanted to see if maybe there were some ideas here. Manjaro just updated glibc to 2.35 and now the backend no longer starts and just throws a core dump. Prior to the glibc update, DD4L was working perfectly. Really hoping I can get back to using it soon. Thanks for the hard work on making this possible.

Process 79580 (virtiofsd) of user 1000 dumped core.

Module linux-vdso.so.1 with build-id c92da1914b8d8df59d1e5784659d5e3558731667
Module libffi.so.8 with build-id f90d8b734f6de9b25faedb8cbfab7054dafc0a42
Module libp11-kit.so.0 with build-id cc372ea3c28c4d3dfc633b4d2e933c8584d2af16
Module libcrypto.so.1.1 with build-id 4c926b672d97886b123e03a008387aecf0786de4
Module libcrypt.so.2 with build-id a0a45f81771945f0559d04e93726d245159930da
Module librt.so.1 with build-id 4761858b348db8303e872e515aa8d56c046c921c
Module libnss_systemd.so.2 with build-id 56da60140e2f0e47044a141378608146f6fd9bb8
Module ld-linux-x86-64.so.2 with build-id c09c6f50f6bcec73c64a0b4be77eadb8f7202410
Module libc.so.6 with build-id 85766e9d8458b16e9c7ce6e07c712c02b8471dbc
Module libdl.so.2 with build-id bb9bd2657bfba9f60bd34d2050cc63a7eb024bc4
Module libm.so.6 with build-id 596b63a006a4386dcab30912d2b54a7a61827b07
Module libpthread.so.0 with build-id 7fa8b52fae071a370ba4ca32bf9490a30aff31c4
Module libgcc_s.so.1 with build-id 5d817452a709ca3a213341555ddcf446ecee37fa
Module libcap-ng.so.0 with build-id 09690c43af29ef92bbec2e53e29101b2b8e9c48c
Module libseccomp.so.2 with build-id 54179323d84e1b713b7547ba0b3f8310e65eec93
Module virtiofsd with build-id ac55adeab7cc1f7ca47fa74c938cf2d46c7d9206
Stack trace of thread 2:
#0  0x00007fe3ec9cf3c6 start_thread (libc.so.6 + 0x8d3c6)
#1  0x00007fe3eca54584 __clone (libc.so.6 + 0x112584)

Stack trace of thread 1:
#0  0x00007fe3eca56800 accept4 (libc.so.6 + 0x114800)
#1  0x000056230db9891b _ZN3std2os4unix3net8listener12UnixListener6accept17h54bf74abcb880374E (virtiofsd + 0x11391b)
#2  0x000056230db9c0d1 _ZN5vhost10vhost_user10connection8Listener6accept17h7f5e4813cc785e95E (virtiofsd + 0x1170d1)
#3  0x000056230dbe757d _ZN9virtiofsd4main17h7fa4789238c3e84aE (virtiofsd + 0x16257d)
#4  0x000056230daa3233 _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h6a68ebb114ba37b2E (virtiofsd + 0x1e233)
#5  0x000056230dbda199 main (virtiofsd + 0x155199)
#6  0x00007fe3ec96f310 __libc_start_call_main (libc.so.6 + 0x2d310)
#7  0x00007fe3ec96f3c1 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2d3c1)
#8  0x000056230daa195a _start (virtiofsd + 0x1c95a)
ELF object binary architecture: AMD x86-64

[wyphan]

I did not have any issues running a few containers on Ubuntu 20.04

@therealdandecker For me Docker Desktop hangs in the background and the GUI never shows up, but that's an issue affecting all Electron apps on my laptop running Ubuntu 20.04.4 LTS amd64. Balena Etcher does the exact same thing.

Also, @p1-0tr just indicated to me over the Docker Community Slack that Docker Desktop requires QEMU 5.2 but Ubuntu focal repos only have up to version 4.2 at the time of writing. Version 5.2 appears in hirsute (21.04):
https://packages.ubuntu.com/search?suite=all&arch=amd64&searchon=names&keywords=qemu-system-x86

Edit: system specs:

[elapuyade]

Also, @p1-0tr just indicated to me over the Docker Community Slack that Docker Desktop requires QEMU 5.2 but Ubuntu focal repos only have up to version 4.2 at the time of writing

@wyphan I'm not sure about the reason for the requirement for qemu 5.2. But FYI I run DD4L on qemu 4.2 from 20.04.4 repos and kernel 5.13.0-37 just like you with no issues. However, please note that even if it appears to work, ubuntu 20.04 is not a supported platform.

[p1-0tr]

@elapuyade the reason for requiring qemu 5.2<= is virtiofs, 4.2 does not officially advertise support for it in changelogs (there is code in 4.2, but a few important fixes are definitely missing).

[alxxthegeek]

gui just reports docker desktop is stopped and all settings are greyed out

Ubuntu 22.04 qemu 6.2.0 (Debian 1:6.2+dfsg-2ubuntu5)

diagnostics ids
d3869781-705d-46fa-8b8c-f1eb168f3574/20220401235952
d3869781-705d-46fa-8b8c-f1eb168f3574/20220402001304
if it helps

~ ▓▒░ tail -f ~/.docker/desktop/log/host/com.docker.driver.amd64-linux.stderr.log ░▒▓ INT х at 11:00:16
com.docker.driver.amd64-linux.stderr: [2022-04-01T23:53:11.821785804Z][com.docker.driver.amd64-linux][I] (7cb8baa9) 49120c04-DriverCMD C<-S c786dbd6-BackendAPI GET /features (453.455µs): {"DesktopExtensions":{"description":"Add/remove features from Docker Desktop easily","enabled":false,"label":"Enable Desktop Extensions","name":"Desktop Extensions","type":1},"NightlyBuilds":{"description":"Switch the application update to the night builds","enabled":false,"label":"Enable nightly builds","name":"Nightly builds","type":1},"ProUser":{"description":"You can upgrade your current tier here","enabled":false,"label":"personal","name":"ProUser","type":3},"Procd":{"description":"Enable advanced process management functionality like suspend and resume of containers and the VM","enabled":true,"label":"Enable process management daemon","name":"Process management daemon","type":1},"SimultaneousLinuxAndWindowsContainers":{"description":"Allow both Linux and Windows containers simultaneously using docker cli contexts","enabled":false,"label":"Simultaneous Linux and Windows containers","name":"Simultaneous Linux and Windows containers","type":3},"grpcfuseV2":{"description":"Switch off to use the legacy osxfs file sharing instead.","enabled":true,"label":"Use grpcfuse for filesharing by default","name":"Grpcfuse","type":1}}
com.docker.driver.amd64-linux.stderr: [2022-04-01T23:53:11.822440670Z][com.docker.driver.amd64-linux][I] Virtiofsd has started: /bin/sh -c /usr/share/docker-desktop/virtiofsd --socket-path=/.docker/desktop/virtiofs.sock0 -o cache=auto -o source=/home
com.docker.driver.amd64-linux.stderr: [2022-04-01T23:53:11.822567494Z][com.docker.driver.amd64-linux][I] VM has started: qemu-system-x86_64 -accel kvm -cpu host -machine q35 -m 8092 -smp 8 -kernel /usr/share/docker-desktop/linuxkit/kernel -append page_poison=1 vsyscall=emulate panic=1 nospec_store_bypass_disable noibrs noibpb no_stf_barrier mitigations=off linuxkit.unified_cgroup_hierarchy=1 vpnkit.connect=tcp+bootstrap+client://gateway.docker.internal:35283/0c1dcbc018aa2713d3bb76db40a0b7e955be093d5e1f39b5bca32e7d25380af0 vpnkit.disable=osxfs-data console=tty0 -initrd /usr/share/docker-desktop/linuxkit/initrd.img -serial pipe:/tmp/qemu-console2077341418/fifo -drive if=none,file=/.docker/desktop/vms/0/data/Docker.raw,format=raw,id=hd0 -device virtio-blk-pci,drive=hd0,serial=dummyserial -netdev user,id=net0,ipv6=off,net=192.168.65.0/24,dhcpstart=192.168.65.9 -device virtio-net-pci,netdev=net0 -vga none -nographic -monitor none -object memory-backend-memfd,id=mem,size=8092M,share=on -numa node,memdev=mem -chardev socket,id=char0,path=/.docker/desktop/virtiofs.sock0 -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=virtiofs0
com.docker.driver.amd64-linux.stderr: [2022-04-01T23:53:11.822688243Z][com.docker.driver.amd64-linux][I] created VM console
com.docker.driver.amd64-linux.stderr: [2022-04-01T23:53:11Z INFO virtiofsd] Waiting for vhost-user socket connection...
com.docker.driver.amd64-linux.stderr: qemu-system-x86_64: -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=virtiofs0: Failed to read msg header. Read 0 instead of 12. Original request 1.
com.docker.driver.amd64-linux.stderr: qemu-system-x86_64: -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=virtiofs0: vhost_backend_init failed: Protocol error
com.docker.driver.amd64-linux.stderr: [2022-04-01T23:53:11.976191428Z][com.docker.driver.amd64-linux][I] Hypervisor subprocess has shutdown
com.docker.driver.amd64-linux.stderr: [2022-04-01T23:53:11.976310710Z][com.docker.driver.amd64-linux][I] (30f5f14e) 00823493-DriverCMD C->S BackendAPI POST /events: {"HasServerTimestamp":false,"content":"driver sent docker state stopped","docker":"stopped","timestamp":1648857191976220200}
com.docker.driver.amd64-linux.stderr: [2022-04-01T23:53:11.977021306Z][com.docker.driver.amd64-linux][I] (30f5f14e) 00823493-DriverCMD C<-S c786dbd6-BackendAPI POST /events (772.262µs): OK

df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 6.3G 2.3M 6.3G 1% /run
/dev/mapper/vgubuntu--mate-root 1.8T 322G 1.4T 19% /
tmpfs 16G 268M 16G 2% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 32G 0 32G 0% /run/qemu
/dev/nvme0n1p1 511M 5.3M 506M 2% /boot/efi
tmpfs 6.3G 268K 6.3G 1% /run/user/1000

Version 4.7.0 (76677)
Engine: 20.10.14
Compose: 1.29.2
Credential Helper: v0.6.4
Kubernetes: v1.22.5
Snyk: v1.827.0

ubuntu 22 with mate desktop on asus pn51 5700u with 64GB

[aiordache]

@patrickhousley @alxxthegeek Thank you for reporting the issues you got.

There seems to be an incompatibility between the virtiofsd that Docker Desktop uses and the most recent version of qemu. As DD runs as non-root user, we can't rely on the virtiofsd shipped with qemu as it requires to run as root.
Modifying ~/.docker/desktop/settings.json and removing all approved shared directories, may unblock the startup of DD:

"filesharingDirectories": [],

But we can't do filesharing from the host in this case so it is very inconvenient.
We are looking to fix this asap.

[aiordache]

@patrickhousley @alxxthegeek We have a new deb package with a potential fix for your issues:

docker-desktop.deb

If you've got the time to test it and confirm it works on your machines, that would be great. Thanks in advance!

[SalahAdDin]

@patrickhousley @alxxthegeek We have a new deb package with a potential fix for your issues:

docker-desktop.deb

If you've got the time to test it and confirm it works on your machines, that would be great. Thanks in advance!

It is a good news!

[alxxthegeek]

So far all good with the new deb.
docker desktop starts, can run images.
WIll do some more testing later with k8's

[Neirth]

A few questions, has support for Fedora Workstation / Silverblue been considered? And have you considered the possibility of using our own installation of moby engine instead of using a virtual machine based on linuxkit?

[jmlogan]

Are there any intentions of supporting RHEL and RHEL-like distros in the future?

[aiordache]

We are preparing an rpm package at the moment. We'll update the docs page with links to download it once we are done.

@Neirth There are no plans to use a local installation of the engine, we've documented the main reasons why we have chosen to go with a VM approach here.

[SalahAdDin]

We are preparing an rpm package at the moment. We'll update the docs page with links to download it once we are done.

@Neirth There are no plans to use a local installation of the engine, we've documented the main reasons why we have chosen to go with a VM approach here.

After that, a good package for Arch Linux!!! yey!

[mruderman]

I'm a scientific Linux user (but fairly non-technical) interested in Docker for reproducibility and potentially to deploy Shiny WebApps for data visualization. I don't have any practical experience using Docker yet. Can any Ubuntu 20.04 testers say whether the current beta .deb is workable/stable enough for a user at my level to try and get my hands dirty with Docker? (or is it best to wait for a later beta or full release, or even use an interim 3rd party gui client). Thank you Devs and Testers!
Thanks D

[alxxthegeek]

The only problem I've hit is trying to get paketo buildpacks to work with docker desktop, they seem to expect docker-ce

pack build paketo-demo-app --builder paketobuildpacks/builder:base ░▒▓ 125 х took 33s at 16:19:46
ERROR: failed to build: failed to fetch builder image 'index.docker.io/paketobuildpacks/builder:base': Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Thats using the demo apps from https://paketo.io/docs/

[christophermclellan]

Hi all, given that Docker Desktop for Linux is now available I'm going to close this ticket. If you have any issues or feature requests please do submit them here - https://github.com/docker/desktop-linux/issues. We're actively monitoring that thread and trying to jump on issues as quickly as possible.

[jmlogan]

Is RHEL 8/9 on the roadmap?