Dietpi: Image | ROCK Pi 4

[tenrek]

ADMIN EDIT

Testing image available: https://github.com/MichaIng/DietPi/issues/2445#issuecomment-528088922

Many thanks for @canabino for creating this! 👍 ❤️

---

So, any plans for support / make an DietPi for ROCK Pi 4 ?

Debian Desktop download

Admin edit: Vote for it on FeatHub: https://feathub.com/MichaIng/DietPi/+35

[MichaIng]

@tenrek
Thanks for your request.
Feel free to add it to our FeatHub page to collect votes: https://feathub.com/MichaIng/DietPi

If we get a developer sample or @Fourdee is willing to buy one, we can create one.

Official Debian Stretch desktop image available: https://wiki.radxa.com/Rockpi4/downloads

---

Hmm what I don't like when reading the website:

• They claim 4th gen RPi, but it has nothing to do with "Raspberry Pi" and there are no earlier ROCK Pi versions, AFAIK.
• Their graphics and website style even mimic the ones from Raspberry Pi.
• Board style as well very similar, although this is often the case with model B SBCs.
• So overall I get the impression it is tried to build/benefit from the popularity of the Raspberry Pi by subtly mimic it and giving the impression it would be an upgraded RPi version.
• But after all it's a new "Radxa Lmited" SBC brand from China and we will see how well they maintain the product with up-to-date OS images 🤔.

[Fourdee]

@MichaIng

subtly mimic it and giving the impression it would be an upgraded RPi version.

Yep, although ASUS TB has the same form factor as a RPi 3. However, seems the Chinese companies can go much further to "copy and promote a copy" without their copyright laws lol.

[MichaIng]

@Fourdee
Jep nothing against identical form factor. I am fans of standards, so e.g. SBC cases can fit for many different SBCs. But ROCK Pi goes a bid too far here. Calling it RPi 4 and also v1.3 on top of Raspberry Pi 3B being v1.2. This is not about standards only, at least all is pointing in this direction to use a bid more careful wording 😉.

I guess they do not even break any copyright here, but the aim or result is quite clear.

Positive thing related:

• You can use Raspberry Pi camera and accessories with the ROCK Pi 👍.

[MichaIng]

I was reading a bid the forum: https://forum.radxa.com/c/community

• Feedback from users (many from UK) looks good.
• Currently only sold at AllNet, however many requests for having this on Amazon or other shops to make it easily available in Europe.
• It is still in early stage: Official heatsink in development; video playback needs manual tweaking, 4k doesn't work yet at all; chromium does not work on official Debian image; ...
• Mainline kernel 5.1 integration will be done, so we can expect up-to-date kernels after 5.1 release.
• Currently they are active in development, up-to-date images and support forum. If this stays, we would have a great Chinese manufacturer compared to the experiences with OPi/BPi.

@Fourdee
Perhaps they will send you a developer sample, when asking? 😃

[MichaIng]

PR up to do initial definitions: https://github.com/MichaIng/DietPi/pull/2933
User image incoming for testing and further implementing into DietPi: https://dietpi.com/phpbb/viewtopic.php?p=18445#p18445

[canabino]

@MichaIng
Hi there so, please walk me through creating this image. I have the script you sent.
I have an eMMC module and microSD card. Which one should I use? After I installed the Armbian image with the 5.1 kernel on the RockPi. Should I run the DietPi-PREP? Then what? Take out the eMMC/microSD place it in my windows pc running what OS on a virtual machine? Then run the script?
Thanks

[canabino]

I installed the latest Armbian with the 5.1 kernel and ran the DietPi-PREP script.
It came up with the following errors.

#### Details:
- Date           | Thu  6 Jun 15:39:03 UTC 2019
- Bug report     | N/A
- DietPi version | v6.24.1 (MichaIng/master)
- Img creator    | n/a
- Pre-image      | n/a
- SBC device     | NULL (index=22)
- Kernel version | #5.88 SMP Thu Jun 6 17:19:49 CEST 2019
- Distro         | stretch (index=4)
- Command        | G_AGUP
- Exit code      | 100
- Software title | DietPi-PREP

#### Extra details:
<!-- Please post any extra details that might help solve the issue -->
- ...

#### Additional logs:
Log file contents:
Ign:1 https://apt.armbian.com stretch InRelease
Ign:2 https://cdn-aws.deb.debian.org/debian stretch InRelease
Hit:3 https://cdn-aws.deb.debian.org/debian stretch-updates InRelease
Hit:4 https://cdn-aws.deb.debian.org/debian-security stretch/updates InRelease
Hit:5 https://cdn-aws.deb.debian.org/debian stretch-backports InRelease
Hit:6 https://cdn-aws.deb.debian.org/debian stretch Release
Err:7 https://apt.armbian.com stretch Release
  server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Reading package lists...
E: The repository 'http://apt.armbian.com stretch Release' does no longer have a Release file.

[MichaIng]

@canabino
Please try:

curl -sSL https://apt.armbian.com/armbian.key | apt-get add -
apt update

Ah or is it the HTTPS certificate? In this case:

apt-get install --reinstall ca-certificates
apt update

[canabino]

I changed the repository in /etc/apt/sources.list.d/armbian.list
And it is working now.

[MichaIng]

@canabino
Ah, what was the error with this repo? "https://apt.armbian.com stretch Release" above at least looks like it should.

I am a bid too tired now to write down to go through the DietPi-PREP steps, need to sleep, will check back tomorrow.

Just quick note about above:
Since I just added the ROCK Pi 4 definition into dev branch, you might want to run the script from that branch + install dev DietPi:

cd /tmp
wget https://raw.githubusercontent.com/MichaIng/DietPi/dev/PREP_SYSTEM_FOR_DIETPI.sh
chmod +x PREP_SYSTEM_FOR_DIETPI.sh
./PREP_SYSTEM_FOR_DIETPI.sh

• When it asks for the branch, select "dev". After v6.25 release, when we want to publish this for testing+feedback, we can manually revert to master target.

[canabino]

I changed it from "https://apt.armbian.com to https://mirrors.tuna.tsinghua.edu.cn/armbian following a google search.

I will run the code you sent.
Sleep well and chat tomorrow.

[canabino]

I changed back to https://apt.armbian.com and apt-get update is working fine now. Maybe the server was down at the time.
I ran your script and chose "dev"
I was able to choose ROCKPi 4 from the list. 👍
It first came up with errors.

Log file contents:
Failed to enable unit: File dietpi-firstboot.service: No such file or directory

I ran it again and it was successful. 👍
Let me know what the next step is.

[MichaIng]

@canabino
Found a bug in our new env vars implementation. The chosen Git info was overwritten by master branch. Fixed: https://github.com/MichaIng/DietPi/commit/e3f97a0d40ca01f97e894257bf90621fb2831bbf

Ah you second try seems to have been shortly after I fixed it, great.

Okay, next is to shutdown the system (of course) and plug SDcard or eMMC onto an external system. If you want to spin up a VM, take our VM images 🙂: https://dietpi.com/#download

There:

cd /tmp
wget https://github.com/MichaIng/DietPi/blob/dev/.meta/dietpi-imager
chmod +x dietpi-imager
./dietpi-imager

Hmm, I see now that dd runs as first step. I added this as last step on the minimised partition/file system, but @Fourdee switched this. Ups and downs:

• The current way the disk/SDcard will stay untouched, so one can always redo if something fails.
• Also since the HDD most likely is faster than the SDcard, some steps will be faster.
• But dd takes much longer since it copies the whole SDcard size.

[canabino]

Okay I dowloaded and installed VirtualBox.
Then I downloaded your DietPi_VirtualBox-x86_64-Stretch.ova
It booted up and and I did all the installations for DietPi.
I added the usb device with microSD from the RockPi to the VM.
It shows as /dev/sdb/ when I ran fdisk -l Can I run your script like this?

[MichaIng]

@canabino
Jep, the script asks you which drive to pick.

[canabino]

ok 👍

[canabino]

It came up with errors

[MichaIng]

@canabino
Ah me dumb, sorry wrong download link.
This one: wget https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-imager

It did download the html page when opening the file on GitHub 😉.

