On Tue, Jul 28, 2020 at 12:01 AM Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote: > > Paul Whalen writes: > > > > > > > ----- Original Message ----- > > > > I'm trying to install an aarch64 guest VM on F32 x86-64 host. > > > > > > > > I created a suitably large disk image, then proceeded to: > > > > > > <snip> > > > > > > > I surmize that arm-image-installer expected a real /dev to write to, > > > > instead of what is effectively a plain fie, so it failed to mount the > > disk > > > > image. I suppose that what it needs to do is a loopback mount, instead. > > Is > > > > there a way to do this? > > > > > > The sole reason for arm-image-installer is to set up the device > > > specific firmware if the devices require it to been on the same media > > > as the OS. This is not the case with virt as it has dedicated > > > tianocore firmware which is in a completely separate location to the > > > OS virtual disk image. > > virt-manager politely offered me an option to set up a raspberry pi 2 and 3 > VM, which seems like a perfect match for the corresponding options to arm- > image-installer. You definitely don't want that option, you want one of the virt ones, it's likely easier to do it via cmd line > > > > > > https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86 > > > > The AArch64 page is here: > > https://fedoraproject.org/wiki/QA:Testcase_Virt_AArch64_on_x86 > > Both arm and aarch64 pages didn't quite match what happened to me. > > The download image for Fedora Workstation is a raw image, not an iso image: > > https://alt.fedoraproject.org/alt/ > > Because of that the documentation on the arm page was a closer match to > this, then the aarch64 page. > > Creating a new VM, based on the raw image, eventually concludes with the VM > booting to a login prompt, without going into setup or prompting me to set > up the root password, then the console demands the root login. > > Tried to boot to a rescue shell via a direct kernel boot, the instructions > on the arm page for setting up a direct kernel boot mostly worked. virt-get- > kernel worked. virt-cat didn't, whatever file currently has the kernel boot > args it's no longer /etc/extlinux.conf. Using the suggested default of > "console=ttyAMA0 rw root=LABEL=_/ rootwait" ended up booting the system > about halfway until "Reached target Basic System", and the direct boot hangs > at that point. Same results with "console=ttyAMA0 rw root=LABEL=_/ rd.break > enforcing=0". The boot hangs with virt-manager showing a flatlined CPU > utilization at about the 30% mark. > > Turned off direct kernel boot, and booted the VM normally, and the boot > proceeds past that point, but then again I get the login prompt, without > giving me the opportunity to set the root password. > > After some attempts, I was able to interrupt the grub menu. I never liked > how, X years ago, the default timeout for grub was changed to be, basically, > no timeout. Eventually, hitting cursor down as soon as the grub menu appears > worked. I added 'rd.break enforcing=0' to the kernel command line, as per > Google's instructions. > > This gave me a dracut shell. I remounted /sysroot read-write, ran passwd to > change the root password, then retraced my steps. > > This allowed me to login as root, at the console. Once. After a subsequent > reboot, I could not log in again, my password got rejected. To make a long > story short, eventually I got to the root of it (pun intended): > > [root@arm ~]# ls -alZ /etc/shadow > ----------. 1 root root system_u:object_r:unlabeled_t:s0 1240 Jul 27 15:53 /etc/shadow > [root@arm ~]# restorecon /etc/shadow > [root@arm ~]# ls -alZ /etc/shadow > ----------. 1 root root system_u:object_r:shadow_t:s0 1240 Jul 27 15:53 /etc/shadow > > Looks like the first time I managed to get a rescue shell, in order to be > able to set the root password, I ended up blowing away the context > on /etc/shadow. That was the issue. > > Getting back on track, shouldn't the workstation image boot to X? Why, yes, > "systemctl get-default" comes back with "graphical.target", but it boots to > the console. I created the VM by following the instructions, but it appears > that selecting "Fedora 32" as the OS to install, together with the aarch64 > image (and architecture), resulted in a VM without a a graphical device. > > I added the Spice driver. This resulted in a blank screen showing "Guest > disabled display." Additionally, the keyboard no longer worked, on the grub > menu. > > I tried to replicate the config from my other Windows VM, which has both > spice and the video qxl drivers. The only video driver that the aarch64 vm > accepted was virtio, and the result was the same, "Guest disabled display." > I had to remove them both, in order to be able to use the grub menu. > > So, right now my bottom line is: > > Direct kernel boot hangs, possibly due to wrong command line options, and > the instruction for extracting the ones that the image uses are out of date. > > Installing the raw image does not result in the setup wizard running, and > letting me set the root password. I had to use a rescue shell to set the > root password, and fix SELinux issues. > > The new VM did not have support for X, adding Spice and Video to the VM only > had the result of losing the system console, entirely. This might be related > to the issue of the setup wizard not getting run, since, IIRC, it's an X > app; and it's possible that something that it should do, but never happened, > ends up breaking console logins. > > So, what is needed to get X up and running, in a qemu VM? I'm going to > install all the updates, and see if it makes any difference. > > _______________________________________________ > arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
