I verified the patch on powerpc64, powerpc64le and it fixes the issue completely. Also, powerpc 32 bit is fine with this patch.

@mckusick , thank you for the improved patch!
During test I figured out that kernel retries to mount the filesystem several times. I prevented this changing sys/kern/vfs_mountroot.c

remove empty line

Update with code from mckusick

In D37675#856834, @mckusick wrote:

Here is my proposed fix:

{F53027994}

Let me know if this works for you.

In D35962#856826, @imp wrote:

In D35962#856824, @alfredo wrote:

Would a "hack" activated by poudriere/ports to change the behavior of uname(1) and uname(3) to report HW_MACHINE_ARCH instead of HW_MACHINE, be acceptable?

I doubt it would work. The hack is easy to write: just set UNAME_m=$(uname -p) when building packages (but not for buildworld, etc). However, even this wouldn't do what you want... It would break at least kernel module building would be broken since MACHINE wouldn't be powerpc in this case. It may also break some utilities that grovel in the kernel as well (though they may not since /usr/include/machine would be built correctly... though anything that needs to know where kernel sources are might not work).

In D35962#856824, @alfredo wrote:

Would a "hack" activated by poudriere/ports to change the behavior of uname(1) and uname(3) to report HW_MACHINE_ARCH instead of HW_MACHINE, be acceptable?

In D35962#856814, @imp wrote:

You are wrong. Very wrong. Wikipedia is a bad source.

In D35962#856667, @imp wrote:

In D35962#856587, @pkubaj wrote:

Well, Poudriere should use uname -p. Using -p doesn't make sense. On powerpc*, it prints just powerpc on all 4 platforms and is totally misleading on 3 of them. On armv{6,7}, it's imprecise (do we deal with arm as in the removed ARMv5, armeb, armv6 or maybe armv7?), although not as incorrect as on powerpc*. On riscv64, it makes other software think it's actually riscv32, which FreeBSD doesn't even support. I have posted previously links here to software and ugly workarounds that I needed to use.

EDIT: I meant "Using -m doesn't make sense." in my 2nd sentence.

Poudriere is doing exactly the right thing. It uses them for different things. uname -m is for kernel APIs, and uname -p is for userland ABIs. We use both in our build process in a nuanced way, and it works.

Given how much this broke, I'm going to go out on a limb and say you'll never be able to change this. You must patch all the software to conform with FreeBSD's quirky way of splitting these. While uname(1) didn't change, a lot of things use uname (3) rather than sysctl for this information, and you'll be playing whack-a-mole fixing the things that are already working. So I'm back to dead set against this because it causes too much POLA.

I have some questions :)
Should we define a custom (negative) error number for endian mismatch?
Should we check for the returned error number and make the caller print the message instead?

@cperciva this change caused a regression on powerpc64 and powerpc64le (mountroot can't mount the filesystem).

In D36900#844037, @arichardson wrote:

This is fine as a workaround, but maybe we should just use command -v instead of which? I've seen build failures where docker images didn't include which

This was superseded by https://reviews.freebsd.org/D36420

Thanks imp, but I'm abandoning since actually looks like the ":" makes sense here as there are more output due to "stack_print()" !

Make this change powerpc* only in order to unbreak pfsync module and
the test infrastructure.

I started a similar discussion some time ago on IRC and the only conclusion I got was there's no standard. I looked at https://en.wikipedia.org/wiki/Uname to try to find some pattern, but found none as well and I agreed to keep as is to avoid breaking things. However I understand that keeping as is today adds an unnecessary (and avoidable) extra burden to the already small number of ports maintainers that do an excellent job keeping powerpc* ports in shape. Since no regular package delivery for powerpc* existed and we are about to have them (with the new hardware that was acquired), it's the the perfect moment to discuss it.

In D36234#822496, @markj wrote:

This is rather strange. The description makes it sound like there is a bug somewhere in powerpc relocation handling, nothing specifically to do with cpuset code.
Until the problem is better understood, I don't think it's appropriate to commit something like this - how do you know that the bug won't require another workaround next week?

This change was reverted in a12eb9e4ae534557867d49803a1e28bfe519a207

In D35691#810745, @jhibbits wrote:

I just updated the review upstream, adding the needed test, so I think it should be good to submit in the next several days. I think that should make this change redundant at that point.

Thanks for the reviews!

Make -lm added to powerpcspe only

I like the idea! However I burned an DVD for a PowerBook G4 and I only see the regular disc icon.
What's your device model? (based on other sources your patch looks correct. Maybe my firmware is too old for this feature)

@rmacklem, 'vfs.root.mountroot' is used as a kernel parameter to specify (or override) where is the root filesystem to be mounted and its partition type. It's usually something like "vfs.root.mountroot=ufs:/dev/da0s1a" if you use a local disk, or "vfs.root.mountroot=nfs:192.168.0.1:/tftpboot/root" if using nfs.

use strncmp instead of strstr in order to match only the beginning of the string

In D34567#785714, @rmacklem wrote:

Have you tested the case where there is no suitable
net interface and no local root fs to see if the failure
is "as clear" to users as the panic is?

Hi @imp, are you ok with current patch?

In D34567#783123, @alfredo wrote:

During tests I found that when a eligible NIC exists and network isn't prepared for bootp, it cannot load the local root file system.
More investigation is required:

style