Crc: Corrupt bundles are not overwritten by `crc setup`

[ajaysimha]

General information

• OS: Linux (Fedora 30)
• Hypervisor: KVM
• Did you run crc setup before starting it (Yes/No)? Yes

CRC version

# [asimha@asimha-fedora crc-linux-1.0.0-rc.0-amd64]$ crc version
version: 1.0.0-rc.0+34371d3
OpenShift version: 4.2.0-0.nightly-2019-09-26-192831 (embedded in binary)

CRC status

# Put `crc status` output here

CRC config

# Put `crc config view` output here

Host Operating System

# Put the output of `cat /etc/os-release` in case of Linux
# put the output of `sw_vers` in case of Mac
# Put the output of `systeminfo` in case of Windows

[asimha@asimha-fedora Downloads]$ cat /etc/redhat-release
Fedora release 30 (Thirty)

Steps to reproduce

1. Download CRC and pull-secret.txt
2. run crc setup
3. run crc start
4.

Expected

complete without errors

Actual

[asimha@asimha-fedora crc-linux-1.0.0-rc.0-amd64]$ ./crc start -p ~/Downloads/pull-secret.txt
INFO Checking if running as non-root
INFO Checking if oc binary is cached
INFO Checking if Virtualization is enabled
INFO Checking if KVM is enabled
INFO Checking if libvirt is installed
INFO Checking if user is part of libvirt group
INFO Checking if libvirt is enabled
INFO Checking if libvirt daemon is running
INFO Checking if a supported libvirt version is installed
INFO Checking if crc-driver-libvirt is installed
INFO Checking if libvirt 'crc' network is available
INFO Checking if libvirt 'crc' network is active
INFO Checking if NetworkManager is installed
INFO Checking if NetworkManager service is running
INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists
INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists
INFO Extracting bundle: crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle ...
ERRO Error occurred: Error getting bundle metadata: xz: data is truncated or corrupt

Logs

You can start crc with crc start --log-level debug to collect logs.
Please consider posting this on http://gist.github.com/ and post the link in the issue.
https://gist.github.com/ajaysimha/2dcbe27465e5e1c3d137e7be7fea80c7

[ajaysimha]

BTW I did sha256sum on my download:
[asimha@asimha-fedora Downloads]$ sha256sum -b ./crc-linux-amd64.tar.xz
4c75bb69e536bbc1238933c8fea909a5270202c48c55c1e9ce1bee4d943c18e2 *./crc-linux-amd64.tar.xz

It matches https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/sha256sum.txt:
4c75bb69e536bbc1238933c8fea909a5270202c48c55c1e9ce1bee4d943c18e2 crc-linux-amd64.tar.xz

[gbraad]

How much memory in your computer?

[gbraad]

awkward issue, seems to be an incomplete slicing from the binary, and this causes the archive to be incomplete perhaps (and therefore corrupt)

We first slice the bundle from the binary, after which this archive is unpacked to the cache. Maybe a disk space or storage allocation issue?

[ajaysimha]

Hi,

I did "file crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle" and it showed me zero bytes.
After this, i did "rm -rf .crc"
Cleaned up
Ran "crc setup" again
After that it runs fine.

I don't know if you want to to pursue this any further or close the bug?

Thank you for your support!

Ajay

[gbraad]

we check for the existence of the bundle in the ~/.crc folder, but assume
this is a valid unpacked bundle. I was able to reproduce this behaviour.
You can also solve this by just removing the .crcbundle from there.

On Mon, Oct 21, 2019 at 5:24 PM Ajay Simha [e-mail] wrote:

Hi,

I did "file crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle" and
it showed me zero bytes.
After this, i did "rm -rf .crc"
Cleaned up
Ran "crc setup" again
After that it runs fine.

I don't know if you want to to pursue this any further or close the bug?

Thank you for your support!

Ajay

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/code-ready/crc/issues/747?email_source=notifications&email_token=AAAAOZQ3ZJWZEFFCSWPMVYDQPVYLVA5CNFSM4JCQZZ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBZVH2A#issuecomment-544429032,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAOZVYL3ORE5Q7OSJWWMTQPVYLVANCNFSM4JCQZZ5Q
.

--

Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]

[ajaysimha]

May be this was a freak situation. However, I think If I downloaded new/fresh download I should have not seen this. I'd counter that 'crc setup' should wipe out .crc dir and start over. I'm closing this bug for now.

[ajaysimha]

Closing this bug as it is not longer an issue. If some does run into this issue, do a 'rm -rf .crc' and thn run 'crc setup' it resolved the issue for me.

[cfergeau]

However, I think If I downloaded new/fresh download I should have not seen this. I'd counter that 'crc setup' should wipe out .crc dir and start over. I'm closing this bug for now.

crc should be robust against that situation, we should keep this open to track it.

[ajaysimha]

I agree. For a newbee like me. I have no idea. On a slow link I downloaded the package 3 times waiting all night. Better to take care of this during install and avoid unnecessary traffic from newbees

[gbraad]

The bundle code needs to be inspected, as to make space I also removed the bundle, but keeping the unpacked version. Due to this is started to complain (placed the file back) but is unused. We might need to record some of the edge cases here and resolve them. In the case described, we might need to check a checksum and decide if the file is OK... but only in the case when an extraction is really neeed (to avoid taking a penalty to check this).

[cfergeau]

We could also stop having separate steps between extracting bundle from the binary and uncompressing it, and do both as one step. So we would only be doing all of this when we don't have the directory we expect, and we would not need the intermediate bundle copy.

[cfergeau]

This branch https://github.com/cfergeau/crc/commits/embed has some changes which would help with that.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gbraad]

We added partial checksum and size checks...

... I'd rather create a new issue of a regression occurs.