DietPi OS unbootable on a Pi1 after attempting to implement a ds3231 RTC

  • DietPi version | latest as of today
  • Distro version | bookworm
  • Kernel version | what ever ships with the current latest release
  • Architecture | ARMv6
  • SBC model | Pi1 Model B+
  • Power supply used | 5V 1A
  • SD card used | SanDisk ultra

Steps to reproduce

  1. Enable I2C via “Dietpi-config”
  2. Reboot
  3. Then attempt to append the following line to “/boot/config.txt” “dtoverlay=i2c-rtc,ds3231”

Expected behaviour

  • Successful boot and functional RTC

Actual behaviour

  • DietPi OS is no longer booting

Extra details

I successfully installed the ds3231 RTC Circuit, and enabled i2c successfully via the “dietpi-config” utility.

The system rebooted fine, I then attempted to enable the RTC clock in the kernel via the “config.txt” file located in the boot directory, however once adding the suggested line to the bottom of the file “dtoverlay=i2c-rtc,ds3231” and rebooted I was brought to couple of bus errors before the Pi soft bricked itself.

I checked the video feed via hdmi and I’m getting no output, no longer can connect over ssh since DietPi isn’t even booting.

Thus I attempted to undo the changed in the config.txt file using a separate Linux computer and mounting the boot directory from my SD card, as far as I can see the config.txt file is missing.

I attempted to recreate it via fetching the file over on the DietPi github, however that didn’t seem to solve my issue.

Could someone please help me solve this booting issue then show me how to properly implement this module.

Any help is greatly appreciated, thank you.

did you try to connect SD card to another system like a Windows or Linux box? There should be a vFAT partition containing the config.txt. It’s not on the ext4 partition.

1 Like

I did, I connected it to an Arch system. however I was only looking at the boot directory found in the root of the main ext4 partition.

Yea on Raspberry Pi, there is a vfat partition hosting boot files and config. It’s the typical partition design for RPI device family.

1 Like

Yes, I can confirm that the vfat partition is still prescient, I mounted it on my Arch system and removed the line “dtoverlay=i2c-rtc,ds3231” from the bottom of the “config.txt” file located in the root of the vfat partition… after removing the mentioned line my Pi1 booted up perfectly fine again…

now I’ve reversed the prior effects and have gained access back into my DietPi Instance, how would you suggest I implement the RTC Module “ds3231” successfully?

I don’t see much for direct guides online other then some early posts here discussing the process, perhaps you can explain or point me in the right direction.

Thank you for your time.

did you already enable i2c within dietpi-config?

Personally, I don’t own such a module. Just found this guide on the web Adding a Real Time Clock (RTC) to the Raspberry Pi - Pi My Life Up

But it should be similar to what you already did.

1 Like

That’s literally the article I used, yes I enabled I2C in the dietpi-config and the circuit is recognized. But when adding the line to the boot config that enables the usage of that module for rtc in the kernel, it causes the OS to no longer boot till that line is removed.

maybe @MichaIng has an idea why this happen

1 Like

Generally if there is a dedicated overlay for a device, there is usually no need to enable the GPIO interface explicitly, respectively it can even conflict. I would not expect the RPi to deny booting, but not sure. Try to disable I2C again in dietpi-config and assure that in config.txt the i2c-rtc is the only I2C-related overlay/param enabled.

1 Like

Just tried this with I2C disabled in the “dietpi-config” and the following line appended in my “/boot/config.txt” file dtoverlay=i2c-rtc,ds3231 no other devices are mentioned in this file related to the I2C.

the only error I received in console during reboot is the following.

Failed to set wall message, ignoring: Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists

Call to Reboot failed: Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists

Pi1 running DietPi OS v8.25.1 now fails to boot.

Any further suggestions?

Update made some progress: When following this guide and some pointers in this Forum post I THINK I’m booting with the hwclock/ds3231 RTC Module, I’m gonna outline my steps here and it would be extremely appreciated if one of you could comment on your thoughts for optimizations and or things I should change.

|LInks|

This is the forum post in question: [SOLVED] How do I use the DS3231 RTC on NanoPi NEO3 with DietPi 7.0.2?

This is the guide used for reference “Heads up both of these resources seem dated”: Set RTC Time | Adding a Real Time Clock to Raspberry Pi | Adafruit Learning System

Okay so I didn’t bother with enabling I2C in the dietpi-config as @MichaIng suggested, I did notice that the errors previously mentioned in my last post are triggered if I2C is enabled, could you please explain what those are referring too?

this also means you won’t be able to use the i2cdetect commands to check the circuit via the python and I2C tools.

the first file I modify is the /boot/config.txt I’ve appended the following line to the end of the file, make sure to adjust it if you have a different chip.

#-------RTC-------
dtoverlay=i2c-rtc,ds3231

