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

So sad.

from roadmap.

@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).

from roadmap.

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.

from roadmap.

We are now starting work on this :) https://www.docker.com/blog/accelerating-new-features-in-docker-desktop/

from roadmap.

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

from roadmap.

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.

from roadmap.

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

from roadmap.

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

from roadmap.

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 :)

from roadmap.

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?

from roadmap.

Hi all - here’s the doc for our Docker Desktop for Linux tech preview, which explains how to download and install the package. Please note that for this early preview we are only providing a .deb, though will look to add support for other distros soon.

Any feedback that you’re able to provide is massively appreciated, specifically on any bugs that you may encounter and performance benchmarks that you’re able to share.

Thanks in advance !

from roadmap.

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.

from roadmap.

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

Wrong. We are Linux developers, expected to have full features, in parity with other platforms.

A GUI is a tool like any other, and it's almost insulting Docker developed a tool for other platforms but not for Linux, specially considering docker started in Linux.

from roadmap.

A few months later... any update?

from roadmap.

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

from roadmap.

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.

from roadmap.

Hey @kmanwar89 - that was me that reached out to you ! I’d completed the research by the time I received your reply, apologies that I didn’t clarify this sooner.

By way of an update, we are looking forward to sharing our very first tech preview of Desktop for Linux with this thread on Friday. Thank you all for your patience, we’re excited to get your feedback very soon.

from roadmap.

Dev on Linux is becoming more of a norm than niche - not supporting it just does not make sense...

from roadmap.

I am waiting for Docker Desktop on Ubuntu. I hope it happens soon.

from roadmap.

Thank you @therealdandecker This request is simply about Docker seeing Docker Desktop implemented for Linux, so the same user experience is across the 3 major OS platforms. even if RHEL and Ubuntu are the only two officially supported. That in itself will be enough.
Would be happy to hear if @justincormack and @nebuk89 want to chime in if any updates from Docker ?

from roadmap.

I really don't think it's totally accurate to say that most Linux devs prefer commandline. It's true that most are proficient in commandline, there are some that use VIM, and many server maintenance activities are often over SSH on a Linux box, but there are a lot of activities that devs on Linux want to use a GUI for just as much as someone on another os. I'm not using a GUI web browser on Ubuntu (my OS of choice since 2008). I'm not that much of a commandline guru at all, and I use Goland for my IDE, prefer Wireshark to Tshark, and I would very much appreciate a Docker Desktop dashboard to see my images and containers for easy management just like I can do when I work on a Mac or Windows machine. Thinking it isn't useful to me because I'm a Linux user is nonsense and ignores the ongoing feedback here.

from roadmap.

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

P.S. Pun Intended

from roadmap.

@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?

For us it's 50%. All of my developer friends use Linux.

from roadmap.

Some of these responses about Portainer or Windows containers are not relevant to this request.

The request posted here is simple- a Docker Desktop application / utility identical to the one available on Windows and Mac available on Linux Desktop.

If folks could stop citing third-party solutions or talking about smaller deployment scenarios (Windows Containers) it would be nice. Those of us following this thread are pretty savy - the request is development or clarification on Docker Desktop for Linux Desktop.

from roadmap.

I was reached out to by a Docker Community Manager (I think that was their title) to get my opinions around DD4L (Docker Desktop for Linux). I replied a couple weeks later but never heard back. Seems the discourse around this issue has died off.

I'm genuinely curious if anyone from the Docker team would be able to provide an update? There was an article around the developer program, but it's been a few months. I've asked to sign up, but I'd be interested to hear how that program is going, what the roadmap looks like, etc. I've been brushing up my Python skills lately so perhaps I could contribute (assuming it's a native app, and not yet another Electron-slapped-on-top bandage solution)

from roadmap.

Hey @kmanwar89 - that was me that reached out to you ! I’d completed the research by the time I received your reply, apologies that I didn’t clarify this sooner.

