With Systemd v254 and above (i.e. Torizon 7.x), systemd has introduced a new “soft reboot” feature which resets only the userspace environment and programs.
This has some interesting applications for devices and an improved/more responsive user experience if a device must be rebooted.
However, when I tried it out on one of our devices (on Torizon 7.1.0), it presented an interesting problem: /home/ is not remounted and so the system is left unusable as during this process - /var/rootdirs/home disappears. It would appear that the bind mount into /sysroot isn’t being recreated.
:~# ls /var/rootdirs/
media/ mnt/ opt/ srv/
Note this isn’t a feature we need anytime soon - just a bug report/observation that could trip up others wanting to take advantage.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Thank you for sharing your observation regarding the ‘soft reboot’ feature in systemd v254 on Torizon 7.1.0. It seems that during a soft reboot, the /home directory is not being remounted, which indeed could leave the system in an unusable state. This issue might stem from the bind mount into /sysroot not being recreated as expected.
To address this, you might want to:
Review Systemd Service Configurations: Check the configurations related to mount points in your systemd services. Ensure they are set to remount during a soft reboot. This might involve adjusting the service files to explicitly handle remounting.
Manual Remounting: As a temporary workaround, consider manually remounting the necessary directories after a soft reboot to restore system functionality.
This appears to be a limitation or bug with the current implementation of the ‘soft reboot’ feature. Your feedback is valuable and could help improve the robustness of this feature in future updates.
Thank you again for your contribution.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
I’m not familiar with this “soft reboot” feature. In detail could you elaborate the exact steps you performed to get into this state on the device?
Without knowing more about the mechanics of this “soft reboot”. My impression of what happened is that this “soft reboot” resets the mounting and filesystem setup of OSTree. But, since it’s not an actual reboot the OSTree isn’t properly setup and mounted again when the system resumes. OSTree does this initial setup and mounting during the initramfs, so I guess this “soft reboot” does not invoke the initramfs like a normal reboot does.
If my assumptions are correct, I guess this would mean OSTree is not really compatible with this “soft reboot” functionality at the moment. With that, I did a quick search and it seems my assumptions are correct: support systemd soft reboots · Issue #3242 · ostreedev/ostree · GitHub
On the Github thread I see there is some discussion, and one person even has an experimental fork to try and solve the issue. Though nothing has made it’s way into the upstream project yet.
Unless you need this urgently, the best course of action seems to be just to follow the progress of this on the upstream project. Maybe you could comment or add to the thread on Github just to put a little more attention on this issue with the OSTree maintainers.
It’s fairly straightforward to get into this state:
Boot a 7.x Torizon install with Systemd v255
run sudo systemctl soft-reboot
Wait for the reset to finish
Observe system is in a broken state.
I suspect you are correct though - currently if OSTree is doing things explicitly in initrd, these would not be invoked again as soft-reboot starts from a later stage in the boot process.
I see. Well thanks for bringing awareness to the issue. As I said though for now let’s see what the upstream project comes up with since this seems to be on their radar as well.
