Dietpi: Images | Update all images to Buster where possible

[MichaIng]

Note to testers:

Many thanks for testing one of our new images.
Please give us some feedback whether the board boots fine, including all first run setup steps, when you face some issues and as well when not. This helps us to evaluate whether an image can be considered as stable.

---

All stable images: https://dietpi.com/downloads/images/
All testing images: https://dietpi.com/downloads/images/testing/

• [x] VirtualBox => Buster, stable!
• [x] VMware => Buster, stable!
• [x] x86_64 PC BIOS => Buster, stable!
• [x] x86_64 PC UEFI => Buster: #1171, stable!
• [x] RPi => Buster: #2935, stable!
• [x] ROCK Pi 4 => Buster: #2445, stable!
• [x] ASUS Tinker Board => Buster: #2977, stable!
• [x] Firefly RK3399 => Buster: #1986
• [x] ROCK64 => Buster: #3051, stable!
  
  
  
  • Might solve: #2522
  
  
• [x] PINE A64 => Buster: https://dietpi.com/downloads/images/DietPi_PineA64-ARMv8-Buster.7z => stable!
• [x] ROCKPro64 => Buster: https://dietpi.com/downloads/images/DietPi_RockPro64-ARMv8-Buster.7z => stable!
• [x] Pinebook => Buster: https://dietpi.com/downloads/images/DietPi_Pinebook-ARMv8-Buster.7z => stable!
• [x] NanoPC T4 => Buster: #2142 https://dietpi.com/downloads/images/DietPi_NanoPCT4-ARMv8-Buster.7z => stable!
• [x] NanoPi M3/T3/F3 => Buster: #3221, stable!
• [x] Sparky SBC => Stretch: https://dietpi.com/downloads/images/DietPi_SparkySBC-ARMv7-Stretch.7z => stable!
  
  
  
  • Might solve: #2610
  
  
  • Debian Buster requires min Linux 3.16 (vs 3.10)
  
  
• [x] Odroid N2 => Buster: https://dietpi.com/downloads/images/DietPi_OdroidN2-ARMv8-Buster.7z => stable!
• [x] Odroid N1 => Buster: https://dietpi.com/downloads/images/DietPi_OdroidN1-ARMv8-Buster.7z => stable!
• [x] Odroid XU3/XU4/MC1/HC1/HC2 => Buster: https://dietpi.com/downloads/images/DietPi_OdroidXU4-ARMv7-Buster.7z => stable!
  
  
  
  • Might solve: #2584
  
  
  • Fixed: #2990
  
  
• [x] Odroid C2 => Buster: https://dietpi.com/downloads/images/DietPi_OdroidC2-ARMv8-Buster.7z => stable!
• [x] Odroid C1 => Buster: https://dietpi.com/downloads/images/DietPi_OdroidC1-ARMv7-Buster.7z => stable!
• [x] NanoPi M1 Plus => Buster: https://dietpi.com/downloads/images/DietPi_NanoPiM1Plus-ARMv7-Buster.7z => stable!
• [x] NanoPi K1 Plus => Buster: https://dietpi.com/downloads/images/DietPi_NanoPiK1Plus-ARMv8-Buster.7z => stable!
• [x] NanoPi M1/T1 => Buster: https://dietpi.com/downloads/images/DietPi_NanoPiM1-ARMv7-Buster.7z => stable!
• [x] NanoPi NEO => Buster: https://dietpi.com/downloads/images/DietPi_NanoPiNEO-ARMv7-Buster.7z => stable!
• [x] NanoPi NEO Air => Buster: https://dietpi.com/downloads/images/DietPi_NanoPiNEOAir-ARMv7-Buster.7z => stable!
  
  
  
  • Probably solves: #2270
  
  
• [x] NanoPi M2/T2 => Stretch: https://dietpi.com/downloads/images/DietPi_NanoPiM2-ARMv7-Stretch.7z => stable!
  
  
  
  • Not supported by Armbian, not even a testing/dev image available, not supported by Armbian build tools as well: https://github.com/armbian/build/tree/master/config/boards
  
  
  • FriendlyARM provides only outdated Linux 3.4 images, where even Stretch-support is critical, hence Buster will most likely cause more issues then benefits.
  
  
  • Build scripts for Linux 4.4 available, requires testing: https://github.com/friendlyarm/debian_nanopi2
  
  
• [x] NanoPi NEO2 => Buster: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2-ARMv8-Buster.7z => stable!
  
  
  
  • Works for NEO2 Black (2020 version) as well? #3333
  
  
  • EDIT: It does, but does not support boot from eMMC. New image for NEO2 Black created below.
  
  
  • Might solve: #2683
  
  

~- [ ] RPi AlloGUI~
~- [ ] Sparky SBC AlloGUI~

---

New images

• [x] NanoPi NEO2 Black: https://dietpi.com/downloads/testing/DietPi_NanoPiNEO2Black-ARMv8-Buster.7z
  
  
  
  • #3333 Does is allow boot from eMMC? EDIT: It does!
  
  
• [x] NanoPi M4/NEO4: https://dietpi.com/downloads/images/DietPi_NanoPCT4-ARMv8-Buster.7z => stable!
• [x] NanoPi M4V2: Separate image required due to DDR4 vs DDR3 (NEO4/M4/T4): https://dietpi.com/downloads/images/DietPi_NanoPiM4v2-ARMv8-Buster.7z => stable!
• [x] ROCK Pi S: #3365 https://dietpi.com/downloads/testing/DietPi_ROCKPiS-ARMv8-Buster.7z
• [x] PINE H64: #3286 https://dietpi.com/downloads/testing/DietPi_PineH64-ARMv8-Buster.7z
• [x] Odroid C4: #3500

[FredericGuilbault]

The file DietPi_RPi-ARMv6-Buster.7z contain the file DietPi_v6.24_RPi-ARMv6-Buster.img Having the version number inside the compressed file but not outside will cause confusion in the next release.

[MichaIng]

@FredericGuilbault
Why this causes confusion? Having no version string in the 7z filename allows us image updates without having to adjust the download links. Having the version string (v6.25 btw) inside is just an additional info. But IMO this can be indeed removed. Due to auto update on first run (if network available), it is perhaps misleading. Also it is shown in login banner anyway.

Basically having the version string in the img file is how Fourdee handles it and I simply never though about changing it.

@Fourdee
What do you think? Simplify it slightly by removing the version string from .img file? I think for VM images I also never added it 😅.

[FredericGuilbault]

Suddent addition of the version number broke my script as it was expecting zip name and file name to be the same. It's not a big deal, I fixed it right away. But the morning you will update the version number. My script will break agan.

Having a zip file with a changing version number inside make things unpredictable.

maybe If you want a static download link dietpi-lastest could be used

[MichaIng]

Okay, before doing any other coding, creation of Buster images for all supported SBCs, with DietPi v6.28, is the next step.

[MichaIng]

New RPi image ready for testing: https://dietpi.com/downloads/testing/DietPi_RPi-ARMv6-Buster.7z

[Joulinar]

@MichaIng
I was testing the new RPi image on my RPi4B but something seems to be not correct. I tried it multiple times but I was running into same issue always. Somehow DNS is not working.

login as: root
[email protected]'s password:
 ─────────────────────────────────────────────────────
 DietPi v6.28.0 : 01:25 - Thu 26/09/19
 ─────────────────────────────────────────────────────
 - LAN IP : 192.168.0.12 (eth0)
[  OK  ] DietPi-Login | Checking network connectivity
[FAILED] DietPi-Login | Checking DNS resolver: ping -c 1 -W 5 one.one.one.one
 ping: one.one.one.one: Temporary failure in name resolution

as this is the first initial boot, I'm not able to enter dietpi-config to check network settings.
Probably something wrong with the TimeSync as it is still displaying an incorrect system time.

[FAILED] DietPi-Login | Unable to continue, DietPi-Login will now terminate.
root@DietPi:~# systemctl status systemd-timesyncd.service
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Thu 2019-09-26 01:24:52 BST; 4min 41s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 288 (systemd-timesyn)
   Status: "Idle."
    Tasks: 2 (limit: 4915)
   Memory: 3.1M
   CGroup: /system.slice/systemd-timesyncd.service
           └─288 /lib/systemd/systemd-timesyncd

Sep 26 01:24:52 DietPi systemd[1]: Starting Network Time Synchronization...
Sep 26 01:24:52 DietPi systemd[1]: Started Network Time Synchronization.
root@DietPi:~#

[MichaIng]

@Joulinar
Many thanks for reporting. I am wondering why there are multiple reports about one.one.one.one resolving issue. It is the globally available hostname for Cloudflares 1.1.1.1 DNS resolver: https://www.dnswatch.info/dns/dnslookup?la=en&host=one.one.one.one&type=A&submit=Resolve

