DietPi don't expand SD-Card on Rock64

[ghost]

Required Information:

• DietPi Version: 6.0
• SBC Device: Rock64
• Power supply used: 5V/2A Offical Rock64 Power Supply
• SD card used: SanDisk Ultra 32 GB
• Distro: Stretch | Linux DietPi 4.4.77-rockchip-ayufan-136 #1 SMP Thu Oct 12 09:14:48 UTC 2017 aarch64 GNU/Linux

Expected behaviour:

DietPi should expand the SD card

Actual behaviour:

DietPi don't expand SD-Card

Error Message:

Available free space on RootFS is low (0 MB). To prevent potential issues due to running out of free space, this script will now be terminated.
Please free up at least 500 MB of free space, then try again.

Bug Report ID: 5bbe22ea-b04e-46b1-a13d-db6473b6f13b-0

[Fourdee]

@canoxnet

Thanks for the report 👍

We'll try to replicate with local testing.

[ghost]

I was able to fix the problem by running resize_rootfs.sh. Nevertheless, the SD card will not be expanded automatically on first startup

[Fourdee]

@canoxnet

Unable to replicate:

root@DietPi:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
...
/dev/mmcblk1p7   15G  336M   14G   3% /

Please provide the resize logs:

cat /var/tmp/dietpi/logs/fs_*

---

Reference, successful logs:

root@DietPi:~# cat /var/tmp/dietpi/logs/fs_*
resize2fs 1.43.4 (31-Jan-2017)
Filesystem at /dev/mmcblk1p7 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk1p7 is now 3856763 (4k) blocks long.


Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help):
Disk /dev/mmcblk1: 14.9 GiB, 15931539456 bytes, 31116288 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: gpt
Disk identifier: 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0

Device          Start     End Sectors  Size Type
/dev/mmcblk1p1     64    8063    8000  3.9M Linux filesystem
/dev/mmcblk1p2   8064    8191     128   64K Linux filesystem
/dev/mmcblk1p3   8192   16383    8192    4M Linux filesystem
/dev/mmcblk1p4  16384   24575    8192    4M Linux filesystem
/dev/mmcblk1p5  24576   32767    8192    4M Linux filesystem
/dev/mmcblk1p6  32768  262143  229376  112M Microsoft basic data
/dev/mmcblk1p7 262144 1368063 1105920  540M Linux filesystem

Command (m for help): Partition number (1-7, default 7):
Partition 7 has been deleted.

Command (m for help): Partition number (7-128, default 7): Partition number (7-128, default 7): First sector (262144-31116254, default 262144): Last sector, +sectors or +size{K,M,G,T,P} (262144-31116254, default 31116254):
Created a new partition 7 of type 'Linux filesystem' and of size 14.7 GiB.

Command (m for help):
Disk /dev/mmcblk1: 14.9 GiB, 15931539456 bytes, 31116288 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: gpt
Disk identifier: 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0

Device          Start      End  Sectors  Size Type
/dev/mmcblk1p1     64     8063     8000  3.9M Linux filesystem
/dev/mmcblk1p2   8064     8191      128   64K Linux filesystem
/dev/mmcblk1p3   8192    16383     8192    4M Linux filesystem
/dev/mmcblk1p4  16384    24575     8192    4M Linux filesystem
/dev/mmcblk1p5  24576    32767     8192    4M Linux filesystem
/dev/mmcblk1p6  32768   262143   229376  112M Microsoft basic data
/dev/mmcblk1p7 262144 31116254 30854111 14.7G Linux filesystem

Command (m for help):
The partition table has been altered.
Calling ioctl() to re-read partition table.

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

[themax75]

I have the same issue on my Pine A64 1GB.

SD Card is 16GB.

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 845M 696M 96M 88% /
devtmpfs 458M 0 458M 0% /dev
tmpfs 491M 0 491M 0% /dev/shm
tmpfs 491M 6.6M 484M 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 491M 0 491M 0% /sys/fs/cgroup
/dev/mmcblk0p1 50M 14M 37M 28% /boot
tmpfs 20M 20K 20M 1% /var/log
tmpfs 491M 4.0K 491M 1% /tmp
tmpfs 10M 1.4M 8.7M 14% /DietPi

