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.
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.