One issue I faced on my VirtualBox machines:
As long as IPv6 is not disabled via dietpi.txt/sysctl, ping will resolve this hostname to an IPv6 address (if nothing cached yet), even if the CONFIG_PREFER_IPV4 setting is enabled in dietpi.txt (default). This is due to preferring IPv4 is something that can only be done on per-program basis, which is done with APT (/etc/apt/apt.conf.d/...) and wget (/etc/wgetrc) but not for the ping command yet (also since it has no config file, AFAIK). My VMs are able to resolve IPv6 addresses but not to connect to them, for some reason, probably since IPv6 is disabled for the whole local network, not sure. Hence I need to disable IPv6 completely on these machine or use ping4/ping -4. Another workaround would be to choose a test domain which has no IPv6 address attached.

What we need to do hence is to check for CONFIG_PREFER_IPV4=1 dietpi.txt entry and add -4 option to the DNS resolve test ping command. I'll add this as part of the planned network setup rework, where DNS test will become a DietPi-Globals function.

But that should be not an issue in 99.5%, also it is not an issue to resolve the address, but only to connect to it:

2020-01-08 23:36:46 root@VM-Buster:~$ ping -6 -W 5 -c 1 one.one.one.one
PING one.one.one.one(one.one.one.one (2606:4700:4700::1001)) 56 data bytes

--- one.one.one.one ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

2020-01-08 23:37:08 root@VM-Buster:~$ ping -4 -W 5 -c 1 one.one.one.one
PING one.one.one.one (1.0.0.1) 56(84) bytes of data.
64 bytes from one.one.one.one (1.0.0.1): icmp_seq=1 ttl=59 time=6.32 ms

--- one.one.one.one ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.317/6.317/6.317/0.000 ms

When disabling IPv6, ping will automatically resolve to IPv4 addresses in every case.

---

@Joulinar
Could you run the following tests:

ping -c 1 one.one.one.one
ping -4 -c 1 one.one.one.one

[Joulinar]

@MichaIng
I don't think it has to do with Cloudflares as the same happen with google.com as DNS resolver

 ─────────────────────────────────────────────────────
 DietPi v6.28.0 : 02:25 - Thu 26/09/19
 ─────────────────────────────────────────────────────
 - LAN IP : 192.168.0.12 (eth0)
[  OK  ] DietPi-Login | Checking network connectivity
[FAILED] DietPi-Login | Checking DNS resolver: ping -c 1 -W 5 google.com

Once terminated the install agent, it can't resolve anything.

[FAILED] DietPi-Login | Unable to continue, DietPi-Login will now terminate.
root@DietPi:~#
root@DietPi:~# ping -c 1 one.one.one.one
ping: one.one.one.one: Temporary failure in name resolution
root@DietPi:~# ping -c 1 google.com
ping: google.com: Temporary failure in name resolution
root@DietPi:~# ping -4 -c 1 one.one.one.one
ping: one.one.one.one: Temporary failure in name resolution
root@DietPi:~# ping -4 -c 1 google.com
ping: google.com: Temporary failure in name resolution

Qestion: could that be that /run/resolvconf is missing??

On the new Image

root@DietPi:~# ls -l /run/resolvconf
ls: cannot access '/run/resolvconf': No such file or directory
root@DietPi:~#

On my current prod system RPi 3 Model B+ v6.26.3

root@DietPi:~# ls -l /run/resolvconf
insgesamt 4
-rw-r--r-- 1 root root   0 Jan  3 11:17 enable-updates
drwxr-xr-x 2 root root  80 Jan  8 19:30 interface
-rw-r--r-- 1 root root 172 Jan  8 19:30 resolv.conf
root@DietPi:~#

EDIT
I found this one in journalctl
Jan 09 00:17:29 DietPi4 ifup[348]: mkdir: cannot create directory '/etc/resolvconf/run': File exists

[MichaIng]

@Joulinar
Uii, yes this is a good reason. I made some workaround to resolve hosts correctly from within the container, I guess the copy forth and back went wrong with the symlink 😅. I'll check and repair.

---

Okay, nothing about the symlink, the resolvconf service simply has not been enabled as I placed a mask to run systemd-nspawn. The package is not installed/enabled on raw Raspbian Lite, and the APT postinst script/systemctl skips enabling a new systemd unit if a mask is in place.

New archive is being packed. ... done

[Joulinar]

ok the DNS is working now but NTPD is still giving some strange messages during initial setup

login as: root
[email protected]'s password:
 ─────────────────────────────────────────────────────
 DietPi v6.28.0 : 00:57 - Fri 10/01/20
 ─────────────────────────────────────────────────────
 - LAN IP : 192.168.0.12 (eth0)
[  OK  ] DietPi-Login | Checking network connectivity
[  OK  ] DietPi-Login | Checking DNS resolver
[  OK  ] DietPi-Run_NTPD | systemctl restart systemd-timesyncd
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[ INFO ] DietPi-Run_NTPD | NTPD: Waiting for completion of systemd-timesyncd (1/60)
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[  OK  ] DietPi-Run_NTPD | NTPD: systemd-timesyncd synced
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[  OK  ] NTPD: Network time sync | Completed

But it seems to be gone after first reboot. At least it was irritating me to see something in red pacing by 😃

[MichaIng]

@Joulinar
Nothing to worry about, yes systemctl daemon-reload or reboot solves it. It is a bid unexpected since nothing touches the unit file, but I faced this as well by times in rare cases without any actual change done. Not sure if some journaling/kernel/fsck write or such can trigger this.
To be sure I tested if changing the config file /etc/systemd/timesyncd.conf (which is done on first boot) triggers this warning, but it doesn't. As well systemd unit infrastructure has no change to recognise this as this config is read binary-internal.

[MichaIng]

New Rock64 Buster image is ready for testing. It has been created within a systemd-nspawn container, hence real hardware test is required: https://dietpi.com/downloads/testing/DietPi_Rock64-ARMv8-Buster.7z

[FrostyMisa]

Hello MichaIng, I have same problem like Joulinar, i get this message again and again:
[ OK ] DietPi-Run_NTPD | systemctl restart systemd-timesyncd
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[ INFO ] DietPi-Run_NTPD | NTPD: Waiting for completion of systemd-timesyncd (1/60)
Even I try to "systemctl daemon-reload", this command do nothing and I reboot many times, change NTP to geteway, change back...
And because I cant get time sync, I cant do anything. I cant update, I cant install something. I cant finish installer after set password, because of this. I never have this problem before, but today i downloaded your new image and its like this. I have new raspberry 4b.
Edit: I can ping everything, I get normal result. Connected over LAN.
Edit2:
─────────────────────────────────────────────────────
DietPi v6.28.0 : 01:38 - Thu 26/09/19
─────────────────────────────────────────────────────

• LAN IP : 192.168.1.142 (eth0)
  [ OK ] DietPi-Login | Checking network connectivity
  [ OK ] DietPi-Login | Checking DNS resolver
  [ OK ] DietPi-Run_NTPD | systemctl restart systemd-timesyncd
  Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
  [ INFO ] DietPi-Run_NTPD | NTPD: Waiting for completion of systemd-timesyncd (1/60)
  Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
  [ INFO ] DietPi-Run_NTPD | NTPD: Waiting for completion of systemd-timesyncd (2/60)
  Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
  [ INFO ] DietPi-Run_NTPD | NTPD: Waiting for completion of systemd-timesyncd (3/60)
  Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
  [ INFO ] DietPi-Run_NTPD | NTPD: Waiting for completion of systemd-timesyncd (4/60)
  Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
  [ INFO ] DietPi-Run_NTPD | NTPD: Waiting for completion of systemd-timesyncd (5/60)
  Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
  [ INFO ] DietPi-Run_NTPD | NTPD: Waiting for completion of systemd-timesyncd (6/60)
  ^Croot@DietPi:~# systemctl daemon-reload
  root@DietPi:~# systemctl restart systemd-timesyncd
  Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
  root@DietPi:~#

[MichaIng]

@FrostyMisa
Could you please open a new issue, since your problem is a different one. First ideas:

• Did you try to give it some more time, e.g. the 60 seconds maxing out?
• Did you try the most generic NTP pool: pool.ntp.org
• If all of this does not work, please paste: journalctl -u systemd-timesyncd

But as said, please open a new issue for the above 😉.

[Joulinar]

@MichaIng
Not sure if you already know, but today I was able to replicate an issue on the new RPi v6.28 image.
The problem is, that you gonna stuck during first Initial boot/setup if system will be started without valid network connection. This could happen if you try using WiFi right from the beginning but used some incorrect credential in dietpi-wifi.txt. Another case would be using STATIC IP but setup wrong gateway.