now that I’ve defined my overlay I’m gonna modify the configuration file for the system clock located here, /lib/udev/hwclock-set the following is my configuration taken from both the guide and vmiceli’s post.

#!/bin/sh
# Reset the System Clock to UTC if the hardware clock from which it
# was copied by the kernel was in localtime.

dev=$1

#if [ -e /run/systemd/system ] ; then
#exit 0
#fi

#/sbin/hwclock --rtc=$dev --systz
/sbin/hwclock --rtc=$dev --hctosys

if [ -e /run/udev/hwclock-set ]; then
    exit 0
fi

HCTOSYS_DEVICE=rtc1

Now will have to remove the fake hwclock package from the system using the following commands…

sudo apt -y remove fake-hwclock

sudo update-rc.d -f fake-hwclock remove

now you can reboot the Pi via sudo reboot now

after the pi reboots use the following command to read the hardware clocks date and time.

sudo hwclock -r

If the time and date is incorrect make sure your Pi is connected to the internet and use the date command to check the current system clock time.

If the time is correct you can pass that on to the Hardware clock via sudo hwclock -w then again check the hardware clocks time and date via sudo hwclock -r

I’m assuming it’s working, I’m now able to pull the system up and down, without issues, however I am curious about a few things.

what does this line do in the /lib/udev/hwclock-set file, is it necessary? HCTOSYS_DEVICE=rtc1 and what about these lines, what are they doing exactly?

dev=$1
/sbin/hwclock --rtc=$dev --hctosys
 
 if [ -e /run/udev/hwclock-set ]; then
     exit 0
 fi

Now what about confirming that I’m actually falling back to the system clock, how can this be done?