[canabino]

It got a new name after I downloaded.

[MichaIng]

@canabino
It was saved to "dietpi-imager.1" since wget does not automatically overwrite files:

mv dietpi-imager.1 dietpi-imager
chmod +x dietpi-imager
./dietpi-imager

[canabino]

ok

[canabino]

I'm in 👍

[canabino]

[MichaIng]

@canabino
Would be nice to have disk size in this menu, at least for me this is always the best indicator to know which drive is which.

[canabino]

You are right it would be nice.

[canabino]

Just a quick mention I loaded the Armbian with the 5.1 kernel on my system using the same script and everything was working fine. NordVPN and Jackett.

[canabino]

Where will it store the image?

[MichaIng]

@canabino
To /root/DietPi_XXXX_XXX.img and /root/DietPi_XXXX_XXX.7z (the archive).

[canabino]

Oh, thanks

[canabino]

It's done.

[MichaIng]

@canabino
You ran out of disk space sadly. This was the initial dd to create a raw image which will be resized then. It should require as much space as the SDcard size, so 15 GiB.

I think we should at least add the option to reduce the file system and partition size on the SDcard first and run dd afterwards, which requires then muuuuch less space 🤔. But if something fails then, once might need to reflash and run DietPi-PREP again 🤔.

[canabino]

Oh should I make the VM's drive bigger?

[canabino]

[MichaIng]

@canabino
Ah of course did not think about that. Before doing so, do:

rm /root/myimage.img
systemctl enable dietpi-fs_partition_resize

This enables the partition resize service for next boot.

[canabino]

[canabino]

I rebooted. But the partition is still 8GB

[canabino]

I adjusted it in the VirtualBox

[canabino]

Now it doesn't want to boot.
Give me a moment to set it up again.

[canabino]

I have adjusted it to 32GB and will start again.

root@DietPi:~# fdisk -l
Disk /dev/sda: 32.2 GiB, 34611757056 bytes, 67601088 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: 0x13ced30f

Device     Boot Start      End  Sectors Size Id Type
/dev/sda1  *     2048 16775167 16773120   8G 83 Linux




Disk /dev/sdb: 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: 0x9df16f21

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1       32768 30805119 30772352 14.7G 83 Linux

[MichaIng]

@canabino
Note that the partition still needs to be extended, hence the systemctl enable dietpi-fs_partition_resize + reboot.

[canabino]

ok

[canabino]

I ran the partition resize code and rebooted.
I started the DietPi-Imager script again but it still ran out of space.

root@DietPi:/tmp# systemctl enable dietpi-fs_partition_resize
Created symlink /etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service → /etc/systemd/system/dietpi-fs_partition_resize.service.
root@DietPi:/tmp# reboot

root@DietPi:/tmp# wget https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-imager
--2019-06-25 01:56:08--  https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-imager
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.4.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.4.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7312 (7.1K) [text/plain]
Saving to: ‘dietpi-imager’

dietpi-imager                       100%[=================================================================>]   7.14K  --.-KB/s    in 0s

2019-06-25 01:56:08 (219 MB/s) - ‘dietpi-imager’ saved [7312/7312]

root@DietPi:/tmp# chmod +x dietpi-imager
root@DietPi:/tmp# ./dietpi-imager
[  OK  ] DietPi-Imager | Root access verified.
[  OK  ] DietPi-Imager | RootFS R/W access verified.
6553194496 bytes (6.6 GB, 6.1 GiB) copied, 1764.03 s, 3.7 MB/s
dd: error writing '/root/myimage.img': No space left on device
1600498+0 records in
1600497+0 records out
6555635712 bytes (6.6 GB, 6.1 GiB) copied, 1764.72 s, 3.7 MB/s
root@DietPi:/tmp#

[MichaIng]

@canabino
Strange, as it stops at the same point, the expansion seems to not have worked:

parted /dev/sdb print
cat /var/tmp/dietpi/logs/fs_partition_resize.log

[canabino]

root@DietPi:~# parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 34.6GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  8589MB  8588MB  primary  ext4         boot

root@DietPi:~# cat /var/tmp/dietpi/logs/fs_partition_resize.log
Removed /etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service.
/var/lib/dietpi/services/fs_partition_resize.sh: line 45: cannot create temp file for here-document: No space left on device
resize2fs 1.43.4 (31-Jan-2017)
The filesystem is already 2096640 (4k) blocks long.  Nothing to do!

I used the DietPi-Drivemanager to resize to maximum.

Now it shows the right size.

root@DietPi:~# parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 34.6GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  34.6GB  34.6GB  primary  ext4         boot

I am running the Imager now.

[MichaIng]

@canabino
Lol was a snake biting its tail. Some part of the resizing script failed because there was no space left 😄. Okay great it worked now.

[canabino]

🐍 🤣
It is almost finished, do you want the archive or the img?
Where should I upload to?

[MichaIng]

@canabino
The archive, please, lets not stress bandwidth more then required 😄.
Sounds funny but misusing the survey/bugreport user to upload to the DietPi server directly is easiest:

curl -T <archive_name>.7z sftp://dietpi-survey:[email protected]/bugreport/

And would be great if you could then flash this image onto the SDcard again to test boot and firstrun setup. I am thinking if it's easier to use dd again from within the VM (backwards) or if I should provide you the link to the online archive, once I put it into an appropriate download directory.

The shared folder function of VirtualBox is actually helpful here to easily transfer files between host and guest, however requires guest extensions etc 😉.

[canabino]

It's asking: Is /root/myimage.img a GPT filesystem?

Yes or cancel?

[MichaIng]

@canabino
Ähhm good question, let me see.

---

Next ToDo: GPT auto detection.

[MichaIng]

@canabino

Disklabel type: dos

No GPT, select "Cancel" => Should be called "No".

[canabino]

ok

[canabino]

[MichaIng]

@canabino
1

[canabino]

DietPi_<device>-<arch>-<distro>___
DietPi_ROCK Pi 4-aarch64-Stretch

Will this be correct?

[MichaIng]

DietPi_ROCKPi4-ARMv8-Stretch

[canabino]

[  OK  ] DietPi-Imager | G_AGI gdisk dosfstools zerofree
e2fsck 1.43.4 (31-Jan-2017)
/dev/loop0p1: recovering journal
Clearing orphaned inode 1822 (uid=0, gid=0, mode=0100644, size=35568)
Clearing orphaned inode 13342 (uid=0, gid=0, mode=0100755, size=704920)
Clearing orphaned inode 34265 (uid=0, gid=0, mode=040755, size=4096)
Clearing orphaned inode 36839 (uid=0, gid=0, mode=0100644, size=758)
Clearing orphaned inode 1856 (uid=0, gid=0, mode=0100644, size=266992)
Clearing orphaned inode 9756 (uid=0, gid=0, mode=0100644, size=1679776)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (3499616, counted=3639092).
Fix<y>?

I think y yes?

[MichaIng]

@canabino
Hmm not good that there are already orphaned inodes and wrong inode count, however "yes" for all questions that occur.

[canabino]

Just OK?

[MichaIng]

@canabino
Jep.

[canabino]

Success!!!!!!

[canabino]

DietPi_ROCKPi4-ARMv8-Stretch.7z Is only 32MB

[MichaIng]

@canabino
Hmm that is strange... What is the size of DietPi_ROCKPi4-ARMv8-Stretch.img: ls -lh /root

[canabino]

Sorry my bad ......
MobaxTerm didn't refresh the window it is 125MB

[MichaIng]

@canabino
Ah okay jep in range if expectations, then

curl -T /root/DietPi_ROCKPi4-ARMv8-Stretch.7z sftp://dietpi-survey:[email protected]/bugreport/

[canabino]

It is uploading. I will load the image on a microSD and test the install later.
I will let you know. I am in an AirBnB at the moment and the Internet is a shared line.
So it will take a while.

[canabino]

My connection to ssh.dietpi.com is slow.

root@DietPi:~# curl -T /root/DietPi_ROCKPi4-ARMv8-Stretch.7z sftp://dietpi-survey:[email protected]/bugreport/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:02:10 --:--:--     0curl: (7) Failed to connect to ssh.dietpi.com port 2

