Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images #3221

Open
MichaIng opened this issue Nov 7, 2019 · 12 comments
Open

NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images #3221

MichaIng opened this issue Nov 7, 2019 · 12 comments

Comments

@MichaIng
Copy link
Owner

@MichaIng MichaIng commented Nov 7, 2019

Thanks to @StephanStS we can offer a new set of community-created Debian Buster images. Those are based on @Armbian, so credits for the kernel, bootloader and firmware work, to have Debian running on those boards, go to them.

Besides finally running Debian Buster and Linux 4.14, a great benefit for M3/T3/Fire3 is that they run a ARMv8/aarch64 kernel + OS.

The images have been tested and are actively used by @Stephan and have gone through some review by us. However we offer them as "beta" for now until some more users have tested them their way. This means for you, if you face any issue or have any suggestions to enhance the initial boot or setup experience, please report this here, so we can do some fine tuning before shipping them as stable replacement for the current Stretch-based images.

NanoPi M3 + NanoPC T3: https://dietpi.com/downloads/testing/DietPi_NanoPiM3-ARMv8-Buster.7z

NanoPi Fire3: https://dietpi.com/downloads/testing/DietPi_NanoPiFire3-ARMv8-Buster.7z

ZeroPi: https://dietpi.com/downloads/testing/DietPi_NanoPiZeroPi-ARMv7-Buster.7z


The old stable image for M3/T3/Fire3 (Stretch + Linux 4.4 + ARMv7) is available here: https://dietpi.com/downloads/images/DietPi_NanoPiM3-ARMv7-Stretch.7z
Although it has been proven to work fine, I highly recommend to go with the above updated images. Report any issue here and we'll assist quickly.

MichaIng added a commit that referenced this issue Nov 12, 2019
v6.27
+ DietPi-Obtain_HW_model | Add FriendlyARM ZeroPi support with new hardware ID 59: #3221
@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Nov 12, 2019

ZeroPi hardware identifier added for v6.27: bd0aa9b

dietpi.com download page for M3/T3/Fire3 links to this issue now: https://dietpi.com/#download
The benefit if the new images is too large to have any user downloading the old (though proven stable) ones. We'll assist here quickly if any issue arises.

@MichaIng MichaIng added this to the v6.27 milestone Nov 12, 2019
@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Nov 12, 2019

Could one of you guys with ZeroPi paste cat /proc/cpuinfo, please? So we can apply the new DietPi internal hardware ID 59 to all of them during next update. Otherwise I would scan /etc/armbian-release to apply it at least for Armbian-based images, but it would be better to do that based on generic /proc/cpuinfo identifier 😉.


Added hardware ID to DietPi-PREP: 3a6a060
Changelog: 72b7dff

MichaIng added a commit that referenced this issue Nov 12, 2019
v6.27
+ CHANGELOG | FriendlyARM ZeroPi: Initial hardware identifier (ID: 59) and support for this device has been added to DietPi: #3221
@StephanStS

This comment has been minimized.

Copy link

@StephanStS StephanStS commented Nov 12, 2019

root@DietPiZeroPi:~# cat /proc/cpuinfo

processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

Hardware : Allwinner sun8i Family
Revision : 0000
Serial : 02c00181ef5b3435

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Nov 12, 2019

@StephanStS
Many thanks! Sadly the revision code is not unique, hence I guess we must rely on /etc/armbian-release to apply hardware ID to existing systems. However, for all systems based on your image, this works, so no big issue.

@StephanStS

This comment has been minimized.

Copy link

@StephanStS StephanStS commented Nov 12, 2019

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Nov 12, 2019

@StephanStS
I have no idea what OMV installer does, just remember that it is quite intrusive and OMV in general doubles many DietPi features and config setup, hence conflicts e.g. with dietpi-config network options for sure and probably with the initial network setup as well, not sure. This was the reason we removed the OMV install option from DietPi-Software once.

