|
|
发表于 2005-1-16 22:40:22
|
显示全部楼层
记得我碰到这个问题时，是用下面其中的一个方法解决的，具体是哪个，忘记了 
Having Knoppix 3.1 as host OS I had the "The system has no more ptys. Ask your system administrator to create more." message when I made an
expect -c "spawn ls"
I had to change to root, install the .bash_profile in /root and then make a "su - " to execute it. This way I have been able to continue with the gcc compilation phase 2.
I'm using knoppix and not only am I not quite sure what the above poster means, when I tried copying the .bash_profile into root from /home/lfs nothing happened. Anyone care to elaborate?
With Knoppix, all i had to do was "chmod 666 /dev/ptmx", that sorted out the above problem.
I had the same problem and found the solution here : /usr/src/linux/Documentation/Changes:
Optional support for Unix98 pty devices has also been added. If you want to use the Unix98 ptys, you should be running at least glibc-2.0.9x, and you must switch completely to Unix98 pty's. The general procedure for configuring Unix98 pty support is:
- Compile your kernel with CONFIG_UNIX98_PTYS and CONFIG_DEVPTS_FS.
- mknod /dev/ptmx c 5 2
- chmod 666 /dev/ptmx
- mkdir /dev/pts
- Add to /etc/fstab
none /dev/pts devpts gid=5,mode=620 0 0
(Note: gid=5 is applicable for ?RedHat systems for which group "tty" has gid 5. Adjust according to your distribution. Use mode=600 if you want "mesg n" to be default.)
- Mount /dev/pts
--Benoit Fleury
Hey, Benoit, thanks for the info! That is exactly what I needed to do to get everything running correctly!
I run into this problem in chapter 6, when you allready chrooted. But there is an easy solution:
open a terminal on your host system
execute the following command:
/dev/MAKEDEV -d $LFS/dev pty
So you get 256 ptys. There might be a problem because not every pty has theire own tty
Host System: Fedora Core 2, glibc-2.3.4-20040828, binutils-2.15.91.0.2
Andi Hotz at http://www.mbphuber.ch/Andi
"Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the same working directory. They will all unfold into a single gcc-3.3.1/ subdirectory."
Color me dumb, but this line wasn't entirely clear to me. After rereading it a couple of times I decided that was asked of me was to make any directory in the =/tools/source= directory (I used gcc-build, in the spritit of the earlier "working directories"). After getting all three archives into =/tools/source/gcc-build/gcc-3.3.1= I read the next command to input, which is patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch. This clearly indicates that the gcc-3.3.1= should be one level into =/source, not two.
Now, as I said, this might've been my own misreading. Also, the fact I am not a native speaker might've mislead me. Thirdly, the "problem" could be considered fairly inconsequential as the meaning becomes obvious three paragraphs later.
So, this might all have been useless information, but I thought I would share it regardless, as so far it has been the only slightly puzzling instruction in otherwise very clear and consise explaination. 
I am a native english speaker, and I fully agree that this was unclear. I did read ahead and figure out that the author expected me to have /tools/source as my cwd, but it was still unclear whether or not I had to wipe out the previous /tools/source/gcc-build directory or if I could start with it in its previous state. This was irritating as it was time-consuming to wipe it out and re-create it. In general, I like to always leave build directories as is after installing software. That way, when I start using it and find a bug I would like to fix, I can go back, edit the source and re-compile without having to start from scratch. (After all, that _was_ one of the principle reasons for the existence of make.) Due to uncertainty about what exactly the author expected me to do, I tarred and bzipped the current gcc-build as well as the current gcc-3.3.1 before wiping them out and starting over.
I recommend the authors always think carefully about distinguishing between when one "could" or "should" or "must" do any particular step in any particular way, particularly with respect to the necessary states for subsequent passes in multi-pass compiles. Also, be careful to make sure the user knows what his cwd should be at all times (if it matters). There is at least one place I have found so far where the clearly-stated "default" assumption about cwd was not correct.
Just wanted to say what I did because I too was unsure in this case - I moved the existing gcc-3.3.3 and gcc-build directories to gcc-3.3.3-old and gcc-build-old, and extracted all three archives to take their place. This way, I kept everything I had originally because I wasn't sure if I could get rid of them, and left room for what I felt was requested by the book.
My system doesn't have any Unix98 pty's, and expect returned "The system has no more ptys.". I created all the BSD pty's and tty's, but it still didn't work (all permissions were set to 666). Then I remembered something I read sometime about pt_chown in the libc info. And yes, once you issue (as root)
chmod u=rwxs,g=rx,o=rx $LFS/tools/libexec/pt_chown
chown root:root $LFS/tools/libexec/pt_chown
expect won't moan anymore. (This is a nai"ve ordering of the commands above, not a security-aware one.) The problem is caused by two facts:
not having (or using) /dev/ptmx, grantpt() needs pt_chown which must be setuid root
the temporary glibc's "make install" in chapter 05 was run as lfs, not root |
|
IP卡
狗仔卡
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