Guix on a cloud VM

Guix on a cloud VM

[Ben Sturmfels]

Hi Mathieu (and CC'ing help-guix),

Thanks for your help on the Guix IRC yesterday! I'm still struggling
with getting the VM running as I'd like. I tried the ISO format as you
suggested, but my hosting service (Binary Lane) seems to treat this
somewhat-specially as a read-only format. I can "trick" it into
restoring from this image using their "clone" feature though. The
machine boots up fine but the result seems to be a read-only Guix where
/etc/fstab shows an iso9660 filesystem.

Backing up a little for context, I've tried qcow2 format which is lovely
and small, but fails to boot on my hosting service with "No bootable
devices".

I've also tried efi-raw which boots and runs smoothly, but fails to
resize later on my hosting service. (Resize is required because
otherwise I literally have to generate and upload a 20GB image.) I
suspect (but don't know for sure) that this is related to the additional
40M EFI partition created in the image before the root EXT4 partition.
The images provided by my hosting service only have a single EXT4
partition eg. Debian 10.

Do you know if it's possible to get `guix system image` to skip the EFI
partition when creating an efi-raw image?

A couple of other questions too:

Does the process in your blog post work for you if you go straight to
QCOW2 with `--image-type=QCOW2` rather than converting the efi-raw to
qcow2?

Are you able to later resize the storage via your DigitalOcean control
panel? This operation is failing for me currently.

Thanks again for your help and excellent blog post!

Ben

Reference for anyone else reading:

Mathieu's blog post:
https://othacehe.org/hosting-a-blog-using-only-scheme.html

My work-in-progress guix deploy experiments:
https://stumbles.id.au/getting-started-with-guix-deploy.html

Re: Guix on a cloud VM

[Mathieu Othacehe]

Hello Ben,

> Thanks for your help on the Guix IRC yesterday! I'm still struggling
> with getting the VM running as I'd like. I tried the ISO format as you
> suggested, but my hosting service (Binary Lane) seems to treat this
> somewhat-specially as a read-only format. I can "trick" it into
> restoring from this image using their "clone" feature though. The
> machine boots up fine but the result seems to be a read-only Guix where
> /etc/fstab shows an iso9660 filesystem.

Yeah, the read-only partition is imposed by Guix itself. The <image>
record has a "volatile-root?" field that defaults to true. This means
that an overlayfs backed with a tmpfs partition is created for the ROOT
partition. You can have a look to the "mount-root-file-system" procedure
of the (gnu build linux-boot) module.

I don't think that iso9660 is the appropriate format for what you are
trying to achieve anyway, as you probably want changes to the image to
be made persistent.

> Backing up a little for context, I've tried qcow2 format which is lovely
> and small, but fails to boot on my hosting service with "No bootable
> devices".

Oh, too bad. You could maybe contact Binary Lane support to find out
why? Have you tried to boot your qcow2 image on your machine with QEMU?
The command line would look like the one presented here:
https://guix.gnu.org/manual/en/html_node/Installing-Guix-in-a-VM.html.

> I've also tried efi-raw which boots and runs smoothly, but fails to
> resize later on my hosting service. (Resize is required because
> otherwise I literally have to generate and upload a 20GB image.) I
> suspect (but don't know for sure) that this is related to the additional
> 40M EFI partition created in the image before the root EXT4 partition.
> The images provided by my hosting service only have a single EXT4
> partition eg. Debian 10.
>
> Do you know if it's possible to get `guix system image` to skip the EFI
> partition when creating an efi-raw image?

No it is not possible currently, due to how Grub is installed on Guix
System images. However, you should be able to resize your partition
manually using fdisk and resize2fs, see below :).

> Does the process in your blog post work for you if you go straight to
> QCOW2 with `--image-type=QCOW2` rather than converting the efi-raw to
> qcow2?

Yes, the --image-type=qcow2 option was introduced after the blog post
writing, it should be equivalent.

> Are you able to later resize the storage via your DigitalOcean control
> panel? This operation is failing for me currently.

I had a root partition smaller than the disk size, and managed to resize
it following those instructions:
https://askubuntu.com/questions/24027/how-can-i-resize-an-ext-root-partition-at-runtime.

Be sure that you answer "N" to that question:

--8<---------------cut here---------------start------------->8---
Do you want to remove the signature? [Y]es/[N]o: N
--8<---------------cut here---------------end--------------->8---

Thanks,

Mathieu

Re: Guix on a cloud VM

[Ben Sturmfels]

Thanks Mathieu! We've discussed further on IRC, but summarising below
for the list.

On Tue, 31 Aug 2021, Mathieu Othacehe wrote:

> Oh, too bad. You could maybe contact Binary Lane support to find out
> why? Have you tried to boot your qcow2 image on your machine with QEMU?
> The command line would look like the one presented here:
> https://guix.gnu.org/manual/en/html_node/Installing-Guix-in-a-VM.html.
>
>> I've also tried efi-raw which boots and runs smoothly, but fails to
>> resize later on my hosting service. (Resize is required because
>> otherwise I literally have to generate and upload a 20GB image.) I
>> suspect (but don't know for sure) that this is related to the additional
>> 40M EFI partition created in the image before the root EXT4 partition.
>> The images provided by my hosting service only have a single EXT4
>> partition eg. Debian 10.
>>
>> Do you know if it's possible to get `guix system image` to skip the EFI
>> partition when creating an efi-raw image?
>
> No it is not possible currently, due to how Grub is installed on Guix
> System images. However, you should be able to resize your partition
> manually using fdisk and resize2fs, see below :).

I contacted Binary Lane's support and they advised that while they
didn't support QCOW2, I could resolve the resizing issue by using their
"BYO OS" configuration, rather than their built-in image configurations
like "Debian". Doing so disables their auto-magic storage resizing
feature which seems to choke on the multi-partition image. I can live
with uploading a 1.5GB raw image and then resizing the partition. :)

Noting that you also have a working demo of a single partition image
type, that we may see in the near future.

Thanks very much for your help!

Regards,
Ben

Re: Guix on a cloud VM

[Ben Sturmfels]

FYI for others, I've updated my `guix deploy` blog post with a bunch of
extra learnings thanks to Mathieu and others:

https://stumbles.id.au/getting-started-with-guix-deploy.html

Regards,
Ben