Installing an OS on the Talos II

2018-09-15 12:12

Installing an OS on the Talos II

The goal is to get a Gentoo system going.

Starting from a ppc64le fedora install ISO, grab the kernel and initrd and place them in a tftp-accessible directory.

Get the contents of the ISO accessible via http, and boot the Talos II connected to the serial console from the BMC.

Add to petitboot a custom entry: - kernel tftp://10.9.8.8/vmlinuz - initrd tftp://10.9.8.8/initrd.img - Boot arguments: repo=http://tthanna.enimihil.net/fedora inst.vnc

Where tftp parts are from ppc/ppc64/ from the install ISO. And the Fedora ppc64le ISO is loop mounted at /fedora on the HTTP server.

Boot the Fedora installer, watching the serial console.

Connect to provided vnc IP address.

Select minimal install.

Add a prepboot partition to make the installer happy.

Add a single 15G partition for / (as ext4)

Change hostname in network config to "talos-fedora", leave automatic networking set up.

Begin installation.

Set root password and create (administrative) user.

Wait for install to complete.

Reboot installer, watch serial console.

Fedora installation now shows in petitboot, select it.

Now you can log in over SSH, rather than the serial console, and we can try to figure out how to get Gentoo on this thing.

Fedora doesn't seem to know about the VGA or the PCI video card, so no direct monitor keyboard yet:

Linux talos-fedora 4.18.7-200.fc28.ppc64le #1 SMP Mon Sep 10 15:21:50 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux

Create a new 20G ext4 partition for a Gentoo prefix, to use to bootstrap the new system, mount it on /prefix.

  • Install gcc
  • Install gcc-c++
  • Install tar
  • Install make
  • Install bzip2
  • Install python (python2)
  • Install pax-utils (for scanelf)

(Install htop for a pretty view of the system while you wait)

Follow https://wiki.gentoo.org/wiki/Project:Prefix/Bootstrap to make a prefix.

Takes a bit, then fails because it can't select a profile (unknown arch).

$ cd /prefix/etc/portage
$ ln -s ../../usr/portage/profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/ make.profile

And try again.

Now it stops up at installing baselayout-prefix because it's not keyworded:

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
 # required by sys-apps/baselayout-prefix (argument)
 =sys-apps/baselayout-prefix-2.2-r5 **

So let's add that, but this is early in bootstrapping so it needs to live in /prefix/tmp/etc/portage/package.accept_keywords.

Next failure is:

* QA Notice: the following files are outside of the prefix:
* /usr
* /usr/bin
* /usr/bin/gcc-config
* /usr/lib64
* /usr/lib64/misc
* /usr/lib64/misc/gcc-config
* ERROR: sys-devel/gcc-config-1.8-r1::gentoo failed:
*   Aborting due to QA concerns: there are files installed outside the prefix

Unpleasant. Let's unmask 2.0, which seems to be happier.

GCC fails to bootstrap, appears to be this issue: https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg576933.html

Let's unmask GCC 8.2 and see how it goes.

Now it looks like binutils is having trouble, configure is failing, with the config.log showing this:

/prefix/var/tmp/portage/sys-devel/binutils-2.30-r2/work/binutils-2.30/configure: line 4391: ./a.out: Too many levels of symbolic links

Which seems just a bit nuts, the path to the workdir does not contain any symbolic links.

Running the configure line from config.log, while in the build directory appears to work:

[enimihil@talos-fedora build]$ /prefix/var/tmp/portage/sys-devel/binutils-2.30-r2/work/binutils-2.30/configure --enable-gold --enable-plugins --disable-nls --with-system-zlib --build=powerpc64le-unknown-linux-gnu --enable-secureplt --enable-default-hash-style=gnu --prefix=/prefix/usr --host=powerpc64le-unknown-linux-gnu --target=powerpc64le-unknown-linux-gnu --datadir=/prefix/usr/share/binutils-data/powerpc64le-unknown-linux-gnu/2.30 --datarootdir=/prefix/usr/share/binutils-data/powerpc64le-unknown-linux-gnu/2.30 --infodir=/prefix/usr/share/binutils-data/powerpc64le-unknown-linux-gnu/2.30/info --mandir=/prefix/usr/share/binutils-data/powerpc64le-unknown-linux-gnu/2.30/man --bindir=/prefix/usr/powerpc64le-unknown-linux-gnu/binutils-bin/2.30 --libdir=/prefix/usr/lib64/binutils/powerpc64le-unknown-linux-gnu/2.30 --libexecdir=/prefix/usr/lib64/binutils/powerpc64le-unknown-linux-gnu/2.30 --includedir=/prefix/usr/lib64/binutils/powerpc64le-unknown-linux-gnu/2.30/include --enable-obsolete --enable-shared --enable-threads --enable-relro --enable-install-libiberty --disable-werror --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 2.30 p2 --disable-static --disable-gdb --disable-libdecnumber --disable-readline --disable-sim --without-stage1-ldflags