When I did have I2C enabled via the dietpi-config I was able to check via sudo i2cdetect -y 1 which would either output 69 (Circuit is correct but chip not detected) or UU (which means the RTC chip is recognized by the kernel, once disabling I2C I can’t run these checks, and when enabled it prompts me every reboot with those two errors I mentioned in my previous post.

Is there any other way to confirm this is working as intended?

Notes for anyone struggling, this link does have some great diagrams for those wiring this up. Adding a Real Time Clock (RTC) to the Raspberry Pi - Pi My Life Up

if you run into any errors after rebooting your Pi and attempting to read or write from and to the RTC Module there’s a possibility your coin battery is bad.

Finally it’s worth mentioning that in the adafruit guide, they mention that the Pi1 used the following command to check if the rtc circuit was correct, sudo i2cdetect -y 0 the bus address changed from 0 to 1 but on my Pi1 Model B+ only sudo i2cdetect -y 1 works, I would assume this may have been a software change and not a difference in hardware but I could be mistaken, please correct me if I’m wrong.

Please do let me know what you suggest I change from here @MichaIng and @Joulinar thanks for your time, hopefully someone find this information helpful in the future.

Oh, and I’ve also created a /etc/rc.local file and added the following line to it sudo hwclock -s -f /dev/rtc1 vmiceli mentions that in order to have the system time set from the DS3231 at boot you need to do so… but when attempting to enable the service via sudo systemctl restart rc.local.service supposedly the service doesn’t exist on my system, what’s the purpose of this, and do I need it? will the rtc time be applied to the system clock anyway?

Another update, apparently these errors occur every reboot regardless if I2C is enabled or not.

 Failed to set wall message, ignoring: Unit 
dbus-org.freedesktop.login1.service failed to load properly, please 
adjust/correct and reload service manager: File exists

Call to Reboot failed: Unit dbus-org.freedesktop.login1.service
 failed to load properly, please adjust/correct and reload service 
manager: File exists

The message is not related to I2C at all, or any device connected. We try to hide them however on some systems which has been upgrade from Bullseye, it did not work. usually, the message is not doing any harm to your system.

1 Like

Good to know I must of not noticed, out of curiosity what’s it complaining about?

Also could you confirm the entries in my hwclock config?

Missing dbus package. We don’t install it on a default setup as it is not needed in most case. However you could install it manually if needed.

Maybe something @MichaIng could do

1 Like

The shutdown/reboot messages are unrelated and visual only. How do your shutdown/reboot? When using the commands poweroff, reboot and halt, those messages should not show up. If you use the shutdown command: This is actually for scheduled shutdown in a certain amount of seconds/at a certain time, which requires dbus indeed. For immediate shutdown, the above 3 commands are better suited. If you use systemctl poweroff etc, these indeed have a bunch of additional features and try to pre-connect to dbus and do a lot of checks, usually not required on a single-user system.

About RTC/I2C: Do not follow the old topic, as it refers to a very different SBC and the content is pretty wrong as well. This /lib/udev/hwclock-set is not required with systemd, hence the contained exit path if /run/systemd/system exists. No idea why one would comment out these intended lines if systemd does the RTC calls internally. For this reason, this file, the legacy init.d service and even the hwclock command itself are not even part of a default Debian Bookworm anymore, but split out into a separat package util-linux-extra. Is this package installed on your system? Also any /etc/rc.local entry should hence not be required.

Removing fake-hwclock indeed makes sense. There is also a toggle for this in dietpi-config advanced options as well, but it does nothing else than installing/removing this package.

I am wondering why it is /dev/rtc1. Does a /dev/rtc0 node exist as well? Usually the first should not exist if there is only one RTC attached. This naming is AFAIK not done based on bus, but simple in the order of device detection. Not sure whether systemd would have issues if /dev/rtc1 would need to be read from while /dev/rtc0 exists as well :thinking:.

I am not sure whether i2cdetect is intended to work with the RTC (overlay) enabled. Probably it is intended that the generic I2C API is disabled, but instead everything internally configured to work with the RTC, and nothing else. i2cdetect -l does not list anything with the RTC overlay enabled but I2C disabled?

Basically, to test whether the RTC works and is correctly used as source for the system time at boot: Set time sync mode to “Custom” in dietpi-config advanced options > Time sync mode, shutdown the system, leave it off for a while, boot again, and see whether the system clock is still accurate or matches the time at shutdown (or last time sync) instead.

1 Like

Yes, I use poweroff, reboot, and halt specifically sudo reboot now or sudo reboot was used when these messages appear. I don’t notice this behavior on my Pi4 running the latest dietpi os as of the book worm update. anything helpful we can digup here, or should I just install the dbus package so I don’t have to see those warnings, ahaha

I do have a multi user system, since this Pi is being used as a backup for my Pi4’s services I could see having scheduled shutdown’s or reboots would be helpful.

In that case I’ve removed the /etc/rc.local file I created, I had a feeling alot of that documentation was a dated resource. Yes I have the util-linux-extra package installed by default, least it may of been installed as a dependency for something, util-linux-extra is already the newest version (2.38.1-5). The directory /run/systemd/system does exist, but it’s empty.

I’ve also removed the additional lines in the /lib/udev/hwclock-set config file, and uncommitted the default lines as suggested.

The Pi1 boots fine without any changes besides adding the RTC Overlay line to enable it at kernel boot time, I’m assuming it was actually the fake-hwclock package hanging me up.

I was wondering the same thing regarding RTC0 and RTC1, was this perhaps a thing with that specific sbc in the older topic?

Yes, when executing the i2cdetect -l command it does not list anything with the RTC overlay enabled and the I2C api disabled.

I attempted this, set the set time sync mode to “Custom” and left it off for a bit before booting again. when it came back up my system had the correct time compared to my local client’s host and the time the correct amount of time ahead compared to the time stamp I copied via the date command prior to shutdown.

does this mean my RTC is working??? it’s worth mentioning I think that I noticed that the RTC Mode is set to “Hardware” in the dietpi-config so the config gui is updating based on my manual purge of the fake-hwclock package.

Thanks again for the help, I truly appreciate it, the steps turned out to be less lengthy.

On the system where you still see the messages, can you check:

declare -f reboot
systemctl status systemd-logind

Quite possible that it was pulled as dependency, okay.

That is normal: It is created by systemd at boot and used as a flag for whether systemd is used as init system or not. If so, the RTC time should automatically be used as system time at boot, hence no dedicated udev rule, init.d service or something like that. All those hence check for the existence of this directory, and if so, exit without doing anything.

That is possible indeed: It stores the system time at shutdown (and every hour) to /etc/fake-hwclock.data and restores it from there at boot. But it runs way after systemd applied the RTC time as system time, well it is a systemd service, so it overrides the RTC time that way.

I am actually wondering whether we should remove fake-hwclock from our images. Actually, systemd-timesyncd does exactly the same: On every sync, it touches the file /var/lib/systemd/timesync/clock. The mtime of this file is used as boot as initial system time, in case no RTC is available. I am not 100% sure how reliable it detects this, i.e. how it knows whether the RTC time is actually true or just the one when it was manufacturered, e.g. if no battery is attached. The hwclock command in this case works and prints some (old) time, so I have no idea how systemd knows whether the RTC is true or not. Probably it uses /var/lib/systemd/timesync/clock only if its timestamp is newer than the one of the RTC. That would make sense.

I’ll run some tests after the release tomorrow. EDIT: Ah, this only works with time sync daemon mode, otherwise systemd-timesyncd is not running at shutdown, hence not touching the file.

Ah, does it exist on your system?

ls -l /dev/rtc*

Seems to :slightly_smiling_face:. Yes, dietpi-config just checks for the existence of the fake-hwclock package and the installs/deinstalls it, very simple. We just wanted to have this exposed beside the time sync mode option, so users will see it better and toggle both as needed.

1 Like