Open ahmadsyahidr opened 1 year ago
Time Zone: (UTC+07:00) Bangkok, Hanoi, Jakarta
I have tried this on my machine
Time Zone: (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi
but it does not look like a timezone issue
Time Zone: (UTC+07:00) Bangkok, Hanoi, Jakarta
I have tried this on my machine
Time Zone: (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi
but it does not look like a timezone issue
Is it OK in your Environment ? I also have golang, android studio, and docker desktop+k8s in my computer.
Just tested on windows 11 pro fresh environment
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22621 N/A Build 22621
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
Got a cluster running for 30 mins without any issue
CRC VM: Running
OpenShift: Running (v4.12.13)
RAM Usage: 6.517GB of 9.397GB
Disk Usage: 16.65GB of 32.74GB (Inside the CRC VM)
Cache Usage: 19.71GB
Cache Directory: C:\Users\rhqp\.crc\cache
maybe entries in your kube config that cause a conflict?
maybe entries in your kube config that cause a conflict?
I've tried to clean up everything inside .kube folder before installation, but the same error still appear.
The .kube folder should be in C:/Users/myuser/.kube right ?
@mii-syahid make sure you didn't have KUBECONFIG
env set or if it set then don't have expired entry for crc.testing
domain. As per logs cluster started and running successful.
@mii-syahid make sure you didn't have
KUBECONFIG
env set or if it set then don't have expired entry forcrc.testing
domain. As per logs cluster started and running successful.
Sorry, I've check on the environment variables lists, there is no kubeconfig or anything like that. The weird thing is, the certificate information looks like owned by VMware:
Common Name: VMware Subject Alternative Names: Organization: Organization Unit: VMware Locality: Palo Alto State: Country: US Valid From: August 22, 2021 Valid To: August 22, 2022 Key Size: 2048 bit Serial Number: f0257a4ae83597d4
@mii-syahid make sure you didn't have
KUBECONFIG
env set or if it set then don't have expired entry forcrc.testing
domain. As per logs cluster started and running successful.Sorry, I've check on the environment variables lists, there is no kubeconfig or anything like that. The weird thing is, the certificate information looks like owned by VMware:
Common Name: VMware Subject Alternative Names: Organization: Organization Unit: VMware Locality: Palo Alto State: Country: US Valid From: August 22, 2021 Valid To: August 22, 2022 Key Size: 2048 bit Serial Number: f0257a4ae83597d4
Is it because I've installed crc on my VMware Workstation in my Laptop a long time ago ? VMware app was still there, only I can't open any vm because Hyper-v is up.
@mii-syahid make sure you didn't have
KUBECONFIG
env set or if it set then don't have expired entry forcrc.testing
domain. As per logs cluster started and running successful.
I've also check on C:\Users\ahmad.crc\cache\crc_hyperv_4.12.13_amd64\kubeconfig All certificate in there is good, nothing expired. I also add this path C:\Users\ahmad.crc\bin\oc in environment variable, to ensure I use the correct oc client.
oc version Client Version: 4.12.13 Kustomize Version: v4.5.7
Can you explain which certificate are this crc-start error are referring to ?
The weird thing is, the certificate information looks like owned by VMware:
Where did you get this certificate information from? Not clear why crc would end up trying to use this certificate/CA.
The weird thing is, the certificate information looks like owned by VMware:
Where did you get this certificate information from? Not clear why crc would end up trying to use this certificate/CA.
I got that information from web browser, accessing this console --> https://console-openshift-console.apps-crc.testing/
Can you check what IP address https://console-openshift-console.apps-crc.testing resolves to? Just to be sure, you are not using nested virtualization? (Windows running in a VMWare virtual machine, and crc installation happening inside this Windows VM).
Can you check what IP address https://console-openshift-console.apps-crc.testing resolves to? Just to be sure, you are not using nested virtualization? (Windows running in a VMWare virtual machine, and crc installation happening inside this Windows VM).
Sure, it was 127.0.0.1.
ping console-openshift-console.apps-crc.testing
Pinging api.crc.testing [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
I'm sure it wasn't nested virtualization, I installed crc on my windows, and We can see a new virtual machine named by crc exists in hyper-v manager.
@ahmadsyahidr Can you try latest version of crc and see if that fix the issue?
@praveenkumar Sure, but I can only try it next week. I will update the result here.
@ahmadsyahidr did you get chance to try out latest version?
@ahmadsyahidr Did you ever resolve this? I'm facing the exactly same issue...
What crc version are you using?
I resolved the issue for me. I also have VMware installed on my machine. The expired certificate is located at C:\ProgramData\VMware\SSL
. It is used by the VMware Workstation Server
Windows service. Stopping this service allowed the crc start
to complete successfully. As I don't actively use VMware right now, this solution is good enough. I'm using crc version 2.34.1
(currently the latest one).
General information
crc setup
before starting it ? YesCRC version
CRC status
CRC config
Host Operating System
Steps to reproduce
Expected
Actual
Logs
https://gist.github.com/mii-syahid/986020794eab92c050c82dbae3d55848
Before gather the logs try following if that fix your issue
Already tried, they aren't solving the issue. Please consider posting the output of
crc start --log-level debug
on http://gist.github.com/ and post the link in the issue.