The initial setup stuck due to missing network and offers to enter dietpi-config. However this is not possible because of the following message: First-run setup has not reached sufficient state. Please reboot before using DietPi-Config. If this issue persists, please report this as bug. Even leaving the setup process did not change anything. No chance to fix the incorrect network setup. The only option left is to reboot wich will bring you back to the failed initial setup process 😉

I crosschecked it with the old v6.25 image and there it was possible to adjust the network if it fails during first run.

[MichaIng]

@Joulinar
Indeed dietpi-config must be available even prior to firstrun update currently. It is an edge case and one can manually fix things as usual, but I agree that for less experienced users this is a stuck situation.

I will remove the firstrun update requirement from dietpi-config for v6.29 and patch this into new images as well. DietPi v6.29 shall have some targeted config options directly from within the error handler anyway.

EDIT done: https://github.com/MichaIng/DietPi/commit/a8f5579262d104f531192683fe7b959ae7bc8f94

[MichaIng]

New RockPro64 image based on Armbian Debian Buster, ready for testing: https://dietpi.com/downloads/testing/DietPi_RockPro64-ARMv8-Buster.7z

[MichaIng]

New Pinebook image based on Armbian Debian Buster, ready for testing: https://dietpi.com/downloads/testing/DietPi_Pinebook-ARMv8-Buster.7z

[MichaIng]

New NanoPC T4 image based on Armbian Debian Buster, ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPCT4-ARMv8-Buster.7z

• Note that this is no eMMC installer image but a simple SDcard image. Once can flash it to eMMC via adapter or from running system via dd, preferably after remounting the file system R/O.

[MichaIng]

New Firefly RK3399 image based on Armbian Debian Buster with mainline Linux 5.4: https://dietpi.com/downloads/testing/DietPi_FireflyRK3399-ARMv8-Buster.7z

[MichaIng]

New Sparky SBC image based on our old one, reviewed, cleaned and updated, including some kernel drivers, ready for testing: https://dietpi.com/downloads/testing/DietPi_SparkySBC-ARMv7-Stretch.7z

[MichaIng]

New Odroid N2 image based on Meverics Debian Buster minimal image, available for testing:

• Download: https://dietpi.com/downloads/testing/DietPi_OdroidN2-ARMv8-Buster.7z
• Pre-image: https://forum.odroid.com/viewtopic.php?f=179&t=35658
• As can be read, Kodi GPU acceleration is not yet 100% supported, X11 acceleration never was on this device.

[MichaIng]

Odroid C1 image creation

🈴 systemd-nspawn boot fails with:

# systemd-nspawn -bD m
Spawning container m on /root/m.
Press ^] three times within 1s to kill container.
systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
Detected virtualization systemd-nspawn.
Detected architecture arm.

Welcome to Debian GNU/Linux 10 (buster)!

Set hostname to <DietPi>.
Failed to enqueue loopback interface start request: Operation not supported
Caught <ILL>, core dump failed (child 3, code=killed, status=4/ILL).
Exiting PID 1...
Container m failed with error code 255.

• It is about the lo network interface, but I cannot find any reason why this is "not supported". CAP_NET_ADMIN and even CAP_SYS_ADMIN does not change anything.
• This is true for the current Armbian dev image as well as when using their build tools to compile an own one.
• I purged the image down, including all kernel/bootloader and firmware, all non-Debian packages, reinstalled many system packages to assure original config files and checked/removed all non-defaults. So I currently lack any idea what is different between this image any all the other Buster images which work fine 🤔.
• For now I'll just update our Stretch image and will retry to create a Buster image from scratch via debootstrap, something I want to do with all our images somewhere in the future, after educating myself about this a bid more.
  

  EDIT: Bug with qemu-user-static v4, affecting all ARMv7 images. After manual downgrade all images work fine. Odroid C1 Buster image on the way 😃.

[MichaIng]

Odroid C1 Buster image, based on Armbian, ready for testing: https://dietpi.com/downloads/testing/DietPi_OdroidC1-ARMv7-Buster.7z

[MichaIng]

New Odroid N1 Buster image, based on Meverics kernel and repo, ready for testing: https://dietpi.com/downloads/testing/DietPi_OdroidN1-ARMv8-Buster.7z

[MichaIng]

New Odroid XU4 Buster image, based on Meverics kernel and repo, ready for testing: https://dietpi.com/downloads/testing/DietPi_OdroidXU4-ARMv7-Buster.7z

[MichaIng]

New Odroid C2 Buster image, based on Meverics kernel and repo, ready for testing: https://dietpi.com/downloads/testing/DietPi_OdroidC2-ARMv8-Buster.7z

[MichaIng]

New NanoPi M1 Plus Buster image, based on Armbian, ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiM1Plus-ARMv7-Buster.7z

[MichaIng]

New NanoPi K1 Plus Buster image, based on Armbian, ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiK1Plus-ARMv8-Buster.7z

[MichaIng]

New NanoPi NEO2 Buster image, based on Armbian, ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiNEO2-ARMv8-Buster.7z

[MrGlasspoole]

Not working on Odroid C1+

There happens nothing. Black screen and the blue LED is just always on.

[MichaIng]

@MrGlasspoole
I read through your thread in the forum (ours and Armbian) as well.

• Did I get it right that the latest Armbian image has the same issue for you? That's what we used for our latest Buster beta image as well.
• SDcard boot works fine including HDMI? I thought about unsupported resolution by monitor first, but that should affect SDcard boot as well of course.
• If you have the same issue with our current stable Stretch image, then it must be specific to your board, or eMMC specific.

As you also reported issue with the legacy Jessie image, possibly there is an issue with your hardware. If you have a chance to switch PSU and/or eMMC module, this would be a chance to verify or rule that hardware out.

I'll also have a look into the uboot config /boot/boot.cmd to check if there is a eMMC switch required e.g.

[MrGlasspoole]

Hi, I'm not using eMMC. Its a SD.

Armbian 5.38 Jessie (3.10.107) and the Hardkernel Ubuntu 18.04.3 minimal (3.10) work.

With the DietPi Jessie i get:

-bash: /DietPi/dietpi/login: No such file or directory
-bash: /DietPi/dietpi/func/dietpi-globals: No such file or directory

And i guess that's not a hardware problem.

