MichaIng commented 4 years ago

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/images/DietPi_NanoPiM3-ARMv8-Buster.7z

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

ZeroPi: https://dietpi.com/downloads/images/DietPi_ZeroPi-ARMv7-Buster.7z

The old stable image for M3/T3/Fire3 (Stretch + Linux 4.4 + ARMv7) is available here: REMOVED INVALID LINK 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 commented 4 years ago

ZeroPi hardware identifier added for v6.27: https://github.com/MichaIng/DietPi/commit/bd0aa9b5f37be72a69306194569c6daed10b480f

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 commented 4 years ago

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: https://github.com/MichaIng/DietPi/commit/3a6a06032ff6490df7cbc6a0cbb6a698daccd2be Changelog: https://github.com/MichaIng/DietPi/commit/72b7dff0fc9a7d84d4fc03fa0c539067a5f020e0

StephanStS commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

Hello Micha,

I am investigating a strange issue. I tried to install OMV5 on the DietPi buster image on a NanoPi Fire3 (has no WIFI).

After installing it manually (via shell) I did not see any DNS entries in /etc/resolv.conf and also there was no DNS server shown in the network settings part of dietpi-config. As a result, apt update failed. Also a „ping www.google.de http://www.google.de “ failed, so there seems to be no running DNS resolution.

I then installed OMV5 on an Armbian buster image (same manual procedure like above) and then I see two nameservers (one IPv4 and one IPv6): nameserver 192.168.178.2 nameserver fd00::1315:e5fc:9b36:3ad0 search fritz.box

This is what I expected.

I then looked at the basic image install status of a DietPi NanoPi ZeroPi:

root@DietPiZeroPi:~# cat /etc/resolv.conf nameserver 1.0.0.1 nameserver 192.168.178.2 search fritz.box

Additionally a DietPi NanoPi M3 image shows: nameserver 192.168.178.2 search fritz.box

The situation at my home is a fritz box with a pi-hole running as the DNS server on 192.168.178.2 (and fd00::1315:e5fc:9b36:3ad0). The 1.0.0.1 is a Cloudflare DNS server which is used by the pi-hole if its internal DNS resolution cache fails. So, the DNS or DHCP seems to have some problems on the DietPi images. Are there any investigations I may do? Are there any logging options where I may look at? Whom could I contact (and afterwards possibly file an issue on GitHub)?

I could assume that there are some timeout settings in the DietPi which are too short, but I am not too familiar with the DHCP procedure in detail.

I am not able to install wireshark and record the DHCP procedure to investigate what DHCP is responding. ☹

Regards Stephan

MichaIng commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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: https://github.com/MichaIng/DietPi/issues/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 commented 4 years ago

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 commented 4 years ago

@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.

epicfrequency commented 4 years ago

zeropi images hangs on MPD usb audio card playback, not sure why

MichaIng commented 4 years ago

@epicfrequency Many thanks for testing. Does the USB sound card otherwise work fine? You selected it via dietpi-config > Audio Options? If so, please open a separate issue, since this should then be some soundcard and/or MPD specific issue, not related to the underlying image 😉.

epicfrequency commented 4 years ago

Hi Michalng I have the same usb card(gustard u16) working perfectly fine with Dietpi on Odroid C2/Tinkerboard S using same MPD version .21.16, so that rules out soud card.

In addtion, I tried buildroot Zeropi image built accoring to this one https://github.com/bz31/Buildroot, works fine as well, that rules out the Zeropi itself.

That's why I am guessing something wrong with the Dietpi ZeroPi image:) ~

MichaIng commented 4 years ago

@epicfrequency Finally to rule out its MPD-related it would be good to test raw audio playback first, e.g. using aplay /path/to/test.raw. Also MPD logs, or probably related dmesg/journalctl entries could help.

The (quite interesting) Buildroot image contains some kernel/dt patch for ZeroPi: https://github.com/bz31/Buildroot/blob/master/board/zeropi/patches/uboot/add-zeropi.patch It includes some usb_otg driver settings, although I have not much experience with that. Possibly that fixes some issue(s) with other kernel configs, used by ARMbian/kernel that our image is based on. At least could be worth to compare those.

