general/other Issue(s) booting FreeBSD 12.2 aarch64 on Parallels Desktop on Apple Silicon

I've succeeded in importing the 'FreeBSD-12.2-RELEASE-arm64-aarch64.vhd' into the Parallels Desktop 16 for Mac M1 Preview Edition by converting the given .vhd into .hdd and substitute the .hdd file in the .pvm. However, after booting, issues occur that I can't do anything else.

As you have seen, it seems that things related to filesystem failed in the booting procedure. And though RETURN directly enables access to /bin/sh, operations like adduser, bsdinstall, etc. can't be finished for the filesystem is read-only, and I can't do anything else.
I'm a UNIX newbie and have no knowledge on how to solve this kind of problem on myself. Few resource can be found on running an aarch64 FreeBSD VM on Parallels Desktop, and I wonder if special preparations beyond me should be made in advance.
The version of Parallels Desktop installed is 16.3.1(50393) Technical Preview on a MacBook Air M1 8GB.
You need to select just one CPU in Parallels and then it boots without issue (on my M1 Mac mini 8G/256G).

Unfortunately in Xorg it does not recognise the mouse which is very unhelpful :(

If you just want consoles though, it is very nice even with just one CPU. A kernel recompile took just under 10 minutes .
Did you try both with and without moused running?
FYI, I just committed some updates to sysutils/desktop-installer to auto-configure X11 under x86 Parallels and VMWare. I'd be interested in knowing if it works on M1 Macs as well.
Bummer. Hopefully someone else with an M1 will spot this thread and have a look.
Mouse issues can also be video-driver related and solved by switching to software cursor. Both moused and software-sursor are default-on options in desktop-installer for this reason.
I had a similar situation with having difficulty getting the mouse to work in both VMWare & Parallels on an M1 mac. I installed from the iso file, parallels seemed to require FreeBSD 14-CURRENT or else it would crash during boot. VMWare fared better and I was able to use FreeBSD-13-RELEASE. Both worked with multiple (2) CPUs, but I was stuck w/o a working mouse on both.

I was worried I needed the xf86-input-vmmouse package to get a working mouse (there's no aarch64 build though), and I followed many suggestions involving enabling things in rc.conf, disabling autoadddevices for Xorg and then manually setting up the mouse device there.

Ultimately the only change I needed was:

# /boot/loader.conf

This fixed the issue for both VMWare & Parallels. Mouse is working in the terminal w/ moused & in Xorg.

I hadn't seen any info about desktop-installer until this thread, sounds like I should have given that a try!

Hopefully this info helps someone else.

I found the referencing to using ums_load in relation to FreeBSD on an ARM64 VM here:
Welcome to FreeBSD Forums.

… things related to filesystem failed in the booting procedure. …

The failure to grow the UFS file system is remarkable. Given the virtual machine context (I haven't touched Parallels for around fifteen years) I might guess that this relates to use of resizing, in combination with snapshots, at the VM level. I base this guess on experience with VirtualBox.

From the closing lines in your photograph, I wonder whether the file system will be irreparable. Beyond the pictured failure of fsck_ufs, you might also find it impossible to use what's called the rescue system; and so on.

A comparable photograph, which I took a few months ago:

View attachment 10114


… RETURN directly enables access to /bin/sh, … the filesystem is read-only, …

The RETURN takes you to single user mode, in which things are read-only by design. To mount the root of the file system with write access:

mount -uw /

Then you can attempt:

fsck -fn

forcing checks and not attempting to write changes. I suspect that the checker will crash, as before.

… I'm a UNIX newbie …

If you can:
  1. start afresh with anything other than the FreeBSD-provided images for virtual machines
  2. install FreeBSD 13.0-RELEASE to an empty virtual disk
  3. make the logical (virtual) size reasonably future-proof, I typically choose 128 GB
  4. for the file system, choose ZFS, not UFS.