cat /var/tmp/dietpi/logs/fs_*

resize2fs 1.43.4 (31-Jan-2017)
The filesystem is already 227840 (4k) blocks long. Nothing to do!

Image used is: DietPi_v6.0_PineA64-ARMv8-Stretch.img

(sorry noob at GitHub, don't know how to do the fancy markup)

[themax75]

Update : I executed resize_rootfs.sh and got :

root@DietPi:~# resize_rootfs.sh

• DEVICE=/dev/mmcblk0
• PART=2
• resize
• fdisk -l /dev/mmcblk0
• grep /dev/mmcblk0p2
• awk {print $2}
• start=143360
• echo 143360
  143360
• set +e
• fdisk /dev/mmcblk0

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 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: 0x990596f6

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 40960 143359 102400 50M 6 FAT16
/dev/mmcblk0p2 143360 1966079 1822720 890M 83 Linux

Command (m for help): Partition number (1,2, default 2):
Partition 2 has been deleted.

Command (m for help): Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): Partition number (2-4, default 2): First sector (2048-31116287, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (143360-31116287, default 31116287):
Created a new partition 2 of type 'Linux' and of size 14.8 GiB.
Partition #2 contains a ext4 signature.

Command (m for help):
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

• set -e
• partx -u /dev/mmcblk0

• resize2fs /dev/mmcblk0p2
  resize2fs 1.43.4 (31-Jan-2017)
  Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
  old_desc_blocks = 1, new_desc_blocks = 1
  The filesystem on /dev/mmcblk0p2 is now 3871616 (4k) blocks long.

• echo Done!
  Done!

[themax75]

Now df -h reads:
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 15G 699M 14G 5% /
devtmpfs 458M 0 458M 0% /dev
tmpfs 491M 0 491M 0% /dev/shm
tmpfs 491M 6.6M 484M 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 491M 0 491M 0% /sys/fs/cgroup
/dev/mmcblk0p1 50M 14M 37M 28% /boot
tmpfs 20M 20K 20M 1% /var/log
tmpfs 491M 4.0K 491M 1% /tmp
tmpfs 10M 1.4M 8.7M 14% /DietPi

[Fourdee]

@themax75

Thanks for the report, please can you paste results of our resize logs:

cat /var/tmp/dietpi/logs/fs_*

[themax75]

When I type that, it only shows :

resize2fs 1.43.4 (31-Jan-2017)
The filesystem is already 227840 (4k) blocks long. Nothing to do!

[Fourdee]

@themax75

Thanks, appears rootFS partition resize failed, i'll try to replicate.

Note to self:

• Service Log (saved to rootFS) causing this to fail?

[Fourdee]

🈯️ Sandisk Ultra 16GB - Rock64:

root@DietPi:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk1p7   15G  336M   14G   3% /

🈯️ Sandisk Ultra 8GB - PineA64:

root@DietPi:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.3G  1.5G  5.6G  21% /

[Fourdee]

As i'am unable to replicate (https://github.com/Fourdee/DietPi/issues/1452#issuecomment-369630342), we'll need serial debugging to identify the issue, from those affected.

If anyone experiences failed RootFS resize/partition, please do the following:

• Write a fresh DietPi image
• Connect Serial console
• Power on
• Wait for the serial console to prompt for login
• Login, and check df -h
• Paste the whole serial console print in a new post on this ticket

[Fourdee]

https://twitter.com/FlyingRich/status/970333749312393216

🈯️ Test with Pine installer:

 ───────────────────────────────────────
 DietPi     | 17:30 | Sun 04/03/18
 ───────────────────────────────────────
 v6.-1       | Rock64 (aarch64)
 ───────────────────────────────────────
 IP eth0    | 192.168.0.33
 ───────────────────────────────────────
[ INFO ] Checking RootFS R/W access. Please wait...
[  OK  ] RootFS R/W access.

[ INFO ] Initializing database, please wait...
^Croot@DietPi:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            460M     0  460M   0% /dev
tmpfs            93M  3.8M   89M   5% /run
/dev/mmcblk1p7   15G  336M   14G   3% /

[elRadix]

same issue as https://github.com/Fourdee/DietPi/issues/1511

[Fourdee]

@elRadix

same issue as #1511 | GPT mismatch

Could be a possible partition issue with the pre-image we use: https://github.com/ayufan-rock64/linux-build/releases/download/0.5.15/stretch-minimal-rock64-0.5.15-136-arm64.img.xz

@elRadix

Does the rootFS resize function with an SD card?

[damufo]

Hello:
Update: flashed by etcher-1.3.1-linux-x86_64
Same problem on rock64 4GB
/dev/mmcblk0p7 466M 453M 0 100% /media/dani/linux-root
/dev/mmcblk0p6 100M 41M 60M 41% /media/dani

/boot

[Fourdee]

Confirmed GPT table corruption. Will try recreating image.

Interesting, running Gparted through the pre-image results in:

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 1142784 sectors, needs to be 31116288 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 31116254, but backup header is at
31116287 and disk size is 1142784 sectors.
The 'e' option on the experts' menu will probably fix this problem

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Identified 5 problems!

------------

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64            8063   3.9 MiB     8300  loader1
   2            8064            8191   64.0 KiB    8300  reserved1
   3            8192           16383   4.0 MiB     8300  reserved2
   4           16384           24575   4.0 MiB     8300  loader2
   5           24576           32767   4.0 MiB     8300  atf
   6           32768          262143   112.0 MiB   0700  boot
   7          262144         1142783   430.0 MiB   8300  root

Command (? for help): w
Caution! Secondary header was placed beyond the disk's limits! Moving the
header, but other problems may occur!

Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Aborting write of new partition table.

[damufo]

Hello:
Update: flashed by etcher-1.3.1-linux-x86_64
on debian stretch

[DmitryMyadzelets]

Having the same error message on the very first start of Rock64 with 16MB SD card.
The image is DietPi_v6.0_Rock64-ARMv8-Stretch.img. After writing with dd to SD:

sdb      8:16   1  14.9G  0 disk 
├─sdb1   8:17   1   3.9M  0 part 
├─sdb2   8:18   1    64K  0 part 
├─sdb3   8:19   1     4M  0 part 
├─sdb4   8:20   1     4M  0 part 
├─sdb5   8:21   1     4M  0 part 
├─sdb6   8:22   1   112M  0 part /media/boot
└─sdb7   8:23   1   540M  0 part /media/linux-root

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb6       100M   41M   60M  41% /media/boot
/dev/sdb7       530M  396M  112M  79% /media/linux-root

On the Rock64, after booting and the failure:
root@DietPi:~$ df -h

Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           393M   11M  383M   3% /run
/dev/mmcblk1p7  466M  454M     0 100% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
tmpfs           2.0G     0  2.0G   0% /tmp
tmpfs            10M  1.4M  8.7M  14% /DietPi
tmpfs            20M   16K   20M   1% /var/log
/dev/mmcblk1p6  100M   41M   60M  41% /boot/efi
/dev/sda1        29G  156M   29G   1% /mnt

root@DietPi:~$ fdisk -l

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mmcblk1: 14.9 GiB, 15931539456 bytes, 31116288 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: gpt
Disk identifier: 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0

Device          Start     End Sectors  Size Type
/dev/mmcblk1p1     64    8063    8000  3.9M Linux filesystem
/dev/mmcblk1p2   8064    8191     128   64K Linux filesystem
/dev/mmcblk1p3   8192   16383    8192    4M Linux filesystem
/dev/mmcblk1p4  16384   24575    8192    4M Linux filesystem
/dev/mmcblk1p5  24576   32767    8192    4M Linux filesystem
/dev/mmcblk1p6  32768  262143  229376  112M Microsoft basic data
/dev/mmcblk1p7 262144 1368063 1105920  540M Linux filesystem

root@DietPi:~$ cat /var/tmp/dietpi/logs/fs_*

resize2fs 1.43.4 (31-Jan-2017)
The filesystem is already 138240 (4k) blocks long.  Nothing to do!


Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): 
Disk /dev/mmcblk1: 14.9 GiB, 15931539456 bytes, 31116288 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: gpt
Disk identifier: 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0

