| Message ID | cd9e7fa23e9e4da9ccf59598d68413ba13cb00d3.1520183159.git.yann.morin.1998@free.fr |
|---|---|
| State | Accepted |
| Commit | 6e5df928539efd424a381f3434fe5b9da1f2dffa |
| Headers | show |
| Series | [1/3] package/skeleton-init-systemd: work around for /var/lib not populating | expand |
On Sun, 2018-03-04 at 18:06 +0100, Yann E. MORIN wrote: > Currently, we handle the factory by redirectoring /var with a symlink at > build time, and with some trickery during the filesystem generation, > depending on whether we need to remount the filesystem read-write or > not. > > However, this is causing wquite some pain with latest systemd, now that > they have moved their dbus socket to /run instead of /var/run. > > As such, trying to play tricks with /var/run as a symlink is difficult, > because at times it is in .usr/share/factory/var/run (during build) and > then it is in /var/run (at runtime). So a relative symlink is not > possible. But an absolute symlink is not possible either, because we are > installing out-pf-tree. The symlink does work ok if the patches to fix it are applied. Both the build time ${TARGET_DIR}/var/run and run time /var/run work. However... > We fix all this mess by making /var a real directory from the onset, so > that we can use the runtime-expected layout even during the build. > > Then, during filesystem generation, we move /var away to the factory, > and populate it as we used to do. This still requires a post-fs hook to > restore /var after the filesystem generation. I think this a better way. It was I was alluding to on IRC as a system that wasn't tied to work-arounds for specific directories in var. But I was troubled by... > This leaves a situation that, should the filesystem generation fails, > /var will be left in an inconsistent state. But that is not worse than > what we already had anyway. I wondered if there was a way to get fakeroot to also "fake" the movement of the files in addition to modification of owner and group, but it appears there is not. I do not think it would be impossible for fakeroot to gain this ability.
diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk index 6a0527fde2..ff64205cbe 100644 --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk @@ -19,7 +19,6 @@ ifeq ($(BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW),y) define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW echo "/dev/root / auto rw 0 1" >$(TARGET_DIR)/etc/fstab - mkdir -p $(TARGET_DIR)/var endef else @@ -31,15 +30,14 @@ else # back there by the tmpfiles.d mechanism. define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW mkdir -p $(TARGET_DIR)/etc/systemd/tmpfiles.d - mkdir -p $(TARGET_DIR)/usr/share/factory/var - ln -s usr/share/factory/var $(TARGET_DIR)/var echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab endef define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR - rm -f $(TARGET_DIR)/var - mkdir $(TARGET_DIR)/var + rm -rf $(TARGET_DIR)/usr/share/factory/var + mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var + mkdir -p $(TARGET_DIR)/var for i in $(TARGET_DIR)/usr/share/factory/var/* \ $(TARGET_DIR)/usr/share/factory/var/lib/* \ $(TARGET_DIR)/usr/share/factory/var/lib/systemd/*; do \ @@ -59,7 +57,7 @@ SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_V define SKELETON_INIT_SYSTEMD_POST_ROOTFS_VAR rm -rf $(TARGET_DIR)/var - ln -s usr/share/factory/var $(TARGET_DIR)/var + mv $(TARGET_DIR)/usr/share/factory/var $(TARGET_DIR)/var endef SKELETON_INIT_SYSTEMD_ROOTFS_POST_CMD_HOOKS += SKELETON_INIT_SYSTEMD_POST_ROOTFS_VAR @@ -68,6 +66,8 @@ endif define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS mkdir -p $(TARGET_DIR)/home mkdir -p $(TARGET_DIR)/srv + mkdir -p $(TARGET_DIR)/var + ln -s ../run $(TARGET_DIR)/var/run $(SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW) endef
Currently, we handle the factory by redirectoring /var with a symlink at build time, and with some trickery during the filesystem generation, depending on whether we need to remount the filesystem read-write or not. However, this is causing wquite some pain with latest systemd, now that they have moved their dbus socket to /run instead of /var/run. As such, trying to play tricks with /var/run as a symlink is difficult, because at times it is in .usr/share/factory/var/run (during build) and then it is in /var/run (at runtime). So a relative symlink is not possible. But an absolute symlink is not possible either, because we are installing out-pf-tree. Oh the joys of cross-compilation... :-) We fix all this mess by making /var a real directory from the onset, so that we can use the runtime-expected layout even during the build. Then, during filesystem generation, we move /var away to the factory, and populate it as we used to do. This still requires a post-fs hook to restore /var after the filesystem generation. This leaves a situation that, should the filesystem generation fails, /var will be left in an inconsistent state. But that is not worse than what we already had anyway. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Trent Piepho <tpiepho@impinj.com> Cc: Adam Duskett <aduskett@gmail.com> Cc: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> --- Note: even with this, we can't move the /var directory back to the common skeleton, becasue the sysv skeleton has a slew of symlinks back to /tmp anyway. So /var has to stay a per-skeleton directory. Pfeew... --- package/skeleton-init-systemd/skeleton-init-systemd.mk | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)