Installing an OS on the Talos II
- Published
- Author(s)
- Enimihil
- Tags
- #gentoo #linux #ppc64 #ppc64le #talos
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.