Hello Sid,
On Wed, Dec 28, 2022 at 05:39:46PM -0800, Sid Agrawal wrote:
Hi, I am attempting to run the *vmm_arm run scripts* and am running into a few issues. I am running this on Ubuntu 22.04 with x86_64. The scenario I am trying is to run a with the *hw kernel with arm_v8a arch.*
First Issue: '*src/libc' not found - unable to guess version* *Steps:*
*git clone ...*
*cd genode-dir* *tool/create_builddir arm_v8a*
*# Add additional repos in the build.conf file.*
*cd build* *make KERNEL=hw BOARD=virt_qemu_arm_v8a* *make KERNEL=hw BOARD=virt_qemu_arm_v8a run/vmm_arm* # Returns the following errors: including /home/siagraw/genode-hw/tool/run/power_on/qemu including /home/siagraw/genode-hw/tool/run/log/qemu including /home/siagraw/genode-hw/tool/run/boot_dir/hw including /home/siagraw/genode-hw/repos/os/run/vmm_arm.run Error: recipe for 'src/libc' not found - unable to guess version make: *** [Makefile:431: run/vmm_arm] Error 1
The reason is most probably that you did not add the `repos/libports` repo to the REPOSITORIES variable inside your `build.conf` file. The libc and other ported libraries are part of this repo. Without including it, the depot tools used in the run-script cannot find the recipe for libc.
[init -> vm] / # mount /dev/vda /root; cp -r /etc /root; ls /root/etc; umount /root [init -> vm] mount: mounting /dev/vda on /root failed: No such file or directory <--- This seems to failing as there is nothing inside /dev in the VM. I tried an "ls" in my run script and that showed that /dev is empty. [init -> vm] fstab init.d resolv.conf Run script execution successful.
I have a few questions here:
- Was it ok to remove the libc line from the run script?
It seems that actually no component is really dependent on the libc in this run-script (anymore?). Otherwise, you would have seen that it fails to start, because of the missing libc.so ROM module. Maybe, it was necessary before, but missed to be removed again. Thank you for the hint!
- I was expecting the VM to hang around with a shell. Is that not the
expected behavior?
The VM is presenting a shell, but this is not interactively connected with the UART. It is an automated test, where the component `test-terminal_expect_send` waits for the shell prompt, mounts the VirtIO block device, copies data to it, and prints the result. The run-script proofs the printed results.
- I should be able to run this scenario of a rpi3, right? Instead of
running inside Qemu(where I have effectively 2 level of virtualization from the point of the VM).
The run-script gets executed nightly on i.MX 7D SABRE, and i.MX 8MQ EVK boards, and can be executed on QEmu. In theory it should work on RPI3 too. But this board is not part of our testing infrastructure. So I cannot give guarantees.
Regards Stefan
Best, Sid
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users