glibc-2.8_p20080602-r1 breaks a brand new Gentoo installation on a PS3 ppc64 installation. Reproducible: Always Steps to Reproduce: 1. Get a PS3 (d'oh!) 2. Unpack the latest stage3-ppc64-64ul and the portage tree 3. chroot, etc 4. Change make.conf to optimise for the cell processor (-mcpu=cell), ACCEPT_KEYWORDS="~ppc64" 5. emerge -uNDav1 python 6. python-updater 7. emerge -uNDav1 system Actual Results: After the glibc upgrade : >>> Emerging (32 of 32) sys-devel/gcc-4.3.3-r2 Traceback (most recent call last): File "/usr/lib/portage/bin/ebuild", line 59, in <module> import portage File "/usr/lib/portage/pym/portage/__init__.py", line 96, in <module> from portage.data import ostype, lchown, userland, secpass, uid, wheelgid, \ File "/usr/lib/portage/pym/portage/data.py", line 101, in <module> mystatus, myoutput = getstatusoutput("id -G portage") File "/usr/lib64/python2.6/commands.py", line 55, in getstatusoutput pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') OSError: [Errno 9] Bad file descriptor Getting this python error for anything. I tried to start a python interpretor and directly use the os.popen function. Fails. Expected Results: Not this to happen ;-) I can't ren emerge --info, as python is broken.
Modified version number. This is the one, the 2.8 version was the one who was unmerged at the end of the process... sorry for the typo.
You didn't update python and forgot to run python-updater, right?
Nop, that time I specifically updated python (because I ran into this problem twice using an old PS3 2008.0 stage) and ran python-updater. Just tried again without the -mcpu=cell and -abi=altivec flags: Steps to Reproduce: 1. Get a PS3 (d'oh!) 2. Unpack the latest stage3-ppc64-64ul and the portage tree 3. chroot, etc 4. ACCEPT_KEYWORDS="~ppc64" 7. emerge -uNDav1 system Failing at the exact same place (after glibc's upgrade)
If you have any test request, I'm starting over. I'll update everything but glibc and GCC. Just tell me what to test / what glibc version to merge, etc :-)
Same test with glibc-2.9_p20081201-r1. Changing summary to reflect that all revisions of glibc-2.9_p20081201 do break the system.
someone with Gentoo actually installed on their PS3 will have to take a look. the popen/pipe issue should have been fixed already by 1095_all_glibc-2.9-assume-pipe2.patch.
Just tested with hard-masked 2.10.1, same issue :(
(In reply to comment #6) > someone with Gentoo actually installed on their PS3 will have to take a look. > the popen/pipe issue should have been fixed already by > 1095_all_glibc-2.9-assume-pipe2.patch. > Where is this file? Merged with another patch? I don't find it anywhere in Portage...
Well, well, well. Checking the comments on the patch, I understood what's the problem. I'm on a LiveCD, trying to install a Gentoo on the PS3, but the only LiveCD that works on the PS3 is an old one with an old kernel. (2.6.23 I think). Updating the system before installing a new kernel and rebooting will compile glibc with 2.6.29 headers but the kernel running is old... Should be added in the Gentoo documentation not to upgrade everything prior to the first boot of the machine with the current stage3. Resolving bug with resolution to INVALID.
mmm that shouldnt cause a problem unless you also set NPTL_KERN_VER to something newer than the running kernel
(In reply to comment #10) > mmm that shouldnt cause a problem unless you also set NPTL_KERN_VER to > something newer than the running kernel > Everything works fine while booted on a newer kernel. I did not set NPTL_KERN_VER to anyting ;-) Booting the recent kernel was only a workaround?
correct. the default build should allow for building against any recent kernel header version but running on 2.6.9+.
This also happed to me, running 2.6.24. /usr/include/linux/version.h indicates 2.6.27.
(I did not set NPTL_KERN_VER, and I wasn't installing from a live cd, but merely upgrading a working system.)
Also, both the stage4 and the kernel source overlays seems to contain nothing newer than 2.6.24, so where to get the new kernel?
Building and installing 2.6.28.10 straight from kernel.org fixed the problem. Luckily, the system was not too botched to compile a kernel.
(In reply to comment #15) > Also, both the stage4 and the kernel source overlays seems to contain nothing > newer than 2.6.24, so where to get the new kernel? > You don't need any "special" kernel, the vanilla Linux kernel supports the PS3 since I don't remember what version. You can use the normal gentoo-sources. There is a file named ps3_defconfig in arch/powerpc/configs from which you can base your .config. Watch out though, this .config example doesn't include lots of needed things (USB keyboard and mouse, filesystems, etc).
Well, it's been a long time since I had to compile a ps3 kernel last... :-) No worries about the config, I used the one from my 2.6.24 kernel and did make oldconfig, which turned out ok.
I just ran into this bug on my PS3 with ppc64 installation. After upgrading my kernel from ps3-sources-2.6.23-r1 to gentoo-sources-2.6.27-r8, all problems related to popen() are gone. And my 240 days uptime :( I suggest making glibc-2.9 dependent on a recent kernel, since it gives bad problems with old kernels. Even emerge does not run anymore! If you run into this bug, and emerge is broken, you can 'fix' emerge by changing getstatusoutput("id -G portage") to 0, '250' in /usr/lib/portage/pym/portage/data.py. Then you can emerge recent kernel sources, configure, compile and install them, and reboot. Afterwards, you can undo the fix again. I used this fix with portage version 2.1.6.13.
it'll take me a while to set up my ps3 with linux, so it'll be faster if someone could give me temp access (non-root) to a box that is misbehaving ...
(In reply to comment #20) > it'll take me a while to set up my ps3 with linux, so it'll be faster if > someone could give me temp access (non-root) to a box that is misbehaving ... > If you want to set up your PS3 with Gentoo and run into that bug, you can follow this howto I wrote/updated some weeks ago: http://en.gentoo-wiki.com/wiki/Sony_Playstation_3 Just ensure you stay in the chroot of the old PS3 LiveCD to do all the upgrade. I've got two installations up and running (ppc and ppc64) and I don't plan for now to reproduce this bug again... I may do it in a couple of weeks if you don't want to try it out on your own until then. I could then give you an access.
looks like another kernel bug. the official linux-2.6.23 release had powerpc maxing out at 309 syscalls. that means anything with 310 or higher should return ENOSYS. unfortunately, it would seem that the sony patches to the linux kernel adds unofficial syscalls thus breaking this whole process. if you look at the patchsets in the ps3-sources 2.6.23 / 2.6.24, you'll see this little gem: http://overlays.gentoo.org/proj/cell/browser/sys-kernel/ps3-sources/files/00-sony-2.6.24.patch.bz2 --- linux-2.6.24/include/asm-powerpc/unistd.h +++ linux-2.6.24-20080131/include/asm-powerpc/unistd.h @@ -332,10 +332,22 @@ #define __NR_eventfd 307 #define __NR_sync_file_range2 308 #define __NR_fallocate 309 +#define __NR_pfm_create_context 310 +#define __NR_pfm_write_pmcs (__NR_pfm_create_context+1) +#define __NR_pfm_write_pmds (__NR_pfm_create_context+2) +#define __NR_pfm_read_pmds (__NR_pfm_create_context+3) +#define __NR_pfm_load_context (__NR_pfm_create_context+4) +#define __NR_pfm_start (__NR_pfm_create_context+5) +#define __NR_pfm_stop (__NR_pfm_create_context+6) +#define __NR_pfm_restart (__NR_pfm_create_context+7) +#define __NR_pfm_create_evtsets (__NR_pfm_create_context+8) +#define __NR_pfm_getinfo_evtsets (__NR_pfm_create_context+9) +#define __NR_pfm_delete_evtsets (__NR_pfm_create_context+10) +#define __NR_pfm_unload_context (__NR_pfm_create_context+11) -#define __NR_syscalls 310 +#define __NR_syscalls 322 which means anything in the future that officially uses these numbers (like pipe2) will break. the only solution here is to upgrade your kernel and stop using the ps3-sources kernel. i'll add a blocker to the newer glibc, but the ppc64 guys really should: - update the livecd to a newer kernel not using these custom patchsets - add a newer ps3-sources ebuild that simply does `die` or redirects to gentoo-sources
dont use ps3-sources
And don't install using old liveCDs running on it ;) (that was the original problem). And anyway now people must own a PS3 which isn't upgraded to the newest Sony firmwares :(.
i'm debating buying a 2nd PS3 ... was hoping geohot would have something released by now for us
I've got two PS3s, one that remains with the old firmware (I've got Gentoo on it, but I didn't use it for months), and one other that I had to upgrade to play the latest games, etc. I hope geohot will release something... (maybe it's done, didn't check since one month).
