I downloaded the Rock64 image and wrote it to an SD card. Windows only sees an unformatted disk. Disk Management shows the disk as 16MB Unallocated and 420MB Healthy (Primary Partition) (and the rest of the card unallocated).
I tried writing the image with both balenaEtcher and Win32DIskIMager with the same result. I downloaded the image again and got the same result.
If I tried exactly the same procedure with a DietPi image for a different system, e.g. the Raspberry Pi image then it works with no problems; the FAT boot partition pops up straight away after completion of writing the image to the card.
Am I doing something wrong? Is the Rock64 image somehow different or does it require a different procedure? Is there an older version of the Rock64 image I could try anywhere?
Any help would be most gratefully received.
jebworth
This is expected on Windows. Linux systems usually run on the ext4 file system, but Windows can’t read this and shows it as unformatted. Don’t ask why, ext4 code is an was always open source so if wanted, could have been implemented easily since years.
Yes, you’re right that Windows can’t see the ext4 partition. But shouldn’t there also be a fat partition that Windows can read and that the device actually boots from? This partition is where all the installation configuration settings can be made and so on, as per https://dietpi.com/forum/t/getting-started-download-dietpi-image/24/1 As in my previous post, some images have this partition, such as the DietPi Raspberry Pi image and the DietPi Odroid C2 image. The Rock64 image does not seem to have the fat partition at all.
If I look at Disk Manager on Windows for the Odroid C2 DietPi image, which I can access the boot fat partition of, I see:
If I look at DIsk Manager on Windows for the Rock64 DietPi image, where I cannot access the boot fat partition, I see:
So, it is as if the boot partition is not there on the Rock64. I’m not sure if this is by design or there is something I don’t understand. I tried booting the Rock64 with the image but it did not work.
Ah sorry I was not reading carefully enough 
.
Hmm, AFAIK the Rock64 image has EFI boot partitions, and I remember in some cases it was not possible to format those as FAT, but not 100% sure. But as well the new image is based on ARMbian where things have changed.
Strange that the image does not boot. It was created just a week ago and definitely tested by some users.
Also I can open the .img file with 7zip and browse all files of root and boot.
Actually it looks like now everything is on a single partition, which would match your disk manager view.
When you attach a HDMI to the Rock64, can you see some boot log and where it hangs/crashes in case?
Ah, that makes sense that there might not be a fat partition by intention. I assumed based on my very limited knowledge that all these images always had a fat partition that was used to boot.
I was hung up on that and I’ve just tried booting the image again and this time it worked! So, that’s the main thing. I think I assumed there must be a fat partition from following the getting started guide about editing the dietpi.txt setup file. If there is no fat partition is it not possible to edit this configuration file on Windows for devices like the Rock64, or is there some other way to do it? It’s not essential as at least I can boot into it and set it up that way now.
Great that it booted now.
Yeah, I remember there being no FAT boot partition in some cases and yes that makes it impossible to safely edit dietpi.txt for first run setup. There are some Windows drivers for ext4 (read the Wikipedia article linked above), but the free solutions I tried worked very unreliable, causing errors, so nothing I would recommend… Never tried the commercial solution…
However, if you have another Linux machine, you can edit the ext4 partition there. Or on Windows you can install VirtualBox or VMware and run a Linux VM (e.g. DietPi 
). You can mount through the SDcard or USB drive to the VM and edit it there. This is as well handy if some SDcard corruption (file system corruption) needs to be cleaned externally via fsck.
And yeah finally all dietpi.txt changes can be done on the running DietPi system as well after finished first run setup, via dietpi-config mostly.
That all makes sense. Thanks for all your help. 