I am trying to run balenaSound 64-bit on a Rpi3B. The 32 bit version ran fine, but it was a bit slow, so I thought running a 64-bit version may help with that and since there is an option for a 64 bit OS why not give it a try.
I am booting from an SSD via USB3, in case that makes any difference (again the 32-bit version ran just fine).
I am getting the following error message on all of the images that are being downloaded.
failed to download image 'registry2.balena-cloud.com/v2/01ebfcbc4d899f9b47341bb10ff2c6df@sha256:1c47d5499f225b81adcf358086a92bd37fde457c5528df88dcadbbb966271bb0' due to '(HTTP code 404) no such image - no such image: registry2.balena-cloud.com/v2/01ebfcbc4d899f9b47341bb10ff2c6df@sha256:1c47d5499f225b81adcf358086a92bd37fde457c5528df88dcadbbb966271bb0: No such image: registry2.balena-cloud.com/v2/01ebfcbc4d899f9b47341bb10ff2c6df@sha256:1c47d5499f225b81adcf358086a92bd37fde457c5528df88dcadbbb966271bb0 '
I found a post from lucianbuzzo that said to login on to a console and run a few commands. Well I tried that and the first command failed miserably
balena run --privileged --name parted -dit debian
When I run it I get
balena: failed to register layer: Error processing tar file(exit status 1): write /var/lib/dpkg/info/libsystemd0:arm64.shlibs: no space left on device.
Do you have a link to the post that outlines the commands you were trying to run? That command implies it’s a space issue? Can you check with df how much free space you have on your disk?
I cannot find it for the life of me (I’ll have to go through the browser’s history to see if I can find it that way). In any case I surely hope it is not a space issue since I am using a 120GB SSD and I used the same disk for the 32-bit version and it ran fine. But in any case the result of df -h is:
Hi. When you first boot after flashing, balenaOS should expand the /mnt/data partition to fill the disk and this is not happening here. I’ve asked about this internally, but what is probably happening is that this specific setup (USB SSD) is confusing the expander. We’ll update you once we have a better idea of what might be happening here.
In the meantime, please use the 32-bit version. 64-bit applications are larger in terms of disk space and it seems that in this case the difference is big enough to push past the limits of the (unexpanded) /mnt/data.