On a Windows Server 2019, I have a storage spaces mirror with REFS dedup volume. I connected all of the drives that are a part of the storage spaces mirror to a Windows 11 Pro device. Everything is seen as it should be except it cannot copy any of the files off without error. I then connected it back to the Windows Server, and the storage space is seen but the volume is seen listed as raw. Running refsutils does see it but fsutils does not see it as refs.
I’m trying to understand what Windows 11 Pro would have done to the volume to cause it to no longer be readable on Server 2019 so that I can start working to find a fix.
Related
I looked up on the internet and it said courgette.log file is based on docker.
I am using Docker version 20.10.17, build 100c701 on Windows 11 Home.
But I have docker installed for a long time now. Why did courgette.log file appear today itself empty and with size: 0 bytes.
This is a well-known issue related to GitHub:
https://github.com/docker/for-win/issues/12468
courgette.log is created each time you're going to update Docker desktop.
Issue are reproduced on Windows 11 and Windows 10.
This log file is apparently created by an executable file called courgette64.exe into Docker installation folder.
Do not hesitate to remove it, it does not cause any side effects.
Chromium projects related links:
https://chromium.googlesource.com/chromium/src/courgette/+/HEAD
https://www.chromium.org/developers/design-documents/software-updates-courgette/
I have installed latest Docker Desktop. Currently unable to switch to Windows container. The option is blocked from task bar :
I am running Windows 10 Home 64-bit Build 19042.
You need windows 10 Pro or Enterprise to have access to Windows containers.
Source
The other answer will indeed switch your daemon mode to Windows, but you will not be able to pull any Windows container.
Update 2022:
The link above now mentions that it should work for
Windows 11 64-bit: Home or Pro version 21H2 or higher, or Enterprise or Education version 21H2 or higher.
Windows 10 64-bit: Home or Pro 21H1 (build 19043) or higher, or Enterprise or Education 20H2 (build 19042) or higher.
I had spent hours debugging this issue and have to purchase win 10 pro license as well but still faced the same issue, by default it takes linux containers, switching to windows shows waiting forever, anyway here is how I fixed:
Windows Pro
Close/Shutt down the client by right clicking on the tiny icon on taskbar, and wait for a minute or two to have it close itself.
3.Open command prompt with Administrative rights
Type in this command:
c:\Program Files\Docker\Docker\resources>dockerd.exe
Open another command prompt with Administrative rights
C:\Program Files\Docker\Docker>DockerCli.exe -SwitchDaemon
Type "C:\Program Files\Docker\Docker>docker version" command to make sure it has switched to windows containers, it should look like attached screenshot
as per the latest Docker Desktop version, your settings should look like this
Quit Docker Desktop, and open again, Hope it helps some.
This command will change from windows to linux and vice versa.
I could not switch it easily, even using Altaf's approach. Eventually I went to Services (services.msc) and disabled Docker Desktop Service and updated docker service (Docker Engine) to make sure it can automatically start (for example, make sure the daemon.json config file exists in the location as the service command specified).
Then I can verify the result by typing docker version (in non-Administrative command prompt).
https://kontext.tech/article/1216/how-to-change-docker-data-root-path-on-windows-10#h-switch-to-windows-containers
I am exploring docker for one of my company project. In this project I need to run the MemCached on CentOS and I prefer to run this in a docker container. I have successfully able to run this on Windows 10 machine with Docker Community Edition installed. But our project needs Windows Server 2019 in production and I want to run the container of same image (MemCached on CentOS) on windows server 2019. I googled a lot and found a link for running Linux Containers on Windows Server 2019. But as per the above link we are installing docker package in Preview version. I believe that this Preview version I should not use in Production. Is my understanding is correct or not?
Also is there any other stable released way to run Linux containers on Windows Server 2019.
Thanks in advance.
As per the Preview version you can remove the -RequiredVersion preview tag and then install. The process will install Docker Enterprise Edition on Server 2019 and not the CE version as the one for WIN 10.
If the container you want to run is a Linux container then you may face some tough times reason being
The containers(linux) runs on Server 2019 using LCOW way and the LCOW way is an experimental feature.
You said that you want to run container in Production environment and I would say not to use and experimental feature for Production.
Incase you need to run the containers on a server edition of Windows ie Server 2016 or Server 2019 you can go with the Docker CE (ie the same .exe that works on Win 10).
One important point to note is that on server 2016 all the docker versions are not supported.
Docker 2.0.0.31259 is the supported version of Docker on Server 2016.(Latest Docker 2.1.0.3 does not work on server 2016 but it works on Server 2019
Note : I face the same issues as you face ie you want the run the containers on Server 2019. The above are my findings so far. There is no clarity from windows side about how to run docker containers. Please refer to my answer :Here for better understanding
I'm struggling with the same issue for some time, and for me the only working combination of Windows Server and Docker that can effectively run with Linux containers is Windows Server 2019 Standard Edition with an edge release Docker Desktop Community 2.1.3.0 published on 2019-09-16.
The link to read about edge releases and to download them is:
https://docs.docker.com/docker-for-windows/edge-release-notes/
In my case, there was also an issue of nested virtualization, since my Windows Server is installed on VMware machine, and Docker requires Hyper-V inside Windows Server in order to work.
Fixed that issue according to instructions provided here:
https://doitfixit.com/blog/2014/03/06/qhyper-v-components-is-not-runningq-nested-in-vmware-workstation/
as far as my understanding goes, it is experimental feature, however it can be done and works quite OK.
The only requirement is that this feature works on server with hypervisor enabled.
Follow this link: https://www.altaro.com/msp-dojo/linux-containers-windows-server-2019/ for further instructions on how to set it up.
I have a 2013 Mac Pro running the latest Parallels Desktop Pro v
12.2.0 (41591)
On it, is a Windows 10 Pro virtual with Docker Version 17.03.1-ce-win10 (11972)
Docker can only run with 'windows containers' because when trying to fire up the 'MobyLinux' instance in Hyper-V, it never fires up always bombing at:
tsc: Fast TSC calibration failed
I understand this to be some time dependent sync that has to happen at boot time or such failure occurs. I bought a WD 1TB SSD on a Thunderbolt dock to speed up the run/boot time of the virtual. (it was on my platter RAID cage before) to no avail. No diff.
Parallels IS set to 'enable nested virtualization' and I have started a virtual in Hyper-V on the win 10 Pro VM just fine, no errors. I have checked and unchecked 'PMU Virtualization' which I understand will provide statistics to the host but slow the VM.
I tried:
reducing the number of assigned cores to the VM as suggested by
another post to no avail (2-6 cores tried)
Reducing the cores to '1' for Docker (and mixing with above attempt)
increasing the number of cores to docker
adding/reducing memory to VM/Docker
playing with the
C:\Program
Files\Docker\Docker\resources\MobyLinux.ps1
file that loads the VM whereas in another post I changed something to
verifying that "C:\Users\Public\Documents\Hyper-V\Virtual hard disks\MobyLinuxVM.vhdx" is teh correct location for the .vhdx
verifying that the .iso is at "C:\Program Files\Docker\Docker\Resources\mobylinux.iso"
uninstalling Hyper-v/reinstalling Hyper-v manually and letting Docker do it automatically
...
I am at wit's end. I specifically bought this machine so I could do my MS/Visual Studio development along with iOS development on the same box. I have done so, this way, for the past 5-6 years with a 2009 Mac Pro before and now my 2013 MP, but never with Docker before...
So, I need one of two solutions:
a way to make Visual Studio 2015/2017 'look' at my host Mac's Docker instance in order to debug/move on to development
a way to make this 'MobyLinux' Docker vm run.
I was having the same issues and I had initially set the memory to the highest levels allotted and Docker just flat would not run in the Windows box. After tinkering with it for a while I realized that in the Windows box I had not done any of the updates so I ran all those and logged back in, and was getting the same issues of docker not running. That is when I moved over to Parallels and made the changes shown below. Hopefully that helps!
result of docker version:
https://a.cl.ly/kpumLPz4
hyper v:
https://a.cl.ly/jkunldkm
settings in parallels:
https://a.cl.ly/QwuGKq1D
additional settings in parallels that I changed:
https://a.cl.ly/9ZuNElnb
command that I ran for hello_world:
docker run --rm busybox echo hello_world
windows docs on Linux containers 10
docker docs on windows install
I need to work with Delphi 6 Update 2 in Windows 8.1 x64 (in case you were wondering, it's about maintaining an old application, migrating to a newer version is not an option. I can't use a VM because I use the same machine to connect to some peripherals that don't work in a VM).
The problem is that Update 2 has a 32 bit installer with a 16 bit stub. So the current behaviour is that the installer starts, it extracts the files in a temp location, starts the setup then nothing appears on screen.
So far, I gathered that it is impossible to do it. But the same behaviour I 've seen for SQL Server 2000 (don't ask) but there I was able to use msetup.exe (DemoShield) to open a sqlservr.dbd that started the script. However, there is no such dbd file. I guess I was lucky on SQLServer 2000.
So far I've tried compatibility mode, DosBox, replacing the setup file with both Installshield 3 and 5, waiting for hours for the setup to start (sometimes, W8 does that), even comparing files and registries on an XP machine before and after update 2 but this might be a bit too risky to apply on a real machine.
Since Windows 8.1 86 includes Hyper-V for running VMs, most modern hardware supports Hyper-V, and Windows 8 x86 can still run 16-bit based apps:
Install a Windows 8.1 x86 VM under your host physical machine, then install it there.
The up-tick: it is easy to move your VM to a new host without needing to reinstall a full new VM.
See http://www.techrepublic.com/blog/windows-and-office/get-started-with-windows-8-client-hyper-v-the-right-way/7893/ and http://www.infoworld.com/d/virtualization/5-excellent-uses-of-windows-8-hyper-v-208436 to get started with Hyper-V.
Hyper-V can redirect quite a bit of hardware from the host to the VM nowadays. For "old" hardware like COM and LPT ports you often can buy USB adapters that can be redirected.
If installing on x86 Windows 8.1 works and x64 fails, I think you have proved the assumption that the 16-bit portion of the installer is the culprit.
Maybe my blog post from last year can solve your problem:
http://blog.dummzeuch.de/2013/11/11/delphi-6-on-windows-8-1/
excerpt:
I just deleted the registry entry
HKCU\Software\Borland\Delphi\6.0\LM
(I did not make a backup, what would have been the point?)
I started Delphi 6, ignored the warning about incompatibilities (which was talking about Delphi 7 anyway) and went through the registration/activation process again. This time it worked.
Maybe I should mention, that I did not install any of my Delphi versions to c:\program files but put them into c:\Delphi instead to avoid any problems with access rights to the installation directory.