Childhurd fails to run inside ‘guix system vm’

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 17 Sep 2023 17:21
(address . bug-guix@gnu.org)
87sf7cx1tu.fsf@inria.fr
Hello!

I’m failing to run a childhurd inside a ‘guix system vm’ GNU/Linux VM as
of fc3a53525ab3dcaf7c22eec8d62294017f9760fe.

Toggle snippet (8 lines)
Sep 17 17:03:25 localhost shepherd[1]: [qemu-system-i386] qemu-system-i386: Slirp: Failed to send packet, ret: -1
Sep 17 17:03:37 localhost shepherd[1]: [qemu-system-i386] qemu-system-i386: Slirp: Failed to send packet, ret: -1
Sep 17 17:03:43 localhost shepherd[1]: [qemu-system-i386] qemu-system-i386: Bad ram pointer 0x7f739ac0001e
Sep 17 17:03:43 localhost shepherd[1]: secret service: invalid handshake #<eof>
Sep 17 17:03:43 localhost shepherd[1]: Service hurd-vm could not be started.
Sep 17 17:03:43 localhost shepherd[1]: Service hurd-vm failed to start.

When I run it by hand with KVM on my bare-metal GNU/Linux machine, it’s
all good: ?

Toggle snippet (4 lines)
$ "/gnu/store/1rg1fb9mj65rh82467vwlrkmi12p4v89-qemu-minimal-8.1.0/bin/qemu-system-i386" "-m" 2048 "--device" "rtl8139,netdev=net0" "--netdev" "user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:15900-:5900" "--snapshot" "--hda" "/gnu/store/iqacww23byvw9c5ssja9fkx6m4s057b0-disk-image" "--no-reboot" --enable-kvm
VNC server running on 127.0.0.1:5900

However, the same thing *without* KVM (as happens within ‘guix system
vm’) reproduces the “Bad ram pointer” issue:

Toggle snippet (6 lines)
$ "/gnu/store/1rg1fb9mj65rh82467vwlrkmi12p4v89-qemu-minimal-8.1.0/bin/qemu-system-i386" "-m" 2048 "--device" "rtl8139,netdev=net0" "--netdev" "user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:15900-:5900" "--snapshot" "--hda" "/gnu/store/iqacww23byvw9c5ssja9fkx6m4s057b0-disk-image" "--no-reboot"
VNC server running on 127.0.0.1:5900
qemu-system-i386: Bad ram pointer 0x7fa930e0001e
Aborted

Good news: I found a workaround! Just use the x86_64 emulator:

Toggle snippet (4 lines)
$ "/gnu/store/1rg1fb9mj65rh82467vwlrkmi12p4v89-qemu-minimal-8.1.0/bin/qemu-system-x86_64" "-m" 2048 "--device" "rtl8139,netdev=net0" "--netdev" "user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:15900-:5900" "--snapshot" "--hda" "/gnu/store/iqacww23byvw9c5ssja9fkx6m4s057b0-disk-image" "--no-reboot"
VNC server running on 127.0.0.1:5900

Obviously, I have no clue why that works, but who cares, right? :-)

Thoughts?

Ludo’.
L
L
Ludovic Courtès wrote on 18 Sep 2023 23:44
Re: bug#66053: Childhurd fails to run inside ‘g uix system vm’
(address . 66053-done@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87y1h3f976.fsf@gnu.org
Ludovic Courtès <ludovic.courtes@inria.fr> skribis:

Toggle quote (18 lines)
> When I run it by hand with KVM on my bare-metal GNU/Linux machine, it’s
> all good: ?
>
> $ "/gnu/store/1rg1fb9mj65rh82467vwlrkmi12p4v89-qemu-minimal-8.1.0/bin/qemu-system-i386" "-m" 2048 "--device" "rtl8139,netdev=net0" "--netdev" "user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:15900-:5900" "--snapshot" "--hda" "/gnu/store/iqacww23byvw9c5ssja9fkx6m4s057b0-disk-image" "--no-reboot" --enable-kvm
> VNC server running on 127.0.0.1:5900
>
>
> However, the same thing *without* KVM (as happens within ‘guix system
> vm’) reproduces the “Bad ram pointer” issue:
>
> $ "/gnu/store/1rg1fb9mj65rh82467vwlrkmi12p4v89-qemu-minimal-8.1.0/bin/qemu-system-i386" "-m" 2048 "--device" "rtl8139,netdev=net0" "--netdev" "user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:15900-:5900" "--snapshot" "--hda" "/gnu/store/iqacww23byvw9c5ssja9fkx6m4s057b0-disk-image" "--no-reboot"
> VNC server running on 127.0.0.1:5900
> qemu-system-i386: Bad ram pointer 0x7fa930e0001e
> Aborted
>
>
> Good news: I found a workaround! Just use the x86_64 emulator:

Done in 5e0ae2684615b6d10751390420e7db296785112b!

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 66053@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 66053
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch