Hi Fabio, Fabio Natali writes: > On 2025-02-25, 11:27 +0100, Roman Scherer 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.