On Sun, Jan 15, 2017 at 03:05:11PM +0100, Adam Borowski wrote: >On Sun, Jan 15, 2017 at 01:12:53AM +0000, Steve McIntyre wrote: >> >> I think the problem is with your setup. I've just booted that exact >> netinst image happily using >> >> qemu-system-aarch64 -m 4G -cpu cortex-a57 -M virt -smp 8 -nographic >> -pflash AAVMF_CODE.fd -pflash AAVMF_VARS.fd -drive >> file=/scratch/iso/debian-stretch-DI-rc1-arm64-netinst.iso,id=cdrom,if=none,media=cdrom >> -device virtio-scsi-device -device scsi-cd,drive=cdrom -k en-gb >> -netdev user,id=eth0 -device virtio-net-device,netdev=eth0 > >Ie, virtio vs emulating a real piece of hardware. > >The problem here, though, is that qemu picked a piece of hardware that's old >crap that's not expected in any physical arm64 gardware. I guess it'd be >good to ask them to upgrade, like they did with the Cirrus card on x86.
Might be a good plan, yes. Fancy filing a bug? :-) >Ordinarily I'd want you to support this "hardware" as QEMU is a major >platform (at least the one most available), but in this case, with the >extensive incantations required to get it running, requiring virtio might be >acceptable. I refuse to say "arguments" rather than "incantations" as >the former is for specifying what the program should do and what you want >altered from reasonable defaults, rather than a massive ritual that needs to >be performed just to get basic functionality, with every piece involving >lengthy research and breakage/data loss if you skip it. Like, my line lacks >a flash for storing EFI vars, meaning that it will install correctly (with >mini.iso), work when rebooted, even upon multiple reboots, then fail to work >anymore once you shut down qemu and start it again. > >So I wonder what's the best way to proceed. Probably documenting what's >needed might be a good step. And that would be good too. Where should we put that? In the wiki maybe, I'm thinking the installer manual is not ideal. >> and it's running the installer right now with udebs from the >> netinst iso. What version of qemu-efi are you using for >> /usr/share/qemu-efi/QEMU_EFI.fd? > >0~20161202.7bbe0b3e-1 (current unstable and stretch). OK, same as me. I *had* seen issues with older versions of UEFI for arm64, hence the question. -- Steve McIntyre, Cambridge, UK. st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me