I'm trying to install an aarch64 guest VM on F32 x86-64 host.
I created a suitably large disk image, then proceeded to:
arm-image-installer \ --image=/home/mrsam/Downloads/Fedora-Workstation-32-1.6.aarch64.raw.xz \ --target=rpi3 \ --media=/var/lib/libvirt/images/Fedora-Workstation-32-1.6.aarch64.raw \ --selinux=ON --norootpass
This churned for a while, and finished with this:
= Proceed? yes = Writing: = /home/mrsam/Downloads/Fedora-Workstation-32-1.6.aarch64.raw.xz = To: Fedora-Workstation-32-1.6.aarch64.raw …. 11661295616 bytes (12 GB, 11 GiB) copied, 210 s, 55.5 MB/s 0+1339534 records in 0+1339534 records out 11811160064 bytes (12 GB, 11 GiB) copied, 210.762 s, 56.0 MB/s = Writing image complete! Error: mount Fedora-Workstation-32-1.6.aarch64.raw2 /tmp/boot failed
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?
I tried to create a VM with the raw image, as is. It booted for a while, but left me at a login prompt, demanding the root password, and I could not proceed any further.
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.
https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86
You should be able to basically un xz it and follow the instructions linked above.
----- 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.
The AArch64 page is here: https://fedoraproject.org/wiki/QA:Testcase_Virt_AArch64_on_x86
Paul
You should be able to basically un xz it and follow the instructions linked above. _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
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.
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.
On Tue, Jul 28, 2020 at 12:01 AM Sam Varshavchik mrsam@courier-mta.com 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
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@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Peter Robinson writes:
On Tue, Jul 28, 2020 at 12:01 AM Sam Varshavchik mrsam@courier-mta.com 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
I didn't, I chose the "virt" VM to create, but, as I said, I wound up with VM with no video hardware, no Spice server, and no X, and the following in /var/log/Xorg.0.log:
352.678] (EE) Fatal server error: [ 352.683] (EE) no screens found(EE) [ 352.688] (EE) Please consult the Fedora Project support at http://wiki.x.org for help. [ 352.692] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 352.695] (EE) [ 352.743] (EE) Server terminated with error (1). Closing log file.
I'm trying various combinations to see if this can be fixed. If anyone is successfully running X on arm, in a qemu VM, can you share your configuration?
-
Paul Whalen -
Peter Robinson -
Sam Varshavchik