Device          Start     End Sectors  Size Type
/dev/mmcblk1p1     64    8063    8000  3.9M Linux filesystem
/dev/mmcblk1p2   8064    8191     128   64K Linux filesystem
/dev/mmcblk1p3   8192   16383    8192    4M Linux filesystem
/dev/mmcblk1p4  16384   24575    8192    4M Linux filesystem
/dev/mmcblk1p5  24576   32767    8192    4M Linux filesystem
/dev/mmcblk1p6  32768  262143  229376  112M Microsoft basic data
/dev/mmcblk1p7 262144 1368063 1105920  540M Linux filesystem

Command (m for help): Partition number (1-7, default 7): 
Partition 7 has been deleted.

Command (m for help): Partition number (7-128, default 7): Partition number (7-128, default 7): First sector (262144-15523806, default 262144): Last sector, +sectors or +size{K,M,G,T,P} (262144-15523806, default 15523806): 
Created a new partition 7 of type 'Linux filesystem' and of size 7.3 GiB.

Command (m for help): 
Disk /dev/mmcblk1: 14.9 GiB, 15931539456 bytes, 31116288 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: gpt
Disk identifier: 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0

Device          Start      End  Sectors  Size Type
/dev/mmcblk1p1     64     8063     8000  3.9M Linux filesystem
/dev/mmcblk1p2   8064     8191      128   64K Linux filesystem
/dev/mmcblk1p3   8192    16383     8192    4M Linux filesystem
/dev/mmcblk1p4  16384    24575     8192    4M Linux filesystem
/dev/mmcblk1p5  24576    32767     8192    4M Linux filesystem
/dev/mmcblk1p6  32768   262143   229376  112M Microsoft basic data
/dev/mmcblk1p7 262144 15523806 15261663  7.3G Linux filesystem