A make in the build directory also appears to work, but the stage3 bootstrap does not seem to be able to successfully run the configure.

Manually running the stage3 and stage2 bootstrap steps gives me an error telling me it cannot fine emege, but running stage1 appears to try to do something:

$ ./bootstrap-prefix.sh /prefix stage1
...
* patch-2.7.5 successfully bootstrapped
* stage1 successfully finished
[enimihil@talos-fedora ~]$ ./bootstrap-prefix.sh /prefix stage2
* Bootstrapping Gentoo prefixed portage installation using
* host:   powerpc64le-unknown-linux-gnu
* prefix: /prefix
* ready to bootstrap stage2
!!! emerge not found, did you bootstrap stage1?
[enimihil@talos-fedora ~]$

So, back to the automatic version...

Still fails, same configure issue; how about unmasking a newer binutils? This one needs to be unmasked in the prefix itself /prefix/etc/portage/....

Same issue, however.

Okay, so let's just give up on the prefix thing entirely and try cross-building from an existing amd64 Gentoo system.

Get a crossdev build set up as described in https://wiki.gentoo.org/wiki/Cross_build_environment for the powerpc64le-linux-gnu target.

What we want to do is build @system and the stage1 packages as binpkgs (pass -b to emerge) so we can manually populate a stage1-like chroot to bootstrap Gentoo.

I ended up with the following versions of the cross-merged toolchain: - cross-powerpc64le-linux-gnu/binutils-2.31.1 - cross-powerpc64le-linux-gnu/gcc-8.2.0-r2 - cross-powerpc64le-linux-gnu/glibc-2.27-r6 - cross-powerpc64le-linux-gnu/linux-headers-4.17

Having finished the cross merge of @system I now have a 163 tarballs in /usr/powerpc64le-linux-gnu/packages.

So now, on my temporary Fedora install:

[root@talos-fedora prefix]# for pkg in $(ssh enimihil@10.9.8.7 "find /usr/powerpc64le-linux-gnu/packages/ -name *tbz2"); do ssh enimihil@10.9.8.7 "cat $pkg" | tar xjf -; done

And I should have a Gentoo chroot that is cross-built enough to get a system going.

So create/mount /proc, /sys, and bind-mount /dev before chrooting into the newly cross-built Gentoo system:

[root@talos-fedora ~]# chroot /prefix /bin/bash
talos-fedora / #

Now we should be able to follow the handbook to install/bootstrap a complete system:

talos-fedora / # emerge -av @system
setlocale: unsupported locale setting
!!! Section 'gentoo' in repos.conf has location attribute set to nonexistent directory: '/usr/portage'
!!! Invalid Repository Location (not a dir): '/usr/portage'
portage: 'portage' user or group missing.
         For the defaults, line 1 goes into passwd, and 2 into group.
         portage:x:250:250:portage:/var/tmp/portage:/bin/false
         portage::250:portage
*** WARNING ***  For security reasons, only system administrators should be
*** WARNING ***  allowed in the portage group.  Untrusted users or processes
*** WARNING ***  can potentially exploit the portage group for attacks such as
*** WARNING ***  local privilege escalation.

setlocale: unsupported locale setting