As well Buildroot kernel config: https://github.com/bz31/Buildroot/blob/master/linux-configs/zeropi_linux-4.19.x_usb-audio.config

ARMbian kernel config: https://github.com/armbian/build/blob/master/config/kernel/linux-sunxi-current.config (not it's Linux 5.3 vs 4.19 on Buildroot) ARMbian kernel patch: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/add-zeropi.patch

MichaIng commented 4 years ago

ZeroPi's are detected during DietPi v6.27 pre-patches to have new hardware ID applied, based on which correct further patches, reinstalls etc can be done, and banner will show the device correctly then as well of course: https://github.com/MichaIng/DietPi/commit/43387b5f8363ddf731f90c01bed66b90173f2160

epicfrequency commented 4 years ago

Looking at dmseg, here shows the error . now sure what is the cause. [ 4532.063527] usb 5-1.1: uac_clock_source_is_valid(): cannot get clock validity for id 1 [ 4532.063545] usb 5-1.1: clock source 1 is not valid, cannot use [ 4532.067692] usb 5-1.1: 1:2: cannot get freq (v2/v3): err -71 [ 4532.072600] usb 5-1.1: 1:2: cannot set freq 705600 (v2/v3): err -71 [ 4535.464982] usb 5-1.1: uac_clock_source_is_valid(): cannot get clock validity for id 1 [ 4535.465004] usb 5-1.1: clock source 1 is not valid, cannot use [ 4535.469303] usb 5-1.1: 1:2: cannot get freq (v2/v3): err -71 [ 4535.474741] usb 5-1.1: 1:2: cannot set freq 705600 (v2/v3): err -71 [ 4661.351676] usb 5-1.1: uac_clock_source_is_valid(): cannot get clock validity for id 1 [ 4661.351690] usb 5-1.1: clock source 1 is not valid, cannot use [ 4661.355925] usb 5-1.1: 1:2: cannot get freq (v2/v3): err -71 [ 4661.360144] usb 5-1.1: 1:2: cannot set freq 705600 (v2/v3): err -71 [ 4667.134616] usb 5-1.1: 1:1: usb_set_interface failed (-71)

MichaIng commented 4 years ago

@epicfrequency Okay a kernel/driver issue. See this patch, which seams to deal with this issue: https://lkml.org/lkml/2019/10/29/201

Could you try to upgrade the firmware packages: apt update && apt full-upgrade

epicfrequency commented 4 years ago

Tired, no package is updated, even tried on 5.4.6 kernel. same as before.

MichaIng commented 4 years ago

@epicfrequency I just recognised that we set ARMbian packages on hold. Doesn't make sense since G_AGDUG and similar override hold states anyway. Just to assure:

apt-mark unhold $(apt-mark showhold)
apt full-upgrade

epicfrequency commented 4 years ago

root@DietPi:~# apt-mark unhold $(apt-mark showhold)

Canceled hold on linux-buster-root-next-zeropi. Canceled hold on linux-dtb-next-sunxi. Canceled hold on linux-image-next-sunxi. Canceled hold on linux-u-boot-zeropi-next. Canceled hold on sunxi-tools.

root@DietPi:~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

