because my patch series tend to fail on x86 while working on arm, I hope those links will help in creating virtual arm debian install for testing official qemu wiki https://wiki.qemu.org/Documentation/Platforms/ARM link from this wiki to older (2017) guide, you probably want to change debian distro name in d/l links https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-6... also, for faster performance try https://wiki.qemu.org/Features/tcg-multithread (do not forgot -smp 4 (or 8) argument)
Hi Andrew, Very interesting, I was thinking about the same, for testing arm64 versions. I have some experience with qemu, although I mostly use VirtualBox. It is quite possible to use UEFI boot with qemu. I presume the emulated arm64 machine is good enough for compilations, for actually testing CinGG you probably need more?? A problem might be missing build utilities, I know a programmer who (for fun) wanted to build a CinGG for macOS had problems there. MatN On Wed, 10 Nov 2021 13:07:13 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
because my patch series tend to fail on x86 while working on arm, I hope those links will help in creating virtual arm debian install for testing
official qemu wiki
https://wiki.qemu.org/Documentation/Platforms/ARM
link from this wiki to older (2017) guide, you probably want to change debian distro name in d/l links
https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-6...
also, for faster performance try https://wiki.qemu.org/Features/tcg-multithread (do not forgot -smp 4 (or 8) argument)
On Wednesday, November 10, 2021, <[email protected]> wrote:
Hi Andrew, Very interesting, I was thinking about the same, for testing arm64 versions. I have some experience with qemu, although I mostly use VirtualBox. It is quite possible to use UEFI boot with qemu. I presume the emulated arm64 machine is good enough for compilations, for actually testing CinGG you probably need more??
more memory, (-m 2047) more -smp :) there is link for opensuse install, you can use pre-installed os image https://en.opensuse.org/openSUSE:AArch64#Using_an_emulator or debian arm64 image (also pre-installed, so no need for multihour long install) https://wiki.debian.org/Arm64Qemu https://cdimage.debian.org/cdimage/openstack/current-10/ you can prepare specific source image with pre-downloaded/unpacked/patched source and add this as second hdd...
A problem might be missing build utilities, I know a programmer who (for fun) wanted to build a CinGG for macOS had problems there.
MatN
On Wed, 10 Nov 2021 13:07:13 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
because my patch series tend to fail on x86 while working on arm, I hope those links will help in creating virtual arm debian install for testing
official qemu wiki
https://wiki.qemu.org/Documentation/Platforms/ARM
link from this wiki to older (2017) guide, you probably want to change debian distro name in d/l links
https://translatedcode.wordpress.com/2017/07/24/ installing-debian-on-qemus-64-bit-arm-virt-board/
also, for faster performance try https://wiki.qemu.org/Features/tcg-multithread (do not forgot -smp 4 (or 8) argument)
On Wednesday, November 10, 2021, Andrew Randrianasulu < [email protected]> wrote:
On Wednesday, November 10, 2021, <[email protected]> wrote:
Hi Andrew, Very interesting, I was thinking about the same, for testing arm64 versions. I have some experience with qemu, although I mostly use VirtualBox. It is quite possible to use UEFI boot with qemu. I presume the emulated arm64 machine is good enough for compilations, for actually testing CinGG you probably need more??
as for runtime it works via vnc (!) on 4 (2ghz max) + 4(1.5 ghz max) arm core and 2 gb ram (+zswap around 1.4 gb shared with android 10) . sometimes it works fast enough (realtime) with even fullhd h264 video, sometimes not - probably due to cpu freqency/sheduling enforced by kernel)
more memory, (-m 2047) more -smp :)
there is link for opensuse install, you can use pre-installed os image
https://en.opensuse.org/openSUSE:AArch64#Using_an_emulator
or debian arm64 image (also pre-installed, so no need for multihour long install)
https://wiki.debian.org/Arm64Qemu https://cdimage.debian.org/cdimage/openstack/current-10/
you can prepare specific source image with pre-downloaded/unpacked/patched source and add this as second hdd...
A problem might be missing build utilities, I know a programmer who (for fun) wanted to build a CinGG for macOS had problems there.
MatN
On Wed, 10 Nov 2021 13:07:13 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
because my patch series tend to fail on x86 while working on arm, I hope those links will help in creating virtual arm debian install for testing
official qemu wiki
https://wiki.qemu.org/Documentation/Platforms/ARM
link from this wiki to older (2017) guide, you probably want to change debian distro name in d/l links
https://translatedcode.wordpress.com/2017/07/24/installing- debian-on-qemus-64-bit-arm-virt-board/
also, for faster performance try https://wiki.qemu.org/Features/tcg-multithread (do not forgot -smp 4 (or 8) argument)
On Wednesday, November 10, 2021, Andrew Randrianasulu < [email protected]> wrote:
On Wednesday, November 10, 2021, Andrew Randrianasulu < [email protected]> wrote:
On Wednesday, November 10, 2021, <[email protected]> wrote:
Hi Andrew, Very interesting, I was thinking about the same, for testing arm64 versions. I have some experience with qemu, although I mostly use VirtualBox. It is quite possible to use UEFI boot with qemu. I presume the emulated arm64 machine is good enough for compilations, for actually testing CinGG you probably need more??
as for runtime it works via vnc (!) on 4 (2ghz max) + 4(1.5 ghz max) arm core and 2 gb ram (+zswap around 1.4 gb shared with android 10) . sometimes it works fast enough (realtime) with even fullhd h264 video, sometimes not - probably due to cpu freqency/sheduling enforced by kernel)
for userspace emulation (faster) you can try this wiki page instructions https://wiki.debian.org/RaspberryPi/qemu-user-static and for faster install on qemu-system you can look into this (dvd media instead of netboot) https://blog.lazym.io/2021/04/16/Run-ARM-MIPS-Debian-on-QEMU/ have good night/rest!
more memory, (-m 2047) more -smp :)
there is link for opensuse install, you can use pre-installed os image
https://en.opensuse.org/openSUSE:AArch64#Using_an_emulator
or debian arm64 image (also pre-installed, so no need for multihour long install)
https://wiki.debian.org/Arm64Qemu https://cdimage.debian.org/cdimage/openstack/current-10/
you can prepare specific source image with pre-downloaded/unpacked/patched source and add this as second hdd...
A problem might be missing build utilities, I know a programmer who (for fun) wanted to build a CinGG for macOS had problems there.
MatN
On Wed, 10 Nov 2021 13:07:13 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
because my patch series tend to fail on x86 while working on arm, I hope those links will help in creating virtual arm debian install for testing
official qemu wiki
https://wiki.qemu.org/Documentation/Platforms/ARM
link from this wiki to older (2017) guide, you probably want to change debian distro name in d/l links
https://translatedcode.wordpress.com/2017/07/24/installing-d ebian-on-qemus-64-bit-arm-virt-board/
also, for faster performance try https://wiki.qemu.org/Features/tcg-multithread (do not forgot -smp 4 (or 8) argument)
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. 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? Shouldn't one be able to have an "headless" Debian with a GUI terminal on the remote end (in this case the host)? MatN
On Friday, November 12, 2021, <[email protected]> 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
I got Debian on arm64 working in non-graphical mode. As before, I used Fedora_35 and qemu 6.0.1. My earlier attempts follow web instructions failed, so I decided to do it the easy way and use virt-manager. This is an GUI interface to libvirt; virsh is the cmd line version. libvirt is a generic interface to various emulation platforms, like qemu in system mode, qemu in user mode, XEN, and libvirt-LXC. What these emulator emulate is irrelevant to libvirt, so to answer your earlier question, libvirt can handle anything qemu can handle, and that includes arm64 (called aarch64). Although virt-manage gave me only two architecture choices, but that might be because I only installed those two qemu targets. Anyway, I assumed that both qemu and libvirt with each new release have more built-in knowledge of the various emulators, like how you set up a cdrom device for iso installs. So I used virt-manager to set up a new Debian 11 aarch64 VM. I downloaded the Debian 11 netinstall (< 320 MB); the one I tried previously was 4.4 GB. In virt-manager, I started a new machine, qemu/kvm user session, use local install media (the downloaded iso), set architecture option to aarch64, gave it extra memory and cpus, have it generate virtual disks of 30G (that is the max it will use), and then take it from there; I used user-mode networking. Install was dead easy, it just worked. It took three hours, surprising little network traffic, but that went up to 10 MB/s in places. I selected the XCFE desktop, even though I did know that graphical likely would not work. Do remember the root password you make. The slow install is because of the apparent use of single thread, not because of network of disk access ( gave the VM 4 cpus and 4 G memory). The virtual disk in user mode will end up in .local/share/libvirt/images. If you do "ls" there, you'll the the 30G disk, but "du" will show the the actual size; in some places, like configuring the kernel, the progress on the screen did not change, but "du" showed the actual disk growing. Be patient. You have to answer some questions now and then, but largely you can do other things. At this point, you have a 80x22 screen. In the end, it rebooted by itself, and I got a working system, inclusive network. It was fully up to date too (e.g. during the install a newer kernel was installed), and the disk was < 5.4 GB. Do add the user you created to the sudoers file, to avoid having to be root many times. You can start/stop the VM nicely via virt-manager (the "stop" knob at the top sends a nice shutdown signal by the looks of it, not just kill it), and it also has a built-in viewer for the client. You "open" a VM, via "view", select "console" (client screen, can be GUI or character based), or "details", where you can visually change VM machine details, much like in VirtualBox; but you must enable editing the xml via virt-manager edit->preferences. If a VM is running, you must click in its console to have it grab the keyboard (like any other window), the mouse works seamlessly. Anyway, because the VM was not configured with a graphical card, I used the "details" view to Add a video card, I tried various types, but settled for now on "virtio", that seems to have a driver for it (under aarch64). If you then start the VM, you still get a character screen, but you can drag it to whatever size you want, which is handy when editing or building software. If you install inxi (apt install inxi), then "inxi -F" will show the VM machine details as Debian detected them. I also added a AC97 sound card to it in the same way, no idea if it will work, but inxi shows it is there. Anyway, with this setup there is a working environment to test cinGG arm64 builds. A character-based editor would be handy, maybe "ne". Hope this helps you with the arm testing. MatN
On Monday, November 15, 2021, <[email protected]> wrote:
I got Debian on arm64 working in non-graphical mode. As before, I used Fedora_35 and qemu 6.0.1.
My earlier attempts follow web instructions failed, so I decided to do it the easy way and use virt-manager.
This is an GUI interface to libvirt; virsh is the cmd line version. libvirt is a generic interface to various emulation platforms, like qemu in system mode, qemu in user mode, XEN, and libvirt-LXC. What these emulator emulate is irrelevant to libvirt, so to answer your earlier question, libvirt can handle anything qemu can handle, and that includes arm64 (called aarch64). Although virt-manage gave me only two architecture choices, but that might be because I only installed those two qemu targets.
Anyway, I assumed that both qemu and libvirt with each new release have more built-in knowledge of the various emulators, like how you set up a cdrom device for iso installs. So I used virt-manager to set up a new Debian 11 aarch64 VM.
I downloaded the Debian 11 netinstall (< 320 MB); the one I tried previously was 4.4 GB. In virt-manager, I started a new machine, qemu/kvm user session, use local install media (the downloaded iso), set architecture option to aarch64, gave it extra memory and cpus, have it generate virtual disks of 30G (that is the max it will use), and then take it from there; I used user-mode networking. Install was dead easy, it just worked. It took three hours, surprising little network traffic, but that went up to 10 MB/s in places. I selected the XCFE desktop, even though I did know that graphical likely would not work. Do remember the root password you make.
The slow install is because of the apparent use of single thread, not because of network of disk access ( gave the VM 4 cpus and 4 G memory). The virtual disk in user mode will end up in .local/share/libvirt/images. If you do "ls" there, you'll the the 30G disk, but "du" will show the the actual size; in some places, like configuring the kernel, the progress on the screen did not change, but "du" showed the actual disk growing. Be patient. You have to answer some questions now and then, but largely you can do other things. At this point, you have a 80x22 screen.
In the end, it rebooted by itself, and I got a working system, inclusive network. It was fully up to date too (e.g. during the install a newer kernel was installed), and the disk was < 5.4 GB. Do add the user you created to the sudoers file, to avoid having to be root many times.
You can start/stop the VM nicely via virt-manager (the "stop" knob at the top sends a nice shutdown signal by the looks of it, not just kill it), and it also has a built-in viewer for the client. You "open" a VM, via "view", select "console" (client screen, can be GUI or character based), or "details", where you can visually change VM machine details, much like in VirtualBox; but you must enable editing the xml via virt-manager edit->preferences. If a VM is running, you must click in its console to have it grab the keyboard (like any other window), the mouse works seamlessly. Anyway, because the VM was not configured with a graphical card, I used the "details" view to Add a video card, I tried various types, but settled for now on "virtio", that seems to have a driver for it (under aarch64). If you then start the VM, you still get a character screen, but you can drag it to whatever size you want, which is handy when editing or building software.
If you install inxi (apt install inxi), then "inxi -F" will show the VM machine details as Debian detected them.
I also added a AC97 sound card to it in the same way, no idea if it will work, but inxi shows it is there.
Anyway, with this setup there is a working environment to test cinGG arm64 builds. A character-based editor would be handy, maybe "ne".
Hope this helps you with the arm testing.
thanks a lot for detailed writeup! (currently am a bit short on storage for trying proot-distro - with normal glibc and such, as opposed to termux/android bionic libc.)
MatN
On Mon, 15 Nov 2021 17:14:28 +0300 Andrew Randrianasulu <[email protected]> wrote: <snip>
thanks a lot for detailed writeup! (currently am a bit short on storage for trying proot-distro - with normal glibc and such, as opposed to termux/android bionic libc.)
Some more info: - I was wrong about the needed disk space. The virtual disk is not dynamic like on VirtualBox. If you say it is 30G, it will allocate 30G. Until now, with the CinGG build failing quite early, it uses 7.4G of the allocated space. Because a simple ./bld.sh on Fedora produces 3Gs, you might be OK with 12G or even less. You can find the used space with "du -BM <virtual-disk-filename>" . - It works here fine now with GUI, I use the XFCE desktop. You have to configure both host and client, as follows, using virt-manager VM Details view, then via the "Add hardware" at bottom right: - add usb keyboard - add usb mouse - add Graphics (this is the host side of the clients graphical output), type Display: Spice, Listen type: Address, address: Hypervisor default. Do not select OpenGL. - Add video (client side graphical interface). There are 5 types, all work, but Ramfb has a fixed format of 800x600. Have not done any measurements, QXL seems slightly quicker to react to kbd input (typing). I use virtio. if you select virtio, deselect 3D acceleration (GL). Would be nice if it works, but it did not here; maybe it works if the system has a later GL version. - Once the GUI is running, you can change its resolution (in XFCE via the "display" settings), but unlike VirtualBox, it is not picked up automatically: in virt-manager, do "View->Resize to VM" - For sound, add the ICH6 or ICH9 sound card, AC97 does not work. "pavucontrol" reports line out and line in, but playing a Youtube video shows output, but the host gets none of it. - Have not attempted file sharing between host and client yet. For serious work this would be better that smb. (and the latter I do not have working yet either). usb passthrough not tested yet, could also be useful for file sharing. - Cut-and-paste between host and client not working so far. The emulation (7 of the 8 host threads) is a _lot_ slower than running "native" but workable for compiling. Firefox is pretty unusable. Anyway, should be enough to find arm64 build problems. Have fun, MatN
On Thursday, November 18, 2021, mnieuw--- via Cin < [email protected]> wrote:
On Mon, 15 Nov 2021 17:14:28 +0300 Andrew Randrianasulu <[email protected]> wrote:
<snip>
thanks a lot for detailed writeup! (currently am a bit short on storage for trying proot-distro - with normal glibc and such, as opposed to termux/android bionic libc.)
Some more info: - I was wrong about the needed disk space. The virtual disk is not dynamic like on VirtualBox. If you say it is 30G, it will allocate 30G.
there must be type of disk, qcow(2), raw, etc.. qcow2 supposed to be growable.
Until now, with the CinGG build failing quite early, it uses 7.4G of the allocated space. Because a simple ./bld.sh on Fedora produces 3Gs, you might be OK with 12G or even less. You can find the used space with "du -BM <virtual-disk-filename>" .
- It works here fine now with GUI, I use the XFCE desktop. You have to configure both host and client, as follows, using virt-manager VM Details view, then via the "Add hardware" at bottom right: - add usb keyboard - add usb mouse - add Graphics (this is the host side of the clients graphical output), type Display: Spice, Listen type: Address, address: Hypervisor default. Do not select OpenGL. - Add video (client side graphical interface). There are 5 types, all work, but Ramfb has a fixed format of 800x600. Have not done any measurements, QXL seems slightly quicker to react to kbd input (typing). I use virtio. if you select virtio, deselect 3D acceleration (GL). Would be nice if it works, but it did not here; maybe it works if the system has a later GL version.
it was working for me on opengl 3.3 hardware (nvidia g92 / nouveau) for x86-64 guest..
- Once the GUI is running, you can change its resolution (in XFCE via the "display" settings), but unlike VirtualBox, it is not picked up automatically: in virt-manager, do "View->Resize to VM" - For sound, add the ICH6 or ICH9 sound card, AC97 does not work. "pavucontrol" reports line out and line in, but playing a Youtube video shows output, but the host gets none of it. - Have not attempted file sharing between host and client yet. For serious work this would be better that smb. (and the latter I do not have working yet either).
I think I had nfs set up on (x86) host for some x86 guests..
usb passthrough not tested yet, could also be useful for file sharing. - Cut-and-paste between host and client not working so far.
The emulation (7 of the 8 host threads) is a _lot_ slower than running "native" but workable for compiling. Firefox is pretty unusable. Anyway, should be enough to find arm64 build problems.
thanks again. Hopefully problems will be not overwhelming. are you running into config.guess in some old thirdparty libs not knowing about aarch64?
Have fun, MatN
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Friday, November 12, 2021, <[email protected]> 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.
apparently aarch64-on-x86_64 shiuld be supported combination: https://fedoraproject.org/wiki/QA:Testcase_Virt_AArch64_on_x86 but uefi on arm64 a bit too complicated for me, you might need to create empty 64mb file and feed it to qemu via -pflash..
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? Shouldn't one be able to have an "headless" Debian with a GUI terminal on the remote end (in this case the host)?
https://unix.stackexchange.com/questions/508362/running-an-x11-application-o... hopefully answers here will help you.. (we do not use kvm, but qemu-tcg, but because kvm usually use same qemu as hypervisor.. i hope it all applicable!)
MatN
On Friday, November 12, 2021, <[email protected]> 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.
found this remark in debian bugtracker: --- USED QEMU COMMANDS (All options should be on single line; SCSI seems necessary for Debian installer to detect CD-ROM properly on ARM64): qemu-system-aarch64 -nographic -machine type=virt -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -netdev user,id=vnet,ipv4=on,ipv6=off,hostfwd=tcp::60010-:60000 -device e1000,romfile=,mac=52:54:00:12:34:56,netdev=vnet -cpu max -smp cores=1 -m 1024 -device virtio-scsi-pci -blockdev driver=raw,node-name=hd,file.driver=file,file.filename=HD.img -device scsi-hd,drive=hd -blockdev driver=file,node-name=cd,filename=DEBIAN-NETINST.iso -device scsi-cd,drive=cd --- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990190 but apparently by itself this line does not give you graphical/kbd/mouse enabled VM...
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.
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? Shouldn't one be able to have an "headless" Debian with a GUI terminal on the remote end (in this case the host)?
MatN
participants (2)
-
Andrew Randrianasulu -
mnieuw＠zap.a2000.nl