By way of an update, we are looking forward to sharing our very first tech preview of Desktop for Linux with this thread on Friday. Thank you all for your patience, we’re excited to get your feedback very soon.

Well hello! Thanks for clarifying. I'm really excited to hear about the first implementation of Docker Desktop for Linux. Will the link be made publicly available, or is there a beta program one needs to sign up for?

from roadmap.

@kmanwar89 - the link will be made publicly available, I'll share with this thread very shortly. Sorry for delay (especially after I said it would be sent on Friday) !

from roadmap.

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.

from roadmap.

Thank you @therealdandecker This request is simply about Docker seeing Docker Desktop implemented for Linux, so the same user experience is across the 3 major OS platforms. even if RHEL and Ubuntu are the only two officially supported. That in itself will be enough.
Would be happy to hear if @justincormack and @nebuk89 want to chime in if any updates from Docker ?

Following this for updates from @justincormack and @nebuk89 .

from roadmap.

Seeing that linux is the only free platform left for larger companies, will the docker CLI still remain free on linux or will docker desktop for linux replace the CLI, i.e., will the CLI be delivered as part of docker desktop and might thus be subject to subscription fees?

from roadmap.

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.

from roadmap.

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

from roadmap.

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.

from roadmap.

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

from roadmap.

Can't wait for docker desktop when it happens. It will be a life changer for people wanting to begin using docker.

from roadmap.

It’s funny reading through this thread also wanting this feature. Windows and Mac to get Docker working just spin up a Linux VM following various paths (Apple Hypervisor, Hyper-V/ WSL2 on Hyper-V framework). Maintaining the interaction between host system and VM with the interface seems like it would be harder than a local UI.

from roadmap.

They said in the article it will follow the same pricing / licensing model… but that’s a valid question as I think the GPL license would require it to be open source right?

Docker is Apache2, and the OS kernel license doesn't apply to applications running on Linux. IANAL, but I don't believe assembling various OSS projects with other closed source tools, makes the closed source tools open source, unless there's library level linking and a copy-left license involved.

from roadmap.

@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?

from roadmap.

while we are waiting, I might drop this link (https://www.linuxjournal.com/content/search-gui-docker) for alternative of docker desktop. My personal preference is Portainer (not opensource) and UI For Docker an open source web based UI

Why do you say portainer is not open source ? portainer-ce code is available here in github and is licensed under a zlib license which is fully compatble with GPL. They have a business version built on top of it but saying that portainer is not open source because of that is completely misleading.

from roadmap.

Is there any news? I would also be interested in a graphic app for linux.

from roadmap.

As of today -> no updates from Docker but watch this space still and thank you for your inputs 🙌

from roadmap.

Hey @jkoenig134 - yep I believe you can run it on WSL2 (one of the Docker Captains tried this).

from roadmap.

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?

from roadmap.

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.

from roadmap.

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.

from roadmap.

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.

from roadmap.

Portainer seems nice, but it's a docker image that runs docker management, which is a bit like a chicken-and-egg situation

from roadmap.

Thanks @nebuk89, this is a wonderful news. One question, will it be open-sourced or closed-sourced like the ones for Windows and Mac?

from roadmap.

@lmapii

Seeing that linux is the only free platform left for larger companies,

Redhat RHEL isn't free, and large companies that build their business on technologies such as Linux understand they need to invest in these technologies to be sustainable

will the docker CLI still remain free on Linux or will Docker desktop for Linux replace the CLI, i.e., will the CLI be delivered as part of Docker desktop and might thus be subject to subscription fees?

I'm sure the docker-ce CLI and daemon side will be free and opensource, but the Docker Desktop (Product) will of course be scoped into their subscription model and consistent across their offering

In Corey Quinny podcast with Scot Johnston, gives a good perspective https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/heresy-in-the-church-of-docker-desktop-with-scott-johnston/

from roadmap.

@christophermclellan can this be installed on WSL in parallel with Docker Desktop on Windows to try it out?

from roadmap.

Thank you @christophermclellan!! Was waiting on this with bated breath :)