And I have narrowed down the failure only happens when I play the maximum DSD512 setup(equivalent of 32bit PCM768Khz . Everything else works. Same behavior shows in Buildroot.

On dietpi with Odroid C2/Tinkerboard/64bit X86 all works fine. I am guessing more of a Zeropi limitation?

MichaIng commented 4 years ago

@epicfrequency Okay, so if the above linked patch indeed solves this ZeroPi audio issue, then it is not yet merged into ARMbian kernel packages. Great that you found a workaround meanwhile.

Could be ZeroPi limitation but I guess kernel/driver patches could solve it. But this exceeds my knowledge. If the issue is the same with buildroot, probably it should be reported there. It could be tested with fresh ARMbian image (https://dl.armbian.com/zeropi/Buster_current_minimal) as well and if its the same then with DietPi (pretty expected), then it could be reported to ARMbian forum as well, if not already a related issue exists: https://forum.armbian.com/forum/13-allwinner-h2-h3/ These guys should be able much better to track down the issue or even find a solution.

MichaIng commented 4 years ago

I moved the images to stable, updated download links: https://dietpi.com/#download I'll update them by times for new testing images.

MichaIng commented 4 years ago

@StephanStS Little question: We have a workaround on NanoPi Fire3 in place since HDMI output on TTY1 did not work on previous image. Does it still work fine when you remove it?

rm /var/lib/dietpi/postboot.d/fire3_tty2
chvt 1 # When accessing via HDMI
# And to check whether boot output and and login prompt appears still fine
reboot

This does not affect SSH or such, only local console output and login.
Actually the workaround could even lead to missing login prompt, since getty@tty1 is enabled but not getty@tty2 on the new image.

Btw sorry for missing mail reply. I am currently using any free time for image updates/creation + related DietPi-PREP fine tuning and review, mostly. M4v2 is up already: https://github.com/MichaIng/DietPi/issues/2979 When all are done and uploaded for testing, we have a good basis to start with, regarding the topics you listed in your mail.

StephanStS commented 4 years ago

Hallo Micha,

ich verstehe Deine Frage nicht so ganz.

Ich habe das Nanopi Fire3 Image am Laufen, das ich erstellt hatte. Screenshot via putty:

Wenn ich jetzt an den Mikro-HDMI Ausgang meinen HDMI-Monitor anschließe, kommt dort etwas heraus. Ich kann mich dann per USB-Tastatur fehlerfrei einloggen. Alles scheint zu klappen.

Unter /var/lib/dietpi/postboot.d/ liegt keine Datei.

Ich habe das mit diesem Image durchgeführt, die ich dort für Dich abgelegt hatte:

Verwendet habe ich das Image im Verzeichnis 2019-11-04\NanoPiFire3\Armbian\:

FILE: DietPi_v6.26_NanoPiFire3-ARMv8-Buster.img

DATE: Mon 04 Nov 2019 01:07:06 AM EST

MD5: 408606b5ebcad3660362a82549bd0d3d

SHA1: d83b22741be3a5c1e716df44164946fa14e3b462

SHA256: 67cfaa03a6f11bf0c66b8221f6a170d10191444c8d4fb54a0acc7f61c8aadeb1

Ich kann gerne auch ein Video vom Bootvorgang machen und Dir zusenden, oder eine Log-Datei (dazu müsstest Du mir sagen, welche Datei) zusenden. Dann kannst Du auch den Bootvorgang anschauen.

Oder soll ich etwas anderes ausprobieren?

Gruß

Stephan

Von: MichaIng notifications@github.com Gesendet: Mittwoch, 19. Februar 2020 14:24 An: MichaIng/DietPi DietPi@noreply.github.com Cc: StephanStS stephan.schultze@schultze-online.de; Mention mention@noreply.github.com Betreff: Re: [MichaIng/DietPi] NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images (#3221)

@StephanStS https://github.com/StephanStS Little question: We have a workaround on NanoPi Fire3 in place since HDMI output on TTY1 did not work on previous image. Does it still work fine when you remove it?

rm /var/lib/dietpi/postboot.d/fire3_tty2 chvt 1 # When accessing via HDMI

And to check whether boot output and and login prompt appears still fine

reboot

This does not affect SSH or such, only local console output and login.
Actually the workaround could even lead to missing login prompt, since getty@tty1 is enabled but not getty@tty2 on the new image.

Btw sorry for missing mail reply. I am currently using any free time for image updates/creation + related DietPi-PREP fine tuning and review, mostly. M4v2 is up already: #2979 https://github.com/MichaIng/DietPi/issues/2979 When all are done and uploaded for testing, we have a good basis to start with, regarding the topics you listed in your mail.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/3221?email_source=notifications&email_token=ANYD3XFAYOCRD4ZO6BCA4RTRDUXFTA5CNFSM4JKOFZJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMH2DMA#issuecomment-588226992 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ANYD3XHPURESBANQPIGYBTTRDUXFTANCNFSM4JKOFZJQ . https://github.com/notifications/beacon/ANYD3XFUBXLFZPIZUO2Y463RDUXFTA5CNFSM4JKOFZJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMH2DMA.gif

MichaIng commented 4 years ago

Okay dann scheint der Workaround bei dem neuen Image gar nicht mehr angewendet zu wenden, das ist gut. Um sicherzugehen, das folgende spuckt beim Fire3 nichts aus, oder?

dmesg | grep -i 'NanoPi Fire3'

StephanStS commented 4 years ago

Yep, dmesg | grep -i 'NanoPi Fire3' gibt nichts aus.

Ich will mich in den nächsten Wochen mal über folgende Buster-Varianten für NanoPi hermachen:

M4v2: Prüfung des vorhandenen Images und Vergleich mit „meinem“ erstellten Image. Test auch mit dem (steckbaren) eMMC: Ich habe einen µSD-Adapter für die eMMC-Module. Zudem möchte ich noch mal testen, ob ein laufendes Image einer SDCard per dd einfach auf die eMMC kopiert werden kann. Vermutlich geht das nur dann, wenn ich die eMMC unter Spannung stecken kann, denn beim Booten mit gesteckter eMMC will der NanoPi von der eMMC booten
M1+: Prüfung des vorhandene Images und Vergleich mit „meinem“ erstellten Image
Neo4: Prüfung des vorhandene Images und Vergleich mit „meinem“ erstellten Image. Test auch mit dem (steckbaren) eMMC.
Neo2: Prüfung des vorhandene Images und Vergleich mit „meinem“ erstellten Image
Neo Plus2 v2: Erstellung des Images

Mein NanoPi Fundus beinhaltet nun folgende Module:

ZeroPi
Neo2
Neo4 (incl. eMMC-Modul)
Neo Plus2 (begrenzter Zugriff)
Neo Plus2 v2
M1+
M3
Fire3
M4v2 (incl. eMMC-Modul)

Falls da mal was zu machen ist (z.B. Bullseye Images zum Testen), lass‘ es mich wissen.

Als nächstes interessieren mich natürlich noch der NanoPC T4, NanoPi A64, NanoPi K2, NanoPi M4B. Die habe ich mir aber noch nicht bestellt. Erstmal die Aufgaben oben erledigen… 😊

Gruß

Stephan

Von: MichaIng notifications@github.com Gesendet: Freitag, 21. Februar 2020 19:37 An: MichaIng/DietPi DietPi@noreply.github.com Cc: StephanStS stephan.schultze@schultze-online.de; Mention mention@noreply.github.com Betreff: Re: [MichaIng/DietPi] NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images (#3221)

Lol da war ich zu sehr im Element und habe dir auf Englisch gerieben :D.Okay dann scheint der Workaround bei dem neuen Image gar nicht mehr angewendet zu wenden, das ist gut.Um sicherzugehen, das folgende spuckt beim Fire3 nichts aus, oder? dmesg | grep -i 'NanoPi Fire3'LG Micha -------- Ursprüngliche Nachricht --------Von: StephanStS <notifications@github.com mailto:notifications@github.com > Datum: 21.02.20 17:48 (GMT+01:00) An: MichaIng/DietPi <DietPi@noreply.github.com mailto:DietPi@noreply.github.com > Cc: MichaIng <micha@dietpi.com mailto:micha@dietpi.com >, State change <state_change@noreply.github.com mailto:state_change@noreply.github.com > Betreff: Re: [MichaIng/DietPi] NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images (#3221) Hallo Micha,

ich verstehe Deine Frage nicht so ganz.

Ich habe das Nanopi Fire3 Image am Laufen, das ich erstellt hatte. Screenshot via putty:

Wenn ich jetzt an den Mikro-HDMI Ausgang meinen HDMI-Monitor anschließe, kommt dort etwas heraus. Ich kann mich dann per USB-Tastatur fehlerfrei einloggen. Alles scheint zu klappen.

Unter /var/lib/dietpi/postboot.d/ liegt keine Datei.

Ich habe das mit diesem Image durchgeführt, die ich dort für Dich abgelegt hatte:

Verwendet habe ich das Image im Verzeichnis 2019-11-04\NanoPiFire3\Armbian\:

FILE: DietPi_v6.26_NanoPiFire3-ARMv8-Buster.img

DATE: Mon 04 Nov 2019 01:07:06 AM EST

MD5: 408606b5ebcad3660362a82549bd0d3d

SHA1: d83b22741be3a5c1e716df44164946fa14e3b462

SHA256: 67cfaa03a6f11bf0c66b8221f6a170d10191444c8d4fb54a0acc7f61c8aadeb1

Ich kann gerne auch ein Video vom Bootvorgang machen und Dir zusenden, oder eine Log-Datei (dazu müsstest Du mir sagen, welche Datei) zusenden. Dann kannst Du auch den Bootvorgang anschauen.

Oder soll ich etwas anderes ausprobieren?

Gruß

Stephan

Von: MichaIng <notifications@github.com mailto:notifications@github.com >

Gesendet: Mittwoch, 19. Februar 2020 14:24

An: MichaIng/DietPi <DietPi@noreply.github.com mailto:DietPi@noreply.github.com >

Cc: StephanStS <stephan.schultze@schultze-online.de mailto:stephan.schultze@schultze-online.de >; Mention <mention@noreply.github.com mailto:mention@noreply.github.com >

Betreff: Re: [MichaIng/DietPi] NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images (#3221)

@StephanStS https://github.com/StephanStS

Little question: We have a workaround on NanoPi Fire3 in place since HDMI output on TTY1 did not work on previous image. Does it still work fine when you remove it?

rm /var/lib/dietpi/postboot.d/fire3_tty2

chvt 1 # When accessing via HDMI

And to check whether boot output and and login prompt appears still fine

reboot

This does not affect SSH or such, only local console output and login.
Actually the workaround could even lead to missing login prompt, since getty@tty1 is enabled but not getty@tty2 on the new image.

Btw sorry for missing mail reply. I am currently using any free time for image updates/creation + related DietPi-PREP fine tuning and review, mostly. M4v2 is up already: #2979 https://github.com/MichaIng/DietPi/issues/2979

When all are done and uploaded for testing, we have a good basis to start with, regarding the topics you listed in your mail.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub <https://github.com/MichaIng/DietPi/issues/3221?email_source=notifications https://github.com/MichaIng/DietPi/issues/3221?email_source=notifications&email_token=ANYD3XFAYOCRD4ZO6BCA4RTRDUXFTA5CNFSM4JKOFZJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMH2DMA#issuecomment-588226992 &email_token=ANYD3XFAYOCRD4ZO6BCA4RTRDUXFTA5CNFSM4JKOFZJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMH2DMA#issuecomment-588226992> , or unsubscribe https://github.com/notifications/unsubscribe-auth/ANYD3XHPURESBANQPIGYBTTRDUXFTANCNFSM4JKOFZJQ . https://github.com/notifications/beacon/ANYD3XFUBXLFZPIZUO2Y463RDUXFTA5CNFSM4JKOFZJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMH2DMA.gif

—You are receiving this because you modified the open/close state.Reply to this email directly, view it on GitHub, or unsubscribe.

[

{

"@context": "http://schema.org",

"@type": "EmailMessage",

"potentialAction": {

"@type": "ViewAction",

"target": "https://github.com/MichaIng/DietPi/issues/3221?email_source=notifications\u0026email_token=AGZJJQMKHCISAJKCERW7BW3REAAXPA5CNFSM4JKOFZJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMTK2SQ#issuecomment-589737290",