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’.