Does Guix have an application that runs the guix system vm, that runs a live(SD/SSD) Guix OS installer, that imports system and home configuration files?

Guix
1

And if not, is it possible to create such application?

P.S. I’m not sure whether to call it a Live(SD/SSD) installer as the “Live” part will be missing unless it’s USB.

If anyone wonders why you want to run to run a Live(SD/SSD) OS installer on a VM here’s my little story…

Story time

It was a dark and stormy night… so as usual, I was feeling up for playing some Dance Dance Revolution game which I had installed on my older computer. Now one of my friends asked “Why I would need such a large computer for it, why not use a raspberry Pi?" That way you could more easily bring it to friends whenever they want to play” and I thought “Great idea!“

Now for whatever reason, when I installed the raspberryPI OS on my SD card via a program called manjaro-arm-installer, the network didn’t work, but that was okay, because all I wanted to do was to run the DDR game locally. So all I had to do was install the debian packages and it would be A-OK!
But it turned out that the packages the game needed were all 32-bit and it had to be build from source, which would take a long time and I didn’t know what packages it wanted, so I just ran ./configure && make && make install and hoped for the best… which took hours and then it turned out make failed and that I needed an extra debian package, and again and again and a.. so I had this brilliant idea:
”Why not save a little of bit of time by installing the same OS on a second SD card with all the debian packages, plus some extra for both installing the game and some other setting that would hopefully make the network connection possibly work?”

So I went back and forth on swapping SD cards and then installing everything over again for the next one, and then swapping and installing, swapping and installing… and I did this 30 times and each time when I used the liveSD installer I had to press down and enter to select/dev/sdb or I’d be selecting /dev/sda when pressing enter immediately and well…

I think you guessed it already, after the 30th time I selected the wrong device.. uh oh!!

But, I was able to save it just in time. I’m not sure anymore what exactly happened, but it was along the lines of only having effected /boot, while the rest of my hard disk was still saved. So I started checking.. I think /mnt/boot to confirm my fears. And I would find the Raspberry Pi images on it. So I deleted those with cd /mnt/boot and then sudo rm -rf * and while I was at it with deleting those Raspberry Pi boot image files I thought “Why not wipe my mounted Raspberry SDcard fully before starting anew, so sudo rm -rf ../* and then get some coffee/tea”.

Yeah, let’s relax… mmm… good tea! Delicious!.. Wait, why is it taking so long to delete everything?..
…

……

……..

NOOOOOO..!!! :sob:

And this would never have happened if Live(SD/SSD/USB) installers are run on VMs.

Now you could argue that manjaro-arm-installer should have done what most liveCD installers do and remove devices with giant disk sizes, but that’s still not 100% foolproof.
So that’s why I’m asking this question.

2

That’s an interesting workflow.

Debian uses the lb tool for building custom installations. Look into that if you’re interested in Debian. It’s widely used for “appliance” images & embedded. Guix is much better and more flexible. Because of how apt works, lb can involve a lot of unnecessary work & storage.

vyos/vyos-build contains a lot of bash & python for governing how an image gets built, whether it boots on SD/USB, runs in a VM or runs in a PXE image. The VyOS bootloader loads with grub, uses isolinux and needs to build squashfs archives. Then it selects from one of several VyOS system images (so a router can rollback to a previous OS version). So that project contains a lot of examples of interfacing with the Debian build tools, which I’ve found to be otherwise difficult to find.

Guix and Nix have their own “container” abstractions, which are similar to LXC or docker, but instead have their own tooling for interfacing with Linux’s namespaces. These are lightweight containers, don’t require a docker-daemon. They’re a different tool, but may be an option. Nix has some tooling for running containers as services. I think guix does too.

IDK about passing through hardware to guix containers though (this involves passing the right options to guix container so device files are shared). In any case, libvirt makes it easier to define whether a host or a VM controls hardware. So it’s possible to build a guix system that runs as a VM image, where you iterate on your config.scm while it’s running on libvirt. You can use virt-manager or XML to give the VM access to the raw SD card device.

There may be some better workflow options. Regardless, the more you know about the /gnu/store, the more you can anticipate:

  • what would need a rebuild if you deploy built packages to another system
  • How to control channel updates to ensure packages are reproducible (result in the same hash)
  • How to use tools like guix copy to deliver packages or entire profiles over ssh (requires manually managing guix gc roots sometimes)
3

Although, now I’m reading manjaro instead of Debian, so my entire response is maybe random.

If you look at the Makefile in the RDE source code, Tropin does some automation with VMs that may give you some ideas.

I used to run Garuda Arch in a VM on proxmox on a gaming PC. I later converted that arch installation to run directly in the hardware by extracting the disks from qemu, then writing them to the device and fixing the bootloader. You can definitely install to a VM that writes to raw disks.

4

Oh and you can bridge the /gnu/store inside a VM to the host’s /gnu/store for dev systems so iteration is faster. The RDE Makefile does that and the Guix manual covers it. However it’s a bit hacky and I’ve never tried it, so you may need some help/advice from someone else.

Building these appliance images is one of the primary benefits that brought me to Guix. It’s really cool to have an immutable image you can just plug into a device & boot. Iterating to get to that point can be slow though, unfortunately.