Re: performance benchmarks - I have access to several systems, and can comfortably drop any distribution I'd like on them without issues. Understanding of course that this will only install as a .deb for now, does Docker have a testing methodology they would like us to follow for benchmark consistency?

from roadmap.

from roadmap.

@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.

from roadmap.

@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!

from roadmap.

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

from roadmap.

@shahidcodes The container (OCI) management / runtime tool for Linux is called Podman. It is built on a different concept: if 99% OCI images are Linux-based and the developer doesn't need sophisticated and heavy resource management then there is no reason to build tools on top of Linux. It is much easy to fit Linux to run OCI containers. Pure Linux style CLI is for those who don't need GUI..
They don't conflict, share parts of code but address different ecosystems.

from roadmap.

well it would be cool to have same featuers as windows/mac but most linux devs are more command line users so if we could at least get isolated docker experience (inside super micro vm like mac/windows) from base os like windows/mac this would be cool as a start and no need to replay on package manager for keeping offical docker upto date.

from roadmap.

yes id agree what you said and sure it would be nice to have parirty with mac/windows :)

from roadmap.

The "traditional" containerized applications developers' approach is to be platform's agnostic. The best choice for GUI is the Web GUI ! There are several products available, from Portainer to Prometeus . Some of them are installed by default with the Orchestration engine. It's hard to compare between capabilities of these products and Docker-for-win.

from roadmap.

The "traditional" containerized applications developers' approach is to be platform's agnostic. The best choice for GUI is the Web GUI ! There are several products available, from Portainer to Prometeus . Some of them are installed by default with the Orchestration engine. It's hard to compare between capabilities of these products and Docker-for-win.

They have different use cases. Portainer is more of a production system management tool that can ease some administration tasks, docker desktop is more oriented for image developers or newbie users that are just learning. I develop images in linux and the closest thing I have found to docker desktop is lazydocker, which it is of great help while testing. Being able to quickly enter to or inspect the configuration of a container, looking at logs in one place, resource usage statistics, image administration, etc is of great help. Using portainer for that would be overkill.

from roadmap.

Here is the list of Alternatives, most of them can run on the Linux out-of-the-box: Alternative Docker GUI/Shells. For Docker like any OCI engine, Windows is an obstacle, not a benefit. Docker-for-win bypasses this obstacle, but for the enormous price of separate VM creation and broken networking. Who uses Linux distro like Ubuntu, Centos, Debian, Fedora, etc. can install an Up-to-date Docker version from the repository in one click, with or without Orchestration, without any separate VM, most modern OCI runtime like CRI-O, Crun, as a server or serverless, community or enterprise support.

from roadmap.

@rapha8l Docker is a standard Linux package available for all modern Server/Desktop Linux distro out-of-the-box. Search docker-ce in the repository corresponding to your distro.

from roadmap.

