Proposed as a Blocker for 26-alpha by Fedora user michelmno using the blocker tracking app because:

 Unable to do a simple install ppc64/ppc64le Rawhide since compose 20170131 (worked on 20170125)

It's beeing worked on. I think current systemd git works OK, but some seccomp filters are disabled on PPC and other non-amd64 arches. Systemd 233 is to be released soon (ETA ~ a week or so), and should fix this.

Discussed during the 2017-02-13 blocker review meeting: [1]

The decision was made to classify this bug as a RejectedBlocker and an AcceptedFreezeException as the current information we have on this bug leads us to believe that this only affects non-release-blocking arches (ppc). However this bug is accepted as a FreezeException as it is a major bug for non-blocking releases.

Also, as fixing/changing anything related to systemd is considered hazardous, QE would like to request a backport of the fix, and not a new systemd release build.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-02-13/f26-blocker-review.2017-02-13-18.01.txt

Note that a similar bug was raised on Debian 853755
supposed to be solved by systemd 232.16 as per url
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853755#89

Assuming this is the same problem,
are we able to have such level in fedora ?

Is there a workaround to get the machine to boot again?

To answer my own question, going back to a Fedora kernel
from the GRUB menu seems to have worked
(faulty kernel: 4.11.0-0.rc0.git2.1.fc26.ppc64
working kernel: 4.8.8-300.fc25.ppc64)

(In reply to Richard W.M. Jones from comment #6)
> To answer my own question, going back to a Fedora kernel
                                                   ^ 25

No in fact that didn't work - it just seems to have failed
slightly later on, but with the same fundamental problem of
"Failed at step ADDRESS_FAMILIES ..."

boot with init=/bin/sh and then
sed -i.bak -e 's/RestrictAddressFamilies/#RestrictAddressFamilies/g' /usr/lib/systemd/system/*.service

AFAIK the bad system unit files are present in the new initrds, so booting old initrd (pre-systemd-232) "into" updated local units should work. I used this (no warranty) for recovering a rawhide s390 guest after hitting https://github.com/systemd/systemd/issues/4575 which should be the same root cause (buggy seccomp support).

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

(In reply to Dan Horák from comment #9)
> boot with init=/bin/sh and then
> sed -i.bak -e 's/RestrictAddressFamilies/#RestrictAddressFamilies/g'
> /usr/lib/systemd/system/*.service
> 
> AFAIK the bad system unit files are present in the new initrds, so booting
> old initrd (pre-systemd-232) "into" updated local units should work. I used
> this (no warranty) for recovering a rawhide s390 guest after hitting
> https://github.com/systemd/systemd/issues/4575 which should be the same root
> cause (buggy seccomp support).

Because there is no visible progress in solving of this bug in system for wa while and because we are not able to boot any iso for PowerPC rawhide (still failure with compose 20170228)

Is it easier to have the bypass suggested by Dan to be integrated for Rawhide and F26 build for PowerPC ?

systemd 233 that should fix the issue was released yesterday, no build in Fedora yet, but I expect one in the next hours.

Should be fixed now. Let's see.

correction has been validated on Rawhide f27 compose 20170310
BUT not yet on f26 compose 20170313 still blocked by bug #1426796.