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
?