I will keep trying

[canabino]

If I ping the site it gets a fast reply.

But it doesn't want to upload

[MichaIng]

@canabino
Strange, just tested it here successfully, although with a small test file (also from within a VirtualBox VM). Does this work in your case:

> /root/test
curl -T /root/test sftp://dietpi-survey:[email protected]/bugreport/

[canabino]

Still fails

root@DietPi:~# > /root/test
root@DietPi:~# curl -T /root/test sftp://dietpi-survey:[email protected]/bugreport/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:02:10 --:--:--     0curl: (7) Failed to connect to ssh.dietpi.com port 22: Connection timed out

[MichaIng]

@canabino
Very strange. Could you try to disable IPv6?
dietpi-config > Network Options: Adapters > IPv6 > [Off]

[canabino]

Still the same result. It fails

[MichaIng]

@canabino
Veeery strange. You have PuTTY or a similar SSH client available right?
Does it work when you use ssh.dietpi.com as hostname, so that the login mask appears?

[canabino]

I just uploaded the file to my RockPi in the root directory, then ran the upload code.
It is uploading now.
Very strange that it didn't work from the VM.
I'm using MobaXterm a very nice terminal

[canabino]

It shows 12 minutes left.
I have to go out and do a few things, will chat again later

[MichaIng]

@canabino
Okay moved it into testing download dir: https://dietpi.com/downloads/testing/DietPi_ROCKPi4-ARMv8-Stretch.7z

[MichaIng]

@canabino
Looks fantastic 🎉 ❤️, maany thanks for all the effort that became more than expected, I highly appreciate!

Meanwhile I tuned DietPi-Imager a bid to automate some detection steps and show drive sizes as mentioned above: https://github.com/MichaIng/DietPi/commit/37b4212383a73690873bbb9ed7dbb1a93b72d7e5

If you are still in mood, one last test to download this image above and flash it on SDcard freshly to do a quick boot and firstrun setup test. When this works well, please send a dietpi-bugreport + post ID here, so I can have a look on installed packages (kernel/firmware especially) and possible quirks on boot process. I will then share the link + credits to you on opening posts, so we can find some more testers.

And generally:

• If you find any issue or missing feature (from DietPi-Config, GPU acceleration support/Kodi/desktop or such), feel free to report/request and I will check out and try to implement it.

[canabino]

I am definitely in the mood. I enjoy doing this.
The install finished succesfully except for one error during install.

[  OK  ] DietPi-Survey | Setting in /DietPi/dietpi.txt adjusted: SURVEY_OPTED_IN=1
[  OK  ] DietPi-Survey | Connection test: ssh.dietpi.com
[FAILED] DietPi-Survey | Failed to connect to SFTP server. Please try again later. If problems persist, please report this issue to the DietPi team:

I found another mistake. I will have to do it again. There was that error again with https://apt.armbian.com

Err:7 https://apt.armbian.com stretch Release
  server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Reading package lists...
E: The repository 'http://apt.armbian.com stretch Release' does no longer have a Release file.

when running the dietpi-conversion script before I made the image, so I switched to the Chinese mirror
https://mirrors.tuna.tsinghua.edu.cn/armbian/ in /etc/apt/sources.list.d/armbian.list but I could have sworn that I changed it back to https://apt.armbian.com just after the conversion script ran, but it didn't take it.
So during the install, it takes a while when running the apt-update during install when reading from the Chinese mirror.
I don't mind doing it again from scratch. You were able to finetune a few things along the way.
I was wondering if it will be able to add the dietpi-imager option somewhere in the dietpi-launcher menu so people would be able to make an image of their favorite setup. Just a thought.

[canabino]

Could it be the that the one is http and the other is https

[canabino]

https://apt.armbian.com is working now........ 😄 I don't know why it didn't work earlier and yesterday.
I even posted on the armbian forum. But they said nothing is wrong on their side.

[canabino]

I will start over again. I have all the updated instructions.

[canabino]

I ran into a problem running the DietPi-Imager script
It loops and doesn't stop as soon as it starts to do the compression.

e2fsck 1.43.4 (31-Jan-2017)
/dev/loop0p1: recovering journal
Clearing orphaned inode 1822 (uid=0, gid=0, mode=0100644, size=35568)
Clearing orphaned inode 6226 (uid=0, gid=0, mode=040755, size=4096)
Clearing orphaned inode 9801 (uid=0, gid=0, mode=0100755, size=85176)
Clearing orphaned inode 13342 (uid=0, gid=0, mode=0100755, size=704920)
Clearing orphaned inode 34265 (uid=0, gid=0, mode=040755, size=4096)
Clearing orphaned inode 36839 (uid=0, gid=0, mode=0100644, size=758)
Clearing orphaned inode 1856 (uid=0, gid=0, mode=0100644, size=266992)
Clearing orphaned inode 9756 (uid=0, gid=0, mode=0100644, size=1679776)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (3500004, counted=3638223).
Fix<y>? yes
Free inodes count wrong (909002, counted=931770).
Fix<y>? yes

/dev/loop0p1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/loop0p1: 14118/945888 files (0.2% non-contiguous), 208321/3846544 blocks
[  OK  ] DietPi-Imager | mount /dev/loop0p1 /mnt/loopback_rootfs
[  OK  ] DietPi-Imager | umount /mnt/loopback_rootfs
resize2fs 1.43.4 (31-Jan-2017)
Please run 'e2fsck -f /dev/loop0p1' first.

resize2fs 1.43.4 (31-Jan-2017)
Please run 'e2fsck -f /dev/loop0p1' first.

resize2fs 1.43.4 (31-Jan-2017)
Please run 'e2fsck -f /dev/loop0p1' first.

resize2fs 1.43.4 (31-Jan-2017)
Please run 'e2fsck -f /dev/loop0p1' first.

resize2fs 1.43.4 (31-Jan-2017)
Please run 'e2fsck -f /dev/loop0p1' first.

resize2fs 1.43.4 (31-Jan-2017)
Please run 'e2fsck -f /dev/loop0p1' first.

[MichaIng]

@canabino
Ah jep found the issue and did a fix. Please retry with:

wget https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-imager

[canabino]

I still had issues with the Armbian Repositories Certificate.
I asked on the Armbian Forum and someone recommended running dpkg-reconfigure ca-certificates
It then worked perfectly.
I have the new image now. I will test it.
Should I run the upload script?
curl -T /root/DietPi_ROCKPi4-ARMv8-Stretch.7z sftp://dietpi-survey:[email protected]/bugreport/

[MichaIng]

@canabino
Yes please, after initial boot and first run update+setup went well. Many thanks for doing this 👍 😃!

I still had issues with the Armbian Repositories Certificate.
I asked on the Armbian Forum and someone recommended running dpkg-reconfigure ca-certificates
It then worked perfectly.

Strange that on their own image the ca-certificates packages is outdated/unconfigured to accept their own repository 🤔. However easy solution.

[canabino]

Yeah, I found it strange too, because it was a fresh Armbian install. The Debian repositories were all successful it only failed at Armbian's repositories.

Anyway..... The install went very smooth and I installed a few software packages. Everything works as expected. This is the same build I have been running on my system for a week now and everything is smooth and without any faults.
I will begin uploading soon and will let you know when it is done.
Thanks for all your support with creating this.

[canabino]

It has completed the upload. Have a good night.

[canabino]

Here is a dietpi-bugreport ID of my system that has been running for a week.
b9eb663d-3803-484a-9f8f-3f9bc7edc731

[canabino]

@MichaIng
I found a bug or two.
First is that it doesn't want to update the system. It says that the update is available.

When I hit enter on the update the screen just flashes and nothing happens. In terminal it shows the following:

Another thing is in the dietpi-software it shows these weird characters

[MichaIng]

@canabino
Jep this is due to v6.25 dev/beta code, at least the update issue.
Please run the following to switch to stable code and reapply the update: G_DEV_BRANCH master

Not sure about the dietpi-software menu thing, but perhaps also some temporary dev code issue. Just check if it's gone after the above, otherwise report back.

