ppc and ppc64 - Making the Temporary System Bootable is a placeholder.

[ken]

We've built yaboot (but not hfsutils or powerpc-utils which are needed to install the loader onto a bootstrap partition and bless it), but we don't have any indications how to set it up. As far as I can see, there are at least 4 plausible build scenarios -

(a.) build on a different machine - you'll need to have access to the target machine so that you can copy everything over. possibly, using a rescue disk. I suppose you could use that to format the disk, install the tarball of the bootable system, and then chroot into it to run ybin.

(b.) build on the same machine running osx. Note that you cannot do this from the current (Tiger)version of osx, that broke ext2fsx and at the moment they only have it working read-only so you cannot write to ext2 disks. For a detailed example of how this used to work, consult the 'lfs-from-osx' hint, this approach is only for the very brave.

(c.) build from a Live CD - I suppose it might be convenient to install a bootloader so that you no longer have to boot from CD after this point ? (most of these machines are not superfast, expecting people to sit through a complete build in one go is not realistic)

(d.) building multilib on a G5 from 32-bit userspace (distros have a habit of supplying 32-bit uerspace and a 64-bit kernel for 64-bit machines) - if the kernel has acquired a 32-bit personality (uname reports 'ppc' and libc is 32-bit), you can't chroot. For this, you have the host's bootloader.

I guess this means we have to assume that people have booted from a LiveCD when setting up yaboot. Either we have to build (and install) hfsutils and powerpc-utils, or we have to explain in sufficient detail how to boot from the OF (don't ask me!).

Any alternative views on a sensible way to do this ?

[Jim Gifford]

I've ran into this situation with other architectures. I opted for the non documented netboot option. What about Gentoo's PPC64 option?

[ken]

OK, I'm looking at this, I've even installed the latest ubuntu to play with (seriously, on ppc64 with a recent G5 that is not as simple as you might expect).

[ken]

OK, I'll get the edit started shortly. For ppc64 I'll be going with Jim's patch to mktemp (need mktemp if you plan to rerun ybin, or to use it in a chroot from 32-bit - covering all the options.

I'll also add an appendix for ppc/ppc64 setting out the boot process (particularly, valid filesystem types).

[ken]

I think ppc is done now (r1756) - ppc64 still to do.

[ken]

In theory, ppc64 is done with r1782 last night. Previous experience suggests I've probably missed something, so I'll keep it open for a few days until hopefully I've completed a build with the current versions.

[Jim Gifford]

Ken is PPC64 ready for 1.0.0 release or do you recommend a hold to 1.1.0?

[ken]

Sorry, I've been without email or web for some days and this never arrived in my inbox until today.

I haven't been able to test the current book (I didn't have e.g. binutils-2.17), so I can't yet say for certain. The versions from a few weeks ago seem to work as well as can be expected (lots of test failures in 32-bit glibc, which I think is common to other multilib builds but otherwise ok, and no problems in blfs that I can blame on the CLFS tools.

The other calls on my time are now less than they were, and rather more predictable, so I'm hoping to start x86 probably tomorrow (to check my scripts have survived the transition to e.g. $CLFS and mount -bind for chroot), then ppc64 will be the next arch I try.

[ken]

Oh my word! final-system/gcc.xml is a non-multilib version. That on its own is enough to invalidate the build. How did I miss noticing that before ?

[ken]

Another problem - the new version of e2fsprogs (1.39) has changed ext2_types.h.in and blkid_types.h.in. They are now rather longer, and don't play nice with asm/types.h -

In file included from ../../lib/ext2fs/ext2_fs.h:19,
                 from ../../e2fsck/e2fsck.h:31,
                 from ../../e2fsck/unix.c:50:
../lib/ext2fs/ext2_types.h:98: error: conflicting types for '__u64'
/tools/include/asm/types.h:41: error: previous declaration of '__u64' was here
../lib/ext2fs/ext2_types.h:114: error: conflicting types for '__s64'
/tools/include/asm/types.h:40: error: previous declaration of '__s64' was here
make[2]: *** [unix.o] Error 1

This seems to be hitting this part of asm/types.h

#ifdef __powerpc64__
typedef __signed__ long __s64;
typedef unsigned long __u64;
#else
#if defined(__GNUC__) 
typedef __signed__ long long __s64;
typedef unsigned long long __u64;

because we are cross-compiling, I guess powerpc64 is not defined ?

I've tried reverting these two files to how they were in 1.38 - compiles, but I need to think about how to test this before putting it in the book (blkid is used by fsck, so I need to fsck a spare filesystem, use it, mount it, etc) For the moment, this is a showstopper, which is a pity because in a chroot build it is looking pretty good now.

[Jim Gifford]

Ken, I'm looking into see if there is anything I can do with the headers to fix this. I'll get back to you.

[Jim Gifford]

Try making this change to asm/types.h

#if WORDSIZE == 64 typedef signed long s64; typedef unsigned long u64; #else #if defined(GNUC) typedef signed long long s64; typedef unsigned long long u64;

[ken]

OK Jim, I'll try that (starting over, of course). There is an earlier #ifdef powerpc64 in the same file, I'll make a similar change for that, so that (if it works) we can just sed all (both) of these. Preparing a local patch for the generated headers.

[ken]

Weird, this isn't helping.

According to the output from configure, @SIZEOF_INT@ is 4 @SIZEOF_LONG@ is 8 which matches what I get on native ppc64 (and also on amd64, where I'm compiling) but forcing asm/types.h to use unsigned long u64 also produces the failure to compile, as if u64 is already defined to something different.

Oh spit! The headers for this pure64 box have 'typedef unsigned long long u64' in asm/types.h

It was built with 2.6.16.11-04282006. My x86 is the same.

I can compile e2fsprogs-1.39 if I comment out the code asm/types.h which generates unsigned long u64 (that is, powerpc64, now WORDSIZE == 64) and just use the unsigned long long u64.

That suggests that my original analysis was wrong, and that e2fsprogs-1.38 was compiling happily with the host's u64, but 1.39 fails to compile because the host and target have different ideas about u64 and it is now using the target's u64.

In other words, I now think 1.39 has been changed to use the target's version of u64 when cross-compiling, and this breaks the build if the host and target have different ideas about u64. I feel very confused.

[ken]

I've created e2fsprogs ticket 1529730 at sf. I'll test the patched version of e2fsprogs to see if it works adequately.

[ken]

I suspect this e2fsprogs problem can happen whenever the build machine uses long long for u64 and the target uses just long, and perhaps also with a long host building for a long long target, but it needs way too much infrastructure built for me to test that at the moment. Arches using just 'long' that we care about seem to be alpha, mips64, powerpc64, sparc64 - hmm, so many without bug reports, maybe there is something different about ppc64.

[ken]

Initial tests on a spare fs were successful, test system booted, built the final system. No problems after I fsck'd it from the standard native e2fsprogs. Patch added, book updated in r2285, ppc64 ok except for some remaining minor test issues which aren't specific to it.

Closing this ticket.