Hi, Mathieu Othacehe <m.othac...@gmail.com> skribis:
>> 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: > >> 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.) > > 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. Understood. :-/ Another approach would be to do like ‘guix system vm’, which is to share the store with the host. But then we would need a way to be able to run a daemon in the guest and have its build results overlaid on top of the host-provided store. Note that system tests other than the installation tests actually use the equivalent of ‘guix system vm’ already, so they copy much less stuff around. Thanks, Ludo’.