I will also install new code to the image, adjust the Git branch and publish it as testing image later today. No need to re-create for now, I will rehash and repack it.

[canabino]

Hi @MichaIng
I ran G_DEV_BRANCH master and it switched to the stable code.
There wasn't an update to install after that because it is on v6.25.3
The Software Optimized and Software Aditional still had weird characters.
I then ran dietpi-cleaner from the launcher and selected option 3&4

Now both the software menus are perfect without any weird characters.
One other thing: If I run apt update and then apt upgrade
I get the following:

Why are those packages kept back?

[canabino]

Should I download Armbian Buster and start creating the image again?

[MichaIng]

@canabino

There wasn't an update to install after that because it is on v6.25.3

The update is applied automatically with the command. It sets the subversion string one backwards to reapply the last patch and it would have been done anyway because the RC version was lower as well. However good that the dietpi-software menu is fixed now. Should have nothing to do with dietpi-cleaner, however does not hurt as well.

Why are those packages kept back?

Yeah that is a good question. So basically we are still discussing how to handle ARMbian packages. Of course the firmware + bootloader is required, but the linux-<distro>-root-<branch>-<device> is not for sure. It contains many ARMbian special scripts, services and cron jobs that conflict with DietPi ones, some of them even cause kernel errors (their new own zRam implementation, which is enabled by default). We remove those services/job/binaries manually on DietPi-PREP but package upgrades would reinstall (+enable?) them again. Basically I am thinking of removing the mentioned package. It contains some here and there reasonable kernel/module/udev settings, but nothing really required or that we do not or would not apply outside of ARMbian, when found required/useful. But one thing that is AFAIK required is a initramfs postinst script that converts the initramfs into u-boot format. For this it reads the architecture from /etc/armbian_version which is as well part of the package. So either we would need to do that conversion ourself, or keep only those files from the package for this particular job, or test if initramfs can be skipped completely on certain ARM devices. I am not 100% sure, but AFAIK most ARM kernels can load without it as well, e.g. on RPi we skip initramfs install. Would loose some flexibility on the boot process, but very must users will never miss it and it speeds up boot process slightly.

Should I download Armbian Buster and start creating the image again?

Ah yeah sorry, somehow I though (while writing the Buster update topic) it was already, but mixed it up with all the updates around Debian, kernel and devices, obviously 😉. Yeah actually now that Buster is officially released, I would not invest much maintenance on Debian Stretch for devices which fully support Buster, firmware/GPU/... wise.

If you rebuild the image, now you can do that with the master version directly, no need for dev anymore.

---

Do you have an SDcard/image to play with, where unbootable system would be no problem, e.g. the Stretch one, in case if/before you're going to re-create with Buster?
In case the following test would be great:

apt-mark manual linux-u-boot-rockpi-4b-dev linux-dtb-dev-rockchip64 linux-image-dev-rockchip64
apt purge linux-stretch-root-dev-rockpi-4b initramfs-tools
apt autoremove --purge
apt install --reinstall linux-u-boot-rockpi-4b-dev linux-dtb-dev-rockchip64 linux-image-dev-rockchip64
ls -Al /boot # To check kernel+bootloader files
reboot # And hope this works, actually from package dependencies it should

[canabino]

@MichaIng
Oh understand why those packages are kept back, unnecessary Armbian stuff.

I will try to start working on the new Buster image over the weekend.

So you want me to run the script above on an existing stretch build and give you the results?

[MichaIng]

@canabino

unnecessary Armbian stuff

Not everything unnecessary, but they do similar stuff then DietPi, e.g. have a RAMlog implementation as well, which of course conflict with ours, a config tool which doubles with DietPi-Config (but with much less features 😉), even a software installer (with ~20 software titles) and as well some default system settings files. But the zRam implementation indeed causes strange errors, nothing that should be enabled by default IMO, only has benefits if you know how to use and dangerous if you don't even know it's there.

I will try to start working on the new Buster image over the weekend.

❤️

So you want me to run the script above on an existing stretch build and give you the results?

Jep if you find time, this would be great. E.g. run the above just before flashing the SDcard for Buster anyway. A single reboot will show if it works or not.

[canabino]

@MichaIng
Aye Aye Captain. I understand conflicting stuff.
As soon as I get time I'll do it and let you know.

[MichaIng]

@canabino
I updated DietPi-Imager btw to not read the whole drive to file via dd as first step. It will now shrink partition and filesystem first and run dd with defined target file size based on partition size. So the issue with VM drive space is solved with this, there should be not more than 1.5G free space required for .img file and .7z archive.
I just ran into the issue when creating a new NativePC Buster image from a 128G SSD where the 700M OS would have been written to a 128G .img file.
The way it is now, one has to know that in case of bad failure the OS on the source drive itself can get broken. But I think we should trust the script and the used commands (gdisk/parted/resize2fs etc) that these are safe to use. And the script is tested to use the commands as intended.

Download from here for now: https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-imager

Before merging into main branch, I want to discuss with Fourdee, since he changed the script the way that it runs dd first.

[canabino]

@MichaIng
That sounds like a great improvement. Yeah a 128SSD would cause a huge image at first.
I'll let you know how it goes with the new script.

[canabino]

I installed a fresh RockPi 4 image on an SD.
I ran your script and rebooted it booted without any problems.
I also ran a dietpi-bugreport on it. Reference: m8e4d8646-3ccd-4e10-86ed-e672978396d4e
Here are the results from the script you asked to run.

root@DietPi:~# apt-mark manual linux-u-boot-rockpi-4b-dev linux-dtb-dev-rockchip64 linux-image-dev-rockchip64
linux-u-boot-rockpi-4b-dev was already set to manually installed.
linux-dtb-dev-rockchip64 was already set to manually installed.
linux-image-dev-rockchip64 was already set to manually installed.
root@DietPi:~# apt purge linux-stretch-root-dev-rockpi-4b initramfs-tools
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  cpio dh-python initramfs-tools-core klibc-utils libexpat1 libklibc libmpdec2 libpython3-stdlib libpython3.5-minimal libpython3.5-stdlib linux-base
  mime-support python-apt-common python3 python3-apt python3-minimal python3.5 python3.5-minimal u-boot-tools
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  initramfs-tools* linux-stretch-root-dev-rockpi-4b*
The following held packages will be changed:
  linux-stretch-root-dev-rockpi-4b
0 upgraded, 0 newly installed, 2 to remove and 1 not upgraded.
After this operation, 109 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 14542 files and directories currently installed.)
Removing linux-stretch-root-dev-rockpi-4b (5.88) ...
Removing 'diversion of /etc/mpv/mpv.conf to /etc/mpv/mpv-dist.conf by linux-stretch-root-dev-rockpi-4b'
Removing initramfs-tools (0.130) ...
(Reading database ... 14426 files and directories currently installed.)
Purging configuration files for linux-stretch-root-dev-rockpi-4b (5.88) ...
dpkg: warning: while removing linux-stretch-root-dev-rockpi-4b, directory '/usr/lib/chromium-browser' not empty so not removed
Purging configuration files for initramfs-tools (0.130) ...
root@DietPi:~# apt autoremove --purge
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  cpio* dh-python* initramfs-tools-core* klibc-utils* libexpat1* libklibc* libmpdec2* libpython3-stdlib* libpython3.5-minimal* libpython3.5-stdlib*
  linux-base* mime-support* python-apt-common* python3* python3-apt* python3-minimal* python3.5* python3.5-minimal* u-boot-tools*
