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/

• VirtualBox => Buster, stable!
• VMware => Buster, stable!
• x86_64 PC BIOS => Buster, stable!
• x86_64 PC UEFI => Buster: Image | UEFI compatible x86_64 image #1171, stable!
• RPi => Buster: Image | Raspberry Pi 4 #2935, stable!
• ROCK Pi 4 => Buster: Image | ROCK Pi 4  #2445, stable!
• ASUS Tinker Board => Buster: Asus Tinkerboard install failing #2977, stable!
• Firefly RK3399 => Buster: Image | Firefly RK3399 #1986
• ROCK64 => Buster: Image | ROCK64 Buster #3051, stable!
  • Might solve: Rock64 | 3.5mm audio jack not working #2522
• PINE A64 => Buster, stable!
• ROCKPro64 => Buster, stable!
• Pinebook => Buster, stable!
• NanoPC T4 => Buster: NanoPC T4 | Won't boot with rootfs 0x000B2000, might with 0x00030000 #2142, stable!
• NanoPi M3/T3/F3 => Buster: NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images #3221, stable!
• Sparky SBC => Stretch, stable!
  • Might solve: Sparky SBC | Kernel error trace when switching audio source on USB DAC #2610
  • Debian Buster requires min Linux 3.16 (vs 3.10)
• Odroid N2 => Buster, stable!
• Odroid N1 => Buster, stable!
• Odroid XU3/XU4/MC1/HC1/HC2 => Buster, stable!
  • Might solve: DietPi-Software | Kodi: Video playback freezes after few seconds on Odroid XU4 #2584
  • Fixed: ODROID XU4 incorrect hardware version #2990
• Odroid C2 => Buster, stable!
• Odroid C1 => Buster, stable!
• NanoPi M1 Plus => Buster, stable!
• NanoPi K1 Plus => Buster, stable!
• NanoPi M1/T1 => Buster, stable!
• NanoPi NEO => Buster, stable!
• NanoPi NEO Air => Buster, stable!
  • Probably solves: NanoPi NEO Air | fbtft missing  #2270
• NanoPi M2/T2 => Stretch, 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
• NanoPi NEO2 => Buster, stable!
  • Works for NEO2 Black (2020 version) as well? Image | NanoPi NEO2 Black #3333
    • EDIT: It does, but does not support boot from eMMC. New image for NEO2 Black created below.
  • Might solve: DietPi-Config | NanoPi (NEO2) aplay Audio Hat PCM5102 support #2683

- [ ] RPi AlloGUI
- [ ] Sparky SBC AlloGUI

---

New images: https://dietpi.com/downloads/images/

• NanoPi NEO2 Black
  • Image | NanoPi NEO2 Black #3333 Does is allow boot from eMMC? EDIT: It does!
• NanoPi M4/NEO4 => stable!
• NanoPi M4V2: Separate image required due to DDR4 vs DDR3 (NEO4/M4/T4) => stable!
• ROCK Pi S: Image | ROCK Pi S #3365
• PINE H64: Image | PINE H64 #3286
• Odroid C4: Image | 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/

[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
root@192.168.0.12'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
root@192.168.0.12'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/images/

[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: a8f5579

[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?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/

[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:

fw_printenv

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.