Image | Orange Pi Zero2

[mrx23dot]

Creating an image request

Formal device information

• Device name | Orange Pi Zero2
• Official product URL | http://www.orangepi.org/Orange%20Pi%20Zero2/
• GitHub resource URL (if available) | https://github.com/orangepi-xunlong/orangepi-build
• Image download URL | http://www.orangepi.org/downloadresources/OrangePiZero2/2020-11-04/orangepi3_8849be56b419022d3a1780ac6d.html
  or https://www.armbian.com/orange-pi-zero-2/

Is the SBC officially supported by the Debian installer?

• yes http://www.orangepi.org/downloadresources/
• https://www.armbian.com/orange-pi-zero-2/

Vote for this image on FeatHub: https://feathub.com/MichaIng/DietPi/

https://feathub.com/MichaIng/DietPi/+225

[MichaIng]

Many thanks for your request. Please see my response on the last Orange Pi request: #4227 (comment)

[mrx23dot]

Thanks, I will try to convert it.
Don't understand why armbian guys don't reduce SD writes.

[MichaIng]

Don't understand why armbian guys don't reduce SD writes.

They also do a few things, e.g. make /var/log a zram device (instead of a tmpfs like us), APT list compression and such. But their priorities/focus is different as they especially do kernel development, i.e. making the mainline kernel work on those SBCs. We do more user space development and software implementations, and only that, including more setup areas, like network and drive mounts, hence can focus more on this.

[mrx23dot]

Trying the script:

Generation complete.
[ INFO ] Selected Git branch: MichaIng/master
[FAILED] DietPi-PREP | Unknown or unsupported distribution version: "Armbian 21.02.3 Focal". Aborting...

[MichaIng]

You need to use Debian-based Armbian image instead of Ubuntu. Let me see, at it's called "Armbian Buster".

Focal = Ubuntu 20.04 Focal, the current Ubuntu LTS
Buster = Debian 10 Buster, the current stable Debian

Would be a reasonable suggestion to have then adding the actual OS/distribution name to their images as well instead of only their release code name 🙂.

[mrx23dot]

Oh, good to know :)

Meanwhile with virgin Buster:
[ OK ] DietPi-Set_swapfile | Setting in /boot/dietpi.txt adjusted: AUTO_SETUP_SWAPFILE_SIZE=0
[ OK ] DietPi-Set_swapfile | Desired setting in /boot/dietpi.txt was already set: AUTO_SETUP_SWAPFILE_LOCATION=/var/swap
[ INFO ] DietPi-Set_swapfile | Setting /tmp tmpfs size: 237 MiB
[FAILED] DietPi-Set_swapfile | mount -o remount /tmp
Generic Device (aarch64)

• Command: mount -o remount /tmp ¦
  ¦ - Exit code: 32 ¦
  ¦ - DietPi version: v7.0.2 (MichaIng/master) | HW_MODEL: 22 | HW_ARCH: 3 | DISTRO: 5 ¦
  ¦ - Error log: ¦
  ¦ mount: /tmp: mount point not mounted or bad option.

retry not working.

[MichaIng]

That was within DietPi-PREP or after the conversion?

[mrx23dot]

./PREP_SYSTEM_FOR_DIETPI.sh was still running/finishing up.
Sent an error report just in case.

Logging in parallel gives:

Filesystem Size Used Avail Use% Mounted on
udev 168M 0 168M 0% /dev
tmpfs 48M 5.1M 43M 11% /run
/dev/mmcblk0p1 3.6G 805M 2.7G 23% /
tmpfs 238M 0 238M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 238M 0 238M 0% /sys/fs/cgroup
/dev/zram2 230M 288K 213M 1% /tmp

ls
drwxrwxrwt 10 root root 4096 Apr 27 21:17 tmp

ls /tmp
DietPi-PREP G_EXEC_ERROR_REPORT armbian-hardware-optimization.3M7JUQ
DietPi-Set_swapfile G_EXEC_LOG systemd-private-8b77831b84314e81bf56399f08a74cb7-haveged.service-TF4VZr

[mrx23dot]

512MB RAM board, 2.7GB SD left.

[mrx23dot]

• Bypassed it by replacing remount cmd with dummy echo.
• Script passed.
• "reboot" is not turning on the board, just off, needs power cycling, problematic for remote board.
• After reboot and many minutes it's not showing up on nmap, LED is on the LAN port.
• I could login with onboard serial port.
• Setup continues, complains that it cannot get online. (typical problem with dietpi)

dietpi-config
 - DHCP selected
 - Ethernet    : Available | [On] | **Disconnected**  
 
ip a
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state **DOWN** group default qlen 1000
  link/ether **02:00:7b:cd:90:30** brd ff:ff:ff:ff:ff:ff
