[Pkg-ltsp-devel] Bug#693636: /usr/sbin/ltsp-update-image: creates image with no kernels if /boot is on a separate partition

[Vagrant Cascadian]

Package: ltsp-server
Version: 5.4.2-2
Severity: important
File: /usr/sbin/ltsp-update-image
Control: tags -1 patch

When running "ltsp-update-image / --cleanup" on a system with a separate /boot 
partition, this results in an image without any kernels, and thus thin clients 
cannot boot from it. Also, if partitions such as /usr or /var are sub-mounts, 
it will also fail.

This is because the aufs filesystem it creates does not mirror the submounts of 
branches. It is required to create a separate aufs mount for each submount.

Upstream, this is fixed with the following patch:

 2401 Vagrant Cascadian	2012-11-16
      ltsp-update-image: Mount aufs sub-mounts directly. If we do not mount the 
      sub-mounts directly, systems with a separate /boot partition end up with no 
      kernels for network boot.

=== modified file 'server/ltsp-update-image'
--- server/ltsp-update-image	2012-06-14 15:01:00 +0000
+++ server/ltsp-update-image	2012-11-17 07:05:52 +0000
@@ -145,6 +145,24 @@
         done
         test -n "$union_type" || die "No overlayfs or aufs support detected"
         mark_mount -t "$union_type" -o "$union_opts" "$union_type" "$cu_chroot"
+        if [ "aufs" = "$union_type" ]; then
+            # Aufs doesn't handle sub-mounts, so mount each needed sub-mount
+            # directly. If we do not mount the sub-mounts directly, systems 
+            # with a separate /boot partition end up with no kernels for 
+            # network boot.
+            while IFS= read -r point; do
+                case "$point" in
+                    "$cu_rofs"*|/) 
+                    ;;
+                    *)
+                    mkdir -p "$cu_cow${point%/}"
+                    mark_mount -t "$union_type" -o "dirs=$cu_cow${point%/}=rw:$cu_rofs${point%/}=ro" "$union_type" "$cu_chroot${point%/}"
+                    ;;
+                esac
+            done <<EOF
+$(get_mounts "$chroot")
+EOF
+	fi
     fi
     chroot "$cu_chroot" /usr/share/ltsp/ltsp-cleanup --yes
 }


Overlayfs allegedly doesn't have this problem, although overlayfs is not yet 
available in Debian.

This shouldn't affect the default case of using ltsp-update-image or 
ltsp-build-client with a chroot, but limits the usefulness of a much simpler 
mode for setting up LTSP servers:

  https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp

live well,
  vagrant