all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze)
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Progress on 'guix deploy'
Date: Tue, 11 Jun 2019 11:14:39 -0400	[thread overview]
Message-ID: <87k1dscfxc.fsf@sdf.lonestar.org> (raw)
In-Reply-To: <871s01l4c2.fsf@sdf.lonestar.org> (Jakob L. Kreuze's message of "Mon, 10 Jun 2019 13:47:57 -0400")

[-- Attachment #1: Type: text/plain, Size: 5709 bytes --]

zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:

> It seems likely that the SSH issue I was dealing was being caused by
> the store being read-only. I'll investigate that today and report
> back.

Sorry it took so long. It took me some significant time yesterday to
figure out how the high-level 'virtual-machine' interface actually
starts QEMU guests, but I did eventually boot a marionette with an image
produced by 'system-qemu-image' and was greeted by the same error, so I
suspect that the SSH issue isn't being caused by a read-only store.

In a Guile REPL, I created a VM image with something like the following:

#+BEGIN_SRC scheme
(use-modules ...)

(define os
  (marionette-operating-system
   (simple-operating-system
    (service dhcp-client-service-type)
    (service openssh-service-type
             (openssh-configuration
              (permit-root-login #t)
              (allow-empty-passwords? #t))))))

(with-store store
  (run-with-store store
    (mlet* %store-monad ((image (system-qemu-image os #:disk-image-size (* 3600 (expt 2 20))))
                         (_ ((store-lift build-derivations) (list image))))
      (return
       (begin
         (display (derivation->output-path image))
         (newline))))))
#+END_SRC

I proceeded to start it with 'qemu-sytem-x86_64' to get obtain the
system's store path from 'dmesg', created a writeable image with
'qemu-img' à la 'qemu-command/writable-image', and then passed the
equivalent of the following as the command for 'make-marionette':

#+BEGIN_SRC sh
export QEMU=/gnu/store/sw2rrqmjij73wcy3ajd47ypvmzh12yz6-qemu-3.1.0/
export SYSTEM=/gnu/store/rk5yy9xhxbl9zbqs78kzgxmmxd72zsq0-system/

$QEMU/bin/qemu-system-x86_64 \
    -drive file=/home/jakob/test.img,if=virtio \
    -kernel $SYSTEMkernel/bzImage \
    -initrd $SYSTEM/initrd \
    -append "console=ttyS0 --root=/dev/vda1 --system=$SYSTEM --load=$SYSTEM/boot" \
    -enable-kvm \
    -no-reboot \
    -net nic,model=virtio \
    -object rng-random,filename=/dev/urandom,id=guixsd-vm-rng \
    -device virtio-rng-pci,rng=guixsd-vm-rng \
    -vga std \
    -m 256 \
    -net user,hostfwd=tcp::2222-:22
#+END_SRC

Where '/home/jakob/test.img' is the writeable image that 'qemu-img'
produced. Running 'make check-system TESTS=ssh-deploy-os yields the same
error:

#+BEGIN_SRC
;;; (auth success)
;;; [2019/06/11 10:25:52.727456, 2] channel_open: Creating a channel 43 with 64000 window and 32768 max packet
;;; [2019/06/11 10:25:54.533529, 2] ssh_packet_global_request: Received SSH_MSG_GLOBAL_REQUEST packet
;;; [2019/06/11 10:25:54.533616, 2] ssh_packet_global_request: UNKNOWN SSH_MSG_GLOBAL_REQUEST hostkeys-00@openssh.com 0
;;; [2019/06/11 10:25:54.533638, 1] ssh_packet_process: Couldn't do anything with packet type 80
;;; [2019/06/11 10:25:54.533739, 2] ssh_packet_channel_open_conf: Received a CHANNEL_OPEN_CONFIRMATION for channel 43:0
;;; [2019/06/11 10:25:54.533775, 2] ssh_packet_channel_open_conf: Remote window : 0, maxpacket : 32768
;;; [2019/06/11 10:25:54.534340, 2] channel_rcv_change_window: Adding 2097152 bytes to channel (43:0) (from 0 bytes)
;;; [2019/06/11 10:25:54.534378, 2] channel_request: Channel request exec success
;;; [2019/06/11 10:25:54.593719, 2] grow_window: growing window (channel 43:0) to 1280000 bytes
qemu-system-x86_64: terminating on signal 15 from pid 7454 (/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/guile)
;;; [2019/06/11 10:25:55.074345, 2] channel_open: Creating a channel 44 with 64000 window and 32768 max packet
;;; [2019/06/11 10:25:55.074381, 1] ssh_socket_exception_callback: Socket exception callback: 2 (-1)
;;; [2019/06/11 10:25:55.074418, 1] ssh_socket_exception_callback: Socket error: Unknown error -1
;;; [2019/06/11 10:25:55.074478, 0] channel-open-session: [GSSH ERROR] Socket error: Unknown error -1: #<input-output: channel (closed) 685d880>
Backtrace:
          15 (apply-smob/1 #<catch-closure e08a20>)
In ice-9/boot-9.scm:
    705:2 14 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
    619:8 13 (_ #(#(#<directory (guile-user) e86140>)))
In guix/store.scm:
   623:10 12 (call-with-store _)
In guix/status.scm:
    768:4 11 (call-with-status-report _ _)
In guix/store.scm:
  1794:24 10 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
In unknown file:
           9 (_ #<procedure 2df8820 at ice-9/eval.scm:330:13 ()> #<…> …)
In guix/monads.scm:
    482:9  8 (_ _)
In gnu/tests/machine.scm:
   323:12  7 (_ _)
In gnu/machine.scm:
    118:2  6 (_ _)
In guix/store.scm:
  1690:38  5 (_ #<store-connection 256.99 5364000>)
In guix/ssh.scm:
   292:18  4 (send-files #<store-connection 256.99 5364000> _ _ # _ # …)
   106:18  3 (inferior-remote-eval (begin (use-modules (guix) # …) …) …)
    99:14  2 (remote-inferior _)
In ssh/popen.scm:
     64:4  1 (open-remote-pipe _ "guix repl -t machine" "r+")
In unknown file:
           0 (channel-open-session #<input-output: channel (closed) …>)

ERROR: In procedure channel-open-session:
Throw to key `guile-ssh-error' with args `("channel-open-session" "Socket error: Unknown error -1" #<input-output: channel (closed) 685d880> #f)'.
make: *** [Makefile:5726: check-system] Error 1
#+END_SRC

I was also able to verify that the store was writeable by staring the VM
with the same parameters and running 'guix -i hello'.

Apologies for not having something more easily reproducible -- a lot of
this configuration came about by running the QEMU tools from the shell.
If desired, I can clean it up into a proper commit and push it to my
feature branch.

Regards,
Jakob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2019-06-11 15:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-08  0:42 Progress on 'guix deploy' Jakob L. Kreuze
2019-06-09  2:19 ` Christopher Lemmer Webber
2019-06-10  9:31 ` Ludovic Courtès
2019-06-10 17:47   ` Jakob L. Kreuze
2019-06-11  0:35     ` [bug#36162] [PATCH 0/4] Add 'remote-eval' Jakob L. Kreuze
2019-06-12 13:52       ` Ludovic Courtès
2019-06-12 15:43         ` Jakob L. Kreuze
2019-06-12 20:39           ` Ludovic Courtès
2019-06-11 15:14     ` Jakob L. Kreuze [this message]
2019-06-11 18:40       ` Progress on 'guix deploy' Ludovic Courtès
2019-06-11 20:54         ` Jakob L. Kreuze
2019-06-12 16:34           ` Jakob L. Kreuze
2019-06-11 18:36     ` Ludovic Courtès
2019-06-11 19:42       ` Jakob L. Kreuze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k1dscfxc.fsf@sdf.lonestar.org \
    --to=zerodaysfordays@sdf.lonestar.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.