# fixing DOWN 
ip link set dev eth0 up

• Why is the network DOWN by default?
• Why is the address ipv6 by default, even when ipv4 is preferred?
• Even after disabling ipv6 and restarting 'networking' I still get ipv6 and no DHCP response:

  Listening on LPF/eth0/02:00:7b:cd:90:30
  Sending on   LPF/eth0/02:00:7b:cd:90:30
  Sending on   Socket/fallback
  DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
  DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
  **No DHCPOFFERS received.**
  No working leases in persistent database - sleeping.

It worked great on armbian buster.
Now imagine someone not having access to onboard serial port.

[MichaIng]

/dev/zram2 230M 288K 213M 1% /tmp

Ah of course, Armbian by default has a zram drive mounted at /tmp. A remount is only possible when the mount type did not change, AFAIK. I wonder why I didn't face this issue, probably the dev branch version of DietPi-PREP has it solved. However, skipping it via dummy command should be fine, zram is a volatile mount as well, only compressed. After reboot the tmpfs defined in /etc/fstab will be mounted, so all good.

"reboot" is not turning on the board, just off, needs power cycling, problematic for remote board.

Well known issue with Armbian kernel on several SBCs. Now I see a quite important note on the Armbian download page about this image: https://www.armbian.com/orange-pi-zero-2/

Experimental support, serial console only

Setup continues, complains that it cannot get online. (typical problem with dietpi)

With Ethernet, it should not be. Please check the following:

cat /etc/network/interfaces

should contain (among others) uncommented:

allow-hotplug eth0
iface eth0 inet dhcp

Then:

journalctl -u ifup@eth0

should be the resulting service that configures the Ethernet interface, including startup of the DHCP client to assign an IP address. Obviously something until here did not work as expected. But all tools that are involved are plain Debian = DietPi network stack.

Why is the address ipv6 by default, even when ipv4 is preferred?

What you see is the IPv6 stateless address auto-configuration (SLAAC) that every network device is given (based on the MAC address). It does not indicate any connection state. Preferred IPv4 will make APT and wget use IPv4 connections, when possible, but as IPv6 is still enabled, you'll see a SLAAC address for every network adapter, which is perfectly fine.

Even after disabling ipv6 and restarting 'networking' I still get ipv6 and no DHCP response:

The networking.service is not responsible here, as it's an allow-hotplug interface, so that ifup@eth0.service does the device configuration. However, to skip the systemd overhead, do the following:

ifdown --force eth0
ifup eth0
ip a s eth0

Now the IPv6 address should be gone. Let's see if ifup also succeeds to get a DHCP lease. As you say it worked on Armbian, I think they use NetworkManager by default, but I cannot imagine a circumstance where it would get a DHCP lease while the native isc-dhcp-client would not... As of the "experimental support" note I currently guess it's an instability with the network adapter which breaks ifup@eth0.service at boot, but let's see what the above shows us.

[mrx23dot]

Thanks for the feedback, I knew that it's working progress, but seemed fine with armbian, also someone has to test it to be stable :)

cat /etc/network/interfaces seems okay:

# Ethernet
allow-hotplug eth0
iface eth0 inet dhcp
address 0.0.0.0
netmask 0.0.0.0
gateway 0.0.0.0
#dns-nameservers 0.0.0.0

root@DietPi:~# journalctl -u ifup@eth0 doesn't show any error

Apr 27 23:00:03 DietPi systemd[1]: Starting ifup for eth0...
Apr 27 23:00:03 DietPi dhclient[384]: Internet Systems Consortium DHCP Client 4. 4.1
Apr 27 23:00:03 DietPi dhclient[384]: Copyright 2004-2018 Internet Systems Conso rtium.
Apr 27 23:00:03 DietPi dhclient[384]: All rights reserved.
Apr 27 23:00:03 DietPi dhclient[384]: For info, please visit https://www.isc.org /software/dhcp/
Apr 27 23:00:03 DietPi dhclient[384]: Listening on LPF/eth0/02:00:7b:cd:90:30
Apr 27 23:00:03 DietPi dhclient[384]: Sending on   LPF/eth0/02:00:7b:cd:90:30
Apr 27 23:00:03 DietPi sh[351]: Listening on LPF/eth0/02:00:7b:cd:90:30
Apr 27 23:00:03 DietPi sh[351]: Sending on   LPF/eth0/02:00:7b:cd:90:30
Apr 27 23:00:03 DietPi sh[351]: Sending on   Socket/fallback
Apr 27 23:00:03 DietPi sh[351]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7

ifup eth0

Listening on LPF/eth0/02:00:7b:cd:90:30
Sending on   LPF/eth0/02:00:7b:cd:90:30
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