while we are waiting, I might drop this link (https://www.linuxjournal.com/content/search-gui-docker) for alternative of docker desktop. My personal preference is Portainer (not opensource) and UI For Docker an open source web based UI

from roadmap.

while we are waiting, I might drop this link (https://www.linuxjournal.com/content/search-gui-docker) for alternative of docker desktop. My personal preference is Portainer (not opensource) and UI For Docker an open source web based UI

UI for Docker was deprecated in favor of Portainer.

from roadmap.

while we are waiting, I might drop this link (https://www.linuxjournal.com/content/search-gui-docker) for alternative of docker desktop. My personal preference is Portainer (not opensource) and UI For Docker an open source web based UI

Why do you say portainer is not open source ? portainer-ce code is available here in github and is licensed under a zlib license which is fully compatble with GPL. They have a business version built on top of it but saying that portainer is not open source because of that is completely misleading.

My bad.

from roadmap.

Till it ever happens, Kitematic is quite good

from roadmap.

i would love to have the docker desktop distributaion on linux, so isolated from os plus docker/k8s integration plus updates managed by docker not os. sure ui would be bonus but not expecting that any time soon.

from roadmap.

Any news about this? Kitematic has no a better alternative now.

from roadmap.

@MichaelAquilina compose subcommand is implemented as a CLI plugin, see https://github.com/docker/compose-cli#compose-v2-aka-local-docker-compose

from roadmap.

from roadmap.

Considering docker is used primarily by developers and dev-ops, latest Stack Overflow Developer Survey 2021 shows that Linux is used by about 25% of developers, roughly the same amount as MacOS. It is sensible to support such a large community especially considering that percentage of docker apps being deployed on Linux is quite likely highest of all 3 major platforms.

from roadmap.

@TeoColuccio At least 1 graphic application exists - Portainer, easy to deploy Portainer Installation for Docker, no dependency except Docker itself, platform-independent graphic, robust support. What are the benefits to run Electron GUI, i.e. Windows-specific application on Linux? Anyway, you have no chance to run Windows containers on Linux today because you need Windows Kernel provided by Docker Desktop for Windows.

from roadmap.

@TeoColuccio At least 1 graphic application exists - Portainer, easy to deploy Portainer Installation for Docker, no dependency except Docker itself, platform-independent graphic, robust support. What are the benefits to run Electron GUI, i.e. Windows-specific application on Linux? Anyway, you have no chance to run Windows containers on Linux today because you need Windows Kernel provided by Docker Desktop for Windows.

But it does still require a browser.

from roadmap.

Wasn't docker desktop already using Electron?

from roadmap.

@grealish it wasn’t intended to sound like a complaint, I’ve just seen this on the roadmap and since I have another project going that might make (first) use of Docker I wanted to ask about details. I see how this might help in the long run.
Thanks also for the link, I’ll definitely have a look.

from roadmap.

Awesome, thanks @kmanwar89. In terms of testing, we're really just interested to understand whether you feel this works well for your specific use cases and is performant.

Here are a couple of examples of the sort of feedback we get on our macOS filesharing threads, which are very useful to us:

• #7 (comment)
• docker/for-mac#1592 (comment)

In terms of methodology, it’s really whatever you’re happy / willing to do ! we sometimes get users that run tests a few times to iron out for inconsistencies though that’s not by any means a requirement on our side.

from roadmap.

Thanks @christophermclellan .

At this point, I spun up a fresh VM with Ubuntu Desktop 21.10, installed Docker (as well as docker-ce-cli) and then installed Docker Desktop, but it isn't launching at all. Currently trying to troubleshoot, but there's no error message, so it just silently fails without any way for me to troubleshoot.

I'll edit this post if/when I have an update on the issues I'm facing.

from roadmap.

I had a similar problem to what @kmanwar89 describes. I was running Docker Desktop on my laptop (not a VM) running Ubuntu 21.10. Docker Desktop would not launch and there was no error message. I found a message in /var/log/syslog that said that Docker Desktop could not get enough memory. It wanted 7.9+ GB of memory but the shared memory (/dev/shm) was set to 7.8 GB. According to the section Checking Shared Memory, it will automatically allocate half of the system memory for Docker Desktop. It seems that there is a minimum of 8GB but this is not clear in the document. I adjusted the size of /dev/shm to be 8GB and now Docker Desktop launches fine. There is a setting in Docker Desktop to adjust the amount of memory - I did not try reducing that and then changing /dev/shm.

from roadmap.

I changed the Memory for the VM (Settings -> Resources) to 4 GB and set the size of /dev/shm to 4200M in /etc/fstab. Docker Desktop still fails to start and logs the following in /var/log/syslog:

Feb  6 11:43:58 saaz com.docker.backend[4787]: [037:11:43:58.680][I] checking available shared memory
Feb  6 11:43:58 saaz com.docker.backend[4787]: [037:11:43:58.983][F] /dev/shm has only 4187 MB free space, out of 4096 MB required for VM RAM
Feb  6 11:43:58 saaz com.docker.backend[4787]: [main.reportIfFatal({0x1d5c020, 0xc00035ab50}, {0x0, 0x1b1bd0c, 0xe})
Feb  6 11:43:58 saaz com.docker.backend[4787]: [#011common/cmd/com.docker.backend/main.go:455 +0x98
Feb  6 11:43:58 saaz com.docker.backend[4787]: [main.main()
Feb  6 11:43:58 saaz com.docker.backend[4787]: [#011common/cmd/com.docker.backend/main.go:92 +0x348
Feb  6 11:43:58 saaz systemd[2265]: docker-desktop.service: Main process exited, code=exited, status=1/FAILURE
Feb  6 11:43:58 saaz systemd[2265]: docker-desktop.service: Killing process 4791 (com.docker.back) with signal SIGKILL.
Feb  6 11:43:58 saaz systemd[2265]: docker-desktop.service: Failed with result 'exit-code'.

So it seems as though for now /dev/shm needs to be set to 8G.

from roadmap.

Hi,
There is unfortunately an incorrect information in the log line where it says it requires 4096 MB:
Feb 6 11:43:58 saaz com.docker.backend[4787]: [037:11:43:58.983][F] /dev/shm has only 4187 MB free space, out of 4096 MB required for VM RAM
Internally, we check for at least the VM configured requirement + 100MB, so we really want 4196 MB free, but we forgot to add those additional 100MB in the logged required size. With 10 more MB allocated to /dev/shm, it should work. Sorry for that.

from roadmap.

Hi, There is unfortunately an incorrect information in the log line where it says it requires 4096 MB: Feb 6 11:43:58 saaz com.docker.backend[4787]: [037:11:43:58.983][F] /dev/shm has only 4187 MB free space, out of 4096 MB required for VM RAM Internally, we check for at least the VM configured requirement + 100MB, so we really want 4196 MB free, but we forgot to add those additional 100MB in the logged required size. With 10 more MB allocated to /dev/shm, it should work. Sorry for that.

Hi there, can the actual requirements for Docker Desktop for Linux be published? I can confirm what @jmgrady stated - I had to increase the RAM on my VM to 16GB (from 8GB previously) in order for DD4L to even load. I've confirmed this behavior by creating a fresh Ubuntu Desktop 21.10 VM with 8GB of RAM and the behavior is exactly the same - it does not load.

So at this point, if I had a host machine with only 8 or 16GB of RAM, I would not be able to use DD4L. Fortunately my machine has 32GB, but this may be a blocker.

I'd be curious if others can validate this behavior.

from roadmap.

@kmanwar89 What requirement are you talking about exactly? You can start DD4L with as little as 2 GB of RAM for the VM. The only requirement is that /dev/shm has enough free space to fit a file whose size is VM RAM + 100MB.

Are you saying that setting /dev/shm to, say, 5000MB, and setting VM RAM to 4096MB doesn't work? It should. Can you please show us the log lines for this configuration?

from roadmap.

You can start DD4L with as little as 2 GB of RAM for the VM. The only requirement is that /dev/shm has enough free space to fit a file whose size is VM RAM + 100MB.

@kmanwar89 What requirement are you talking about exactly?

The system requirements for the program - they are not mentioned anywhere. How would a user know they can have a VM as small as 2GB, or perhaps larger in size, without something to go off of? Understand and respect that it's a tech preview, but I would hope these are the kinds of questions we should be addressing.

Are you saying that setting /dev/shm to, say, 5000MB, and setting VM RAM to 4096MB doesn't work? It should. Can you please show us the log lines for this configuration?

As I mentioned in my previous posts, I've tried the following scenarios:

Scenario 1

• Ubuntu Desktop 21.10 VM - 8GB RAM - Docker Desktop does not load at all/fails silently without any error/troubleshooting messages. Logs below:

Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Activating service name='org.gnome.ControlCenter.SearchProvider' requested by ':1.27' (uid=1000 pid=1847 comm="/usr/bin/gnome-shell " label="unconfined")
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Activating service name='org.gnome.Nautilus' requested by ':1.27' (uid=1000 pid=1847 comm="/usr/bin/gnome-shell " label="unconfined")
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Activating service name='org.gnome.Calculator.SearchProvider' requested by ':1.27' (uid=1000 pid=1847 comm="/usr/bin/gnome-shell " label="unconfined")
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Activating service name='org.gnome.Characters.BackgroundService' requested by ':1.27' (uid=1000 pid=1847 comm="/usr/bin/gnome-shell " label="unconfined")
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Activating service name='org.gnome.seahorse.Application' requested by ':1.27' (uid=1000 pid=1847 comm="/usr/bin/gnome-shell " label="unconfined")
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Successfully activated service 'org.gnome.ControlCenter.SearchProvider'
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Successfully activated service 'org.gnome.Nautilus'
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Successfully activated service 'org.gnome.seahorse.Application'
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Successfully activated service 'org.gnome.Characters.BackgroundService'
Feb  7 11:01:39 ubuntu dbus-daemon[1751]: [session uid=1000 pid=1751] Successfully activated service 'org.gnome.Calculator.SearchProvider'
Feb  7 11:01:39 ubuntu gnome-calculato[3204]: search-provider.vala:140: Failed to spawn Calculator: Child process killed by signal 9
Feb  7 11:01:39 ubuntu nautilus[3202]: Connecting to org.freedesktop.Tracker3.Miner.Files
Feb  7 11:01:40 ubuntu systemd[1733]: Started Application launched by gnome-shell.
Feb  7 11:01:40 ubuntu systemd[1733]: Started VTE child process 3283 launched by gnome-terminal-server process 3161.
Feb  7 11:01:40 ubuntu systemd[1733]: Starting Docker Desktop...
Feb  7 11:01:40 ubuntu systemd[1733]: Started Docker Desktop.
Feb  7 11:01:40 ubuntu systemd[1733]: vte-spawn-c9445185-9c9e-452d-9416-3284816a9bcd.scope: Deactivated successfully.
Feb  7 11:01:40 ubuntu systemd[1733]: app-gnome-docker\x2ddesktop-3277.scope: Deactivated successfully.
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
Feb  7 11:01:40 ubuntu com.docker.backend[3284]: 2022/02/07 11:01:40 bugsnag.Notify: bugsnag/payload.deliver: Post "https://notify.bugsnag.com": dial tcp 0.0.0.0:443: connect: connection refused
Feb  7 11:01:40 ubuntu systemd[1733]: docker-desktop.service: Main process exited, code=exited, status=1/FAILURE
Feb  7 11:01:40 ubuntu systemd[1733]: docker-desktop.service: Failed with result 'exit-code'.

For reference, the output of df -h shows I have ample space left in my /dev/shm, so that shouldn't be an issue here:

kadar@Kadar-Linux-Desktop:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  2.0M  3.2G   1% /run
/dev/sda5       337G  152G  168G  48% /
tmpfs            16G  167M   16G   2% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/sda1        96M   31M   66M  32% /boot/efi
tmpfs           3.2G   36K  3.2G   1% /run/user/1000

Scenario 2

• Ubuntu Desktop 21.10 VM - 16GB RAM - Docker Desktop loads and it takes about a minute for the engine to start and for the application to become usable. Interesting log entry to note here:

Feb  7 11:07:28 ubuntu nautilus[2100]: Connecting to org.freedesktop.Tracker3.Miner.Files
Feb  7 11:07:28 ubuntu nautilus[2100]: Source ID 169 was not found when attempting to remove it
Feb  7 11:07:28 ubuntu nautilus[2100]: Source ID 181 was not found when attempting to remove it
Feb  7 11:07:28 ubuntu systemd[1481]: Started Application launched by gnome-shell.
Feb  7 11:07:29 ubuntu systemd[1481]: Started VTE child process 2179 launched by gnome-terminal-server process 2063.
Feb  7 11:07:29 ubuntu systemd[1481]: Starting Docker Desktop...
Feb  7 11:07:29 ubuntu systemd[1481]: Started Docker Desktop.
Feb  7 11:07:29 ubuntu systemd[1481]: app-gnome-docker\x2ddesktop-2173.scope: Deactivated successfully.
Feb  7 11:07:29 ubuntu systemd[1481]: vte-spawn-b7b0d03c-cfa2-47de-ab62-e4fe520f16f0.scope: Deactivated successfully.
---LOGS TRUNCATED FOR BREVITY---
Feb  7 11:07:29 ubuntu com.docker.backend[2190]: [038:11:07:29.328][I] checking available shared memory

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

df -h still shows I have ample room available in /dev/shm

kadar@Kadar-Linux-Desktop:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  2.0M  3.2G   1% /run
/dev/sda5       337G  160G  160G  50% /
**tmpfs            16G  167M   16G   2% /dev/shm**
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/sda1        96M   31M   66M  32% /boot/efi
tmpfs           3.2G   36K  3.2G   1% /run/user/1000

For note:
I have not modified the size of /dev/shm using the methods outline in the docs, but instead am modifying it using the GUI for VMWare Workstation, which I suspect most users would do when setting up a VM. I have also not tried any other RAM settings other than 8 or 16GB - though I'm happy to try others. Am I understanding correctly that perhaps the modification of /dev/shm is required?

So based on those logs, with a VM set for 16GB of RAM allocated to it, 8GB of that is being allocated to the Docker Desktop instance, at which case it then takes an additional 1/2 of that 8GB. So running a VM with 8GB of RAM allocated to it seems to be incompatible based on what I'm seeing.

from roadmap.

Update from my previous post:

I have attempted to manually adjust the /dev/shm values based on the instructions here, but there is no change. I am still greeted with the same error, even after setting /dev/shm to 10GB.

Feb  7 11:49:08 ubuntu gnome-shell[1830]: clutter_actor_get_transition: assertion 'CLUTTER_IS_ACTOR (self)' failed
Feb  7 11:49:08 ubuntu com.docker.backend[2601]: [038:11:49:08.467][F] /dev/shm has only 3957 MB free space, out of 3957 MB required for VM RAM
Feb  7 11:49:08 ubuntu com.docker.backend[2601]: [main.reportIfFatal({0x1d5c140, 0xc00058ad80}, {0x0, 0x1b1be88, 0xe})
Feb  7 11:49:08 ubuntu com.docker.backend[2601]: [#011common/cmd/com.docker.backend/main.go:450 +0x98
Feb  7 11:49:08 ubuntu com.docker.backend[2601]: [main.main()
Feb  7 11:49:08 ubuntu com.docker.backend[2601]: [#011common/cmd/com.docker.backend/main.go:91 +0x348
Feb  7 11:49:08 ubuntu systemd[1659]: docker-desktop.service: Main process exited, code=exited, status=1/FAILURE
Feb  7 11:49:08 ubuntu systemd[1659]: docker-desktop.service: Failed with result 'exit-code'.

kadar@Kadar-Linux-Desktop:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  2.0M  3.2G   1% /run
/dev/sda5       337G  152G  168G  48% /
tmpfs            10G  357M  9.7G   4% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/sda1        96M   31M   66M  32% /boot/efi
tmpfs           3.2G   40K  3.2G   1% /run/user/1000

Something is very broken.

from roadmap.

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.

from roadmap.

@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?

from roadmap.

@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

from roadmap.

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
...

from roadmap.

@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.

from roadmap.

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

from roadmap.

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:

from roadmap.

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.

from roadmap.

@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).

from roadmap.

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

from roadmap.

@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!

from roadmap.

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

from roadmap.

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

from roadmap.

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!

from roadmap.

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

from roadmap.

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/

from roadmap.