Merge branch 'master' into joeyconfig

4 files changed, 91 insertions, 0 deletions

diff --git a/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor.mdwn b/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor.mdwn
new file mode 100644
index 00000000..8625ee00
--- /dev/null
+++ b/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor.mdwn
@@ -0,0 +1,43 @@
+Hello,
+
+I merged 5.2.0 into my .propellor, last merge was merging f6797bed.
+
+Since the merge, when I try to spin, I get:
+
+    riva4.ni.fr.eu.org has ipv4 91.121.114.4 ... ok
+    ** warning: Unknown host OS is not supported by this property.
+    CallStack (from HasCallStack):
+      error, called at src/Propellor/Property.hs:350:30 in main:Propellor.Property
+    riva4.ni.fr.eu.org container vz-web2 ... failed
+    riva4.ni.fr.eu.org overall ... failed
+
+I have in my config.hs:
+
+    riva4 :: Host   
+    riva4 = host "riva4.ni.fr.eu.org" $ props
+	    & ipv4 "91.121.114.4"
+	    & stdContainerSpawn "vz-web2" "2g" vzWeb2
+
+    stdContainerSpawn :: Systemd.MachineName
+		      -> String
+		      -> Systemd.Container
+		      -> Property (HasInfo + DebianLike)
+    stdContainerSpawn name size container =
+	    Lvm.lvFormatted Lvm.YesReallyFormatLogicalVolume
+		    (Lvm.LogicalVolume name (Lvm.VolumeGroup "vg0")) size
+		    Partition.EXT4
+		    `before` Fstab.mounted "auto" dev dir mempty
+		    `before` Systemd.nspawned container
+		    `describe` ("container " ++ name)
+      where 
+	    dev = "/dev/vg0" </> name
+	    dir = "/var/lib/container" </> name
+
+    vzWeb2 :: Systemd.Container
+    vzWeb2 = Systemd.debContainer "vz-web2" $ props
+	    & osDebian (Stable "stretch") X86_64
+	    & ipv4 "10.42.2.13"
+
+I reviewed all changes in propellor, but I cannot find what can cause this.
+
+How can I debug this?
diff --git a/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor/comment_1_6ed53a6752f3f88acce023a4fe1b9bf6._comment b/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor/comment_1_6ed53a6752f3f88acce023a4fe1b9bf6._comment
new file mode 100644
index 00000000..608bc3e2
--- /dev/null
+++ b/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor/comment_1_6ed53a6752f3f88acce023a4fe1b9bf6._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-01-24T16:55:19Z"
+ content="""
+This comes from something using `unsupportedOS'`, perhaps via `pickOS`.
+
+Probably it's coming from the use of `Systemd.nspawned`,
+which is going to use debootstrap to build the container,
+since the container uses debian. To use debootstrap,
+it needs to install it, and `Debootstrap.installed`
+uses `pickOS` to work out how to install it, but only supports
+installing debootstrap on linux hosts. Your riva4 host does not have its OS
+declared, leading to the failure.
+
+It seems there ought to be a way to get a deeper call
+stack, to make it easier to work this out. It's possible to build
+propellor with profiling and get a complete call stack, as shown at
+<https://wiki.haskell.org/Debugging#Stack_trace>. It might make sense for
+propellor to always be built that way. 
+
+A simpler approach is to 
+add `HasCallStack =>` constraints to `pickOS` and `unsupportedOS'`,
+so that those will have a call stack that reaches back to their
+caller, which in your case would reach back to `Debootstrap.installed`,
+which is probably enough. For now, I've made this change.
+"""]]
diff --git a/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor/comment_2_8592411690ea524b65e4fba580d51ba8._comment b/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor/comment_2_8592411690ea524b65e4fba580d51ba8._comment
new file mode 100644
index 00000000..430c4e90
--- /dev/null
+++ b/doc/forum/__34__Unknown_host_OS__34___after_merging_recent_propellor/comment_2_8592411690ea524b65e4fba580d51ba8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Nicolas.Schodet"
+ avatar="http://cdn.libravatar.org/avatar/0d7ec808ec329d04ee9a93c0da3c0089"
+ subject="response"
+ date="2018-01-29T20:49:46Z"
+ content="""
+Thanks, it works :)
+
+riva4 is not configured by propellor yet, but osDebian does not touch anything so it's OK.
+"""]]
diff --git a/doc/forum/imageBuiltFor_mount_points_not_automatically_created/comment_19_22178bd21d8a44bdd67cad162f71c400._comment b/doc/forum/imageBuiltFor_mount_points_not_automatically_created/comment_19_22178bd21d8a44bdd67cad162f71c400._comment
new file mode 100644
index 00000000..bd34df0a
--- /dev/null
+++ b/doc/forum/imageBuiltFor_mount_points_not_automatically_created/comment_19_22178bd21d8a44bdd67cad162f71c400._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/2982bac2c2cd94ab3860efb189deafc8"
+ subject="comment 19"
+ date="2018-01-29T17:55:43Z"
+ content="""
+I tried several configurations, without success. Without a serial console, that was not fun to debug... I finally tried to boot the image with qemu, and that worked! So I thought that maybe I should try to use a MSDOS partition table instead of a GPT one, just to be sure. And that finally produced a bootable image on that damn card! :) I'll report a bug to PCEngines. It's unfortunate I can't test the GPT code more, but it would probably work, as it booted in qemu.
+
+Thanks a lot Joey!
+
+"""]]