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 >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