Command (m for help): 

[lupa18]

Same here with SD card and DietPi_Rock64-ARMv8-Stretch downloaded march 12th

[richardhughes260]

I made a video on the issue https://www.youtube.com/watch?v=T6RCtNDf8Yo&t=1s use gparted on another machine to expand the FS.

[lupa18]

For me, from dietpi bash console, this worked perfect:
resize_rootfs.sh

[woiza]

Same here, resize_rootfs.sh did the job

[Fourdee]

root@DietPi:~$ cat /var/tmp/dietpi/logs/fs_*
/dev/mmcblk1p7 262144 15523806 15261663 7.3G Linux filesystem
Command (m for help):

Looks like everything went through, but possibly it didn't write the final command w. Which doesnt make sense as a new line is added after w.

[1activegeek]

Just dropping in to add that I saw this as well. Rock64 w/ 16GB SanDisk Class 4. Ran the script manually to expand filesystem then was all good to re-launch dietpi-software to setup. I actually just restarted so it kicked in fresh.

[Fourdee]

Hi all,

I've updated our image, slight modification to the resize script. If you have experienced inability of image auto resize, please re-download and try the new image:
https://dietpi.com/downloads/images/DietPi_Rock64-ARMv8-Stretch.7z

Please let us know if this works for you. Many thanks.

[1activegeek]

Is there anything else that was drastically changed in the image? I see it went on a "diet" from 700MB down to 575MB. I hadn't gotten far in my config, so I'm willing to test this new image out and validate the fix, but wanted to make sure there isn't something else missing.

[1activegeek]

So just as an update - I tried running this on a separate SD card. No luck. Still ended up with no expanded space. It gave me the low space notification after trying to do minimal install. Output of df -h:

Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           393M   11M  383M   3% /run
/dev/mmcblk1p7  348M  302M   21M  94% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
tmpfs            20M   16K   20M   1% /var/log
tmpfs            10M  1.5M  8.6M  15% /DietPi
tmpfs           460M     0  460M   0% /tmp
/dev/mmcblk1p6  100M   42M   59M  42% /boot/efi

[Fourdee]

@1activegeek

So just as an update - I tried running this on a separate SD card. No luck. Still ended up with no expanded space. It gave me the low space notification after trying to do minimal install. Output of df -h:

Many thanks for testing this for us. Ok, we'll need to rethink this image and process. Leave it with us for now and we'll re-asses, will report back once we have something for testing.