0 upgraded, 0 newly installed, 19 to remove and 1 not upgraded.
After this operation, 27.5 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 14422 files and directories currently installed.)
Removing initramfs-tools-core (0.130) ...
Removing cpio (2.11+dfsg-6) ...
Removing python3-apt (1.4.0~beta3) ...
Removing klibc-utils (2.0.4-9) ...
Removing 'diversion of /usr/share/initramfs-tools/hooks/klibc to /usr/share/initramfs-tools/hooks/klibc^i-t by klibc-utils'
Removing libklibc (2.0.4-9) ...
Removing linux-base (4.5) ...
Removing python-apt-common (1.4.0~beta3) ...
Removing u-boot-tools (2016.11+dfsg1-4) ...
Removing dh-python (2.20170125) ...
Removing python3 (3.5.3-1) ...
Removing python3.5 (3.5.3-1+deb9u1) ...
Removing python3-minimal (3.5.3-1) ...
Removing python3.5-minimal (3.5.3-1+deb9u1) ...
Unlinking and removing bytecode for runtime python3.5
Removing libexpat1:arm64 (2.2.0-2+deb9u2) ...
Removing libpython3-stdlib:arm64 (3.5.3-1) ...
Removing libpython3.5-stdlib:arm64 (3.5.3-1+deb9u1) ...
Removing libmpdec2:arm64 (2.4.2-1) ...
Removing libpython3.5-minimal:arm64 (3.5.3-1+deb9u1) ...
Removing mime-support (3.60) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
(Reading database ... 13178 files and directories currently installed.)
Purging configuration files for klibc-utils (2.0.4-9) ...
Purging configuration files for mime-support (3.60) ...
Purging configuration files for python3 (3.5.3-1) ...
Purging configuration files for initramfs-tools-core (0.130) ...
dpkg: warning: while removing initramfs-tools-core, directory '/var/lib/initramfs-tools' not empty so not removed
Purging configuration files for linux-base (4.5) ...
Purging configuration files for python3.5-minimal (3.5.3-1+deb9u1) ...
Purging configuration files for libpython3.5-minimal:arm64 (3.5.3-1+deb9u1) ...
root@DietPi:~# apt install --reinstall linux-u-boot-rockpi-4b-dev linux-dtb-dev-rockchip64 linux-image-dev-rockchip64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reinstallation of linux-dtb-dev-rockchip64 is not possible, it cannot be downloaded.
Reinstallation of linux-image-dev-rockchip64 is not possible, it cannot be downloaded.
The following held packages will be changed:
  linux-u-boot-rockpi-4b-dev
The following packages will be upgraded:
  linux-u-boot-rockpi-4b-dev
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 331 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://apt.armbian.com stretch/main arm64 linux-u-boot-rockpi-4b-dev arm64 5.90 [331 kB]
Fetched 331 kB in 3s (104 kB/s)
(Reading database ... 13171 files and directories currently installed.)
Preparing to unpack .../linux-u-boot-rockpi-4b-dev_5.90_arm64.deb ...
Unpacking linux-u-boot-rockpi-4b-dev (5.90) over (5.88) ...
Setting up linux-u-boot-rockpi-4b-dev (5.90) ...
root@DietPi:~# ls -Al /boot # To check kernel+bootloader files
total 26496
-rw-r--r-- 1 root root      164 Jul 13 16:27 armbianEnv.txt
-rw-r--r-- 1 root root   307322 Jun 29 15:43 boot.bmp
-rw-r--r-- 1 root root     2877 Jun  6 16:22 boot.cmd
-rw-r--r-- 1 root root     4882 Jun  6 16:24 boot-desktop.png
-rw-rw-r-- 1 root root     2949 Jun  6 16:25 boot.scr
-rw-r--r-- 1 root root   169118 Jun  6 16:19 config-5.1.0-rockchip64
drwxr-xr-x 4 root root     4096 Jul 13 16:29 dietpi
-rw-r--r-- 1 root root   152079 Jun 29 01:50 dietpi-CHANGELOG.txt
-rw-r--r-- 1 root root     8833 Jun 29 01:50 dietpi-README.md
-rw-r--r-- 1 root root    11992 Jul 13 16:29 dietpi.txt
-rwx------ 1 root root     2790 Jun 29 15:44 dietpi-wifi.txt
lrwxrwxrwx 1 root root       20 Jun  6 16:23 dtb -> dtb-5.1.0-rockchip64
drwxr-xr-x 3 root root     4096 Jun  6 16:23 dtb-5.1.0-rockchip64
lrwxrwxrwx 1 root root       24 Jun  6 16:23 Image -> vmlinuz-5.1.0-rockchip64
-rw-r--r-- 1 root root  4374027 Jun 29 15:43 initrd.img-5.1.0-rockchip64
-rw-r--r-- 1 root root        0 Jun  6 16:23 .next
-rw-r--r-- 1 root root  3237376 Jun  6 16:19 System.map-5.1.0-rockchip64
lrwxrwxrwx 1 root root       24 Jun 29 15:43 uInitrd -> uInitrd-5.1.0-rockchip64
-rw-r--r-- 1 root root  4374091 Jun 29 15:43 uInitrd-5.1.0-rockchip64
-rwxr-xr-x 1 root root 14438912 Jun  6 16:19 vmlinuz-5.1.0-rockchip64

[canabino]

I will start with the Buster image soon.

[canabino]

I installed a fresh Armbian Buster and ran the DietPi-PREP script.
It came up with the following error.

[MichaIng]

@canabino
About your earlier post:
Okay, that initramfs is still there. Makes sense since it is not part of the packages, but created by the packages instead. So the relevant test would be to remove the initrd files and try to reboot:

rm /boot/{uInitrd,initrd}*
reboot

About DietPi-PREP error:
Please try it manually first to see which package causes the issue: apt purge dbus dhcpcd5 mountall

[canabino]

I ran apt purge dbus dhcpcd5 mountall

This is what it shows in the terminal what happened when it failed.

[MichaIng]

@canabino
Ah sorry, yeah mountall only exists on Jessie and Raspbian until Stretch. G_AGP filters non-installed packages automatically, but reduces verbosity 😉.

Only dbus is installed, so run: apt purge dbus

[canabino]

I booted upagain and ran apt purge dbus

[MichaIng]

@canabino
Strange why these two packages are not simply purged as well. They depend on dbus, but both are desktop related and not required. Usually when purging a dependency non-interactively (G_AGP is non-interactive), then all dependants are purged automatically as well. In interactive mode one usually is asked to confirm that. Not sure why here an error occurs. Perhaps indeed there are held packages.

And what the hack, now I see that the ARMbian Buster image is only available with kernel 4.4 and no server image available (only with desktop)...

Okay please try the following:

apt-mark unhold $(apt-mark showhold)
apt purge glib-networking libgtk-3-common
apt purge dbus
apt install linux-u-boot-rockpi-4b-dev linux-dtb-dev-rockchip64 linux-image-dev-rockchip64

• I hope the last step will purge/override the old kernel 4.4, to check which ones are finally installed: dpkg -l linux-*

Try to reboot, if this works well. Perhaps there is an issue with Buster + mainline kernel, so that ARMbian had to revert.

If it works and you are in mood, to go on with the non-initramfs test:

• Create a SDcard backup, manually copying files onto another system would work as well (mkdir -p /mnt/rockpi_backup && cp -a /mnt/rockpi_mount/. /mnt/rockpi_backup/)
• Then boot again into the RockPi and purge initramfs and all related stuff:

apt purge $(dpkg --get-selections linux-*-root-* | mawk '{print $1}') initramfs-tools
apt autoremove --purge
rm -f /boot/{uInitrd,initrd}*
apt install --reinstall linux-u-boot-rockpi-4b-dev linux-dtb-dev-rockchip64 linux-image-dev-rockchip6
reboot

[canabino]

It didn't want to restart after I ran the first set of code. Find attached the terminal text file.
MobaXterm_192.168.100.111_20190714_102316.txt

[MichaIng]

@canabino

E: Unable to locate package linux-dtb-dev-rockchip64
E: Unable to locate package linux-image-dev-rockchip64

I just rechecked the repos. Indeed the kernel 5.X related dev packages are not available in the Buster repo (anymore), only in the Stretch one...

For this reason the default non-dev kernel 4.4 packages are installed:

ii  linux-buster-root-rockpi-4b      5.90         arm64        Armbian tweaks for buster on rockpi-4b (default branch)
ii  linux-dtb-rockchip64             5.90         arm64        Linux DTB, version 4.4.182-rockchip64
ii  linux-image-rockchip64           5.90         arm64        Linux kernel, version 4.4.182-rockchip64
ii  linux-u-boot-rockpi-4b-default   5.90         arm64        Uboot loader 2017.09

