Closed MichaIng closed 4 years ago
FredericGuilbault
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago 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
commented
4 years ago Okay, before doing any other coding, creation of Buster images for all supported SBCs, with DietPi v6.28, is the next step.
MichaIng
commented
4 years ago 
Joulinar
commented
4 years ago @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 resolutionas 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:~#@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 msWhen 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@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.comOnce 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 resolutionQestion: 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
commented
4 years ago @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
commented
4 years ago 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 | CompletedBut it seems to be gone after first reboot. At least it was irritating me to see something in red pacing by 😃
MichaIng
commented
4 years ago @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
commented
4 years ago 
FrostyMisa
commented
4 years ago 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 ─────────────────────────────────────────────────────
MichaIng
commented
4 years ago @FrostyMisa Could you please open a new issue, since your problem is a different one. First ideas:
pool.ntp.orgjournalctl -u systemd-timesyncdBut as said, please open a new issue for the above 😉.
Joulinar
commented
4 years ago @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
commented
4 years ago @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.
MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago dd, preferably after remounting the file system R/O.MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago 🈴 systemd-nspawn boot fails with:
# systemd-nspawn -bD m
Spawning container m on /root/m.
Press ^] three times within 1s to kill container.
systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
Detected virtualization systemd-nspawn.
Detected architecture arm.
Welcome to Debian GNU/Linux 10 (buster)!
Set hostname to <DietPi>.
Failed to enqueue loopback interface start request: Operation not supported
Caught <ILL>, core dump failed (child 3, code=killed, status=4/ILL).
Exiting PID 1...
Container m failed with error code 255.debootstrap, something I want to do with all our images somewhere in the future, after educating myself about this a bid more.
qemu-user-static v4, affecting all ARMv7 images. After manual downgrade all images work fine. Odroid C1 Buster image on the way 😃.MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago 
MrGlasspoole
commented
4 years ago Not working on Odroid C1+
There happens nothing. Black screen and the blue LED is just always on.
MichaIng
commented
4 years ago @MrGlasspoole I read through your thread in the forum (ours and Armbian) as well.
As you also reported issue with the legacy Jessie image, possibly there is an issue with your hardware. If you have a chance to switch PSU and/or eMMC module, this would be a chance to verify or rule that hardware out.
I'll also have a look into the uboot config /boot/boot.cmd to check if there is a eMMC switch required e.g.
MrGlasspoole
commented
4 years ago Hi, I'm not using eMMC. Its a SD.
Armbian 5.38 Jessie (3.10.107) and the Hardkernel Ubuntu 18.04.3 minimal (3.10) work.
With the DietPi Jessie i get:
-bash: /DietPi/dietpi/login: No such file or directory
-bash: /DietPi/dietpi/func/dietpi-globals: No such file or directoryAnd i guess that's not a hardware problem.
After Joulinar gave me this link (i didn't found through the Armbian download site): https://www.armbian.com/odroid-c1/
Under kernel issues i see: serial console only Does that mean no HDMI? Or does it just mean no desktop/GUI?
Because somewhere i did read without a newer kernel from Hardkernel there is no HDMI.
Sudrien
commented
4 years ago Odroid HC1 -
root@DietPi:~# dietpi-update
DietPi-Update ───────────────────────────────────────────────────── Phase: Checking for available DietPi update
[ INFO ] DietPi-Update | Checking mirror: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. [ INFO ] DietPi-Update | No response from: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6 () [ INFO ] DietPi-Update | Checking mirror: https://dietpi.com/downloads/dietpi-update_mirror/master/server_version-6 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. [ INFO ] DietPi-Update | No response from: https://dietpi.com/downloads/dietpi-update_mirror/master/server_version-6 () [FAILED] DietPi-Update | Unable to access any update server. Please check your network connection, then rerun dietpi-update. If this error persists, please report at: https://github.com/MichaIng/DietPi/issues
System time is good, apt update appears to work.
MichaIng
commented
4 years ago @MrGlasspoole Hmm, I saw that also. But usually HDMI works, only GPU/hardware accelerated video features are definitely disabled with the new mainline kernel. Did you try this Armbian image, to rule out it's DietPi-specific? https://dl.armbian.com/odroidc1/Buster_current_minimal_nightly Did you try to SSH into the system after giving it some minutes to boot and finish firstrun setup steps?
@Sudrien Many thanks for your report. On one base image, while creating this particular image, I got the same error. Strangely after DietPi-PREP has finished it was gone, also test boot within container worked fine 🤔. Another user reported the same, so I'll retest. Meanwhile, could you try the following:
apt install --reinstall curl libcurl4
curl -sSL https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6
kaputtzich
commented
4 years ago curl error could be fixed with the commands update-ca-certificates update-ca-certificates --fresh
did a reinstall of "ca-certificates" "curl" and "libcurl4" before, maybe it's needed
MichaIng
commented
4 years ago @kaputtzich Interesting. ca-certificates reinstall is also what I did when facing the issue, and the certificate updates was included in the post-install script, but resulted in 0 new/updated/removed certificates, hence no change :thinking:.
MrGlasspoole
commented
4 years ago @MichaIng, the last Armbian i tried was Armbian_20.05.0-trunk.034_Odroidc1_buster_current_5.4.17_minimal and the result is the same. Not booting.
And the answer at the Armbian forum is. Well...
Here is what works and what doesn't: https://dietpi.com/phpbb/viewtopic.php?p=22313&sid=205966b8e95d5eb6b7b1ad34dde6ba07#p22313
Sudrien
commented
4 years ago @MichaIng The reinstall of curl gave me no change.
@kaputtzich's suggestion of
update-ca-certificates --fresh
did work - it did need the fresh option - without the curl reinstall. /etc/ssl/certs does seem to be missing a lot of .0 soft links that the working system has - for example
lrwxrwxrwx 1 root root 13 Feb 7 23:39 a94d09e5.0 -> ACCVRAIZ1.pem - present on working system
lrwxrwxrwx 1 root root 48 Feb 7 23:39 ACCVRAIZ1.pem -> /usr/share/ca-certificates/mozilla/ACCVRAIZ1.crt - present on both working and broken
That's the only difference I'm noticing, but it appears that everything has a .0 softlink after the fresh-ening
(Install proceeded as expected after that, thank you!)
MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago MichaIng
commented
4 years ago Regarding Buster:
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.dd) manually into place, since this is not placed on the file system.
JaScoMa
commented
4 years ago 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
commented
4 years ago @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
commented
4 years ago 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
commented
4 years ago @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
commented
4 years ago 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
commented
4 years ago @JaScoMa
pls can you past output of systemd-analyze blame
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/
~- [ ] RPi AlloGUI~ ~- [ ] Sparky SBC AlloGUI~
New images: https://dietpi.com/downloads/images/
3333 Does is allow boot from eMMC? EDIT: It does!