* Make a sparse file (to save space) to be our disk image:

dd if=/dev/zero of=disk.img bs=1 count=0 seek=30GiB

* Partition it (I suspect that toggling the boot flag is unnecessary,
  but I did it just to be safe):

parted -s disk.img mklabel msdos
parted -s disk.img mkpart primary ext4 10M 100%
parted -s disk.img toggle 1 boot
parted -s disk.img print

* Set up a loopback device:

sudo losetup -P /dev/loop0 disk.img

* Make a file system:

sudo mkfs.ext4 -L root /dev/loop0p1

* Mount it:

sudo mount /dev/loop0p1 /mnt

* Init the system:

sudo guix system init ~/bare-bones-with-ssh.scm /mnt

* Grab some coffee.

* Unmount it:

sudo umount /mnt

* Detach the loopback device:

sudo losetup -d /dev/loop0

* Compress the disk image, so we can copy it to the instance faster.

gzip disk.img

* Copy the image to the instance:

scp -i ~/.ssh/marusich-ec2.pem disk.img.gz ubuntu@ec2-54-214-139-189.us-west-2.compute.amazonaws.com:/tmp

* Log into the instance (Ubuntu EC2 images always use the "ubuntu" user,
  and the marusich-ec2.pem key is the one that I generated when
  launching the instance using the AWS Management Console earlier).

ssh -i ~/.ssh/marusich-ec2.pem ubuntu@ec2-54-214-139-189.us-west-2.compute.amazonaws.com

(While logged into the instance)

* Write the disk image to the target (30 GiB) EBS volume (/dev/xvdf is
  where it's attached):

sudo bash -c 'gzip -d -c /tmp/disk.img.gz > /dev/xvdf'

* Grab another cup of coffee.  This takes a while.

(From the AWS Management Console)

* Stop the instance.

* Detach all its EBS volumes.

* Attach the target (30 GiB) volume to the instance as '/dev/sda1'.
This will actually attach the volume at '/dev/xvda'.  I don't know why
EC2 requires us to attach it as '/dev/sda1', but it does; it's weird.

* Start the instance.

* Now ssh into your new EC2 instance running GuixSD!

ssh alice@ec2-54-189-100-63.us-west-2.compute.amazonaws.com

* From here, you can reconfigure to your heart's content.  I've
  confirmed that running "guix system reconfigure" works.



Some thoughts about the experience:

* The "get console screenshot" and "get system log" features (of Amazon
  EC2) don't work with the GuixSD instance; not sure why, but it made
  troubleshooting a little harder.  Maybe tty settings need tweaking?

* It would have been nice if I could have done this without relying on
  an existing EC2 instance.  In the future, we could consider using the
  EC2 APIs to import an image, similar to what is described here:
  http://docs.aws.amazon.com/vm-import/latest/userguide/import-vm-image.html

* There was some discussion in IRC about whether or not it would make
  sense to have a "base AMI" for GuixSD.  Dave made a good case for
  avoiding that practice [1], which goes against the spirit of GuixSD.
  Instead, for using GuixSD with virtualization services like EC2, in
  the long term, it seems preferable to make it easy to init the system
  you want (including the ssh keys and all) and then import that system
  into the EC2 service (or other virtualization service).  That's
  basically what I did here, albeit via a hacky manual method.

* There is currently no support for declaring a user's authorized_keys
  for SSH.  Just like we have a way to declare a user's password, it
  would be great to have a way to declare a user's authorized_keys.
  There was some discussion about this on IRC also [1], with some
  promising paths forward.

[1] https://gnunet.org/bot/log/guix/2016-11-30

-- 
Chris