Comments (9)
Weird: In the journalctl log it shows that the time was correctly set:
systemd-timesyncd[297]: Initial clock synchronization to Tue 2024-03-26 09:36:01.879213 GMT.
But during the APT update, it is at an older time. As if it somehow got set back later.
EDIT: Ah right, because it is already set to mode 0, it is not waiting for the time sync. Okay indeed this is not optimal: The systemd-timesyncd service is disabled later after dietpi-software
ran, bit run_ntpd
does not wait for the time sync already before that. Would be better to have it reading the mode elsewhere, so that the effective setting always matches the state of thr systemd unit and is only set together with dietpi-set_software ntpd-mode
after first run setup has otherwise finished. But I do not like to have multiple flags. I have to think about how to do this best.
But in general, it actually also makes sense to set the time sync mode to 0 only after an additional time sync daemon has been installed, not before. Probably best is to better/clearer split dietpi.txt
into sections: One for things which are intended to be set before first boot to be applied during first run setup automatically, and one which contains only flags for things which are not fully effective alone, or cause issues when changing them directly. Such could also be put into a dedicated file.
For this particular case we could also force the updater to wait for timesyncd only during first boot. Just as you suggested.
from dietpi.
Actually the time sync mode configured in dietpi.txt
should be applied after the initial update and after in case automated installs did finish. Without moreless correct system time (so that HTTPS succeeds), it would fail already at the dietpi-update
check. So it should always sync the time at least once with systemd-logind
at early boot, once network has been configured.
At which stage exactly did it fail? Otherwise, I suggest to leave NTP mode untouched for first boot and then apply it with the automation script. You can use this command after chrony was installed:
/boot/dietpi/func/dietpi-set_software ntpd-mode 0
from dietpi.
To reproduce minimally i loaded the image fresh from the dietpi website:
DietPi_RPi-ARMv8-Bookworm.img.xz
No worries about the password in the config, it's public / randomized on build:
dietpi.txt
ssh into the image and it shows this:
Choosing take over and cancel to investigate the state of the image:
root@adsb-feeder:~# cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=1
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
The logs don't seem to be very useful:
root@adsb-feeder:/var/tmp/dietpi/logs# ls
dietpi-firstboot.log dietpi-ramlog.log fs_partition_resize.log
dietpi-firstboot.log:
http://sprunge.us/N7dVni
dietpi-ramlog.log:
http://sprunge.us/FGRdL2
fs_partition_resize.log:
http://sprunge.us/7UMRUC
Anything else in regards to logs i can get you?
I'm pretty sure you could reproduce with the above but i'm happy to investigate further.
Edit:
journalctl: http://sprunge.us/ovZodp
from dietpi.
At which stage exactly did it fail? Otherwise, I suggest to leave NTP mode untouched for first boot and then apply it with the automation script. You can use this command after chrony was installed:
That will be a perfectly good work-around for the usecase in question.
(I've already tested a similar workaround just using sed to modify the config because i wasn't aware of the mentioned command, worked perfectly fine)
from dietpi.
The early setup steps all succeded. Is there some /var/log/dietpi-update.log
or /var/tmp/dietpi/logs/dietpi-firstrun-setup.log
?
from dietpi.
Not that i can see:
root@DietPi:~# ls /var/log/
README btmp lastlog private wtmp
root@DietPi:~# ls /var/tmp/dietpi/logs/
dietpi-firstboot.log dietpi-ramlog.log fs_partition_resize.log
from dietpi.
dietpi-update stage 0 log: http://sprunge.us/oiBnJG
To get the log i added logging to this line: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-login#L188
(Probably good to add logging for that regardless of this issue)
systemd-timesyncd systemd service seems to only runs after that first dietpi-update (it does run as the journal shows and it hasn't yet run because the time isn't set yet)
In other NTP modes dietpi-update specifically starts systemd-timesyncd via run_ntpd when starting but for NTP=0 it does not.
from dietpi.
Yeah that approach didn't work because it doesn't wait for network / wait for timesync success. (the commit above that references the issue that wasn't really ready)
It's quite tricky to add some sort of exception for $G_DIETPI_INSTALL_STAGE == 0
into dietpi/func/run_ntpd
I don't have a good idea for it and it's probably not that important.
In regards to the logging i've tested some simple changes and made a PR but feel free to just close the PR and add logging as you see fit :)
#6988
from dietpi.
Probably best is to better/clearer split
dietpi.txt
into sections: One for things which are intended to be set before first boot to be applied during first run setup automatically, and one which contains only flags for things which are not fully effective alone, or cause issues when changing them directly. Such could also be put into a dedicated file.
Well the issue with this option is that settings 1-4 are perfectly valid to set before first boot, just option 0 is not.
So possibly just a remark that you shouldn't set 0 before first boot is complete?
That of course makes the document longer but maybe that's the way?
from dietpi.
Related Issues (20)
- Regression: GPIO | Latest kernel deprecates sysfs API #5385 HOT 20
- Update failed HOT 1
- Donation: Paypal "Donations to this recipient aren't supported in this country" HOT 4
- HomeBridge stop working ... installed but not HOT 2
- dietpi-update | Error with php apt signing key HOT 6
- Probelm updating from 8.22.3 to 9.2 HOT 2
- Bad news :PiVPN is ending. HOT 18
- available image for Pi-5 HOT 5
- Faile install Logitech Media server HOT 2
- logname: no login name HOT 5
- dietpi-update on first boot is not working HOT 1
- Dietpi-Software Portainer HTTPS? HOT 3
- Time Server Issue in China HOT 21
- Initial startup fails HOT 1
- Failed to install Docker via software HOT 4
- [USER ERROR] After Bullseye upgrade, `apt-get -y -eany update` fails with `option 'e' [from -eany] is not understood` HOT 4
- CPU Governor on NanoPi NEO3 seems faulty HOT 7
- Iteration v9.4 (2024-05-11)
- APT | TLS errors when connecting to dietpi.com HOT 13
- DietPi has encountered an error during update to v9.3.0 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dietpi.