>
> Oh, why is that?  You mean qemu-system-arm running natively on the BBB,
> right?
>

Yes, when running qemu-system-arm you have only a limited set of available
machines (qemu-system-arm -M help).
BBB isn't one of them, but as there are only about 50 emulable machines, it
will be the case for many other boards :(

In a future patch, I'll adapt "load-in-linux-vm" to use "-M virt" for
qemu-system-arm because contrary to most boards,
it works well with linux-libre, allows up to 8 CPU, virtio (see
https://wiki.qemu.org/Documentation/Platforms/ARM) ...

However, I don't think qemu virt machine will boot with every specific arm
kernel a user might end up using
on his target.

Perhaps we should change ‘system-disk-image’ to use a more minimalistic
> initrd since all it needs is those virtio* drivers?
>

That would be an option for the initrd, but the kernel problem above
remains :)

Thanks !

2017-11-13 11:23 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:

> Hello,
>
> Mathieu Othacehe <m.othacehe@gmail.com> skribis:
>
> >> What was the use case and rationale for you?
> >
> > The problematic use case was to try to produce a GuixSD arm installer
> > for beaglebone black. The kernel linux-libre-arm-omap2plus I'm planning
> > to use can't be used in qemu.
>
> Oh, why is that?  You mean qemu-system-arm running natively on the BBB,
> right?
>
> > Plus, I'd like to use a raw-initrd because linux-libre-arm-omap2plus is
> > quite a light kernel configuration. As system-disk-image asks for
> > base-initrd, the required modules won't be find during image
> > construction with omap kernel.
>
> Perhaps we should change ‘system-disk-image’ to use a more minimalistic
> initrd since all it needs is those virtio* drivers?
>
> Thanks for explaining!
>
> Ludo’.
>