!!! /etc/portage/make.profile is not a symlink and will probably prevent most merges.
!!! It should point into a profile within /usr/portage/profiles/
!!! (You can safely ignore this message when syncing. It's harmless.)


!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.
talos-fedora / #

Alright, so some work to do, let's get the portage snapshot and set up the minimum /etc/passwd stuff, and a working /etc/resolv.conf. (Using, ew, nano.), then emerge --sync

Now that we have a portage tree, let's set a profile:

talos-fedora / # eselect profile list
Available profile symlink targets:
[1]   default/linux/powerpc/ppc64/13.0/64bit-userland (exp)
[2]   default/linux/powerpc/ppc64/13.0/64bit-userland/desktop (exp)
[3]   default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome (exp)
[4]   default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome/systemd (exp)
[5]   default/linux/powerpc/ppc64/13.0/64bit-userland/developer (exp)
[6]   default/linux/powerpc/ppc64/13.0/64bit-userland/little-endian (exp)
[7]   default/linux/powerpc/ppc64/13.0/64bit-userland/little-endian/systemd (exp)
[8]   default/linux/powerpc/ppc64/17.0/64bit-userland (stable)
[9]   default/linux/powerpc/ppc64/17.0/64bit-userland/desktop (stable)
[10]  default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome (stable)
[11]  default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome/systemd (stable)
[12]  default/linux/powerpc/ppc64/17.0/64bit-userland/developer (stable)
[13]  default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian (exp)
[14]  default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd (exp)
[15]  hardened/linux/powerpc/ppc64/64bit-userland (dev)
talos-fedora / # eselect profile set --force 13

Apparently it's an experimental one, to be using little-endian.

Since it's complaining about unsupported locale, I unset LANG, then, try to get the system going.

Turns out we need app-portage/elt-patches to build sys-devel/binutils, and that needs a /bin/sh symlink so.

talos-fedora / # ln -s /bin/bash /bin/sh
talos-fedora / # emerge -av --nodeps app-portage/elt-patches
talos-fedora / # emerge -av --nodeps sys-devel/binutils

Or, nevermind, we don't have a gcc yet, making sure I have binpkgs for those.. (on my cross-building machine)

sudo powerpc64le-linux-gnu-emerge -avb sys-devel/binutils sys-devel/gcc sys-libs/glibc

And run the same command as above to splat all the binpkgs into the chroot.

Let's add some options to portage in this chroot as well (in /etc/portage/profile/make.conf):

MAKEOPTS="-j8"
PORTAGE_NICENESS="10"
EMERGE_DEFAULT_OPTS="--quiet-unmerge-warn --jobs --load-average=32

That should let us take a bit more advantage of the power of this machine.

And let's try that binutils merge again...

Nope, not quite. We're missing awk and gcc-config seems very unhappy, so let's do this:

talos-fedora /etc/env.d/gcc # ln -s /usr/bin/gawk /usr/bin/awk
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-gcc /usr/bin/gcc
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-as /usr/bin/as
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-ld /usr/bin/ld
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-g++ /usr/bin/g++
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-ar /usr/bin/ar
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-nm /usr/bin/nm
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-ranlib /usr/bin/ranlib
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-cpp /usr/bin/cpp
talos-fedora /etc/env.d/gcc # ln -s /usr/bin/powerpc64le-linux-gnu-c++ /usr/bin/c++

Now, let's see if a compile will work? nope. Seems like binutils is also wonky.

Things aren't being installed quite like I expected, gcc-config thinks the compiler is a cross compiler, etc.

Maybe we're supposed to be using powerpc64le-unknown-linux-gnu?

Okay... I'll try that:

enimihil@tbd ~$ sudo crossdev -t powerpc64le-unknown-linux-gnu -s4

Splatting the binary files seems to make things somewhat happier, but it does appear to need some manual intervention to get gcc-config and binutils-config to recognize a valid profile.

I added the /etc/env.d/binutils/config-powerpc64le-unknown-linux-gnu and the corresponding /etc/env.d/gcc/... file to point to the correct profiles, and ran env-update and . /etc/profile and the compiler now seems reasonably happy to chunk along with building a non-cross compiled binutils:

emerge -av --nodeps sys-devel/binutils

Adding ~sys-devel/gcc-8.2.0 to /etc/portage/profile/package.accept_keywords allowed me to:

emerge -av --nodeps sys-devel/gcc

( GCC 7.2.0 fails to build )

Working our way towards getting an @system merge:

emerge -av --nodeps autoconf
emerge -av --nodeps sys-libs/pam
emerge -av --nodeps dev-util/pkgconfig

And now:

talos-fedora / # mount -t devpts pts /dev/pts -o gid=5
talos-fedora / # USE="-acl -gdbm -berkdb -nls" emerge -av1 @system

Fails because libffi is picky about being installed on top of itself:

talos-fedora / # rm -rf /usr/lib64/libffi*
talos-fedora / # emerge -av1 libffi
talos-fedora / # USE="-acl -gdbm -berkdb -nls" emerge -avu1 --keep-going @system

Okay, now coreutils won't build:

* ERROR: sys-apps/coreutils-8.29-r1::gentoo failed (prepare phase):
*   patch -p1  failed with /var/tmp/portage/sys-apps/coreutils-8.29-r1/work/patch/003_all_coreutils-gentoo-uname.patch

Maybe?:

emerge --sync

Nope, unmask the latest and try?:

# Add ~sys-apps/coreutils-8.30 to accept_keywords
talos-fedora / # USE="-acl -gdbm -berkdb -nls" emerge -av1 sys-apps/coreutils

Nope, same issue, though apparently since this is a Gentoo patch that is failing:

talos-fedora / # USE="-acl -gdbm -berkdb -nls vanilla" emerge -av1 sys-apps/coreutils

Does the trick, let's keep going:

talos-fedora / # USE="-acl -gdbm -berkdb -nls" emerge -avu1 --keep-going @system

Hm, now patch itself is failing:

/var/tmp/portage/sys-devel/patch-2.7.6-r2/files/patch-2.7.6-fix-test-suite.patch

No vanilla use flag to fall back on here...:

talos-fedora / # cd /var/tmp/portage/sys-devel/patch-2.7.6-r2/work/patch-2.7.6
talos-fedora /var/tmp/portage/sys-devel/patch-2.7.6-r2/work/patch-2.7.6 # patch -p1 /var/tmp/portage/sys-devel/patch-2.7.6-r2/files/patch-2.7.6-fix-test-suite.patch
patch: /lib64/libattr.so.1: version `ATTR_1.3' not found (required by patch)

Ah, okay. We've broken patch. Great. And we need a working patch to build patch. sigh

So on my cross build machine, let's try this:

tbd /net/tbd/home/enimihil # USE="-xattr" powerpc64le-unknown-linux-gnu-emerge -avb patch

talos-fedora / # exit
[root@talos-fedora prefix]# scp enimihil@10.9.8.7:/usr/powerpc64le-unknown-linux-gnu/packages/sys-devel/patch-*tbz2 .
patch-2.7.6-r2.tbz2                                          100%  172KB  32.7MB/s   00:00
[root@talos-fedora prefix]# tar xvpf patch-2.7.6-r2.tbz2
./
./usr/
./usr/bin/
./usr/bin/patch
./usr/share/
./usr/share/man/
./usr/share/man/man1/
./usr/share/man/man1/patch.1.bz2
./usr/share/doc/
./usr/share/doc/patch-2.7.6-r2/
./usr/share/doc/patch-2.7.6-r2/README.bz2
./usr/share/doc/patch-2.7.6-r2/ChangeLog.bz2

bzip2: (stdin): trailing garbage after EOF ignored
./usr/share/doc/patch-2.7.6-r2/AUTHORS.bz2
./usr/share/doc/patch-2.7.6-r2/NEWS.bz2
./usr/share/doc/patch-2.7.6-r2/TODO.bz2
[root@talos-fedora prefix]# chroot . /bin/bash
talos-fedora / # patch
talos-fedora / #

That seems to have done it, now let's build patch:

talos-fedora / # USE="-acl -gdbm -berkdb -nls" emerge -avu1 sys-devel/patch

And see if the rest of @system will build now...:

talos-fedora / # USE="-acl -gdbm -berkdb -nls" emerge -avu1 --keep-going @system

Broke because sysvinit couldn't find a root group, so I added that to /etc/group.

... and now, it seems, the linker is broken because it wants a GLIBC symbol version that doesn't exist:

talos-fedora / # gcc test.c
/usr/lib/gcc/powerpc64le-unknown-linux-gnu/8.2.0/../../../../powerpc64le-unknown-linux-gnu/bin/ld: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /usr/lib/gcc/powerpc64le-unknown-linux-gnu/8.2.0/../../../../powerpc64le-unknown-linux-gnu/bin/ld)
collect2: error: ld returned 1 exit status

Isn't symbol versioning supposed to not break things?:

talos-fedora / # ls -l /lib64/libc-*
-rwxr-xr-x 1 root root 2110680 Sep 19 15:07 /lib64/libc-2.26.so
-rwxr-xr-x 1 root root 2176288 Sep 18 23:08 /lib64/libc-2.27.so
talos-fedora / # ls -l /lib64/libc.so.6
lrwxrwxrwx 1 root root 12 Sep 19 15:07 /lib64/libc.so.6 -> libc-2.26.so
talos-fedora / #

Not for a downgrade, I guess.

So let's fix the symlink and keyword glibc?

Or, not:

talos-fedora / # ln -sf libc-2.27.so /lib64/libc.so.6
talos-fedora / # ls

We probably need to symlink all the glibc libs, then:

[root@talos-fedora prefix]# ls lib64/*-2.27*
lib64/ld-2.27.so               lib64/libdl-2.27.so          lib64/libnss_files-2.27.so
lib64/libanl-2.27.so           lib64/libm-2.27.so           lib64/libnss_hesiod-2.27.so
lib64/libBrokenLocale-2.27.so  lib64/libnsl-2.27.so         lib64/libpthread-2.27.so
lib64/libc-2.27.so             lib64/libnss_compat-2.27.so  lib64/libresolv-2.27.so
lib64/libcidn-2.27.so          lib64/libnss_db-2.27.so      lib64/librt-2.27.so
lib64/libcrypt-2.27.so         lib64/libnss_dns-2.27.so     lib64/libutil-2.27.so
[root@talos-fedora prefix]#

[root@talos-fedora prefix]# ln -sf ld-2.27.so lib64/ld64.so.2
[root@talos-fedora prefix]# ln -sf libanl-2.27.so lib64/libanl.so.1
[root@talos-fedora prefix]# ln -sf libBrokenLocale-2.27.so lib64/libBrokenLocale.so.1
[root@talos-fedora prefix]# ln -sf libcidn-2.27.so lib64/libcidn.so.1
[root@talos-fedora prefix]# ln -sf libcrypt-2.27.so lib64/libcrypt.so.1
[root@talos-fedora prefix]# ln -sf libdl-2.27.so lib64/libdl.so.2
[root@talos-fedora prefix]# ln -sf libm-2.27.so lib64/libm.so.6
[root@talos-fedora prefix]# ln -sf libnsl-2.27.so lib64/libnsl.so.1
[root@talos-fedora prefix]# ln -sf libnss_compat-2.27.so lib64/libnss_compat.so.2
[root@talos-fedora prefix]# ln -sf libnss_db-2.27.so lib64/libnss_db.so.2
[root@talos-fedora prefix]# ln -sf libnss_dns-2.27.so lib64/libnss_dns.so.2
[root@talos-fedora prefix]# ln -sf libnss_files-2.27.so lib64/libnss_files.so.2
[root@talos-fedora prefix]# ln -sf libnss_hesiod-2.27.so lib64/libnss_hesiod.so.2
[root@talos-fedora prefix]# ln -sf libpthread-2.27.so lib64/libpthread.so.0
[root@talos-fedora prefix]# ln -sf libresolv-2.27.so lib64/libresolv.so.2
[root@talos-fedora prefix]# ln -sf librt-2.27.so lib64/librt.so.1
[root@talos-fedora prefix]# ln -sf libutil-2.27.so lib64/libutil.so.1
[root@talos-fedora prefix]# chroot . /bin/bash
talos-fedora / #

Added ~sys-libs/glibc-2.27 to my package.accept_keywords and re-merged that:

talos-fedora / # emerge -av1 sys-libs/glibc

I guess crossdev (unsurprisingly) uses the ~arch versions of packages.

And back to the @system:

talos-fedora / # USE="-acl -gdbm -berkdb -nls" emerge -avu1 --keep-going @system

Alright, seems like we need /dev/shm to build python:

* configure has detected that the sem_open function is broken.
* Please ensure that /dev/shm is mounted as a tmpfs with mode 1777.
* ERROR: dev-lang/python-3.6.5::gentoo failed (configure phase):
*   Broken sem_open function (bug 496328)


talos-fedora / # mount -t tmpfs tmpfs /dev/shm
talos-fedora / # USE="-acl -gdbm -berkdb -nls" emerge -avu1 --keep-going @system

Okay, excellent, now we've gotten the chroot bootstrapped into a sensible-ish state, let's try to update it without the USEflag workarounds:

emerge -avuDN world

Now that we have something of a fraken-installed system, let's see if we can use catalyst to build a proper stage3 and install a clean system, based on https://wiki.gentoo.org/wiki/Catalyst

emerge -av catalyst
# And because I'm sick of nano
emerge -av vim

Since there's no seed stage to start with, let's tar up the chroot filesystem as the stage3...:

[root@talos-fedora prefix]# tar --one-file-system -cjpf /current-stage3-ppc64le-20180919.tar.bz2
[root@talos-fedora prefix]# mv /current-stage3-ppc64le-20180919.tar.bz2 /prefix/var/tmp/catalyst/builds/default/

And having made a catalyst snapshot and editing a stage1.spec

talos-fedora / # catalyst -f stage1.spec
Catalyst, version 2.0.18
Copyright 2003-2008 Gentoo Foundation
Copyright 2008-2012 various authors
Distributed under the GNU General Public License version 2.1

Using default Catalyst configuration file, /etc/catalyst/catalyst.conf
Setting sharedir to config file value "/usr/lib64/catalyst"
Setting snapshot_cache to config file value "/var/tmp/catalyst/snapshot_cache"
Setting hash_function to config file value "crc32"
Setting storedir to config file value "/var/tmp/catalyst"
Setting portdir to config file value "/usr/portage"
Setting distdir to config file value "/usr/portage/distfiles"
Setting options to config file value "autoresume bindist kerncache pkgcache seedcache snapcache"
Autoresuming support enabled.
Binary redistribution enabled
Kernel cache support enabled.
Package cache support enabled.
Seed cache support enabled.
Snapshot cache support enabled.
Envscript support enabled.

!!! catalyst: Argument "compression_mode" not recognized.
        Also: Argument "decompressor_search_order" not recognized.
        Also: Argument "portage_prefix" not recognized.

Traceback (most recent call last):
File "/usr/lib64/catalyst/catalyst", line 216, in build_target
    mytarget=targetmap[addlargs["target"]](conf_values, addlargs)
File "modules/stage1_target.py", line 17, in __init__
    generic_stage_target.__init__(self,spec,addlargs)
File "modules/generic_stage_target.py", line 22, in __init__
    generic_target.__init__(self,myspec,addlargs)
File "modules/generic_target.py", line 10, in __init__
    addl_arg_parse(myspec,addlargs,self.required_values,self.valid_values)
File "/usr/lib64/catalyst/modules/catalyst_support.py", line 689, in addl_arg_parse
    raise CatalystError, '\n\tAlso: '.join(messages)
CatalystError
!!! catalyst: Error encountered during run of target stage1
Catalyst aborting....

So, clearly the wiki page is crazy, or the files are not up to date, or... something.

talos-fedora / # catalyst -f stage1.spec
Catalyst, version 2.0.18
Copyright 2003-2008 Gentoo Foundation
Copyright 2008-2012 various authors
Distributed under the GNU General Public License version 2.1

Using default Catalyst configuration file, /etc/catalyst/catalyst.conf
Setting sharedir to config file value "/usr/lib64/catalyst"
Setting snapshot_cache to config file value "/var/tmp/catalyst/snapshot_cache"
Setting hash_function to config file value "crc32"
Setting storedir to config file value "/var/tmp/catalyst"
Setting portdir to config file value "/usr/portage"
Setting distdir to config file value "/usr/portage/distfiles"
Setting options to config file value "autoresume bindist kerncache pkgcache seedcache snapcache"
Autoresuming support enabled.
Binary redistribution enabled
Kernel cache support enabled.
Package cache support enabled.
Seed cache support enabled.
Snapshot cache support enabled.
Envscript support enabled.

!!! catalyst: Unknown build machine type ppc64le

Traceback (most recent call last):
File "/usr/lib64/catalyst/catalyst", line 216, in build_target
    mytarget=targetmap[addlargs["target"]](conf_values, addlargs)
File "modules/stage1_target.py", line 17, in __init__
    generic_stage_target.__init__(self,spec,addlargs)
File "modules/generic_stage_target.py", line 96, in __init__
    raise CatalystError, "Unknown build machine type "+buildmachine
CatalystError
!!! catalyst: Error encountered during run of target stage1
Catalyst aborting....

Ah, and herein we learn that catalyst has no idea about ppc64le.

I guess we'll muddle along with the franken-install, then, actually make that bootable.

So we'll follow the handbook for a chrooted install, skipping a bootloader, as we've got petitboot already.

Getting a kernel set up and manually configuring petitboot appears to get us booted, ta-da.