After Joulinar gave me this link (i didn't found through the Armbian download site): https://www.armbian.com/odroid-c1/

Under kernel issues i see: serial console only
Does that mean no HDMI? Or does it just mean no desktop/GUI?

Because somewhere i did read without a newer kernel from Hardkernel there is no HDMI.

[Sudrien]

Odroid HC1 -

root@DietPi:~# dietpi-update

DietPi-Update
─────────────────────────────────────────────────────
Phase: Checking for available DietPi update

[ INFO ] DietPi-Update | Checking mirror: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
[ INFO ] DietPi-Update | No response from: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6 ()
[ INFO ] DietPi-Update | Checking mirror: https://dietpi.com/downloads/dietpi-update_mirror/master/server_version-6
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
[ INFO ] DietPi-Update | No response from: https://dietpi.com/downloads/dietpi-update_mirror/master/server_version-6 ()
[FAILED] DietPi-Update | Unable to access any update server. Please check your network connection, then rerun dietpi-update.
If this error persists, please report at: https://github.com/MichaIng/DietPi/issues

System time is good, apt update appears to work.

[MichaIng]

@MrGlasspoole
Hmm, I saw that also. But usually HDMI works, only GPU/hardware accelerated video features are definitely disabled with the new mainline kernel. Did you try this Armbian image, to rule out it's DietPi-specific? https://dl.armbian.com/odroidc1/Buster_current_minimal_nightly
Did you try to SSH into the system after giving it some minutes to boot and finish firstrun setup steps?

@Sudrien
Many thanks for your report. On one base image, while creating this particular image, I got the same error. Strangely after DietPi-PREP has finished it was gone, also test boot within container worked fine 🤔. Another user reported the same, so I'll retest.
Meanwhile, could you try the following:

apt install --reinstall curl libcurl4
curl -sSL https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6

[kaputtzich]

curl error could be fixed with the commands
update-ca-certificates
update-ca-certificates --fresh

did a reinstall of "ca-certificates" "curl" and "libcurl4" before, maybe it's needed

[MichaIng]

@kaputtzich
Interesting. ca-certificates reinstall is also what I did when facing the issue, and the certificate updates was included in the post-install script, but resulted in 0 new/updated/removed certificates, hence no change :thinking:.

[MrGlasspoole]

@MichaIng, the last Armbian i tried was
Armbian_20.05.0-trunk.034_Odroidc1_buster_current_5.4.17_minimal
and the result is the same. Not booting.

And the answer at the Armbian forum is. Well...

Here is what works and what doesn't:
https://dietpi.com/phpbb/viewtopic.php?p=22313&sid=205966b8e95d5eb6b7b1ad34dde6ba07#p22313

[Sudrien]

@MichaIng The reinstall of curl gave me no change.

@kaputtzich's suggestion of

update-ca-certificates --fresh

did work - it did need the fresh option - without the curl reinstall. /etc/ssl/certs does seem to be missing a lot of .0 soft links that the working system has - for example

lrwxrwxrwx 1 root root 13 Feb 7 23:39 a94d09e5.0 -> ACCVRAIZ1.pem - present on working system
lrwxrwxrwx 1 root root 48 Feb 7 23:39 ACCVRAIZ1.pem -> /usr/share/ca-certificates/mozilla/ACCVRAIZ1.crt - present on both working and broken

That's the only difference I'm noticing, but it appears that everything has a .0 softlink after the fresh-ening

(Install proceeded as expected after that, thank you!)

[MichaIng]

Uploaded new Odroid XU4 beta image with fixed curl/ca-certificates

[MichaIng]

New NanoPi M1/NanoPC T1 Buster image, based on Armbian: https://dietpi.com/downloads/testing/DietPi_NanoPiM1-ARMv7-Buster.7z

[MichaIng]

New NanoPi NEO Buster image, based on Armbian, ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiNEO-ARMv7-Buster.7z

[MichaIng]

New NanoPi NEO Air Buster image, based on Armbian, ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiNEOAir-ARMv7-Buster.7z

[MichaIng]

New NanoPi M2 + NanoPC T2 Stretch image, ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiM2-ARMv7-Stretch.7z

Regarding Buster:

• Not supported by Armbian, not even a testing/dev image available, not supported by Armbian build tools as well: https://github.com/armbian/build/tree/master/config/boards
• FriendlyARM provides only outdated Linux 3.4 Debian Jessie images, where even Stretch-support is critical, hence Buster will most likely cause more issues then benefits.
• Build scripts for Linux 4.4 available, requires testing: https://github.com/friendlyarm/debian_nanopi2
  Probably we can also use their current/latest build scripts (for creating Ubuntu+Android-based images, Debian support was dropped) to compile + update the kernel + bootloader on our Debian image to Linux 4.4, then dist-upgrade to Buster: https://github.com/friendlyarm/sd-fuse_s5p4418
• As I will not find time to play with this, I would be happy if someone else finds time to go through this on the actual M2/T2 device (I can only do that within ARMv7 container). Basically its compiling kernel image + modules from their sources, dd bootloader to the specific bits of the drive/image, copy initramfs image, configs and dtoverlays into place. Not sure about the /lib/firmware parts.
• In theory things could be copied from their eflasher image as well, although not sure if there is something Ubuntu-specific: http://112.124.9.243/dvdfiles/S5P4418/rootfs/rootfs-eflasher.tgz
  Only bootloader must be flashed (dd) manually into place, since this is not placed on the file system.

[JaScoMa]

Trying the RockPro64 Buster image and everything seems to be working fine except for the Reboot.

Whether its a reboot by the system or the reboot command, it just shuts the system down. I have to press the power button to turn the system back on. The internal "red' and "white" system LED's are lit after telling the system to reboot.

Thank you..

[MichaIng]

@JaScoMa
Thanks for testing and reporting. I would declare it as minor known issue. Just checking if this is known to Armbian. The download page says: https://www.armbian.com/rockpro64/

• short-pressing (~1s) the power button turns the board on, long-pressing it (~3s) turns it off. If it gets stuck while halting, press the reset button. If it does not boot (ie the white led does not come up), reset, then power on.

Generally keep the kernel/firmware packages up-to-date: apt update && apt full-upgrade

The forum throws some issues that sound similar, but not with RK3399 or RockPro64. So before reporting there, it should be tested with official Armbian image first.

[JaScoMa]

I ran dietpi-update, G_AGUP and G_AGDUG after the installation but the reboot issue still occurred. Tried the above apt update && apt full-update and it reported that it was fully up to date. I'll keep an eye on it and report any other issue I may run into. But seems good thus far. Thank you.

[MichaIng]

@JaScoMa
If you (or some other RockPro64 owner) are in mood, you could test the official Armbian Debian Buster server image: https://www.armbian.com/rockpro64/#kernels-archive-all
If the issue is the same there, it can be reported to Armbian forum: https://forum.armbian.com/forum/11-other-supported-boards/

[JaScoMa]

Actually reboot is working, just takes a lot longer as compared to Stretch. Averages about 70 seconds from connection lost at reboot to first response to ping; the ping fails to respond after about 5 seconds after the reboot command.

Tried doing a dietpi-services stop prior to the reboot, but no change in the amount of time.

[Joulinar]

@JaScoMa
pls can you past output of systemd-analyze blame

[MichaIng]

Yes, also when having a screen attached it would be interesting to know if shutdown phase or boot phase takes so long.

[JaScoMa]

Hello..
Attached is the output to the systemd-analyze blame command.

I rebooted with a screen attached and it only took a number of seconds to go blank once I issued the reboot command. The screen sat there without an input for about a minute until it appeared with what looks like a normal boot-up procedure. At the same time, when the screen appeared, the device started responding to pings.

I am using an eMMC storage device instead of the SD card. My only thought it maybe there's a time-out with the system looking to boot off a SD card which isn't there, then finally trying the eMMC, finding it and booting. As you will see with the blame command, it only takes 10-15 seconds for the system to boot.

I do have a spare SD card which I can throw DietPI on and see if there's any change.

Thank you..

blame.txt

[MichaIng]

@JaScoMa
Okay yeah there are some other issues reported in combination with eMMC boot. Is this only an issue on reboot or boot after full shutdown as well?

[JaScoMa]

Tried both a SD card with Buster and another with Stretch. Obviously they're slower than the eMMC, but for Buster, it took over a minute to reboot and with Stretch, it took about 30 seconds to reboot.

So it appears as though no matter which drive is used, Buster just takes longer to reboot.

[MichaIng]

Our stretch image is based on friendlyarm official kernel, but they do not offer Debian images anymore. Armbian uses modern mainline kernel but with a more generic approach, more kernel features enabled and such. Also buster might be slightly more heavy, at least binaries are growing usually with every new update. So this might be an issue with buster + armbian 5.X Linux in general :thinking:.

[gurabli]

Can I use the new beta image with Bustet on Neo2 (not the new black edition) with an sdcard? I would need newer kernel (Buster) for a DVB-C stick. Is it safe to use and can I update the beta image without flashing? Since I don't have access to the device, only over internet.
Edit: I mean, I will install beta on Sd card from image, but later I would like to use dist-upgrade to update to newer (or final) new image, without reflashing.

[MichaIng]

@gurabli
Yes the new NEO2 image has been tested by others already, generally they work, as SDcard image even on NEO2 black. But I'm currently creating a new image for NEO2 black as well.

You cannot use the image without flashing, but you could try to dist-upgrade your image to Buster + switch the kernel/firmware packages to Armbian. But that might break existing software configs and require post-tinkering, depending on how much additional software you have installed, just to have it mentioned 😉.

[gurabli]

@MichaIng Thank you!
For the first time I will flash the image. But for new releases I can update over ssh, without flashing again?

I use Armbian now, but I like the concept of DietPi better and want to try on long term. For example, Armbian is always late on Wireguard version update, and dkms is broken for long time now.

[MichaIng]

@gurabli
Yes you can update the DietPi version via "dietpi-update" cmd. Only distro upgrades (underlying Debian version) are not done by this and not officially supported due to the hard to estimate result and possible follow-up issues.

Note that DietPi for NEO2 is based on Armbian as well, same kernel and bootloader etc. For WireGuard we use the official Debian packages from Bullseye repo: https://packages.debian.org/bullseye/wireguard
But more importantly WireGuard has not been enabled for all devices, especially not for the NEO2 or any Armbian-based images for now. Our old image did not contain kernel headers and none were available from FriendlyARM for this particular version anymore, hence no chance to compile WireGuard module there. Armbian has kernel header packages, hence this is generally possible. We'll implement some generic WireGuard install support for Armbian-based systems for retesting soon, but we ran into issues with them as well, e.g. I remember WireGuard module build failed on Rock64 with some strange Python-related issue that we were not able to resolve.

Since Armbian has wireguard-tools packages in their repo, I think they rely on Linux 5.X builtin WireGuard? Until this has been moved to Linux stable, AFAIK done with Linux 5.6, I would always go with the up-to-date DKMS module.

[MichaIng]

New NanoPi NEO2 Black image ready for testing. The NEO2 image works as well on SDcard but seems to not allow boot from eMMC. Probably this NEO2 Black specific image does: https://dietpi.com/downloads/testing/DietPi_NanoPiNEO2Black-ARMv8-Buster.7z

[MichaIng]

Initial NanoPi M4v2 Buster image, based on Armbian, ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiM4v2-ARMv8-Buster.7z

[JaScoMa]

Something I've noticed after running Buster on the RockPro64 for a few days; the CPU temperature is running warm compared to Stretch. SSH'd into it this morning and it was showing its temperature at 125 degrees F when prior it would run at or below 100 degrees. It usually didn't get that high unless I was watching a movie or something; I have Emby running on it. Thanks..

[MichaIng]

@JaScoMa
Many thanks for your report. Did you check/compare CPU clocks, max and actual ones due to frequency scheduling?
Full overview should give:

cat /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state

It shows how much overall time the CPUs ran at which frequency since boot. So it shows min/max frequency as well as how they were used.

[MichaIng]

New NanoPi NEO4 only image: https://dietpi.com/downloads/testing/DietPi_NanoPiNEO4-ARMv8-Buster.7z

To compare especially boot speed with the NanoPC T4 image, which boots on NEO4 as well, but with quite long boot time: https://github.com/MichaIng/DietPi/issues/2260#issuecomment-585536405

[MichaIng]

NanoPi M4 image ready, same as for NEO4 above: https://dietpi.com/downloads/testing/DietPi_NanoPiM4-ARMv8-Buster.7z

[maartenlangeveld]

NanoPi NEO2 image (Buster)

Cannot get my NanoHatOled to work, seems beta Buster image does not support i2c devices.
ls -l /dev/ does not show any i2c devices.

Cannot enable i2c:

root@DietPi-DNS:~# /DietPi/dietpi/func/dietpi-set_hardware i2c enable

 DietPi-Set_hardware
─────────────────────────────────────────────────────
 Mode: i2c (enable)

[ INFO ] DietPi-Set_hardware | Input name (i2c) is not supported by NanoPi NEO 2 (aarch64). Nothing has been applied.
[  OK  ] i2c enable | Completed

[MichaIng]

New image for Pine H64, based on Armbian Buster, ready for testing: https://dietpi.com/downloads/testing/DietPi_PineH64-ARMv8-Buster.7z

New image for ROCK Pi S, based on official Radxa Debian Buster, ready for testing: https://dietpi.com/downloads/testing/DietPi_ROCKPiS-ARMv8-Buster.7z

• Since Armbian and Radxa both ship Linux 4.4, we went with the official Radxa image for now, also to test its usage and the contained Radxa APT repository for kernel and firmware.
• But the kernel subversion already lacks behind the one of Armbian (4.4.137 vs. 4.4.207) and is missing some kernel features, however especially in terms of firmware Radxa might turn out better for now. We'll switch most likely when Armbian releases a mainline kernel 5.X image for this device without major feature lack.

[maartenlangeveld]

NanoPi NEO2:

I get following 'error' messages with 'apt update' :

N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'https://build.openvpn.net/debian/openvpn/stable buster InRelease' doesn't support architecture 'armhf'
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://build.openvpn.net/debian/openvpn/stable buster InRelease' doesn't support architecture 'arm64'

root@DietPi-DNS:/# apt update
Hit:2 https://deb.debian.org/debian buster InRelease
Hit:3 https://deb.debian.org/debian buster-updates InRelease
Hit:4 https://deb.debian.org/debian-security buster/updates InRelease
Hit:5 https://deb.debian.org/debian buster-backports InRelease
Hit:6 https://deb.debian.org/debian unstable InRelease
Hit:1 https://apt.armbian.com buster InRelease
Hit:7 https://build.openvpn.net/debian/openvpn/stable buster InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'https://build.openvpn.net/debian/openvpn/stable buster InRelease' doesn't support architecture 'armhf'
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://build.openvpn.net/debian/openvpn/stable buster InRelease' doesn't support architecture 'arm64'

[MichaIng]

@maartenlangeveld
Indeed https://build.openvpn.net/debian/openvpn supports only x86 systems. Did you apply this source manually or a faulty 3rd party installer? Please don't say PiVPN installer placed this 😱?

Hmm, I am actually not happy with Armbian images adding armhf architecture to dpkg on arm64 devices. Mixing packages with different architectures can cause issues and should be only done targeted for single packages that are really not available for arm64 otherwise. Also it doubles reads and writes of all APT tasks... Before moving the images to stable I'll repack them and remove the armhf arch.

dpkg --remove-architecture armhf

• Only thing to check if there is some Armbian kernel/firmware package available for armhf only, which would then be a good reason why they add it.

The same is true for our own x86_64 images which have the i386 architecture added 😅. I always wanted to go through our installs, add it only where required and remove from the images.

dpkg --remove-architecture i386

[maartenlangeveld]

@MichaIng

Please don't say PiVPN installer placed this 😱?

I am sorry to say but PiVPN did this...

Let me now when it's safe to remove armhf architecture, please.
dpkg --remove-architecture armhf

[MichaIng]

@maartenlangeveld

Let me now when it's safe to remove armhf architecture, please.

Just checked and all by default installed kernel/bootloader/firmware packages are available for arm64 architecture, no need for armhf. If at any point any package that is expected to be present in the repo, cannot be found, it can be easily readded: dpkg --add-architecture armhf

I am sorry to say but PiVPN did this...

... my goodness, at least we're not the only ones who create dumb bugs 😅.

[maartenlangeveld]

@MichaIng

Again, many thanks!!

[MichaIng]

@maartenlangeveld
I added a PR to PiVPN for fix: https://github.com/pivpn/pivpn/pull/963
I think they didn't recognise it during tests since apt update during script execution is hidden and its exit code is not handled. Hence the error only shows up when running apt update again afterwards, especially when error handling it as we do.

It this is not added to stable/release until DietPi v6.29 release, I'll add a workaround to remove the repo right after PiVPN installer has been executed.

---

EDIT: Merged quickly, that is great! Most likely no need for us to apply a workaround.

[maartenlangeveld]

@MichaIng

That's a quick response, they're fast ! Thanks !

[MichaIng]

@maartenlangeveld
There are some other similar issues, like x86 kernel headers being installed on non-x86 systems, when WireGuard is chosen. Discussed in the same PR. I was already interested about how they manage generic WireGuard install but actually they do not. Likely WireGuard will then only be offered for systems where kernel headers are clearly available with known packages (package names), hence x86 systems on Ubuntu and Debian + RPi on Raspbian. In all other ARM cases the issue is the same that we face: A large number of different custom package naming schemes, depending on kernel/firmware repo, if there is one at all. On Armbian header package name can be derived but our last test installs failed somewhere within Python code execution, needs retest.

[UNiXMIT]

The Pine A64 image seems more stable than the latest stable image. I had issues starting from fresh with the stable image (http://bit.ly/2TwNjP4) so I tested the Buster Pine A64 image and so far so good. Got everything installed back on it again and it's working without issue so far.

[MichaIng]

@UNiXMIT
Many thanks for testing and feedback. Yes I can imagine that the new images work smoother in many cases since the old ones meanwhile run through a lot of DietPi updates at first start and the Armbian packages as well changed a lot.

[UNiXMIT]

@MichaIng
I've finished setting it up now and it's worked amazingly. The only issue I came across was some problem when it tried to ping one.one.one.one but a retry and it worked fine the second time. Not sure what that was. I'll report back If I discover any issues. Thanks so much

[UNiXMIT]

@MichaIng
Actually 1 other thing. When trying to increase swap space i tried setting it to 1 for auto but it didn't change anything. I had to set 2000 instead. That might be correct behavior in my case but I'm not sure to be honest. Thanks

[MichaIng]

@UNiXMIT
Setting 1 should be the default value: https://github.com/MichaIng/DietPi/blob/master/dietpi.txt#L44
It only creates a swap file then if the physical RAM size is less then 2 GiB, so that practically 2 GiB are available in every case. If you need more RAM, indeed you need to enter a custom value indeed.

[UNiXMIT]

@MichaIng
When I went into the settings initially, swap size was set to 55. I tried changing it to 1 but it reverted to 55. In the end I just set it to 2000 myself. So that's fine.

[MichaIng]

@UNiXMIT
This is since your model has practically 1993 MiB physical RAM available (free -m), the option then adds 55 MiB so that 2048 MiB are available overall. Probably we have to disable it fully when less then 100 MiB would be added to avoid such tiny swap files 🤔.

[gary2002]

I have received an ODROID-N2 with 4GB RAM and a 32GB eMMC as the system / boot device.

Stretch boots just fine - a quick boot and then the blue LED shows the "Kernel Running" heartbeat.

Buster (dated 29Jan20) doesn't boot - the blue LED remains on and doesn't get to the "heartbeat" stage.

I haven't had any time to investigate further.

[MichaIng]

@gary2002
Many thanks for testing. I'll check and repack/recreate the image. Also Meveric uploaded a new one, probably this fixed some issue, e.g. with eMMC: http://fuzon.co.uk/meveric/images/Buster/

[gary2002]

Many thanks !!!

[maartenlangeveld]

Hi Michael,

Just an update. Running Buster image on NanoPi NEO2 works great. NanoHatOLED is also working after (manually) applying your fix. No problems so far. My NanoPi NEO2 acts as Pi-hole server (beta 5), including DHCP and unbound DNS-resolver for my local network. Everything works okay.

Thanks again for the great support !

Kind regards,

Maarten, a very happy and content DietPi user :-)

[MichaIng]

@maartenlangeveld
Many thanks for testing and feedback again.

NanoHatOLED is also working after (manually) applying your fix.

This was by enabling the device tree overlay i2c0 via /boot/armbianEnv.txt, right? I hope I find some time to add a generic method to our scripts for all Armbian-based SBCs: Check for overlay-prefix, check for first <prefix>-i2c match in /boot/dts/overlays/*.dtbo and if found add to /boot/armbianEnv.txt overlay setting.

[gary2002]

If I use the Meveric Buster binary - which does boot on the ODROID-N2 - what files and modifications do I have to copy from the existing DietPi Buster image (from the "testing" directory).

I created boot media using Etcher for both DietPi Buster (testing) and Meveric.

I had a quick look and copied some files and scripts across from the DietPi Buster (testing) image to the Meveric.

The ODROID-N2 booted but I was unsure how to proceed to "install" the DietPi customisations.

[MichaIng]

@gary2002
Copying code is not sufficient. Run this script to install DietPi on it:

apt update && apt install curl
bash -c "$(curl -sSL https://raw.githubusercontent.com/MichaIng/DietPi/PREP/PREP_SYSTEM_FOR_DIETPI.sh)"

[gary2002]

Many thanks - tomorrow evening's little task, I think!! ;-)

[MichaIng]

@gary2002
I'm currently rebuilding the image as well, so probably you can skip to do it yourself 😉.

[maartenlangeveld]

@MichaIng
Yes, that solved my issue !

@maartenlangeveld
Many thanks for testing and feedback again.

NanoHatOLED is also working after (manually) applying your fix.

This was by enabling the device tree overlay i2c0 via /boot/armbianEnv.txt, right? I hope I find some time to add a generic method to our scripts for all Armbian-based SBCs: Check for overlay-prefix, check for first <prefix>-i2c match in /boot/dts/overlays/*.dtbo and if found add to /boot/armbianEnv.txt overlay setting.

[MichaIng]

@gary2002
New image is ready: https://dietpi.com/downloads/testing/DietPi_OdroidN2-ARMv8-Buster.7z

[gary2002]

Many thanks - I'll give it a go this evening (Sydney time) and let you know my results.

Thanks!! Gary

[gary2002]

Couldn't wait - flashed, installed, booted like a charm with all of the the now-familiar DietPi setup options.

My migration from an RPi-4 to ODROID-N2 can now proceed.

Many thanks!!

[FusionPlmH]

please update raspberry pi image also， it seem that the device recognize has problems,my devices is rpi3b+,after first unit and reboot, it recognize as rpi ,CPu frequency stuck at 900mhz.

[Joulinar]

@LeeMenHin
pls can you run dietpi-software > 3 : Performance Options > Overclocking > default

Usually this should fix it

[FusionPlmH]

@LeeMenHin
pls can you run dietpi-software > 3 : Performance Options > Overclocking > default

Usually this should fix it

No overclicking avaliable

[MichaIng]

@LeeMenHin
We identify RPi models by their revision code. Can you please paste the output of:

cat /proc/cpuinfo

[FusionPlmH]

[FusionPlmH]

I didn't make any change of cpu config

[Joulinar]

looks like CPU model is not detected correctly. Maybe a new CPU version/type. You can see it as well on the initial screen where device model is just displayed as RPi but should be:

Device model : RPi 3 Model B+ (armv7l)

[FusionPlmH]

I have been try couple of times , same results

[MichaIng]

@LeeMenHin
Hmm, there is a leading 2 that does not belong to the plain revision code: https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
Very strange. I know that there can be a leading 1000, indicating that the RPi has been overvolted. We need to check why/where this comes from. What was the last thing you did with the RPi before it showed the wrong model?

Dirty fix:

sed -i "s/'a020d3'/\*'a020d3'/" /DietPi/dietpi/func/dietpi-obtain_hw_model
/DietPi/dietpi/func/dietpi-obtain_hw_model
/DietPi/dietpi/func/dietpi-banner # should now show the correct model

[FusionPlmH]

Just first time setup and reboot ,get into dietpi-config,then show like this.Btw this problem have been appear from last year,I forgot to report about it

[FusionPlmH]

anyway dirty fix just working at the moment , feel free to find me to fix the problem if needed

[MichaIng]

Another case: https://forum.xda-developers.com/showpost.php?p=80480049&postcount=60
Ask for reason on RPi repo: https://github.com/raspberrypi/firmware/issues/1348

[MichaIng]

@LeeMenHin
Okay, I got it: https://github.com/raspberrypi/documentation/pull/1370/files
So the leading 2 means that your warranty was void. Did you set force_turbo=1 and any over_voltage once?

I will now implement generic RPi hardware info detection based on revision code decoding.

[MichaIng]

Fixed: https://github.com/MichaIng/DietPi/commit/24425e5120fd510084a24f8b2d63896272255367
Yey this allowed to vastly reduce the code 😃.

[FusionPlmH]

Not setting anything keep like the same , and also great to know few hour later already fixed👍👍

[FusionPlmH]

Here is an new issue on Atomic Pi temperature measurement.

Link of the hardware:
https://dlidirect.com/products/atomic-pi

The temperature as below:

─────────────────────────────────────────────────────
DietPi v6.28.0 : 21:54 - 四 2020年03月19日
─────────────────────────────────────────────────────

• Device model : Native PC (x86_64)
• CPU temp : 0'C : 32'F (Who put me in the freezer!)
• LAN IP : XX.XXX.XX.XXX (eth0)
• MOTD : Folding@home takes up the fight against 2019 Corona virus:
  -> https://foldingathome.org/2020/02/27/
  On x86_64 system you can install it via dietpi-software and contribute.
  ─────────────────────────────────────────────────────

DietPi Team : MichaIng (lead), Daniel Knight (founder)
Image : DietPi Core Team (pre-image: Debian mini.iso)
Web : https://DietPi.com | https://twitter.com/dietpi_
Patreon Legends : Bryce
Donate : https://DietPi.com/#donate
DietPi Hosting : Powered by https://MyVirtualServer.com

dietpi-launcher : All the DietPi programs in one place.
dietpi-config : Feature rich configuration tool for your device.
dietpi-software : Select optimized software for installation.
htop : Resource monitor.
cpu : Shows CPU information and stats.

root@DietPi:~#

[MichaIng]

@LeeMenHin
Many thanks for your report. Can you please paste the result of the command I posted here: https://github.com/MichaIng/DietPi/issues/3412#issuecomment-595743388

[gary2002]

─────────────────────────────────────────────────────
DietPi v6.28.0 : 10:49 - Fri 03/20/2020
─────────────────────────────────────────────────────

• Device model : Odroid N2 (aarch64)
• CPU temp : 40'C : 104'F (Optimal temperature)
• LAN IP : 192.168.20.252 (eth0)
• MOTD : Folding@home takes up the fight against 2019 Corona virus:
  -> https://foldingathome.org/2020/02/27/
  On x86_64 system you can install it via dietpi-software and contribute.
  ─────────────────────────────────────────────────────

DietPi Team : MichaIng (lead), Daniel Knight (founder)
Image : DietPi Core Team (pre-image: Meveric)
Web : https://DietPi.com | https://twitter.com/dietpi_
Patreon Legends : Bryce
Donate : https://DietPi.com/#donate
DietPi Hosting : Powered by https://MyVirtualServer.com

dietpi-launcher : All the DietPi programs in one place.
dietpi-config : Feature rich configuration tool for your device.
dietpi-software : Select optimized software for installation.
htop : Resource monitor.
cpu : Shows CPU information and stats.

root@xxx:~# for i in /sys/class/thermal/thermal_zone[0-9]/temp /sys/class/hwmon/hwmon[0-9]/temp[0-9]_input /sys/devices/platform/coretemp.[0-9]/hwmon/hwmon[0-9]/temp[0-9]_input

do
[[ -e $i ]] && echo "$i : $(<$i)"
done
/sys/class/thermal/thermal_zone0/temp : 38600
/sys/class/thermal/thermal_zone1/temp : 40100
root@xxx:~#

On 20-Mar-20, at 05:15, MichaIng [e-mail] wrote:

@LeeMenHin https://github.com/LeeMenHin
Many thanks for your report. Can you please paste the result of the command I posted here: #3412 (comment) https://github.com/MichaIng/DietPi/issues/3412#issuecomment-595743388
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/2979#issuecomment-601336631, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFF4UPC64C24UWDMEWRWVDRIJOLRANCNFSM4H7ZO34A.

[Joulinar]

@maartenlangeveld
As you are running PiHole, your settings are automatically changed to 127.0.0.1. Changing settings in dietpi-config should not have any impact because PiHole is managing your local DNS settings on the device. If you need to change upstream DNS, you would need to change them inside PiHole. For testing purposes, you could switch off PiHole service. Anyway PiHole 5 support will be added with DietPi v6.29. Let me check on my device how this behave for /etc/resolv.conf

However nameserver 1.0.0.1 is not correct. Can you have a look to /etc/resolvconf/resolv.conf.d/head. I guess you will find 1.0.0.1.

[maartenlangeveld]

@Joulinar,

update
I re-installed resolvconf, that did the trick

rm /etc/resolv.conf
apt-mark auto resolvconf
G_AGA
G_AGI resolvconf
reboot

Apologies, I deleted original post and did not see your answer (you were probably in the process of writing).

I cannot find 1.0.0.1. in /etc/resolvconf/resolv.conf.d/head

Probably resolv.conf still gets overwritten by a left-over from Pihole v4. I will contact Pihole devs again.

Thanks for your assistance!

kind regards, Maarten

[maartenlangeveld]

@Joulinar

After re-install of resolvconf local hostnames are not resolved any more. arp shows only IP addresses and no host names.

Do you a idea what is going wrong?

update: resolving now... took some time I guess

[Joulinar]

so all fine now on your image running Pihole 5. correct?

[maartenlangeveld]

@Joulinar

Everything is running fine now. NanoPi NEO2 with Buster image, running Pihole beta v5.

Thanks to you and fellow developers for the great work on DietPi, it's a fine product with great support by it's developers !

[gary2002]

Absolutetly - many thanks.

Gary Speechley

mailto:[email protected]

---- On Fri, 10 Apr 2020 02:14:43 +1000 Joulinar [e-mail] wrote ----

so all fine now on your image running Pihole 5. correct?

—
You are receiving this because you were mentioned.
Reply to this email directly, https://github.com/MichaIng/DietPi/issues/2979#issuecomment-611615501, or https://github.com/notifications/unsubscribe-auth/ACFF4ULBOGNGQ5INIFOFLVLRLXX7HANCNFSM4H7ZO34A.

[tylon85]

Odroid C2

DietPi version: v6.28.0
HW_MODEL: 12
HW_ARCH: 3
DISTRO: 5

• [x] Installation
• [x] First run (set IP automatically)
• [x] Set static IP via DietPi-Config
• [ ] Install additional software Kodi
• [ ] Send an error report

If I try to install Kodi, I get an error, that DietPi is "unable to locate package aml-libs-odroid".

If I try to send the error report, DietPi shows me a message, that something goes wrong and if I want to restart the First-run-config again.

Should I open an issue?

[Joulinar]

@tylon85
No need to open a new request. Should be similar to this one #3417

[StephanStS]

How can I upload an image of the NanoPi NEO Plus 2?

[MichaIng]

@StephanStS
I'll create a new hardware identifier for this now. It is very similar to NEO2 but with WiFi+BT, second USB and eMMC support, enough to require an own device tree.
Done: #3483

[StephanStS]

@StephanStS
I'll create a new hardware identifier for this now. It is very similar to NEO2 but with WiFi+BT, second USB and eMMC support, enough to require an own device tree.
Done: #3483

So shall I quickly generate a new image for the NEO Plus 2 with your changes?
Takes only a few minutes. :-)
If yes: Shall I use dev or beta or stable?

[MichaIng]

@StephanStS
That would be great. Use dev branch of DietPi-PREP, choose it as target branch as well and for DietPi-Imager. But either directly after DietPi-PREP run or when the image has been mounted during DietPi-Imager for changes (on a second SSH session), change back to DEV_GITBRANCH=master in /boot/dietpi.txt. So right after v6.29 stable release, systems will be migrated to stable branch automatically.

[StephanStS]

Ok, I will do that and additionally run some short tests afterwards with the 7z file.

[Joulinar]

with v6.29 the folder ./DietPi/ will be moved to ./boot again. I guess that's the reason why script is already pointing to . /boot/

[MichaIng]

@StephanStS @Joulinar
Ja genau, das host system muss dann ebenfalls auf dem dev branch sein, andernfalls kann man auch den Imager vom PREP branch nehmen, den habe ich extra erstellt bis v6.29 released ist.

[StephanStS]

During the NEO Plus 2 PREP... script I had two times the error message
/boot/dietpi/func/dietpi-set_hardware: line 1278: ((: 57 < 10 && : syntax error: operand expected (error token is "&& ").
It was at these two areas:

• [ SUB1 ] DietPi-Set_hardware > wifimodules (onboard_enable)
• [ SUB1 ] DietPi-Set_hardware > wifimodules (enable)

Do you want to try to fix anything, or shall I go on with dietpi-imager?

[MichaIng]

@StephanStS
You can go on, this is just a visual based on a change today. I'll fix it regardless for next beta + release.

Fixed with: https://github.com/MichaIng/DietPi/commit/ae4e3d91b0b2733d2f9f36559c80a129e36458fe

[StephanStS]

@MichaIng: Images for NanoPi NEO Plus 2 are downloadble from my cloud (there are also updates for ZeroPi, M3, Fire3 with the latest DietPi v6.29 release).

[StephanStS]

@MichaIng: It's still open how and where to upload the finished images.

[MichaIng]

@StephanStS
I downloaded your new images and currently uploading them. I'll create a new download button for the NanoPi NEO Plus2 😄. There is currently no public upload option for images. We have an open request on our VPS provider to increase drive space. If this has been applied, I'll create an upload account for you.

[StephanStS]

@MichaIng: I now have created a Buster image (kernel 5.4) for the NanoPi R2s (with dev-branch). Actually there is no ID for this board, so I have chosen "generic". If you want to add an ID and I shall generate the image again, just inform me.

This board has two ethernet connectors. After the update the WAN port is the active one, this could be noticed anywhere.
How is dietpi-config handling the second interface? I only could configure the WAN port and not the LAN port.
If this board is interesting for testings of the Rework: Network setup project I can offer to do some testings with the R2s board on request.

You can download this R2s image from my cloud (where I also added a ZeroPi image with kernel 5.4).

[MichaIng]

Many thanks for this. Yes indeed for a router system DietPi-Config needs some rework, the current implementation basically allows to configure Ethernet adapter only, the first that is recognised connected. The rework indeed includes configuring each found network adapter/interface individually and then configuring one as www/WAN adapter (although WAN might be wrong wording if it's behind a NAT) and the others as local network adapters. I'm currently playing with some functions and structures about how to build this up. Will be a new script DietPi-Network with whiptail + non-GUI interface, outsourced from DietPi-Config (but available through the same menu as before).

Great about the Linux 5.4 images. I'll check and upload them for testing. Let's see if there are any downsides or lost features, although AFAIK Linux 4.19 before was already mainline kernel and not the official manufacturer one.

[StephanStS]

Shall I also update further 5.4 kernel images (besides the ZeroPi and R2s I did for now)?
As far as I saw at armbian.com, these of my NanoPis could be an option: M1, M1+, M4v2, NEO2, NEO Plus2, NEO4.

[MichaIng]

All other images are already on Linux 5.4, hence this is only relevant for the ones you served 🙂.

[Joulinar]

@MichaIng
I guess you would need to recreate the RPi image with current kernel. There was a RPi4B 8GB version released and there the current image is not working ootb. Atm it's needed to install Raspbian Lite + running PREP script.

https://dietpi.com/phpbb/viewtopic.php?f=11&t=7746

[MichaIng]

Thanks, I recognised it and was thinking if Raspbian (or now "Raspberry Pi OS (32 bit)") is even able to use the 8 GiB? Isn't the new 64 bit version (Debian repo) required for this anyway? It is still in early beta though...

[Joulinar]

yep indeed, a 32bit OS can address a maximum of 4gb of RAM. The actual limit is often less – around 3.5gb – since part of the registry is used to store other temporary values besides memory addresses. Means the 64bit OS would be mandatory to use the full 8gb. However the 32bit will work even if it can't address the full 8gb.

Question is if you like to wait for the 64bit version or if we create an interim 32bit image just in case some more user will get a new RPi.

[StephanStS]

I just ordered a Pi4 8GB (to be sure to be able to generate resp. test an image)...
In a couple of days it shall arrive.

[MichaIng]

New NanoPi M4v2 image ready for testing, which might enhance boot time: https://dietpi.com/downloads/images/testing/DietPi_NanoPiM4v2-ARMv8-Buster.7z

[medevil84]

You can download this R2s image from my cloud (where I also added a ZeroPi image with kernel 5.4).

@StephanStS Would you mind sharing that image? i would like to try it on my new r2s...

[StephanStS]

@medevil84: Can I have an E-Mail address where I can sent you a link to?
This address can then be deleted after I have retreived it that it does not reside here.

[medevil84]

Got it, already downloading! Thanks a lot.

[StephanStS]

@medevil84: Take into account that at first, the LAN port is active (I did not test the WAN port).
After running the DietPi first time boot, the WAN port ist active and the LAN port is not. Possibly you have to switch the LAN cable then.
Afterwards you have to configure them by hand.

[medevil84]

@medevil84: Take into account that at first, the LAN port is active (I did not test the WAN port).
After running the DietPi first time boot, the WAN port ist active and the LAN port is not. Possibly you have to switch the LAN cable then.
Afterwards you have to configure them by hand.

Thanks! I have a usb to ttl key but no pin and solder, so this info will help a lot...

[dzubybb]

So, i installed buster img on NanoPi Neo v1.31. Installation went fine. Some things to mention:

• on start max cpu frequency is 1.368 Ghz, when hw specs for that SBC is max 1.2Ghz. I have radiator on my cpu and everything was fine, but maybe on start it should be max 1.2 or even 1 Ghz (as was in previous image), with option to increase it ?
• serial terminal works fine in both ways (on previous image i was able only to read text, not to type) so nice 👍
• it seems that network card has different mac address that in previous image, cause it got different IP from DHCP server (it is pinned by MAC), but this is not a problem
• unfortunately alsa after installation do not see any sound cards :(

#cat /proc/asound/cards
--- no soundcards ---

# lsmod
Module                  Size  Used by
snd_soc_simple_card    20480  0
sun8i_codec_analog     24576  0
snd_soc_simple_card_utils    20480  1 snd_soc_simple_card
sun4i_i2s              24576  0
sun8i_adda_pr_regmap    16384  1 sun8i_codec_analog
snd_soc_core          131072  4 sun4i_i2s,sun8i_codec_analog,snd_soc_simple_card_utils,snd_soc_simple_card
sunxi_cedrus           32768  0
ac97_bus               16384  1 snd_soc_core
lima                   36864  0
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_pcm                69632  3 sun4i_i2s,snd_pcm_dmaengine,snd_soc_core
sun4i_gpadc_iio        16384  0
snd_timer              28672  1 snd_pcm
industrialio           53248  1 sun4i_gpadc_iio
v4l2_mem2mem           20480  1 sunxi_cedrus
gpu_sched              24576  1 lima
snd                    49152  3 snd_timer,snd_soc_core,snd_pcm
videobuf2_dma_contig    20480  1 sunxi_cedrus
sun8i_thermal          16384  0
videobuf2_memops       20480  1 videobuf2_dma_contig
soundcore              16384  1 snd
videobuf2_v4l2         20480  2 sunxi_cedrus,v4l2_mem2mem
videobuf2_common       36864  3 sunxi_cedrus,v4l2_mem2mem,videobuf2_v4l2
videodev              151552  4 sunxi_cedrus,videobuf2_common,v4l2_mem2mem,videobuf2_v4l2
sun4i_tcon             28672  0
mc                     36864  5 sunxi_cedrus,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2
sun8i_tcon_top         16384  1 sun4i_tcon
evdev                  20480  0
sun8i_mixer            36864  0
uio_pdrv_genirq        16384  0
uio                    16384  1 uio_pdrv_genirq
cpufreq_dt             20480  0
usb_f_acm              20480  1
u_serial               24576  3 usb_f_acm
g_serial               16384  0
libcomposite           45056  2 g_serial,usb_f_acm
ip_tables              24576  0
x_tables               24576  1 ip_tables
autofs4                36864  2
fixed                  20480  2
gpio_keys              20480  0

[MichaIng]

Many thanks for testing. To enable audio, please try the following:

• Edit /boot/armbianEnv.txt
• Add analog-codec to the overlays=, separated with white space.
• reboot

From the readme in /boot/dtb/overlay/:

### analog-codec

Activates SoC analog codec driver that provides Line Out and Mic In
functionality

This seems to be required on all sunxi boards if I see it correctly. Worth it to implement this into dietpi-config audio options to enable onboard audio.

[dzubybb]

@MichaIng thanks, i'll try that. But it will take time, my other sd card has read errors, and new will arrive later in the week.
I tried to use it only for boot by deleting partition from it, and burn image to usb. DietPi boots from usb just fine, but it tries to mount sd card all the time and it causes errors later in update process.
Is there a way to use sd card only for boot, and disable it later after boot ?

[MichaIng]

Is there a way to use sd card only for boot, and disable it later after boot ?

The issue you face is due to the reason that the SDcard and USB drive flashed with the same image will have the same UUID, which should be the unique identifier for the root device mount.

I'm not sure if the NenoPi NEO has native USB boot support. sunxi docs talk about FEL mode: https://linux-sunxi.org/FEL/USBBoot
But actually it looks like this is only to flash bootloader and in case initramfs + Linux to the USB drive.

I would simply try to flash the Image to the USB drive directly and remove the SDcard entirely (to avoid UUID conflict). If this does not work, then you could attach and flash the external drive, copy all data from SDcard (skipping all tmpfs/kernel mounts + /boot) to an external drive. Edit /etc/fstab to add the external drive (with new UUID) as new root mount and alter the old root mount entry to be /boot mount. As well /boot/armbianEnv.txt needs to be altered, replace the roodev=UUID= entry to match the UUID of the new external drive. Would be actually a good start to integrate rootfs move to external drive for single-partition Armbian-based images into DietPi-Drive_Manager.

[dzubybb]

Boot from usb doesn't work, but adding analog-codec to overlay helped with audio, so i'm trying to go all in with the new Buster image. One more thing to mention, mac address isn't pinned by default, it's different on every DietPi boot, which can lead to problems in some setup (as in mine, where dhcp has pinned ip addresses to mac address). I had to add it manually to /etc/network/interfaces.

[dzubybb]

I'm happy to say that everything i had on stretch DietPi image works on Buster :) That is:

• audio on builtin H3 Audio Codec
• pi-hole
• cloudflare DNS-Over-HTTPS proxy
• spotifyd armhf build (thanks to new glibc version), with alsa volume control

Plus things that didn't work on previous image :

• cpu oc (it was max 1 GHz)
• bi-directional serial terminal

Good work 👍

[MichaIng]

One more thing to mention, mac address isn't pinned by default, it's different on every DietPi boot, which can lead to problems in some setup (as in mine, where dhcp has pinned ip addresses to mac address). I had to add it manually to /etc/network/interfaces.

Ah indeed this is an issue. Generally static IP is anyway best to avoid the overhead of a DHCP client daemon but in some cases this is not wanted or not possible. I'll check if there is some possibility to use the hardware MAC or otherwise pin the MAC via u-boot/kernel parameters.

[MichaIng]

@dzubybb
I probably found a solution for the MAC address. Can you please check the following:

Several SBCs (onboard) Ethernet adapters do not have a hardware MAC address. It is set either by u-boot or otherwise randomly on every boot.
For u-boot the environment variable is ethaddr for the first adapter interface (eth0) and it can be set via armbianEnv.txt (respectively boot.cmd/boot.scr directly). ~However, based on a compile-time config, this one might be a one-time thing, so setting it once you might not be able to change it another time, I guess aside of re-flashing u-boot: https://github.com/u-boot/u-boot/blob/master/README
I am pretty sure Armbian compiled u-boot with flexible MAC address but until we know for sure please only set it if you can live with a fixed MAC.~ EDIT: Ah there seem to be a difference between "flashing" the environment into u-boot storage (e.g. via fw_setenv in userspace or saveenv in boot.cmd/boot.scr) and setting/overriding it on boot via mentioned config file.

If fw_printenv does not list the ethaddr variable, or a CRC error is shown, that usually means that there is no stored environment (or the tools are not configured to know where it is), you can try to add the following as new line to /etc/armbianEnv.txt:

ethaddr <mac_addr>

From what I read, it might be necessary to not use any random mac, but a valid one, although not sure what the limitations might be as long as the six 256-bit hexademical blocks are respected of course. However safest and most reasonable is probably to use the currently assigned one: ip l l eth0

[MichaIng]

I opened a new issue to investigate the MAC address topic: #3618
Further discussion there.

I mark this topic as closed since most images have been moved to stable now. Only new devices are still flagged as beta but those have their own issue.