Subject: [bug#76501] [PATCH 1/1] gnu: machine: hetzner: Fix deployment on smaller instances.

From: Roman Scherer <[email-masked]>
Date: Wed, 26 Feb 2025 09:52:33 +0100

Hi Fabio,

Fabio Natali <[email-masked]> writes:

> On 2025-02-25, 11:27 +0100, Roman Scherer <[email-masked]> wrote:
>> I also opened a support ticket at Hetzner with the request to have more
>> disk space on the rescue system of smaller instances. They said they
>> handed the request over to their customers team and will prioritize it,
>> depending on demand.
>>
>> @Fabio / anyone listening: If you want to see this happening, maybe also
>> send them an email about this ;)
>
> Hi Roman,
>
> Absolutely, good idea and glad to do that. I think the Guix Foundation
> has a Hetzner account too, we could think of sending an email from that
> account too. I'll try and reach out to someone at the Guix Foundation
> (Tanguy? Chris?) to suggest this.
>
> Shall we generally indicate that we've run into issues with the size of
> the rescue system - or do we have any number that we can attach to our
> request? E.g. anything above X GB on all instances (including the
> smallest ones)?

The current approach works with the smallest ARM instance, cax11, and it
has 1.9GB free space when booted into the rescue system. Maybe ask for a
bit more than this, just to be safe.

> This is orthogonal and probably worth a separate thread but I wonder how
> this works with the other guix deploy backend, the DigitalOcean one, and
> if there's any similar limitation there.

On Digital Ocean guix deploy does not use a resuce system, but instead
boots into a Debian system that then gets "infected" with a Guix system,
by installing it on top of the Debian system, and moving directories
like /etc around. I tried this initially, but run into issues with the
network not resolving hosts anymore when /etc got moved. It looked like
the infect script used for Digitial Ocean is tied to a specific Debian
version, that wasn't available on Hetzner.

> Thanks, best wishes, Fabio.