Looks like dietpi doesn't get a DHCP reponse, but armbian does.
I had a very similar network issue with dietpi running on RPi1, switching back to raspbian solved it there.

[Joulinar]

Maybe you are able to trace on the DHCP server if a request is received

Btw: my RPI1 is running fine using DietPi and DHCP 😉

[mrx23dot]

Went back to armbian, internet still works:

ping google.com

PING google.com (142.250.200.46) 56(84) bytes of data.
64 bytes from lhr48s30-in-f14.1e100.net (142.250.200.46): icmp_seq=1 ttl=114 time=62.1 ms
64 bytes from lhr48s30-in-f14.1e100.net (142.250.200.46): icmp_seq=2 ttl=114 time=35.5 ms

armbian config:
cat /etc/network/interfaces
// no eth0 in this?

source /etc/network/interfaces.d/*
# Network is managed by Network manager
auto lo
iface lo inet loopback

ifdown --force eth0
ifdown: unknown interface eth0

What can we learn from this config?

[Joulinar]

They use Network manager and DietPi not 😉

[mrx23dot]

Where can I fetch the DHCP log from this to compare it to dietpi?
service Status gives

   CGroup: /system.slice/NetworkManager.service
           ├─1061 /usr/sbin/NetworkManager --no-daemon
           └─1246 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/dhclient-eth0.pid -lf /var/lib/NetworkManager/dhclient-ee6f985b-64b0-3e8f-82a

Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7314] device (eth0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'manag
Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7397] device (eth0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'man
Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7425] device (eth0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'ma
Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7466] manager: NetworkManager state is now CONNECTED_LOCAL
Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7638] manager: NetworkManager state is now CONNECTED_SITE
Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7649] policy: set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS
Mar 09 08:14:03 orangepizero2 dhclient[1246]: bound to 192.168.10.101 -- renewal in 250928 seconds.
Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7841] device (eth0): Activation: successful, device activated.
Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7894] manager: NetworkManager state is now CONNECTED_GLOBAL
Mar 09 08:14:03 orangepizero2 NetworkManager[1061]: <info>  [1615277643.7997] manager: startup complete

no DHCP problem here.

[Joulinar]

Basically Network Manager is a complete different tool. But @MichaIng could explain it better than I.

Best place to fetch DHCP request would be the DHCP server to see if something is received at all

[MichaIng]

It is a large high level network application, much more complex, much more automated. In some cases this causes issues, in some cases it solves issues. It is however the first time I see ifup failing to get a DHCP lease, while NetworkManager does, especially since it invokes exactly the same DHCP client.

It uses a custom post-lease script: /usr/lib/NetworkManager/nm-dhcp-helper
But that is invoked after the lease has been received, so cannot be the effective difference here.

Unique case so far, but if you want to debug it, indeed tcpdump + checking router logs or so would be an idea to check whether DHCP requests are sent, whether they arrive at the router, and whether answers are received.

Btw, you have an IPv6 address as well on Armbian, right?

---

Another thing, did you do a full package upgrade on Armbian apt update; apt full-upgrade so that the kernel versions are the same?

[mrx23dot]

Unfortunately it's a dumb cable modem+router combo on the network. There wasn't any DHCP entries in the log for today. The lowest level of 'notice' entries are 'DHCP Renew' ones from days ago.

I can't remember whether I did apt update+upgrade, I'm sure I didn't do full-upgrade.
But I saw a lot of apt-update activities in the script. full-upgrade wasn't part of the tutorial.
After rechecking it: full-upgrade on original armbian doesn't add anything to upgrade:
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I will run with armbian for a while, and maybe come back later for dietpi.
Thanks for the support!

[mrx23dot]

On armbian I get:

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:00:7b:cd:90:30 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.101/24 brd 192.168.10.255 scope global dynamic noprefixroute eth0
       valid_lft 604211sec preferred_lft 604211sec
    inet6 fe80::a73b:c850:1c34:7581/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
root@orangepizero2:~# ping google.com
PING google.com (142.250.200.46) 56(84) bytes of data.
64 bytes from lhr48s30-in-f14.1e100.net (142.250.200.46): icmp_seq=1 ttl=114 time=21.1 ms
64 bytes from lhr48s30-in-f14.1e100.net (142.250.200.46): icmp_seq=2 ttl=114 time=20.8 ms
^C

I ssh into it over 192.168.10.101 ipv4

[MichaIng]

I'm gonna mark Orange Pi related image requests as closed for now. Referring to our preparation script guide: https://dietpi.com/docs/hardware/#make-your-own-distribution

Orange Pi is on my first priority list when image creation has been automated enough, for for now I personally cannot effort adding a new manufacturer to my creation schedule.