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

Images | Update all images to Buster where possible #2979

Open
MichaIng opened this issue Jul 10, 2019 · 65 comments · Fixed by #3387
Open

Images | Update all images to Buster where possible #2979

MichaIng opened this issue Jul 10, 2019 · 65 comments · Fixed by #3387

Comments

@MichaIng
Copy link
Owner

@MichaIng MichaIng commented Jul 10, 2019

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/testing/


New images

@FredericGuilbault

This comment has been minimized.

Copy link
Contributor

@FredericGuilbault FredericGuilbault commented Jul 15, 2019

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jul 15, 2019

@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

This comment has been minimized.

Copy link
Contributor

@FredericGuilbault FredericGuilbault commented Jul 15, 2019

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jan 6, 2020

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

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jan 8, 2020

@Joulinar

This comment has been minimized.

Copy link
Collaborator

@Joulinar Joulinar commented Jan 8, 2020

@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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jan 8, 2020

@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

This comment has been minimized.

Copy link
Collaborator

@Joulinar Joulinar commented Jan 8, 2020

@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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jan 8, 2020

@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

This comment has been minimized.

Copy link
Collaborator

@Joulinar Joulinar commented Jan 10, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jan 10, 2020

@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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jan 14, 2020

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

This comment has been minimized.

Copy link

@FrostyMisa FrostyMisa commented Jan 14, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jan 14, 2020

@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

This comment has been minimized.

Copy link
Collaborator

@Joulinar Joulinar commented Jan 19, 2020

@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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Jan 19, 2020

@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

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 11, 2020

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

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 11, 2020

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

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 12, 2020

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

This comment has been minimized.

Copy link

@JaScoMa JaScoMa commented Feb 16, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 16, 2020

@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

This comment has been minimized.

Copy link

@JaScoMa JaScoMa commented Feb 16, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 16, 2020

@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

This comment has been minimized.

Copy link

@JaScoMa JaScoMa commented Feb 17, 2020

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

This comment has been minimized.

Copy link
Collaborator

@Joulinar Joulinar commented Feb 17, 2020

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

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 17, 2020

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

@JaScoMa

This comment has been minimized.

Copy link

@JaScoMa JaScoMa commented Feb 17, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 17, 2020

@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

This comment has been minimized.

Copy link

@JaScoMa JaScoMa commented Feb 17, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 17, 2020

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

@gurabli

This comment has been minimized.

Copy link

@gurabli gurabli commented Feb 18, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 18, 2020

@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

This comment has been minimized.

Copy link

@gurabli gurabli commented Feb 18, 2020

@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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 18, 2020

@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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 18, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 18, 2020

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

@JaScoMa

This comment has been minimized.

Copy link

@JaScoMa JaScoMa commented Feb 20, 2020

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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 20, 2020

@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

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 20, 2020

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: #2260 (comment)

@MichaIng

This comment has been minimized.

Copy link
Owner Author

@MichaIng MichaIng commented Feb 20, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

9 participants
You can’t perform that action at this time.