Hello,
> Yes: you need to have ‘installation-os-for-gui-tests’ (or preferably a > variant thereof) include all the services/packages needed for the target > config. > > In the manual installation tests we use ‘define-os-with-source’ to both > embed the target OS and its references in the installation image *and* > have the source of the target OS available in /etc/target-config.scm in > the installation image. Ok! I'm testing with an installation image containing all desktop environments. This represents 1200 store items (image around 6GiB). The disk-image creation takes 2h45 on a powerful machine (with KVM). I've seen your insights on this topic here: --8<---------------cut here---------------start------------->8--- > I'd like to propose an alternative mechanism which would be faster and > not involving virtual machines. Maybe producing the disk-image in a > container? Unfortunately, I don’t think that’s possible. The reason we resort to VMs is that the Linux kernel doesn’t allow you, for instance, to mount a file system without being root. So doing things like running Parted, mounting a file system, and populating it typically requires root privileges. (In some cases, there are tools like mksquashfs that can do that from user-space, but it’s very ad-hoc.) --8<---------------cut here---------------end--------------->8--- It makes sense and after some digging, I cannot propose something better (nix is using the same mechanism). However, I feel very frustrated by this disk-image thing, loosing a lot of time and computation time for some copies. > It’d be IMO clearer, although technically equivalent, to make it: > > (or (marionette-eval exp marionette) > (throw 'marionette-eval-failure 'exp)) > > Perhaps you don’t even need to catch it. You are right :) I pushed this patch throwing exception as suggested. Thanks, Mathieu