[Cin] arm emulation on qemu links

[Andrew Randrianasulu]

On Friday, November 12, 2021, <mnieuw at zap.a2000.nl> wrote:

> Andrew, thanks for the links. I followed mostly the procedure of
> the DVD:
> https://blog.lazym.io/2021/04/16/Run-ARM-MIPS-Debian-on-QEMU/
>
> Still, it took almost 2 hours until it was finished, that was after
> downloading the ISO. Host CPU load was rarely above 15%, and host disk
> access was almost absent. ISO version was as specified in the
> procedure, but further in the procedure is the wrong version (easy to
> correct).
>
> Some notes:
> 1) I tested this on Fedora_35 with the latest qemu 6.1 release.
> 2) The procedure specified system-arm, that does not exists (anymore). I
> used aarch64. I specified 4G memory, 4 CPUs.
> 3. I did not do anything from that procedure regarding networking.
> Fedora has by default a bridge device setup, and it simply worked,
> looked fast too (not measured). I did see it going out during the
> install, and network detection and dhcp was very quick.
> 4. I did follow his procedure regarding the cdrom, but it is possible
> this later qemu version has a working cdrom device. TODO.
> 4. During the install near the end I was asked if I wanted to install
> some extra utilities, but it failed when I tried it. In the end, the
> qcow2 diskfile was 1.6G, quite small.
> 5. To extract the boot kernel and initrd I did not use sudo as
> specified with virt-copy-out, failed for some reason. Without sudo it
> was fine. His command virt-ls was nowhere to be found (not in the
> package manager), but during the install I noted the exact version
> numbers and used those.
> 6. After installation the system restarted itself, but because the
> qemu parameters were still those from the original start, it came back
> to the installer. I just killed it.
> 7. When starting the system with the supplied example (with adapted
> kernel/initrd numbers) and 4G memory, it starts fine to a cmd prompt.
> But networking does not work. Possibly it will if I use the same
> networking parameters as when doing the install. Even ifconfig was not
> there.
> 8. When using virt-manager, you can create a new VM (in virt-manager)
> from an existing OS image (the .qcow2 file in this case). But it boots
> an UEFI (and that doesn't react to kbd entries, likely because unlike
> a PC boot, it cannot setup kbd/mouse for this "virt" VM), and apparently
> the image is not set up for that. But it does generate a .xml file with
> lots of details, more than specified on the cmd line from the
> instructions. I suspect I can modify it to not use an UEFI firmware
> file and associated nvram file (this is how it works normally), but use
> directly the supplied kernel/initrd.



not sure if virt-manager can deal with 'foreign' aarch64 guest vs x86
host...

>
> So, quite nice so far. Networking next, else this is unusable for
> testing (the building of) an ARM version of CinGG.
> Is there no video-like device anywhere in this "virt" arm machine?


in theory virtio-gpu should be around, see opensuse  howto:

---
You can add graphics and mouse and keyboard by adding the following options:

-device virtio-gpu-pci -device nec-usb-xhci -device usb-tablet -device
usb-kbd
---

but this require guest-side driver in kernel (not sure if Debian compiles
this driver as of deb 10)


> Shouldn't one be able to have an "headless" Debian with a GUI terminal
> on the remote end (in this case the host)?


in theory yes, I played with remote X client (Cingg) from e2k machine, just
need to set up DISPLAY variable on headless end and allow connection to
local X server (xhost?)



> MatN
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20211112/92d0a517/attachment.htm>