However what you need to check is:
/etc/network/interfaces
and if existent, files in
/etc/network/interfaces.d
e.g.
cat /etc/network/interfaces{,.d/*}

The main network adapter needs to have an interface assigned there, in case of DHCP on Ethernet this should then look like this:

allow-hotplug eth0
iface eth0 inet dhcp

With this, there is an ifup@eth0 service that configures this interface, once the adapter is available on boot. ifup then invokes the dhclient to retrieve an IP and as well a DNS nameserver.

You can check the service status and that the dhclient is up:

systemctl status ifup@eth0
ps ax | grep [d]hclient

Common issues due to 3rd party installers are:

  • Install of additional network related packages, e.g. dhcpcd5, an additional DHCP client which conflicts with isc-dhcp-client (dhclient) and requires different /etc/network/interface entries: iface eth0 inet manual (instead of "dhcp" in the end)
  • /etc/network/interface changes, e.g. like above which leads to dhclient not being invoked on interface start.
@MichaIng MichaIng mentioned this issue Nov 13, 2019
@MichaIng MichaIng modified the milestones: v6.27, v6.28 Nov 18, 2019
@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Nov 18, 2019

Adjusted milestone to keep track of those images through next development cycle as well and, if no urgent errors are reported, move them into stable place.

@mrbluecoat

This comment has been minimized.

Copy link

@mrbluecoat mrbluecoat commented Nov 23, 2019

ZeroPi image worked great - thanks!

Benchmark:

 CPU Performance : Duration = 20.64 seconds (lower is faster)
   │  - CPU Temp        : Idle = 37'c | Full load = 51'c
   │  - RootFS          : Write = 13 MiB/s | Read = 21 MiB/s
   │  - RAM             : Write = 328 MiB/s | Read = 476 MiB/s

cat /proc/cpuinfo

processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 136.80
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 1
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 136.80
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 2
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 136.80
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 3
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 136.80
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

Hardware        : Allwinner sun8i Family
Revision        : 0000
Serial          : 02c00181744f6c08
@StephanStS

This comment has been minimized.

Copy link

@StephanStS StephanStS commented Nov 27, 2019

Regarding the resolv.conf issue mentioned above (from 12th of november) I found out:

In the good case the resolv.conf symbolic link was:

root@Fire3:~# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 31 Nov  4 05:46 /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf

In the bad case (after the OMV5 installation) the resolv.conf symbolic link was:

root@Fire3:~# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Nov 26 18:32 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

Also in the bad case the output of "systemctl status ifup@eth0" gave amongst others:

Nov 15 17:51:10 Fire3 sh[595]: /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf

After changing the symbolic link back to /etc/resolvconf/run/resolv.conf the system ran o.k., but further installation problems occured.

Yesterday (a couple of days later) I tested the OMV5 installation again on a fresh dietpi image and it ran without errors, the nameserver resolution showed the correct entries. The symbolic link was changed to /run/systemd/resolve/resolv.conf, but the resolv.conf contents was now correct:

root@Fire3:~# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 1.0.0.1
nameserver 192.168.178.2
search fritz.box

I actually do not know whether this changed behaviour has its cause in a changed OMV 5 installation process, I am not aware that I did any changed to the steps of the OMV 5 installation.

The system is now running fine, this issue I 'define' as closed for now.

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Nov 27, 2019

This was and is the reason why we dropped OMV from software options. It really changes the very basic system setup which breaks our scripts and existing setup. One really has to take it as an own OS and use either OMV or DietPi. Merging both requires the mentioned tinkering, and using OMV UI and dietpi-config/dietpi-software will go on conflicting each other.

To explain what it does:
/run/systemd/resolve/resolv.conf is the systemd-resolved location, which is a systemd-internal alternative to resolvconf, which DietPi uses/expects by default. It makes sense to use this, if one uses systemd-networkd as well, the alternative to ifupdown. Using both in parallel conflicts of course. I was playing around with it as well and thinking about switching DietPi: #1581
However there is none or only marginal benefit. Less APT packages are required, hence some disk space freed, but the systemd services are not passive (like ifupdown + resolvconf) but actively running all the time, taking ~5M RAM constantly each, hence 10M additional RAM usage on idle systems. For 256M SBCs this is too much IMO.

@it-esco

This comment has been minimized.

Copy link

@it-esco it-esco commented Dec 2, 2019

ZeroPi image works great, may thanks

This is cat /proc/cpuinfo

processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

Hardware : Allwinner sun8i Family
Revision : 0000
Serial : 02c0008112b32ca6

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Dec 2, 2019

@it-esco
Many thanks for testing. I'll move that image to stable with v6.27 release and the update will apply the new hardware ID based on /etc/armbian_release content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.