crc
crc copied to clipboard
crc-org
Confusing error message when segment identification hash is malformed (telemetry)
General information
- OS: Windows 10.0.19044.3930
- Hypervisor: Hyper-V
- Did you run
crc setupbefore starting it (Yes/No)? Yes - Running CRC on: Laptop
CRC version
CRC version: 2.28.0+e1f42d OpenShift version: 4.13.14 Podman version: 4.4.4
CRC status
Machine does not exist. Use 'crc start' to create it
CRC config
- consent-telemetry : no
- cpus : 8
- disk-size : 120
- ingress-http-port : 8088
- memory : 20480
Host Operating System
OS Name: Microsoft Windows 10 Enterprise
OS Version: 10.0.19044 N/A Build 19044
OS Manufacturer: Microsoft Corporation
OS Configuration: Member Workstation
OS Build Type: Multiprocessor Free
Registered Owner:
Registered Organization:
Product ID: 00329-00000-00003-AA941
Original Install Date: 2/8/2023, 9:19:47 AM
System Boot Time: 2/6/2024, 11:47:28 AM
System Manufacturer: HP
System Model: HP ZBook Fury 15.6 inch G8 Mobile Workstation PC
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: Intel64 Family 6 Model 141 Stepping 1 GenuineIntel ~2496 Mhz
BIOS Version: HP T95 Ver. 01.15.00, 10/11/2023
Windows Directory: C:\Windows
System Directory: C:\Windows\system32
Boot Device: \Device\HarddiskVolume2
System Locale: en-us;English (United States)
Input Locale: en-us;English (United States)
Time Zone: (UTC-05:00) Eastern Time (US & Canada)
Total Physical Memory: 65,200 MB
Available Physical Memory: 51,764 MB
Virtual Memory: Max Size: 74,928 MB
Virtual Memory: Available: 60,113 MB
Virtual Memory: In Use: 14,815 MB
Page File Location(s): C:\pagefile.sys
Logon Server: N/A
Hotfix(s): 18 Hotfix(s) Installed.
[01]: KB5033909
[02]: KB5003791
[03]: KB5012170
[04]: KB5019180
[05]: KB5034122
[06]: KB5020372
[07]: KB5022924
[08]: KB5023794
[09]: KB5025315
[10]: KB5026879
[11]: KB5028318
[12]: KB5028380
[13]: KB5029709
[14]: KB5031539
[15]: KB5032392
[16]: KB5032907
[17]: KB5005699
[18]: KB5034441
Network Card(s): 8 NIC(s) Installed.
[01]: Intel(R) Ethernet Connection (14) I219-LM
Connection Name: Ethernet
Status: Media disconnected
[02]: Intel(R) Wi-Fi 6 AX201 160MHz
Connection Name: Wi-Fi
DHCP Enabled: Yes
DHCP Server: 192.168.68.1
IP address(es)
[01]: 192.168.68.111
[03]: Bluetooth Device (Personal Area Network)
Connection Name: Bluetooth Network Connection
Status: Media disconnected
[04]: Cisco AnyConnect Virtual Miniport Adapter for Windows x64
Connection Name: Ethernet 2
Status: Hardware not present
[05]: VirtualBox Host-Only Ethernet Adapter
Connection Name: Ethernet 3
DHCP Enabled: No
IP address(es)
[01]: 192.168.56.1
[06]: VirtualBox Host-Only Ethernet Adapter
Connection Name: Ethernet 4
DHCP Enabled: No
IP address(es)
[01]: 169.254.35.205
[07]: Hyper-V Virtual Ethernet Adapter
Connection Name: vEthernet (Default Switch)
DHCP Enabled: No
IP address(es)
[01]: 172.29.224.1
[08]: Hyper-V Virtual Ethernet Adapter
Connection Name: vEthernet (Internal)
DHCP Enabled: No
IP address(es)
[01]: 192.168.99.1
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
Steps to reproduce
1. Install crc, run crc on non-administrator shell
2. Run "crc startup --log-level debug"
time="2024-02-07T12:15:19-05:00" level=fatal msg="Got 0 bytes hash, expected 8"
3. Run "crc status --log-level debug"
time="2024-02-07T12:16:13-05:00" level=fatal msg="Got 0 bytes hash, expected 8"
Expected
crc should run on non-administrative shell.
Actual
crc failed to run. The error message doesn't reveal exactly what blocked crc from running.
Logs
Before gather the logs try following if that fix your issue all crc commands running on non-administrator shell have one line log: time="2024-02-07T12:16:13-05:00" level=fatal msg="Got 0 bytes hash, expected 8"
Please consider posting the output of crc start --log-level debug on http://gist.github.com/ and post the link in the issue.
Did you use crc on this machine before or is it a fresh install of crc?
This error comes from the segment package, could you please share the content of the ~\.crc directory:
PS> ls -a ~\.crc
inside ~\.crc there should be a file called segmentIdentifyHash which is reported as empty in the error, removing that would probably fix your issue
level=fatal msg="Got 0 bytes hash, expected 8"
@anjannath telemetry should never be a fatal situation. can we reproduce this?
os/windows
Why is this marked as Windows? I believe this isue would also occur on macOS in this form, right? Let's see if this can be reproduced
it is reproducible if the file ~/.crc/segmentIdentifyHash is edited and its content is removed by hand, but i don't know how it could be empty without modifying it manually
the fatal error comes from: https://github.com/crc-org/crc/blob/76e7517be00536b3d7f6b6dfc1f004d8f4ba6dc9/cmd/crc/cmd/root.go#L62-L65
Why is this marked as Windows? I believe this isue would also occur on macOS in this form, right? Let's see if this can be reproduced
right it will occur in all platforms, thanks for correcting the label
This might be a nice issue for a newcomer to the team. The workaround for now would be to remove the file, right?
This might be a nice issue for a newcomer to the team. The workaround for now would be to remove the file, right?
yes, i tested removing the file after getting the error and it created a correct file, so removing it fixes the issue
We will schedule to work on this issue later. Most likely second half of Sprint 253 (from the 1st of March).
Note: assigned myself to make sure the newcomer will be able to work on this.
- crc was installed and running fine on un-admin user before
- a security update was adminitered on my machine (which could have corrupted ~/.crc/segmentIdentifyHash)
- after that running any "crc" command will trigger the error message
- after the removal of ~/.crc/segmentIdentifyHash crc is runnable once again.
What should the app behavior be in the case the hash file is malformed? It should obviously continue running, but I’m not sure what to do with the telemetry collection.
If the hash file can't be parsed, I'd just delete it and make sure it gets regenerated with a proper hash when the telemetry code runs.
Right, an invalid hash should be discarded and have it generate a new one.
Note: under no circumstance should the execution (success) of the command be prevented by a failure in telemetry.
Note: under no circumstance should the execution (success) of the command be prevented by a failure in telemetry.
Regarding this, I propose implementing a "mock" segment client that will be returned if the initialization of the real segment client fails. This way, the execution of the command is not interrupted by any error in telemetry. If this happens, the mock client will return a warning stating that telemetry will not be available in current session and its methods will do nothing.
I propose implementing a "mock" segment client that will be returned if the initialization of the real segment client fails.
Could you create a follow-up issue to address/work on this? It feels out of scope of this issue, but a valuable improvement.
Regarding this, I propose implementing a "mock" segment client that will be returned if the initialization of the real segment client fails.
Can be a separate "NoopClient" which is returned when there is an error, or can be the real client which has an "error" state where most ops become noop. Your suggestion would probably give clearer code. But I agree with Gerard that this can be a followup.