Opened 13 years ago

Closed 13 years ago

#35 closed task (fixed)

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

Reported by: ken Owned by: ken
Priority: major Milestone: CLFS Standard 1.0.0
Component: BOOK Version: CLFS Standard 1.0.0
Keywords: Cc:

Description

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 ?

Change History (18)

comment:1 Changed 13 years ago by 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?

comment:2 Changed 13 years ago by ken

Owner: changed from clfs-commits@… to ken
Status: newassigned

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).

comment:3 Changed 13 years ago by 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).

comment:4 Changed 13 years ago by ken

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

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by Jim Gifford

Version: unstable1.0

comment:7 Changed 13 years ago by Jim Gifford

Version: 1.01.0.0

comment:8 Changed 13 years ago by Jim Gifford

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

comment:9 Changed 13 years ago by 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.

comment:10 Changed 13 years ago by 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 ?

comment:11 Changed 13 years ago by 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.

comment:12 Changed 13 years ago by 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.

comment:13 Changed 13 years ago by 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;

comment:14 Changed 13 years ago by 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.

comment:15 Changed 13 years ago by 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.

comment:16 Changed 13 years ago by ken

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

comment:17 Changed 13 years ago by 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.

comment:18 Changed 13 years ago by ken

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.