Could not get the storage format of the medium 'boot2docker.iso' (VERR_NOT_SUPPORTED)

[omidpypi]

minikube start

😄 minikube v1.3.0 on Ubuntu 18.04 🔥 Creating virtualbox VM (CPUs=2, Memory=2000MB, Disk=20000MB) ... E0806 16:29:54.928064 11890 start.go:723] StartHost: create: creating: /usr/bin/VBoxManage storageattach minikube --storagectl SATA --port 0 --device 0 --type dvddrive --medium /home/behpand/.minikube/machines/minikube/boot2docker.iso failed: VBoxManage: error: Could not get the storage format of the medium '/home/behpand/.minikube/machines/minikube/boot2docker.iso' (VERR_NOT_SUPPORTED) VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component MediumWrap, interface IMedium, callee nsISupports VBoxManage: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 179 of file VBoxManageDisk.cpp VBoxManage: error: Invalid UUID or filename "/home/behpand/.minikube/machines/minikube/boot2docker.iso"

💣 Unable to start VM: create: creating: /usr/bin/VBoxManage storageattach minikube --storagectl SATA --port 0 --device 0 --type dvddrive --medium /home/behpand/.minikube/machines/minikube/boot2docker.iso failed:
VBoxManage: error: Could not get the storage format of the medium '/home/behpand/.minikube/machines/minikube/boot2docker.iso' (VERR_NOT_SUPPORTED)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component MediumWrap, interface IMedium, callee nsISupports
VBoxManage: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 179 of file VBoxManageDisk.cpp
VBoxManage: error: Invalid UUID or filename "/home/behpand/.minikube/machines/minikube/boot2docker.iso"

😿 Sorry that minikube crashed. If this was unexpected, we would love to hear from you:
👉 https://github.com/kubernetes/minikube/issues/new/choose

os: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic

[afbjorklund]

Looks like the boot2docker.iso file got truncated or corrupted ? Try replacing it with a fresh copy...

home/behpand/.minikube/machines/minikube/boot2docker.iso

There should be one in the cache folder, or download a new one from the github release page.

[tstromberg]

Agreed. Do you mind sharing the result of:

• ls -la /home/behpand/.minikube/machines/minikube/boot2docker.iso
• sha256sum /home/behpand/.minikube/machines/minikube/boot2docker.iso

This is likely solvable by running minikube delete

[afbjorklund]

Apparently one major difference with go-getter (vs go-download) is that it does not use temp files...

So if you have a partial aborted download, you will be stuck with it "forever". And no checksums left.

This is a design flaw (or two) in the library, but also in our use of it.

The checksum file will be downloaded in a temporary file then parsed.

Once go-getter is done with the checksum file; it is deleted.

i.e. it is never used the second time, and minikube only checks existance.

[tstromberg]

Ouch. That's a really bad regression and such a terrible default that I didn't believe you at first, but it's true:

193082 newfstatat(AT_FDCWD, "/usr/local/google/home/tstromberg/.minikube/cache/iso/minikube-v1.3.0.iso", 0xc0004ac108, 0) = -1 ENOENT (No such file or directory)
193082 openat(AT_FDCWD, "/tmp/minikube-v1.3.0.iso.sha256357829075", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600 <unfinished ...>
193082 openat(AT_FDCWD, "/tmp/minikube-v1.3.0.iso.sha256357829075", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 7
193089 write(1, "\r    minikube-v1.3.0.iso.sha256:"..., 80) = 80
193089 write(1, "\33[1A\r    minikube-v1.3.0.iso.sha"..., 84) = 84
193089 openat(AT_FDCWD, "/tmp/minikube-v1.3.0.iso.sha256357829075", O_RDONLY|O_CLOEXEC <unfinished ...>
193089 unlinkat(AT_FDCWD, "/tmp/minikube-v1.3.0.iso.sha256357829075", 0 <unfinished ...>
193089 openat(AT_FDCWD, "/usr/local/google/home/tstromberg/.minikube/cache/iso/minikube-v1.3.0.iso", O_RDONLY|O_CLOEXEC <unfinished ...>
193089 openat(AT_FDCWD, "/usr/local/google/home/tstromberg/.minikube/cache/iso/minikube-v1.3.0.iso", O_RDWR|O_CREAT|O_CLOEXEC, 0666 <unfinished ...>
193091 write(1, "\r    minikube-v1.3.0.iso: 19.55 "..., 80 <unfinished ...>
193091 write(1, "\33[1A\r    minikube-v1.3.0.iso: 40"..., 84) = 84
193091 write(1, "\33[1A\r    minikube-v1.3.0.iso: 62"..., 84 <unfinished ...>
193088 write(1, "\33[1A\r    minikube-v1.3.0.iso: 84"..., 84 <unfinished ...>
193088 write(1, "\33[1A\r    minikube-v1.3.0.iso: 10"..., 84) = 84
193088 write(1, "\33[1A\r    minikube-v1.3.0.iso: 12"..., 84 <unfinished ...>
193094 write(1, "\33[1A\r    minikube-v1.3.0.iso: 13"..., 84 <unfinished ...>
193094 openat(AT_FDCWD, "/usr/local/google/home/tstromberg/.minikube/cache/iso/minikube-v1.3.0.iso", O_RDONLY|O_CLOEXEC <unfinished ...>
193108 openat(AT_FDCWD, "/usr/local/google/home/tstromberg/.minikube/cache/iso/minikube-v1.3.0.iso", O_RDONLY|O_CLOEXEC <unfinished ...>

[tstromberg]

Apparently, this is partially our fault: our code asserts that if the file exists, it must be valid. When we remove this shortcut, go-getter always checks the checksum of the file. Not exactly optimal though, as it always refetches the checksum file.

[afbjorklund]

Thanks for fixing, should be OK to only check the checksum once - when downloading to a temp file.

[aparsons]

For me, deleting the ~/.minikube directory fixed this.

[tstromberg]

If you run into this, I highly recommended:

1. Run minikube delete
2. Run rm -Rf ~/.minikube/cache/iso (or the Windows equivalent)
3. Upgrade to minikube v1.3.1 - which fixes the download issue

@aparsons - Deleting the entire minikube directory is not recommended, particularly if you have not deleted all the VM's referenced by the existing configuration, as it will leave dangling VM state within your hypervisor.