8:01 a.m.
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.
8:55 a.m.
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.
9:50 a.m.
----- 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.
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
Paul
You should be able to basically un xz it and follow the instructions
linked above.
_______________________________________________
arm mailing list -- arm(a)lists.fedoraproject.org
To unsubscribe send an email to arm-leave(a)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
6:01 p.m.
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.
>
> 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.
3:39 a.m.
On Tue, Jul 28, 2020 at 12:01 AM Sam Varshavchik <mrsam(a)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
> > >
> > > 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(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)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
6:10 a.m.
Peter Robinson writes:
On Tue, Jul 28, 2020 at 12:01 AM Sam Varshavchik
<mrsam(a)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?
1361
days inactive
1362
days old
5 comments
3 participants
participants (3)
-
Paul Whalen -
Peter Robinson -
Sam Varshavchik