After you reached this stage, reboot did not work anymore 🤔? Strange since all the core packages, even initramfs are still installed. Any boot messages about where it hang?

---

Okay things seem to be in heavy change currently due to Debian Buster release... Not sure how to go on best. I would try to install the dev kernel 5.X bootloader + kernel manually for now, or add the ARMbian Stretch repo (additionally to Buster) to allow installing those via APT. But it will be much try&error I guess.

To have an image now without too much try&error I think it's best to go with Buster + kernel 4.4 then. Since all core packages are still installed, I guess the device rebooted successfully but network didn't come up (so no SSH reachable) since DietPi-PREP didn't finish. Is that possible? Do you have a monitor + keyboard to attach?
If so and you are able to login, the next steps (adjusted to match the kernel 4.4 packages) would be:

apt purge linux-buster-root-rockpi-4b initramfs-tools initramfs-tools-core
rm -f /boot/{uInitrd,initrd}*
apt install --reinstall linux-u-boot-rockpi-4b-default linux-dtb-rockchip64 linux-image-rockchip64
reboot

• If reboot works fine, then I will adjust DietPi-PREP to not install initramfs-tools and linux-buster-root-rockpi-4b on ROCK Pi 4, so we can have a clean image without the conflicting ARMbian services.
• If it does not reboot successfully (attached monitor should print some meaningful error then), then we need to stay with ARMbian services.
  
  
  
  • In this case, run the commands to purge dbus BEFORE running DietPi-PREP:
  
  

apt purge glib-networking libgtk-3-common
apt purge dbus

[canabino]

@MichaIng
I have a screen and keyboard, I'll check it out tomorrow.

[canabino]

I connected a screen and keyboard and was able to log in. So I think the networking isn't working.
I ran the commands to match the kernel 4.4 packages.
All the commands ran smooth except for the last one because there was no network.
It couldn't resolve the Armbian host. I then ran Armbian-config and it warned me that there was no network and some parts of the gui won't work, but there wasn't anything to configure in the gui under networking except for dhcp. I then did a reboot, but now it doesn't boot on the screen or ssh. The screen stays blank. I can start over with a fresh Armbian.

[MichaIng]

@canabino
Yeah I think the last command (before reboot) is essential if it can even work. Yeah didn't think about reinstall will not work with missing network of course. DietPi-PREP should run through before doing any reboot to assure that after network-manager removal, ifupdown + resolvconf + default /etc/network/interfaces (Ethernet active with DHCP) is installed.

Instead of removing the initramfs files it makes sense to just create a backup for testing, so one can recover from external Linux system:

mkdir /boot/backup
for i in /boot/{uInitrd,initrd}*; do mv $i /boot/backup/; done

One thing I recognised is that u-boot config has this inside:

load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd

Not sure if boot simply fails if this expected file (initramfs) does not exist, however it makes sense then to remove the line and recompile:

cp -a /boot/boot.{cmd,scr} /boot/backup/
sed -i '/uInitrd/d' /boot/boot.cmd
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

If boot fails, initramfs can then be easily recovered (from external system):

