Systemd is a powerful init-system for Unix; most of the Distros have moved away from sysv-based (System V, init calls scripts based on \/etc\/inittab and \/etc\/rc*.d). Notable forks of „traditional“ (back-wards oriented?) distributions are Devuan (Debian without Systemd), funtoo (forked from Gentoo).<\/p>\n
Now systemd has many nice features such as fine-grained dependency-tracking and therefore concurrent, parallel startup of independent resources. Dependency may be one service depending on the other (feature-wise or time-wise) or even a provided resource (a device, a mount-point, a file within a mount-point).
\nWith all this flexibility comes power, and complexity.<\/p>\n
At HS-Esslingen, I maintain a computer pool with lots of Raspberry PIs: this I want to boot over the network, namely NFS, so that I don’t have to juggle with SD-cards being overwritten, being in a poor state and always out-of-sync. Students should be able to do anything on their respective RPI (like programming and loading a kernel module), yet be able to go back to reboot the well-tested and full-featured Raspbian provided to them centrally.<\/p>\n
Read-only NFS works very well (except for corner-cases such as Chromium requiring loads of dynamic libraries that need to be fetched single-file over NFS). Previously, I had done this check, the creation of mount-point directories and the mounts themselves in one extra systemd service and hooking that into the systemd A better way is to specify two mount-targets: [Mount] Then, one may adapt Systemd is a powerful init-system for Unix; most of the Distros have moved away from sysv-based (System V, init calls scripts based on \/etc\/inittab and \/etc\/rc*.d). Notable forks of „traditional“ (back-wards oriented?) distributions are Devuan (Debian without Systemd), funtoo (forked … Weiterlesen
\nHowever, with every Raspbian update, there are changes that require adaptations: With Raspbian 10.2 being based on Debian Buster, there are several ones, one particular I want to highlight here:
\nThe Service systemd_timesyncd<\/code> requires access to the file \/var\/lib\/systemd\/timesync\/clock<\/code> –this directory therefore has to be read-writable. To do so, we need to mount an overlay<\/code> on top of RAM-backed tmpfs<\/code>.
\nThis is to be only, if we have the common case of student work on the RPIs, but should not be done, when we *want* to access and update files in \/var\/lib<\/code>. Another directory made accessible locally using RAM-backed storage is \/var\/cache<\/code>, e.g. to allow work with aptitude apt search<\/code>.<\/p>\nlocal-fs.target<\/code>. This is not<\/b> very elegant.<\/p>\nvar-lib.mount<\/code> and var-cache.mount<\/code>, which are very similar:
\n
\n[Unit]
\nDescription=Overlay FS for \/var\/lib
\nDocumentation=https:\/\/www.kernel.org\/doc\/Documentation\/filesystems\/overlayfs.txt
\nDocumentation=https:\/\/www.freedesktop.org\/wiki\/Software\/systemd\/APIFileSystems
\nWants=create_tmp_dirs.service
\nAfter=create_tmp_dirs.service
\nConditionPathIsMountPoint=\/var\/tmp<\/p>\n
\nWhat=overlay
\nWhere=\/var\/lib
\nOptions=lowerdir=\/var\/lib,upperdir=\/var\/tmp\/lib_upper,workdir=\/var\/tmp\/lib_work
\nType=overlay
\n<\/code><\/p>\nsystemd-timesyncd.service<\/code> by replacing it into \/etc\/systemd\/system<\/code>, adding just one line:
\nRequiresMountsFor=\/var\/lib\/systemd\/timesync\/clock<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"