I have been able to flash 2 SD’s using BalenaEtcher and both Devices show up without issues in my dashboard. They are using 8GB SD cards.
I’m currently having issues after burning balenaOS 2.67.3+rev4 on a 16GB SD.
The device boots and shows up in the Dashboard as expected. So far so good.
When the application starts to download, I see lots of messages saying “no space left on device”.
When I look at the storage icon on top of the dashboard, it shows as 169MB available.
You’ve tried 2 16GB SD cards and you get the same issue: only 169MB available on the data partition ?
Are both SD cards the same ?
You don’t get this issue with 8GB SD cards ?
Are you using the production or the development variant of balenaOS ?
I indeed used two different SD cards, both same brand however. Patriot LX Series - 16 GB.
The 8 GB cards don’t throw this issue indeed. I’m currently using the production version but if you would like me to flash the card with the dev variant, just let me know.
I couldn’t reproduce this issue with a 32GB sd card I have.
My best guess is that your SD cards have an issue.
Could you please test them with something like H2testw ?
H2testw finished on the SD that you were troubleshooting on earlier:
Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 10.9 MByte/s
Reading speed: 21.4 MByte/s
H2testw v1.4
Burning an img I created from the 8GB flash drive booted as well and showed 6+ GB free disk space. (which makes sense as it was an 8 GB img)
I have flashed the SD card with Balena OS again and booted up the Pi.
The new balena device (it has only booted for the first time a few minutes ago) is online.
Support access already granted: UUID: 9eb6dafee2c0e443f2713c8120fe525a
There are still issues reported in dmesg with the 3rd partition:
EXT4-fs (mmcblk0p3): ext4_check_descriptors: Checksum for group 0 failed (23034!=37961)
EXT4-fs (mmcblk0p3): group descriptors corrupted!
The partition table is messed up:
root@9eb6daf:~# fdisk -l /dev/mmcblk0
Ignoring extra data in partition table 5.
Ignoring extra data in partition table 5.
Ignoring extra data in partition table 5.
Invalid flag 0x40ab of EBR (for partition 5) will be corrected by w(rite).
Disk /dev/mmcblk0: 14.57 GiB, 15634268160 bytes, 30535680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf4c2bd43
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 8192 90111 81920 40M c W95 FAT32 (LBA)
/dev/mmcblk0p2 90112 729087 638976 312M 83 Linux
/dev/mmcblk0p3 729088 1368063 638976 312M 83 Linux
/dev/mmcblk0p4 1368064 1826815 458752 224M f W95 Ext'd (LBA)
/dev/mmcblk0p5 2456165196 2991062657 534897462 255.1G 6a unknown
Could you try using another power-supply ? Some SD cards can behave poorly with unstable voltages.
Or could you retry cloning the 8GB image on this SD and booting it ? Check in dmesg if you see any storage issue.
I have tried swithing the power supply, but that didn’t change a thing unfortunately.
In an attempt to exclude Windows from being the evil in all of this, I have staged a laptop with ubuntu on it (latest release).
I have burnt the image with the most recent version of etcher → validation error at around 70%.
Then I used Ubuntu’s builtin disk15GB was unpartioned, while on a working SD, it was completely used. I have expanded the extended partion 4 with the remaining 15 GB and expanded the resin-data partion (partition 6) to the maximum available. That gave me 169MB available again so no luck there.
Next I tried the same, but expanding both partitions with 8GB instead of the remaining disk space. After booting, the device shows up in the dashboard with 6.2 GB free but is still unable to download the images.
I have booted a device with the 8GB image burned on a 16GB SD card. That device is showing up as online but “VPN only”.
If you would like to check something, feel free to do so.
Support access has been granted: UUID: 4e016bc82eb4a6d99522933e23fd3207
Glad to hear it is working better for you now Luc. As you have now experienced, SD Cards are not always the most reliable, I have had similar situations with devices behaving oddly due to bad blocks on cards as well.