mv /boot/backup/* /boot/

However I don't expect you should do all these testings 😉.
If doing

apt purge glib-networking libgtk-3-common
apt purge dbus

before running DietPi-PREP allows to finish it without error, then this should do it for now. I am still not sure why this is required, however once ARMbian offers a server image (without desktop) then it is not required anymore.

[canabino]

@MichaIng
Should I mount the SD in the VM and run the commands?

[MichaIng]

@canabino
As said, only if you are in mood to again test boot without initramfs.

Actually quickest test is the following:

• Boot fresh ARMbian.

apt purge linux-buster-root-rockpi-4b initramfs-tools initramfs-tools-core
mkdir /boot/backup
for i in /boot/{uInitrd,initrd}*; do mv $i /boot/backup/; done
cp -a /boot/boot.{cmd,scr} /boot/backup/
sed -i '/uInitrd/d' /boot/boot.cmd
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
apt install --reinstall linux-u-boot-rockpi-4b-default linux-dtb-rockchip64 linux-image-rockchip64
reboot

• If it boots up like this, then initramfs can be skipped together with the ARMbian scripts and services. Then I will rewrite DietPi-PREP to cover this.
• If reboot fails, then initramfs is most likely required to boot all ARMbian images. You can then recover by mounting the SD to VM and run:

mv /mnt/sdxi/boot/backup/* /mnt/sdxi/boot/

• Then it should boot again and you can run DietPi-PREP.

[canabino]

@MichaIng
I ran the script and afterwards it didn't want to reboot.
I then recovered with the VM.
I am running DietPi-PREP now.

[canabino]

[MichaIng]

@canabino
Okay, initramfs then seems to be required when using the ARMbian kernel + bootloader packages.

I will think about how to handle the linux-buster-root-rockpi-4b package. I think easiest for now is to mask the ARMbian services and perhaps emptying the cron jobs works.

Yeah the error with dbus is the same, please run:

apt purge glib-networking libgtk-3-common
apt purge dbus

And rerun DietPi-PREP then.

[MichaIng]

@canabino
When this works fine then and you created the image. Might you test the following:

apt install --reinstall linux-buster-root-rockpi-4b
for i in /lib/systemd/system/armbian*; do systemctl disable --now ${i##*/}; done
for i in /lib/systemd/system/armbian*; do systemctl mask ${i##*/}; done
for i in /etc/cron*/armbian*; do > $i; done
apt install --reinstall linux-buster-root-rockpi-4b
for i in /lib/systemd/system/armbian*; do systemctl is-enabled ${i##*/}; done
ls -l /etc/cron*/armbian*

• This is to check if
  
  
  
  • the ARMbian services stay masked when the package is reinstalled or upgraded
  
  
  • the cron jobs stay empty.
  
  

[canabino]

@MichaIng
DietPi_ROCKPi4-ARMv8-Buster for the name?
Is it 6.25?

[MichaIng]

@canabino
Exactly

[canabino]

@MichaIng
The image created successfully. I will run the other test tomorrow.
Enjoy your evening.

[canabino]

@MichaIng
I got a little busy and didn't have time. I installed the newly created image. It didn't want to connect on SSH. I then plugged it into a screen and it asked for login details. It didn't take the default password "dietpi" but my Armbian password I configured before dietpi-prep. Then it said that the installation didn't complete and it needs to start over. i entered on OK and it failed and said it couldn't resolve the host. It came up with dietpi-config where I then enabled the network adaptor. then it continued with the installation and came at this screen

I then enter on

It then comes up with the changing the default passwords

and after this just jumps back to main menu screen and nothing gets installed.

[MichaIng]

@canabino

It didn't take the default password "dietpi" but my Armbian password I configured before dietpi-prep.

That is very strange. The first boot script resets the passwords to what is configured in dietpi.txt, which is "dietpi" by default: https://github.com/MichaIng/DietPi/blob/master/rootfs/var/lib/dietpi/services/dietpi-firstboot.bash#L174-L181
Could you verify this is set: grep 'AUTO_SETUP_GLOBAL_PASSWORD' /DietPi/dietpi.txt

Actually it looks like the dietpi-firstboot.service never ran. At least this would explain the DietPi-Software loop as well.
Could you check: cat /var/tmp/dietpi/logs/dietpi-firstboot.log

[gattohub]

Hi. Any possibility to implement rock pi 4 as a replacement for desktop pc? I was buying this equipment because this support for nvme m.2 SSD and I have doubts because according to what I could see they have tried to build a dietpi oara rock pi 4 image and there was no success in the company.

[canabino]

@gattohub I'm not sure. Best is to ask on the Radxa forum
I haven't used the nvme m.2 SSD port.

[gattohub]

Hello, I see that the post about the implementation of Dietpi in rockpi4 is stagnant. Any chance to refloat it? Or maybe it isn't worth it?
I still have not received my computer, but I am very anxious to test it to replace my desktop pc intel 3 broadwell with 4 g of memory, with the rockpi. Programs that I use and I would like to continue using: firefox, gnome-subtitles with support for video editing and subtitles simultaneously, and libreoffice, and Serviio.

[canabino]

@gattohub I got busy and DietPi is using a new version of Linux. I will definitely get back to helping MichaIng get it done in the following weeks.

[gattohub]

Ok thanks, hopefully it can be implemented.

[MichaIng]

@canabino @gattohub
Hi guys, sorry for being away from this topic for a while. Indeed I want to get this done as well.

@canabino
Finally there is a Debian Buster Linux kernel 5.3 image available by ARMbian: https://dl.armbian.com/rockpi-4b/Debian_buster_dev_minimal_nightly.7z
This is also very minimal, so perfect as a pre-image for us.
So if you find time, might you go through creation for this? Use the dev branch to pull DietPi-PREP from (as well when choosing branch there for the image) and DietPi-Imager, since current code contains some minor additions for RockPi4 as well.

bash -c "$(curl -sSL https://raw.githubusercontent.com/MichaIng/DietPi/dev/PREP_SYSTEM_FOR_DIETPI.sh)"

[canabino]

@MichaIng That is great news about the kernel. I will try to get it done this evening and let you know.

[gattohub]

Hi, it's good news. I hope you can do it and I'm sorry not to be of help, because among other things I still don't have the team with me. I hope you succeed and you can hang the image to install. regards

[canabino]

@MichaIng
I loaded the new Armbian Image and ran your DietPi-PREP command but it says command not found

Which is weird because it doesn't even want to run armbian-config

[canabino]

@MichaIng
Should I rather run the following?

cd /tmp
wget https://raw.githubusercontent.com/MichaIng/DietPi/dev/PREP_SYSTEM_FOR_DIETPI.sh
chmod +x PREP_SYSTEM_FOR_DIETPI.sh
./PREP_SYSTEM_FOR_DIETPI.sh

[canabino]

I ran

cd /tmp
wget https://raw.githubusercontent.com/MichaIng/DietPi/dev/PREP_SYSTEM_FOR_DIETPI.sh
chmod +x PREP_SYSTEM_FOR_DIETPI.sh
./PREP_SYSTEM_FOR_DIETPI.sh

I chose dev branch.
All ran smoothly for DietPi-PREP

I then ran

cd /tmp
wget https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-imager
chmod +x dietpi-imager
./dietpi-imager

All ran smoothly for DietPi-Imager
I am testing the first run now. 😄

[canabino]

@MichaIng
No SSH connection again. 😢 I had to plug into HDMI

[canabino]

@MichaIng
On HDMI again it said the first run failed.

In dietpi-config ethernet wasn't enabled.
After enabling the ethernet it comes up with an error if I select DHCP or if I configure a static IP It comes up with this same error

[canabino]

@MichaIng
I ran dietpi-prep again on a fresh Armbian, but this time I didn't run dietpi-image.
I just rebooted and everything is fine. Something in the dietpi-imager is messing up.

[MichaIng]

@canabino
It says "No space left on device" which of course then causes follow-up issues. However the dietpi-fs_partition_resize service should expend the partition and file system on first boot after DietPi-PREP ran. I guess you somehow land in a console, just with several error messages and failing update etc. From the console, could you paste: cat /var/tmp/dietpi/logs/*
I hope these logs were even created. Otherwise on local console, is it possible to scroll back to check boot logs (shift+page up)? Not sure but in most cases sadly the scrollback buffer on local console is very limited and resets after getty/login target has been reached.

[canabino]

@MichaIng
Great news!!! I started fresh again today with and ran DietPi-PREP. Only difference I did was select that I needed WiFi for the install, previously I didn't.
I also updated my VM to buster and then ran the dietpi-imager and voila. Success!!!!!!!!
Firstboot ran perfectly and I installed a few software packages. Everything is running perfectly.

Where do you want me to upload the image to again?

[canabino]

@MichaIng
I ran:
curl -T /root/DietPi_ROCKPi4-ARMv8-Buster.7z sftp://dietpi-survey:[email protected]/bugreport/

It has finished the upload. 😄

[MichaIng]

@canabino
Perfekt, I will add it as testing image to the download page. Many thanks for doing this and being so patient 😃.

[MichaIng]

Added to download page: https://dietpi.com/#download
Direct download link: https://dietpi.com/downloads/testing/DietPi_ROCKPi4-ARMv8-Buster_new.7z

To all testers: Please consider to run some benchmark from dietpi-config > Tools > Benchmarks, so we can add some performance rating info, check about heat and other pros/cons you recognise.

Of course tell us whenever you face an issue. Note that this is at best beta in any kind:

• The kernel is very up-to-date 5.3
• The ARMbian base image is also maked as "not supported", which means it is in development/testing stage, regarding kernel/bootloader/firmware.
• It is based on the current dev branch code, which as well might not be 100% polished. Please run G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=beta' /DietPi/dietpi.txt after first boot updates/installs, so you get notified when the first DietPi beta is available, which should be more polished. After official v6.26 release you might want to switch to stable/master branch: G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /DietPi/dietpi.txt

---

@canabino

I started fresh again today with and ran DietPi-PREP. Only difference I did was select that I needed WiFi for the install, previously I didn't.

Jep, we do that with all non-VM images, so users can configure to connect to WiFi on first boot directly.

[canabino]

@MichaIng
Thanks so much for guiding me through the creation of the image.

[gattohub]

I tried to boot from microsd with dietpi system but it stays with the green light and nothing happens. What am I doing wrong?
I'm running a rock pi 4 b from the microsd with dietpi image that was uploaded here.

[canabino]

I tried to boot from microsd with dietpi system but it stays with the green light and nothing happens. What am I doing wrong?
I'm running a rock pi 4 b from the microsd with dietpi image that was uploaded here.

That is weird because I have booted to DietPi using the same image on two different SD cards. I have the RockPi 4b too.
How did you write the image to the SD?

[gattohub]

Hi. Record the image with dd: sudo dd if=~/DietPi_v6.25_ROCKPi4-ARMv8-Buster.img of=/dev/sdb
How long does the first restart of dietpi take?

[MichaIng]

@gattohub
Since it's a fast SBC and only one subversion update done to current version, it should not take more than 2 minutes. Of course it takes longer if you do automated first run installs, depending on the chosen software titles.

Do you have a screen attached? In case no output at all? Not sure if there is a switch on this board required to have it booting from SDcard instead of internal eMMC?

[williamwebb]

Only issue I have faced so far is wifi connection will drop under high network traffic. Encountered this ~6 times so far, seems fairly easy to reproduce. Pulling docker images or even large apt installs are enough to kill it.

[MichaIng]

@williamwebb
This is a kernel/firmware/drivers issue most likely. Since the used kernel is quite new and under development, you might want to try upgrading all firmware packages:

apt update
apt full-upgrade

To debug, system and kernel logs could give a hint, i.e. after a WiFi drop happened:

journalctl | tail -20
dmesg | tail -20

[williamwebb]

Thanks @MichaIng, if it happens again ill be sure to capture the logs.

[lwqcz]

I'm going to buy some RockPiS board ... Will be this image suitable for this board also?

[canabino]

I don't think it will work because it has a different design.

[MichaIng]

Jep pretty sure as well that it requires a new image. But same way, using another Debian image for this board and running DietPi-PREP should work fine.

After v6.27 release I'll put some effort in systemd-nspawn + qemu-static based image creation. This worked fine for some other devices and binary compiling and with this I can create images for any device, regardless if I own it or not. But since kernel/bootloader/firmware is not loaded, it always requires a final test on real machine of course. I can do a start with the ROCK Pi S then.

[lwqcz]

https://feathub.com/MichaIng/DietPi/+95 is a RockPI S feature request ... There is not "enough traction" yet...

[canabino]

@MichaIng
Hi Micha
I decided to start my system from scratch and loaded the image on my RockPi. It started up and went through the installation steps. It then came to the page where you can select new software to install. After that it ran apt update and when it ran apt upgrade an error came up and it can't continue.

I sent the bug report. The image worked before. What could be the problem now?
This is the full error

[  OK  ] DietPi-Software | G_AGUP
[ INFO ] DietPi-Software | APT upgrade, please wait...
(Reading database ... 15926 files and directories currently installed.)
Preparing to unpack .../linux-buster-root-dev-rockpi-4b_19.11.4.351_arm64.deb ...
Unpacking linux-buster-root-dev-rockpi-4b (19.11.4.351) over (5.95.190904) ...
dpkg: error processing archive /var/cache/apt/archives/linux-buster-root-dev-rockpi-4b_19.11.4.351_arm64.deb (--unpack):
 unable to create '/usr/share/armbian/armbianEnv.txt.dpkg-new' (while processing './usr/share/armbian/armbianEnv.txt'): No such file or directory
Failed to enable unit: Unit file /etc/systemd/system/armbian-ramlog.service is masked.
mv: cannot stat '/etc/default/armbian-motd.dpkg-dist': No such file or directory
mv: cannot stat '/etc/default/armbian-ramlog.dpkg-dist': No such file or directory
mv: cannot stat '/etc/default/armbian-zram-config.dpkg-dist': No such file or directory
Errors were encountered while processing:
 /var/cache/apt/archives/linux-buster-root-dev-rockpi-4b_19.11.4.351_arm64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

[MichaIng]

@canabino
Could you please paste: cat /etc/dpkg/dpkg.cfg.d/dietpi-no_armbian

[MichaIng]

@canabino
I adjusted the code, which seems to have resolved the issue on my test system. Although strange that reverse test still succeeded. Will check the postinst/conf scripts of this package more closely. However to test:

sed -i '\|/usr/share/armbian|d' /etc/dpkg/dpkg.cfg.d/dietpi-no_armbian
apt full-upgrade

After v6.27 release we clearly need to create new ROCK Pi 4 images based on stable branch. The current ones are dev branch, hence depending on install time can contain untested/unstable DietPi code 😉.

[canabino]

Hi Micha sorry for the late reply. I'm in the process of moving to a new house.
Thanks for the reply. Good to hear that you found the error. As soon as I get settled we can working on the new image.

The reason I wanted to load a new image was because Radarr, Sonarr and different torrent apps including Qbittorrent and Deluge would keep on crashing. They will work for a while after running dietpi-services retart but then will just stop. In services they seem to be running but can't access their webui or daemon. That's when I decided to start fresh.
As soon as I get the time we can get back to creating a new image for 6.27.

[MichaIng]

@canabino
I am not yet 100% sure if it really was the issue, since reverting the change still allowed me to reinstall the package. But checking the code, depending on the existence of some other files, indeed /usr/share/armbian is accessed, hence this must be the reason.

[canabino]

Hi @MichaIng
Everything has settled a bit after our move. I will get some time for the new image. I see you are on 6.29 already ⏩ Should I try the existing image first or should we start with a new image?

Oh I see there are other builds for the RockPi4 to create the image from https://wiki.radxa.com/Rockpi4/downloads
Or should we stick to Armbian?

[MichaIng]

@canabino
Jep new image should be done, this time based on DietPi stable, which is v6.28 currently.

The image offered by Radxa itself is Stretch, hence nothing we should use anymore. From what I see, I'd go with Armbian. Since I have a new method to create images for devices I don't own (via systemd-nspawn container), I can also create the ROCK Pi 4 image and do some review and hotfix and in case DietPi-PREP changes, where required, all together. What would be perfect, if you could then test the resulting image. What do you think?

[canabino]

That sounds great. Nice to hear you can create the images that way. I will be glad to test it out. At the moment I'm on 6.26 dev. If I update it to any later version many software applications crash. Let me know if there is anything I can do to help you out.

[MichaIng]

@canabino

If I update it to any later version many software applications crash

Ui, that should not be the case of course, regardless of device. Could you go into detail a bid?

[canabino]

I run Jackett, Sonarr, Radarr, Sabnzbd and Deluge. With the new updates from 6.27 and up, Deluge will crash. It shows that it is running in dietpi-services but I can't access the webui or daemon. If I reinstall Deluge it will run again but then Sonarr and Radarr will crash, also services show they are running but can't access the webui. If I reinstall Sonarr and Radarr Sabnzbd crashes and Jackett. If I reboot then sometimes it can't access SSH and I have to unplug it and wait a few minutes then start it up. But then none of the apps are accessible even though they are running in services. I then restore a backup of 6.26 dev and everything works again.

[MichaIng]

@canabino
Okay this is strange, since most of those software titles have not gone through any change, nor have been done any ROCK Pi 4 specific changes.

We would need to go through the update log (in case automated reinstalls) and each service logs:

cat /var/tmp/dietpi/logs/dietpi-update.log
journalctl -u sonarr
journalctl -u radarr
journalctl -u jackett
journalctl -u sabnzbd
journalctl -u deluged
dmesg | tail

• The last to assure there are not kernel issues, e.g. OOM, file system errors and all such.

BUT: We should investigate this in a new issue since it should have nothing to do with ROCK Pi 4.

[canabino]

OK. Let me get you the data. You requested. Should I create a new issue? On dietpi.com or github?

[MichaIng]

@canabino
Jep, would be great, just here on GitHub.

[canabino]

I started a new issue here.
https://github.com/MichaIng/DietPi/issues/3327

[MichaIng]

@canabino and all, I just created a new image. Armbian firmware packages are now marked as stable, DietPi v6.28 with all quick fixes (known and fixed for DietPi v6.29) applied already: https://dietpi.com/downloads/images/DietPi_ROCKPi4-ARMv8-Buster.7z

It would be great if someone could test this on a real machine, since it was created on systemd-nspawn container.

[canabino]

@MichaIng That is awesome news. 💯 I would love to test it out and let you know.
Do you need logs or anything let me know if there are any specifics you want me to test?

[canabino]

@MichaIng
I have already downloaded and loaded it onto an SD card. All my problems are gone now. It's running smoothly with all my installed apps. I almost ditched Sonarr for Medusa but I am glad everything is working well again as it should. You da man 👍
Now I have to get it on my eMMC
Again let me know if there is anything else you would like me to test.

[MichaIng]

@canabino
Great, many thanks for testing!

Do you have an eMMC to SD or USB adapter? Otherwise probably some complicated way to boot from SDcard, put the DietPi .img file on a USB stick and dd it from there onto the eMMC, which is hopefully recognised.

[canabino]

@MichaIng I have a eMMC to USB adapter. I made a backup of the system that was working perfect on the SD card, then I loaded the image on the MMC and restored the backup. Everything is running perfect. Very low on resources and very fast.
I love the new installation screens. Very smooth and a different order.

[MichaIng]

@canabino
Jep new image means less patches/update related overhead. Also the Armbian services/cron jobs are blocked more effectively. Next step is to apply required/useful system settings ourself and skip/purge the Armbian root package, which contains all their tools/services etc, which double/conflict with ours. Otherwise Armbian kernel, bootloader and firmware work is fantastic, especially since they adapt very recent mainline kernel for all devices.

Okay great, I'll move this image to stable then, removing the beta plag. Also great to have the container-build method approved :+1:.

[canabino]

So it will just get better and better.👍 Nice to hear that the container-built images are making your job easier. So happy that this image is stable now. Let me know if you need any help from my side to continue to improve this build. I saw RADXA has a link to the DietPi image on their site.

[MichaIng]

@canabino
Jep they have. I'll mail them when moving it to stable and keep a symlink in place to keep their link valid. When you use some GPU, sound and/or other hardware features of the board, inform me when something is not working fine or dietpi-config settings would be nice.

I added generic RK3399 GPU acceleration (mali GPU drivers) to dietpi-software but am not sure how well this is used by e.g. Kodi, other media players, desktop/Xserver applications etc.

[canabino]

@MichaIng When you use some GPU, sound and/or other hardware features of the board, inform me when something is not working fine or dietpi-config settings would be nice
Will do so.
I added generic RK3399 GPU acceleration (mali GPU drivers) to dietpi-software but am not sure how well this is used by e.g. Kodi, other media players, desktop/Xserver applications etc.
I use Emby. Can I do something to check?

[MichaIng]

@canabino

I use Emby. Can I do something to check?

Just if you experience any issue or difficulty or something that could be made easier or automated with our scripts.

Okay I moved the new image in stable place but left a symlink to testing dir in place, so all but the _new.7z links stay valid for a while. I mark this issue as closed.