Thanks again for testing for us. As i'am unable to replicate this issue on our local tests, I really appreciate it 👍

I see it went on a "diet" from 700MB down to 575MB.

Our DietPi image PREP system has been highly optimized since the start of v6.0. We continue to reduce which packages are required to be installed installed, vs installed on demand during installs.

[1activegeek]

No problem. Glad to help. I love the OS itself, and happy its available to run on my Pine64/Rock64 boards. I'll keep a follow on this thread when a potential new fix comes along. I've usually got a spare SD card that I may be able to use for testing/validation.

Hopefully for now, anyone getting stuck on this will google and end up here. The band-aid above works which is the good news. Also love the optimization you mention, that's a fantastic decrease to make this thing even smaller! Keep up the great work!

[Fourdee]

Notes to self:
I believe the issue is due to our current script which resizes the image via loopback, GPT data possibly getting corrupt. Need to research this further. Reason, loopback IO error after running resize script once.

https://superuser.com/questions/1081623/shrink-total-disk-image-uefi-gpt-flashdrive-freespace-at-end

We need to add 34bytes to truncate total for secondary GPT backup

[Fourdee]

Hi all,

I've updated the image, contains the following fixes:

• Truncate breaking GPT table. Fixed during image creation process
• GPT resize script, using modified version of ayufan-rock64 script.

If anyone can help us test this new image, who experienced the resize issue, i'd be grateful.

https://dietpi.com/downloads/images/DietPi_Rock64-ARMv8-Stretch.7z

@1activegeek @richardhughes260 @lupa18

[1activegeek]

Traveling this week, will try to get to it this weekend to test. Thankfully I didn’t move my HASS.io install over to it yet so I can test pretty easily without recourse. 😉

[1activegeek]

Ok, I think this worked! Tested on the 16GB card I was having issue with before. I see promising readout and no errors about lack of space as I just started the base install.

[ INFO ] DietPi-Drive_Manager | Detecting drives, please wait...
[ INFO ] DietPi-Drive_Manager | Detected UUID mount: /dev/mmcblk1p6 > /mnt/6393-85D3
[ INFO ] DietPi-Drive_Manager | Detected UUID mount: /dev/mmcblk1p7 > /
[ INFO ] DietPi-Drive_Manager | autofs4 module not available in kernel, x-systemd.automount has been disabled
[ INFO ] DietPi-Drive_Manager | Processing drive information, please wait...
[ INFO ] DietPi-Drive_Manager | Checking available free space on RootFS, please wait...
[  OK  ] DietPi-Drive_Manager | 13907 MB available, 500 MB required

Nicely done @Fourdee!! Thanks for the hard work on squashing these bugs. 😃

[Fourdee]

@1activegeek

Excellent, many thanks for testing this and confirming now fixed 👍

🥂 Finally we nipped this one in the bud 😄 Will mark as closed and resolved.

[olluz]

this image still doesn't resize my Rock64 with a 16GB SDC

[origamins]

Hi All,
Didn't work for me either SanDisk 16GB SDHC UHS-1, I had to resize on Linux box.
Everything else works fine...

[Fourdee]

@olluz @origamins

Thanks for the reports 👍
We'll verify the image.

Notes:

• 2018-05-08 17:23

[Fourdee]

@olluz @origamins

I was unable to replicate the issue you reported, auto expansion works as intended.

I used the following (latest) image:
https://dietpi.com/downloads/images/DietPi_Rock64-ARMv8-Stretch.7z

With win32diskimager to write.

Please can you retry the above, if problem persists, please let us know and i'll reopen the ticket.

[pfordmedia]

Total noob here, but I'm having the exact same issue using the DietPi version located in the Pine64 installer. Also the newest version v8 is giving me a fatal server error on xserver saying that no screens found. Is this a missing video driver for the Rock64 chipset? Im sorry If I'm not asking the right questions or in the right way.

[Fourdee]

@pfordmedia

Pine64 installer.

Hi, the Pine64 installer is outdated in regards to our image I believe, please write the image using our guide:
https://dietpi.com/phpbb/viewtopic.php?f=8&t=9#p9