FreeBSD arm64 not identified

[ohmantics]

Describe the bug FreeBSD arm64 (aarch64) isn't identified

To Reproduce Check systeminformation.osdata and see "unknown" responses.

Environment (please complete the following information):

• systeminformation package version: 5.11.14
• OS: FreeBSD arm64 running inside UTM
• Hardware: Mac mini M1

Additional context This code is asking for the machdep.bootmethod sysctl, which only exists on i386 and amd64 platforms in FreeBSD. The whole sysctl call returns an error and we fall out of this code with no answers.

[emaste]

That code ought to use sysctl -i:

     -i      Ignore unknown OIDs.  The purpose is to make use of sysctl for
             collecting data from a variety of machines (not all of which are
             necessarily running exactly the same software) easier.

(I have no idea if this is available on NetBSD or OpenBSD, although perhaps they don't work at all right now if they don't have a machdep.bootmethod.)

[emaste]

Just checked OpenBSD's and NetBSD's sysctl(8) man pages, and neither support -i. :(

[emaste]

OpenBSD doesn't have a machdep.bootmethod so will fail here on all platforms. NetBSD adopted machdep.bootmethod but only on x86, like us.

[sebhildebrandt]

Hi @emaste Thank you for reporting. As I am also running an M1 machine as my main device and have UTM installed, it should be easy to reproduce. But I was unable to install a FreeBSD version here ... can you give me a hint (which image you used and maybe some special steps that needed to be done?). Perhaps same for OpenBSD and NetBSD if there are SRM versions that run in UTM ... Thank you for your support, I will then provide a fix for that.

[emaste]

@ohmantics should be able to provide details on what image he used etc. I don't yet have an M1, my FreeBSD installs are x86 laptops and arm64 cloud images.

[jrtc27]

13.1-RELEASE's boot1.iso installs fine for me with UTM 3.2.4 (58) using Other as the OS and otherwise choosing sensible defaults (68.72 GB being 64 GiB because UTM is inconsistent about units...):

Something seems to be wrong with the installer if you select base-dbg, it immediately fails to download any distribution files once the network is configured, so don't do that. I don't know if that's an arm64 issue, a 13.1-RELEASE issue or has been broken for a while, though I have seen suspiciously-quick failures like that installing 14-CURRENT-based CheriBSD images so suspect it's either an arm64 issue or an everywhere issue.

[sebhildebrandt]

@jrtc27 THANK you! Will try it tomorrow!

[sebhildebrandt]

@jrtc27 @ohmantics ... got a VM with FreeBSD running on my M1 machine (using M1) but I am not able to connect to a network (internet) ... maybe if anyone of you got a hint for me I can pull the whole System Information package and node to see what is going on ...

[ohmantics]

I just used UTM. The network settings for the VM are set for Shared Network and virtio-net-pci. The VM seems to have no trouble with network access.

[sebhildebrandt]

@ohmantics I finally was able to get FreeBSD running correctly on M1. I now tested it and made some corrections. si.osInfo() now returns better data:

{
  platform: 'freebsd',
  distro: 'FreeBSD',
  release: '13.1',
  codename: '',
  kernel: '13.1-STABLE',
  arch: 'arm64',
  hostname: '',
  fqdn: '',
  codepage: 'UTF-8',
  logofile: 'FreeBSD',
  serial: '',
  build: '',
  servicepack: '',
  uefi: false
}

Version 5.14.2 just released. Can you also check it on your side?

[emaste]

uefi: false

I suspect this is incorrect; how is it detected?

[sebhildebrandt]

@emaste ... it is determined by sysctl machdep.bootmethod. If this contains uefi then it is true.

I will adapt the code in a way that if there is nothing returned, then uefi = null (which is the default for unknown values in this lib). Would this make sense? Or do you have any other idea how to determine uefi on BSD versions?

[sebhildebrandt]

@emaste ... just an idea:

Could this:

# sysctl kern.geom.confxml
kern.geom.confxml: <mesh>
  ...
  <class id="0xffff000000b075e8">
    <name>PART</name>
    ...
	<provider id="0xffffa00002543e00">
	  <geom ref="0xffffa000025b0000"/>
	  <mode>r1w1e2</mode>
	  <name>vtbd0p1</name>
	  <mediasize>272629760</mediasize>
	  <sectorsize>512</sectorsize>
	  <stripesize>0</stripesize>
	  <stripeoffset>20480</stripeoffset>
	  <config>
	    <start>40</start>
	    <end>532519</end>
	    <index>1</index>
	    <type>efi</type>              // <-------
	    <offset>20480</offset>
	    <length>272629760</length>
	    <label>efiboot0</label>
	    <rawtype>c12a7328-f81f-11d2-ba4b-00a0c93ec93b</rawtype>
	    <rawuuid>c5b1020f-6825-11ed-ba3e-e5ec59365ee6</rawuuid>
	    <efimedia>HD(1,GPT,c5b1020f-6825-11ed-ba3e-e5ec59365ee6,0x28,0x82000)</efimedia>
	  </config>
	</provider>
    </geom>
  </class>
  ...
</mesh>

be an hint that boot method is uefi??

[sebhildebrandt]

@emaste ... code is adapted accordingly. Can you check it once again?

[emaste]

@emaste ... just an idea:

Could <type>efi</type> be an hint that boot method is uefi??

This could be a hint but it won't be completely reliable - for example our install media contains both an efi/ partition as well as BIOS boot code so that it can boot either way.

It looks like we populate machdep.bootmethod only on x86. For arm64 we've only ever supported UEFI boot. By inspection I think the approach implemented in the code is good.

[jrtc27]

We support direct boot using the Linux boot ABI on arm64, too, but there's not really a good reason to use it these days now U-Boot can do UEFI unless you're stuck with an old (or poorly configured) vendor U-Boot blob.

[sebhildebrandt]

@emaste @jrtc27 thank you for having.a look on it! Would it be possible if you can test it on your side and provide feedback if the output is now fine? I really appreciate all your help here! Best regards.