Hey ho! Mathieu Othacehe <m.othac...@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’.
