[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to "install" guixsd on a digitalocean server

From: myglc2
Subject: Re: how to "install" guixsd on a digitalocean server
Date: Fri, 07 Apr 2017 14:34:27 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

On 04/07/2017 at 14:31 ng0 writes:

> Andy Wingo transcribed 1.0K bytes:
>> Hi :)
>> On Fri 07 Apr 2017 16:04, myglc2 <address@hidden> writes:
>> > On 04/07/2017 at 14:07 Andy Wingo writes:
>> >
>> >> I just "installed" GuixSD on a DigitalOcean droplet.  You can't actually
>> >> install GuixSD; you have to mutate an existing installation into
>> >> GuixSD.  But fine.
>> > [...]
>> >
>> > I upgraded Debian to GuixSD on a physical server in a similar way ...
>> >
>> >
>> >
>> > ... but I used 'guix system init' instead of 'guix system reconfigure'.
>> >
>> > I wonder, could that approach have been used in this situation to avoid
>> > the need to "clean up the remaining Debian bits"?
>> Neat.  For me the answer is, I don't know :)  I thought with guix system
>> init you had to do a bunch of partitiony type things?  Certainly if I
>> had a blank scratch space I could do that.
>> In hindsight it is something of a miracle that "reconfigure" worked on a
>> previously non-GuixSD system.  Strange.  I will accept it though :)
>> Andy
> Okay, you have to provide a config.scm and you have to have root or
> sudo, in which case you already have the rights to cause total
> destruction on the machine... but should we point that out that it is
> possible to "accidentally" run a succesful guix system init on a system
> which is let's say Debian or whatever, ever if it is just for curiosity
> of discovery?

I think we should. Because an inadvertent 'guix system init' can easily
produce a machine that no longer boots.

> And why would we point it out?

It is useful. Here are some examples ...

1) Before installing GuixSD, our users may well install Guix to check it
   out (I did with both with nix/nixOS and guix/GuixSD). Once they do,
   'guix system init' is easier than USB install because ...

   - it's quicker.

   - they don't have to find a USB key.

   - they can do install steps (edit config.scm, fdisk, etc) on a fully
     functional OS rather than a less functional install image.

   - If installing a server, they can do it all over ssh. This is way
     easier than plugging in a USB key + monitor or fiddling around with
     remote management tools.

2) As Andy has demonstrated, 'Guix Binary install + guix system init'
   works in situations where the USB install may be inconvenient or may
   not work.

3) In my experience (several headless server installs over the last
   year, including testing the graphical USB installer), I have found
   that 'Guix Binary install + guix system init' is more convenient. A
   simple makefile (attached) makes it even more convenient.

Note: None of this meant as a criticism of our USB install, or the
upcoming Graphical GuixSD installer.

> Is there any harm in it or do we trust sudo/root users to know that
> this can happen?

In my experience, the most likely "bad outcome" with 'guix system init'
is that the system hangs because of a problem with the
grub-configuration or file-system "device" fields. See for example ...

If a user experiences this they may be better off with the USB install
since can reboot from USB and try again. So maybe we should recommend
making a "GuixSD USB rescue key" before trying 'guix system init' for
the first time ;-)

Attachment: makefile
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]