* ARM VM with networking support?
@ 2019-11-03 14:43 Ludovic Courtès
2019-11-03 17:09 ` Mathieu Othacehe
0 siblings, 1 reply; 17+ messages in thread
From: Ludovic Courtès @ 2019-11-03 14:43 UTC (permalink / raw)
To: guix-devel
Hello Guix!
‘guix system disk-image -s armhf-linux …’ currently fails with something like:
--8<---------------cut here---------------start------------->8---
[ 509.985810] FS-Cache: Loaded
[ 518.725029] 9pnet: Installing 9P2000 support
[ 522.164822] 9p: Installing v9fs 9p2000 file system support
[ 522.605051] FS-Cache: Netfs '9p' registered for caching
configuring QEMU networking...
In gnu/build/linux-boot.scm:
502:17 2 (_)
335:18 1 (configure-qemu-networking _)
In unknown file:
0 (network-interface-flags #<input-output: socket 10>)
In procedure network-interface-flags: No such device
--8<---------------cut here---------------end--------------->8---
(gnu linux vm) has this:
;; NIC is not supported on ARM "virt" machine, so use a user mode
;; network stack instead.
,@(if target-arm32?
'("-device" "virtio-net-pci,netdev=mynet"
"-netdev" "user,id=mynet")
'("-net" "nic,model=virtio"))
However this trick doesn’t give us a network interface controller, AFAICS.
I tried various QEMU options (including “-net nic,model=virtio”, which
QEMU doesn’t reject), I tried loading good’ol “e1000.ko” in the guest,
things like that, but I failed to get networking in the ARM VM.
Ideas?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-03 14:43 ARM VM with networking support? Ludovic Courtès
@ 2019-11-03 17:09 ` Mathieu Othacehe
2019-11-09 17:24 ` Ludovic Courtès
0 siblings, 1 reply; 17+ messages in thread
From: Mathieu Othacehe @ 2019-11-03 17:09 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Hello Ludo,
I think I solved this issue on my wip cross system serie:
https://patchwork.cbaines.net/patch/15252/.
Tell me if it works for you :)
Thanks,
Mathieu
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-03 17:09 ` Mathieu Othacehe
@ 2019-11-09 17:24 ` Ludovic Courtès
2019-11-11 7:23 ` Danny Milosavljevic
2019-11-11 17:34 ` Mathieu Othacehe
0 siblings, 2 replies; 17+ messages in thread
From: Ludovic Courtès @ 2019-11-09 17:24 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
Hello Mathieu,
Mathieu Othacehe <m.othacehe@gmail.com> skribis:
> I think I solved this issue on my wip cross system serie:
>
> https://patchwork.cbaines.net/patch/15252/.
>
> Tell me if it works for you :)
I confirm that it works, thank you! You should really push it to
‘master’. :-)
(BTW, there seem to be other patches in that series that have been
reviewed but are not yet applied. Is there any particular reason? Are
we still missing something?)
My goal is to build an image with “guix system disk-image -s
armhf-linux” (with qemu-binfmt) that I could put on a microSD device and
boot my Olimex A20 OLinuXino from that. But we’re not there yet!
With the patch above, I get to the point where it starts building the
image but it eventually fails with a surprising ENOSYS:
--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix system disk-image --image-size=6G ~/src/configuration/olimex-configuration.scm -s armhf-linux -v2
[…]
creating ext4 partition... label: "Guix_image" uuid: "0e4a2990-d5a0-e38c-6ea0-92621cbb768d"
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
mke2fs 1.45.4 (23-Sep-2019)
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/vda1 is mounted.
Discarding device blocks: done
Creating filesystem with 1560064 4k blocks and 390144 inodes
Filesystem UUID: 0e4a2990-d5a0-e38c-6ea0-92621cbb768d
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
[ 1149.161552] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: (null)
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Unsupported ioctl: cmd=0xffffffff80047601
Backtrace:
9 (primitive-load "/gnu/store/yagy92cgx0c4jphy8hmwqsnd4fa���@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
"@ build-log 13776 1
)@ build-log 13776 2
In ./gnu/build/vm.scm:
571:4 8 (initialize-hard-disk "/dev/vda" #:bootloader-package _ ���@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
)@ build-log 13776 2
In srfi/srfi-1.scm:
640:9 7 (for-each #<procedure initialize-partition (partition)> #)
In ./gnu/build/vm.scm:
345:3 6 (initialize-partition #<<partition> device: "/dev/vda1"���@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
>@ build-log 13776 1
)@ build-log 13776 2
368:6 5 (_ "/fs")
In ./guix/progress.scm:
70:36 4 (call-with-progress-reporter _ _)
In srfi/srfi-1.scm:
640:9 3 (for-each #<procedure 1429870 at ./guix/build/store-co���@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
>@ build-log 13776 1
@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
)@ build-log 13776 1
@ build-log 13776 1
In ./guix/build/store-copy.scm:
220:20 2 (_ "/gnu/store/zfaw40y9jr5l872jq7d01xarp2vmhinq-locale-���@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
"@ build-log 13776 1
)@ build-log 13776 1
@ build-log 13776 1
In ice-9/ftw.scm:
478:39 1 (loop _ _ #(20 11428821 16749 3 0 0 0 4096 1571486280 ���@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
)@ build-log 13776 1
@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
�@ build-log 13776 1
)@ build-log 13776 2
In unknown file:
0 (readdir #<directory stream 1057610>)
ERROR: In procedure readdir:
In procedure readdir: Function not implemented
copying 312 store items
[ 1201.814266] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[ 1201.832590] CPU: 1 PID: 1 Comm: init Not tainted 5.3.9-gnu #1
[ 1201.835441] Hardware name: Generic DT based system
--8<---------------cut here---------------end--------------->8---
(Furthermore we hit <https://issues.guix.gnu.org/issue/35350>, hence the
garbled output, but that’s another issue…)
What’s the story with ‘readdir’? The ‘guile-static-stripped’ binaries
seem to work fine:
--8<---------------cut here---------------start------------->8---
$ guix environment -s armhf-linux --ad-hoc guile-static-stripped --no-grafts -- guile -q
GNU Guile 2.2.6
Copyright (C) 1995-2019 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guile-user)> %host-type
$1 = "arm-unknown-linux-gnueabihf"
scheme@(guile-user)> ,use(ice-9 ftw)
scheme@(guile-user)> (scandir "/")
$2 = ("." ".." "bin" "boot" […])
scheme@(guile-user)>
$ guix describe
Generacio 114 Nov 02 2019 11:32:51 (nuna)
guix ab1c063
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: ab1c063ab08e069fbe62919828fa634a2e222bbf
--8<---------------cut here---------------end--------------->8---
Since this happens on a 9P mount, is that a bug specific to 9P on ARM,
or to the 9P bridge in QEMU? What would you suggest? :-)
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-09 17:24 ` Ludovic Courtès
@ 2019-11-11 7:23 ` Danny Milosavljevic
2019-11-17 17:06 ` Ludovic Courtès
2019-11-11 17:34 ` Mathieu Othacehe
1 sibling, 1 reply; 17+ messages in thread
From: Danny Milosavljevic @ 2019-11-11 7:23 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
> What’s the story with ‘readdir’?
Shooting in the dark, we've had "fun" with readdir on ARM before in GNU Mes and
ended up doing the following:
#ifdef __arm__
#define O_DIRECTORY 0x4000
/*#define O_DIRECT 0x10000*/
#else
#define O_DIRECTORY 0x10000
#endif
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-09 17:24 ` Ludovic Courtès
2019-11-11 7:23 ` Danny Milosavljevic
@ 2019-11-11 17:34 ` Mathieu Othacehe
2019-11-17 17:11 ` Ludovic Courtès
1 sibling, 1 reply; 17+ messages in thread
From: Mathieu Othacehe @ 2019-11-11 17:34 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Hey Ludo,
> (BTW, there seem to be other patches in that series that have been
> reviewed but are not yet applied. Is there any particular reason? Are
> we still missing something?)
Yes, as mentionned here:
https://lists.gnu.org/archive/html/guix-patches/2019-10/msg00388.html,
I'd like to get a review on patch 02 and I'll push the whole serie.
> My goal is to build an image with “guix system disk-image -s
> armhf-linux” (with qemu-binfmt) that I could put on a microSD device and
> boot my Olimex A20 OLinuXino from that. But we’re not there yet!
Nice :)
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix system disk-image --image-size=6G ~/src/configuration/olimex-configuration.scm -s armhf-linux -v2
> Since this happens on a 9P mount, is that a bug specific to 9P on ARM,
> or to the 9P bridge in QEMU? What would you suggest? :-)
Hmm, no clue about this one, but if you can share your
olimex-configuration.scm I can have a look with both native and cross
system compilation.
Mathieu
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-11 7:23 ` Danny Milosavljevic
@ 2019-11-17 17:06 ` Ludovic Courtès
0 siblings, 0 replies; 17+ messages in thread
From: Ludovic Courtès @ 2019-11-17 17:06 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
Hi Danny,
Danny Milosavljevic <dannym@scratchpost.org> skribis:
>> What’s the story with ‘readdir’?
>
> Shooting in the dark, we've had "fun" with readdir on ARM before in GNU Mes and
> ended up doing the following:
>
> #ifdef __arm__
> #define O_DIRECTORY 0x4000
> /*#define O_DIRECT 0x10000*/
> #else
> #define O_DIRECTORY 0x10000
> #endif
Wat? :-) (It’s 040000 in arm/fcntl.h actually!)
How would you explain that:
guix environment -s armhf-linux --ad-hoc guile-static-stripped --no-grafts -- guile -q
gives us a Guile with a valid ‘readdir’ then? I mean, the initrd runs
‘guile-static-stripped’?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-11 17:34 ` Mathieu Othacehe
@ 2019-11-17 17:11 ` Ludovic Courtès
2019-11-23 19:01 ` Mathieu Othacehe
2019-12-01 16:30 ` Mathieu Othacehe
0 siblings, 2 replies; 17+ messages in thread
From: Ludovic Courtès @ 2019-11-17 17:11 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
Hello!
Mathieu Othacehe <m.othacehe@gmail.com> skribis:
>> (BTW, there seem to be other patches in that series that have been
>> reviewed but are not yet applied. Is there any particular reason? Are
>> we still missing something?)
>
> Yes, as mentionned here:
> https://lists.gnu.org/archive/html/guix-patches/2019-10/msg00388.html,
> I'd like to get a review on patch 02 and I'll push the whole serie.
I see you pushed it to ‘core-updates’ in the meantime, and I guess it’s
all right! Apologies for not replying earlier.
>> $ ./pre-inst-env guix system disk-image --image-size=6G ~/src/configuration/olimex-configuration.scm -s armhf-linux -v2
>> Since this happens on a 9P mount, is that a bug specific to 9P on ARM,
>> or to the 9P bridge in QEMU? What would you suggest? :-)
>
> Hmm, no clue about this one, but if you can share your
> olimex-configuration.scm I can have a look with both native and cross
> system compilation.
Here’s my tentative config file.
Thanks,
Ludo’.
[-- Attachment #2: the config --]
[-- Type: text/plain, Size: 3312 bytes --]
(use-modules (gnu) (gnu bootloader u-boot))
(use-service-modules networking ssh avahi)
(use-package-modules screen linux pulseaudio wget)
(use-modules (srfi srfi-1))
;; /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt102
;; # redefine green led to blink until shutdown, try to switch OTG port to host
;; (echo heartbeat >/sys/class/leds/*green*/trigger) 2>/dev/null
;; echo 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role 2>/dev/null
;; olimex@A20-OLinuXino:~$ cat .config/pulse/default.pa
;; load-module module-alsa-sink
;; load-module module-rtp-recv
;; load-module module-native-protocol-unix
(define heartbeat-service
(simple-service 'heartbeat activation-service-type
#~(call-with-output-file
"/sys/class/leds/green:ph02:led1/trigger"
(lambda (port)
(display "heartbeat\n" port)))))
(define %ludo-key
(local-file "/home/ludo/.ssh/id_rsa.pub"))
(operating-system
(host-name "olimex")
(timezone "Europe/Paris")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader u-boot-a20-olinuxino-micro-bootloader)
(target "/dev/mmcblk0")))
(firmware '())
(file-systems (cons (file-system
(device (file-system-label "root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
(users (cons (user-account
(name "ludo")
(comment "Ludovic Courtès")
(group "users")
(supplementary-groups '("wheel"
"audio" "video")))
%base-user-accounts))
(packages (cons* screen ;strace
pulseaudio wget %base-packages))
(services (append (list heartbeat-service
(service dhcp-client-service-type)
(service openssh-service-type
(openssh-configuration
(permit-root-login 'without-password)
(authorized-keys
`(("ludo" ,%ludo-key)
("root" ,%ludo-key)))))
;; (service dropbear-service-type
;; (dropbear-configuration
;; (port-number 2222)
;; (root-login? #t)))
(tor-hidden-service "ssh"
'((22 "127.0.0.1:22")
(80 "127.0.0.1:8080")))
(service agetty-service-type
(agetty-configuration
(tty "ttyS0")
(keep-baud? #t)
(term "vt102")
(baud-rate "115200,38400,9600")))
(service ntp-service-type)
(service avahi-service-type))
%base-services))
(name-service-switch %mdns-host-lookup-nss))
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-17 17:11 ` Ludovic Courtès
@ 2019-11-23 19:01 ` Mathieu Othacehe
2019-11-25 14:04 ` Marius Bakke
2019-12-01 16:30 ` Mathieu Othacehe
1 sibling, 1 reply; 17+ messages in thread
From: Mathieu Othacehe @ 2019-11-23 19:01 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Ludo,
> Here’s my tentative config file.
> (use-modules (gnu) (gnu bootloader u-boot))
> (use-service-modules networking ssh avahi)
> (use-package-modules screen linux pulseaudio wget)
I tried to cross-compile your system file, but it depends on glib which
uses meson-build-system, that does not support cross-compilation.
Using --system, I have the same issue, I'll investigate it.
Thanks,
Mathieu
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-23 19:01 ` Mathieu Othacehe
@ 2019-11-25 14:04 ` Marius Bakke
2019-11-25 14:39 ` Mathieu Othacehe
0 siblings, 1 reply; 17+ messages in thread
From: Marius Bakke @ 2019-11-25 14:04 UTC (permalink / raw)
To: Mathieu Othacehe, Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
Mathieu Othacehe <m.othacehe@gmail.com> writes:
> I tried to cross-compile your system file, but it depends on glib which
> uses meson-build-system, that does not support cross-compilation.
Do you know roughly what's needed to support cross-compiling in
meson-build-system, apart from creating a '--cross-file'[0]?
[0] https://mesonbuild.com/Cross-compilation.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-25 14:04 ` Marius Bakke
@ 2019-11-25 14:39 ` Mathieu Othacehe
2019-11-26 10:26 ` Ludovic Courtès
0 siblings, 1 reply; 17+ messages in thread
From: Mathieu Othacehe @ 2019-11-25 14:39 UTC (permalink / raw)
To: Marius Bakke; +Cc: guix-devel
Hey Marius,
> Do you know roughly what's needed to support cross-compiling in
> meson-build-system, apart from creating a '--cross-file'[0]?
Never looked into it, but it seems that nix has proper cross compilation
support for meson (using cross-file.conf as you mentionned), see:
nixpkgs/pkgs/development/tools/build-managers/meson/default.nix
Sadly there are other build-systems where cross-compiling isn't
supported:
* scons.scm
* haskell.scm
* python.scm
* ruby.scm
* perl.scm
* meson.scm
* r.scm
* android-ndk.scm
* go.scm
* waf.scm
* emacs.scm
* asdf.scm
* ocaml.scm
* node.scm
* julia.scm
* dune.scm
* dub.scm
* ant.scm
* linux-module.scm
* rakudo.scm
* cargo.scm
* glib-or-gtk.scm
As I think that using --system is not viable (horribly slow, hard to
find native hardware to cook substitutes), extending cross-compilation
support is very important IMO.
Thanks,
Mathieu
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-25 14:39 ` Mathieu Othacehe
@ 2019-11-26 10:26 ` Ludovic Courtès
0 siblings, 0 replies; 17+ messages in thread
From: Ludovic Courtès @ 2019-11-26 10:26 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
Hi,
Mathieu Othacehe <m.othacehe@gmail.com> skribis:
> Never looked into it, but it seems that nix has proper cross compilation
> support for meson (using cross-file.conf as you mentionned), see:
> nixpkgs/pkgs/development/tools/build-managers/meson/default.nix
>
> Sadly there are other build-systems where cross-compiling isn't
> supported:
>
> * scons.scm
> * haskell.scm
> * python.scm
> * ruby.scm
> * perl.scm
> * meson.scm
> * r.scm
> * android-ndk.scm
> * go.scm
> * waf.scm
> * emacs.scm
> * asdf.scm
> * ocaml.scm
> * node.scm
> * julia.scm
> * dune.scm
> * dub.scm
> * ant.scm
> * linux-module.scm
> * rakudo.scm
> * cargo.scm
> * glib-or-gtk.scm
Yeah. :-/
> As I think that using --system is not viable (horribly slow, hard to
> find native hardware to cook substitutes), extending cross-compilation
> support is very important IMO.
I think we need both, it’s a tradeoff.
Emulated stuff is slow but it can work without any modifications. In
some cases, it’s good enough, especially if our build farm provides
enough substitutes.
Ludo’.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-11-17 17:11 ` Ludovic Courtès
2019-11-23 19:01 ` Mathieu Othacehe
@ 2019-12-01 16:30 ` Mathieu Othacehe
2019-12-09 17:35 ` Ludovic Courtès
1 sibling, 1 reply; 17+ messages in thread
From: Mathieu Othacehe @ 2019-12-01 16:30 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
Hey Ludo,
> Here’s my tentative config file.
I just generated a disk-image with your config file! Just like you, I did
hit the "unsupported ioctl" issue on both master and core-updates
branch.
The reason is that the command run when producing the disk image is:
qemu-arm qemu-system-arm disk-image-builder
^ ^
| |-- Native qemu (so for armhf-linux architecture).
|
Run by binfmt because qemu-system-arm is a binary for armhf
architecture.
So a syscall issued somewhere in disk-image-builder goes through the
kernel emulated by qemu-system-arm and via qemu-arm to your host kernel.
The failing syscall is number 47601 (FS_IOC32_GETVERSION), I don't know
why it is not supported by our host kernel. However, using a
qemu-system-arm built for arm doesn't make much sense here, because we
add an unecessary (and failing) layer of emulation.
So what I would propose is to produce a disk-image using a qemu-system-*
built for the host architecture (and not the system specified by
--system argument). This remains true when cross-compiling a system.
The attached patch does thin in an ugly way but that solves the issue.
WDYT?
Mathieu
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-vm-Force-native-qemu-usage.patch --]
[-- Type: text/x-diff, Size: 2116 bytes --]
From e107692f3a98c19d2457050635818226ee675c52 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe@gmail.com>
Date: Sun, 1 Dec 2019 16:49:36 +0100
Subject: [PATCH] vm: Force native qemu usage.
---
gnu/system/vm.scm | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 8609bd2ace..e760e7f42d 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -68,6 +68,7 @@
#:use-module (gnu system uuid)
#:use-module (srfi srfi-1)
+ #:use-module (srfi srfi-9)
#:use-module (srfi srfi-26)
#:use-module (rnrs bytevectors)
#:use-module (ice-9 match)
@@ -141,6 +142,16 @@
packages))))
(list guile-gcrypt guile-sqlite3)))
+(define-record-type <native-qemu>
+ (%native-qemu qemu system)
+ native-qemu?
+ (qemu native-qemu-qemu)
+ (system native-qemu-system))
+
+(define-gexp-compiler (native-qemu-compiler (native-qemu <native-qemu>) system target)
+ (package->derivation (native-qemu-qemu native-qemu)
+ (native-qemu-system native-qemu)))
+
(define* (expression->derivation-in-linux-vm name exp
#:key
(system (%current-system)) target
@@ -193,6 +204,9 @@ made available under the /xchg CIFS share."
(reboot)
(exit 1))))
+ (define qemu-native
+ (%native-qemu qemu (@ (guix config) %system)))
+
(let ((initrd (or initrd
(base-initrd file-systems
#:on-error 'backtrace
@@ -215,7 +229,7 @@ made available under the /xchg CIFS share."
(gnu build vm))
(let* ((native-inputs
- '#+(list qemu (canonical-package coreutils)))
+ '#+(list qemu-native (canonical-package coreutils)))
(linux (string-append #$linux "/"
#$(system-linux-image-file-name)))
(initrd #$initrd)
--
2.24.0
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: ARM VM with networking support?
2019-12-01 16:30 ` Mathieu Othacehe
@ 2019-12-09 17:35 ` Ludovic Courtès
2019-12-30 21:16 ` Building a bootable disk image for A20-OLinuXino Ludovic Courtès
0 siblings, 1 reply; 17+ messages in thread
From: Ludovic Courtès @ 2019-12-09 17:35 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
Hey ho!
Mathieu Othacehe <m.othacehe@gmail.com> skribis:
>> Here’s my tentative config file.
>
> I just generated a disk-image with your config file! Just like you, I did
> hit the "unsupported ioctl" issue on both master and core-updates
> branch.
>
> The reason is that the command run when producing the disk image is:
>
> qemu-arm qemu-system-arm disk-image-builder
> ^ ^
> | |-- Native qemu (so for armhf-linux architecture).
> |
> Run by binfmt because qemu-system-arm is a binary for armhf
> architecture.
>
> So a syscall issued somewhere in disk-image-builder goes through the
> kernel emulated by qemu-system-arm and via qemu-arm to your host kernel.
>
> The failing syscall is number 47601 (FS_IOC32_GETVERSION), I don't know
> why it is not supported by our host kernel. However, using a
> qemu-system-arm built for arm doesn't make much sense here, because we
> add an unecessary (and failing) layer of emulation.
Woow, good catch!
> So what I would propose is to produce a disk-image using a qemu-system-*
> built for the host architecture (and not the system specified by
> --system argument). This remains true when cross-compiling a system.
Indeed, makes sense.
> The attached patch does thin in an ugly way but that solves the issue.
[…]
> +(define-record-type <native-qemu>
> + (%native-qemu qemu system)
> + native-qemu?
> + (qemu native-qemu-qemu)
> + (system native-qemu-system))
> +
> +(define-gexp-compiler (native-qemu-compiler (native-qemu <native-qemu>) system target)
> + (package->derivation (native-qemu-qemu native-qemu)
> + (native-qemu-system native-qemu)))
> +
> (define* (expression->derivation-in-linux-vm name exp
> #:key
> (system (%current-system)) target
> @@ -193,6 +204,9 @@ made available under the /xchg CIFS share."
> (reboot)
> (exit 1))))
>
> + (define qemu-native
> + (%native-qemu qemu (@ (guix config) %system)))
> +
> (let ((initrd (or initrd
> (base-initrd file-systems
> #:on-error 'backtrace
> @@ -215,7 +229,7 @@ made available under the /xchg CIFS share."
> (gnu build vm))
>
> (let* ((native-inputs
> - '#+(list qemu (canonical-package coreutils)))
> + '#+(list qemu-native (canonical-package coreutils)))
This is a clever hack, but now the result of:
guix system build -s armhf-linux -d …
would be dependent on the actual system type. In other words, the
result would be different if you run it on armhf-linux, if you run it on
x86_64-linux, or if you run it on i686-linux. Not great.
Could we use an evil trick, like the ‘binfmt-misc?’ predicate we
discussed in another thread, to somehow strip one emulation layer? Hmm
probably not possible…
Why do we have that syscall ID mismatch anyway?…
Thoughts?
Ludo’.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Building a bootable disk image for A20-OLinuXino
2019-12-09 17:35 ` Ludovic Courtès
@ 2019-12-30 21:16 ` Ludovic Courtès
2019-12-31 9:26 ` Mathieu Othacehe
0 siblings, 1 reply; 17+ messages in thread
From: Ludovic Courtès @ 2019-12-30 21:16 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
Hello!
In my quest to get Guix System on an Olimex A20-Olinuxino, I tried:
guix system disk-image -s armhf-linux --image-size=16G config.scm
where ‘config.scm’ reads:
(bootloader (bootloader-configuration
(bootloader u-boot-a20-olinuxino-micro-bootloader)
(target "/dev/mmcblk0")))
… this time with offloading to an actual ARM machine. I wrote the
resulting image to an SD card, but the result appears to be unbootable.
What am I doing wrong?
Ludo’.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Building a bootable disk image for A20-OLinuXino
2019-12-30 21:16 ` Building a bootable disk image for A20-OLinuXino Ludovic Courtès
@ 2019-12-31 9:26 ` Mathieu Othacehe
2019-12-31 11:23 ` Mathieu Othacehe
2020-01-12 11:55 ` Ludovic Courtès
0 siblings, 2 replies; 17+ messages in thread
From: Mathieu Othacehe @ 2019-12-31 9:26 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Hey Ludo,
> (bootloader (bootloader-configuration
> (bootloader u-boot-a20-olinuxino-micro-bootloader)
> (target "/dev/mmcblk0")))
>
> … this time with offloading to an actual ARM machine. I wrote the
> resulting image to an SD card, but the result appears to be unbootable.
>
> What am I doing wrong?
Well, I prefer to set target to "/dev/vda", produce the image, then dd
it on the SD card. This way, you have an image with the bootloader
installed. But, this should work too.
The only way to debug is to plug an UART cable[1] :p. Most of the time, the
initrd is missing some drivers to mount the SD card ("sunxi-mmc" and
"sd_mod" maybe?).
To find missing modules, I usually remove the "quiet" kernel argument
and compare dmesg output with a Raspbian, or whatever is booting.
Tell us how it goes !
Mathieu
[1]: https://linux-sunxi.org/Olimex_A20-OLinuXino-Micro
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Building a bootable disk image for A20-OLinuXino
2019-12-31 9:26 ` Mathieu Othacehe
@ 2019-12-31 11:23 ` Mathieu Othacehe
2020-01-12 11:55 ` Ludovic Courtès
1 sibling, 0 replies; 17+ messages in thread
From: Mathieu Othacehe @ 2019-12-31 11:23 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
> Well, I prefer to set target to "/dev/vda", produce the image, then dd
> it on the SD card. This way, you have an image with the bootloader
> installed. But, this should work too.
Hmm now that I think about it, if you create an image with
"/dev/mmcblk0" as target, then dd the image on the same SD card, you are
probably wiping the bootloader installed inside the VM!
Mathieu
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Building a bootable disk image for A20-OLinuXino
2019-12-31 9:26 ` Mathieu Othacehe
2019-12-31 11:23 ` Mathieu Othacehe
@ 2020-01-12 11:55 ` Ludovic Courtès
1 sibling, 0 replies; 17+ messages in thread
From: Ludovic Courtès @ 2020-01-12 11:55 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
Hi Mathieu!
Mathieu Othacehe <m.othacehe@gmail.com> skribis:
>> (bootloader (bootloader-configuration
>> (bootloader u-boot-a20-olinuxino-micro-bootloader)
>> (target "/dev/mmcblk0")))
>>
>> … this time with offloading to an actual ARM machine. I wrote the
>> resulting image to an SD card, but the result appears to be unbootable.
>>
>> What am I doing wrong?
>
> Well, I prefer to set target to "/dev/vda", produce the image, then dd
> it on the SD card. This way, you have an image with the bootloader
> installed. But, this should work too.
Looking at the code (‘write-file-on-device’ called from
‘install-allwinner-u-boot’), it looks like it has to be “/dev/vda”,
indeed!
> The only way to debug is to plug an UART cable[1] :p. Most of the time, the
> initrd is missing some drivers to mount the SD card ("sunxi-mmc" and
> "sd_mod" maybe?).
>
> To find missing modules, I usually remove the "quiet" kernel argument
> and compare dmesg output with a Raspbian, or whatever is booting.
I don’t have a UART cable at hand, so I’m really shooting in the dark
until I get one. :-)
Attached is the latest config I’ve tested, to no avail. I’d say that
the kernel boots, because the Ethernet socket starts blinking, but
there’s no heartbeat.
Danny, I think you added U-Boot support for this board; did you get it
to work on the metal?
Thanks,
Ludo’.
[-- Attachment #2: the config --]
[-- Type: text/plain, Size: 4590 bytes --]
(use-modules (gnu) (gnu bootloader u-boot))
(use-service-modules networking ssh avahi)
(use-package-modules screen linux pulseaudio wget)
(use-modules (srfi srfi-1))
;; /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt102
;; # redefine green led to blink until shutdown, try to switch OTG port to host
;; (echo heartbeat >/sys/class/leds/*green*/trigger) 2>/dev/null
;; echo 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role 2>/dev/null
;; olimex@A20-OLinuXino:~$ cat .config/pulse/default.pa
;; load-module module-alsa-sink
;; load-module module-rtp-recv
;; load-module module-native-protocol-unix
(define heartbeat-service
(simple-service 'heartbeat activation-service-type
#~(catch 'system-error
(lambda ()
(call-with-output-file
"/sys/class/leds/green:ph02:led1/trigger"
(lambda (port)
(display "heartbeat\n" port))))
(const #f))))
(define %ludo-key
(local-file "/home/ludo/.ssh/id_rsa.pub"))
(operating-system
(host-name "olimex")
(timezone "Europe/Paris")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader u-boot-a20-olinuxino-micro-bootloader)
(target "/dev/vda"))) ;"/dev/mmcblk0"
(firmware '())
(initrd-modules '("sunxi-mmc" "ahci-sunxi" "sunxi-nand" "sunxi" "sd_mod"
;; Taken from /etc/modules in the Debian image.
;; "sw_ahci_platform" ;SATA support
"ahci_platform"
;; "lcd"
;; "hdmi"
;; "ump"
;; "disp"
;; "sunxi-emac"
;; "sunxi-gmac"
;; "nand"
;; "gt2005"
;; sun4i_csi0 i2c_addr=0x78 ccm="gt2005"
;; mali
"sun4i_ts"
;; "sunxi_cedar_mod"
;; "gpio_sunxi"
;; "sun4i-keyboard"
;; "g-ether"
;; "pwm-sunxi"
;; sun4i_csi0
;; ft5x_ts
;; "spi-sun7i"
;; "sunxi_can"
;; Taken from %BASE-INITRD-MODULES:
"usb-storage" "uas" "usbhid" "hid-generic"
"nls_iso8859-1"))
(file-systems (cons (file-system
(device (file-system-label "root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
(users (cons (user-account
(name "ludo")
(comment "Ludovic Courtès")
(group "users")
(supplementary-groups '("wheel"
"audio" "video")))
%base-user-accounts))
(packages (cons* screen ;strace
pulseaudio wget %base-packages))
(services (append (list heartbeat-service
(service dhcp-client-service-type)
(service openssh-service-type
(openssh-configuration
(permit-root-login 'without-password)
(authorized-keys
`(("ludo" ,%ludo-key)
("root" ,%ludo-key)))))
;; (service dropbear-service-type
;; (dropbear-configuration
;; (port-number 2222)
;; (root-login? #t)))
(tor-hidden-service "ssh"
'((22 "127.0.0.1:22")
(80 "127.0.0.1:8080")))
(service agetty-service-type
(agetty-configuration
(tty "ttyS0")
(keep-baud? #t)
(term "vt102")
(baud-rate "115200,38400,9600")))
(service ntp-service-type)
(service avahi-service-type))
%base-services))
(name-service-switch %mdns-host-lookup-nss))
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-01-12 11:55 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-03 14:43 ARM VM with networking support? Ludovic Courtès
2019-11-03 17:09 ` Mathieu Othacehe
2019-11-09 17:24 ` Ludovic Courtès
2019-11-11 7:23 ` Danny Milosavljevic
2019-11-17 17:06 ` Ludovic Courtès
2019-11-11 17:34 ` Mathieu Othacehe
2019-11-17 17:11 ` Ludovic Courtès
2019-11-23 19:01 ` Mathieu Othacehe
2019-11-25 14:04 ` Marius Bakke
2019-11-25 14:39 ` Mathieu Othacehe
2019-11-26 10:26 ` Ludovic Courtès
2019-12-01 16:30 ` Mathieu Othacehe
2019-12-09 17:35 ` Ludovic Courtès
2019-12-30 21:16 ` Building a bootable disk image for A20-OLinuXino Ludovic Courtès
2019-12-31 9:26 ` Mathieu Othacehe
2019-12-31 11:23 ` Mathieu Othacehe
2020-01-12 11:55 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).