Ok, this is the followup from testing ranger's 2007.1 PPC64-64ul media. My times never seem to line up with his, so I'm just opening a bug so we can work on it together. yaboot-static 1.3.13-r1 and 1.3.14_pre1 both fail to boot my G5. If I install 32ul, and use normal yaboot-1.3.1[34], both of them work. I suspect something might be broken in the binary build of yaboot-static thusly. I tested with my own kernel, as well as the kernel that was used for the livecd (copied the kernel and system.map) - both kernels have the same error. boot: livecd Please wait, loading kernel... hd:3,/boot/kernel-genkernel-ppc-2.6.23-gentoo-G5: Input/Output error boot: Using an explicit OF path leads to the same error (and a different error if I specify a non-existent OF device). It is failing to access the ext3 partition that forms / for some reason. I'm going to try a dedicated ext2 /boot next.
Ok, I figured out what the source of the problem is. It's one that the GRUB folk solved quite some time ago, but yaboot has the same issue. There are 4 versions of MD RAID metadata: 0.90, 1.0, 1.1, 1.2. 0.90 and 1.0 are at the end of the partition. 1.1 and 1.2 are at the start of the partition. 0.90 is not endian neutral, and has other limitations. My ppc64-32ul install got metadata v1.0, while my ppc64-64ul got metadata v1.2 instead. I'm not sure why the variation, I'm pretty sure I used the same commandline both times aiming for repeatability. Now the yaboot bug came in because if a MD partition is detected, the ext2 handler potentially needs to skip some of the start of the partition, to find the real start of the ext2 data area. Yaboot does not do this. After I made a dedicated /boot that was v0.90, I could boot perfectly. In my case, I have two drives in my G5, and I run them in a RAID1 configuration. Related to this, I found one PPC-specific kernel bug. Namely, the RAID in-kernel auto-assembly seems to be broken for metadata v1.[012] (but this is not a problem for initrd users).
ppc64: 1.3.14 does not fix this (nor even contain any attempts to fix it per the changelog.
This is the same version as what the 32bit folks are using. And it's built and quickpkg'd on a 32bit version. If you know what you are looking for, can you cite a version or a patch that we are missing? The JoseJX and I can see about getting it into portage.
If you notice my comment #1, it's not unique to -static, it's in the source-built version as well. (It was human error that lead to that original statement that -static broken were plain had worked, they are really both broken). I can explain it best from the yaboot source code. They basically need two changes. 1. in second/partitions.c, there is no processing in partition_mac_lookup for RAID devices at all. The kernel (fs/partitions/mac.c) recognizes the label "Linux_RAID" itself. If this is detected, set a flag for now. (I see it ignores actual checking of labels at the moment anyway). 2. in second/fs.c, if the RAID flags are set, check what type of RAID, and adjust the partition.part_{start,size} values that are handed to the filesystem code. I suspect this bug will probably sit here until I get to fixing yaboot myself for it.
