Re: [lfs-support] Unable to login
Op Thu, 03 Oct 2013 23:04:51 +0200 schreef William Harrington
kb0...@berzerkula.org:
On Oct 3, 2013, at 3:24 PM, hans kaper wrote:
I added a line and an error occurred. So login.defs was read.
Now find the line that is causing the invalid argument
chroot and run login and see what happens.
The same error!!
Also, install strace and run login and see what happens.
Installing strace gives a make-error:
gcc -DHAVE_CONFIG_H -I. -I./linux/i386 -I./linux -I./linux -Wall
-Wwrite-strings -g -O2 -MT process.o -MD -MP -MF .deps/process.Tpo -c -o
process.o process.c
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct
ptrace_peeksiginfo_args'
struct ptrace_peeksiginfo_args {
^
In file included from defs.h:159:0,
from process.c:37:
/usr/include/sys/ptrace.h:191:8: note: originally defined here
struct ptrace_peeksiginfo_args
^
make[2]: *** [process.o] Error 1
make[2]: Leaving directory `/sources/strace-4.8'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/sources/strace-4.8'
make: *** [all] Error 2
I tried to verify the packet with gpg: error: public key not found. How to
find that key?
I am not that experienced with gpg.
By the way, thanks to Bruce and you for the effort to help me.
Hans.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Unable to login
hans kaper wrote:
Op Thu, 03 Oct 2013 23:04:51 +0200 schreef William Harrington
kb0...@berzerkula.org:
On Oct 3, 2013, at 3:24 PM, hans kaper wrote:
I added a line and an error occurred. So login.defs was read.
Now find the line that is causing the invalid argument
chroot and run login and see what happens.
The same error!!
Also, install strace and run login and see what happens.
Installing strace gives a make-error:
gcc -DHAVE_CONFIG_H -I. -I./linux/i386 -I./linux -I./linux -Wall
-Wwrite-strings -g -O2 -MT process.o -MD -MP -MF .deps/process.Tpo -c -o
process.o process.c
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct
ptrace_peeksiginfo_args'
struct ptrace_peeksiginfo_args {
^
In file included from defs.h:159:0,
from process.c:37:
/usr/include/sys/ptrace.h:191:8: note: originally defined here
struct ptrace_peeksiginfo_args
Use the patch:
http://www.linuxfromscratch.org/patches/downloads/strace/strace-4.8-glibc_2.18_build_fix-1.patch
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] More control and package management using package users
I have updated the wrapper scripts to handle some new chmod functionality. It now supports OCTAL-MODEs that are longer than 4 digits or have preceding @ signs. See: https://lists.gnu.org/archive/html/bug-coreutils/2012-03/txtWUJXdGwYNs.txt Where it says: chmod, mkdir, install now accept new style of octal mode specification. When octal mode is preceeded by @ or is 5+ digits long with leading zeros, it can clear the set user id and set group id bits on directories. Get the latest more_control_helpers.tar.xz file from https://www.javacrypt.com/lfs/ Thanks, Robert Taylor On Mon, Sep 23, 2013 at 2:08 PM, Rob Taylor rtaylor...@gmail.com wrote: Thanks for the link Hans. On Mon, Sep 23, 2013 at 12:51 PM, hans kaper spaky...@xs4all.nl wrote: ** Op Mon, 23 Sep 2013 21:05:01 +0200 schreef Rob Taylor rtaylor...@gmail.com: I have been working through LFS 7.2, 7.3 and 7.4 testing and revising scripts for this package management system. I have added a number of scripts and in some cases almost entirely rewritten the existing scripts. While I have tested these scripts no one else has so, my version of this package should be considered Alpha or Beta at best. You can play with the revised project and see my notes here: https://www.javacrypt.com/lfs/ I don't have a lot of time for development or support so use at your own risk and use the lists here or Google as a resource if my replies seem rather slow. Enjoy, Robert Taylor Looks impressive. I stopped using the package management system; too much trouble and not enough benefits, but I still use scripts that are based on it. I will look into yours; maybe I can learn from it. Another interesting piece of work on this subject you can find at https://github.com/ericherman/package-users. There was also a discussion on this subject on this support site about two years ago, initiated by Drew Ames. Hans. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Unable to login
Op Fri, 04 Oct 2013 17:13:50 +0200 schreef Bruce Dubbs bruce.du...@gmail.com: hans kaper wrote: Op Thu, 03 Oct 2013 23:04:51 +0200 schreef William Harrington kb0...@berzerkula.org: On Oct 3, 2013, at 3:24 PM, hans kaper wrote: Also, install strace and run login and see what happens. Use the patch: http://www.linuxfromscratch.org/patches/downloads/strace/strace-4.8-glibc_2.18_build_fix-1.patch That worked! First line in Password is now: root::0:0:root:/root:/bin/bash I omitted the x after the first :, as Bruce advised. I assume that then no password is necessary. Next I chroot as in the begin of ch.6, so that devices are loaded. Then: strace -olog.txt login The log-file gives a lot of data, but I think the most important are: . read(0, root\n, 1024) (reading from the kbd) . open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3 .. read(3, root::0:0:root:/root:/bin/bash\nb..., 4096) = 159 ... write(4, Wachtwoord: , 12)= 12 (=Password: ) read(4, \n, 4096) = 1 (just Enter, no password necessary) write(4, \n, 1) ... _llseek(4, 0, 0xbfeae3e0, SEEK_CUR) = -1 ESPIPE (Illegal seek) I assume the last line is the error, but I don't know what it means. If I give the password, the result is the same. Hans. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Unable to login
hans kaper wrote: Op Fri, 04 Oct 2013 17:13:50 +0200 schreef Bruce Dubbs bruce.du...@gmail.com: hans kaper wrote: Op Thu, 03 Oct 2013 23:04:51 +0200 schreef William Harrington kb0...@berzerkula.org: On Oct 3, 2013, at 3:24 PM, hans kaper wrote: Also, install strace and run login and see what happens. Use the patch: http://www.linuxfromscratch.org/patches/downloads/strace/strace-4.8-glibc_2.18_build_fix-1.patch That worked! First line in Password is now: root::0:0:root:/root:/bin/bash I omitted the x after the first :, as Bruce advised. I assume that then no password is necessary. That's right. Next I chroot as in the begin of ch.6, so that devices are loaded. Then: strace -olog.txt login The log-file gives a lot of data, but I think the most important are: . read(0, root\n, 1024) (reading from the kbd) . open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3 .. read(3, root::0:0:root:/root:/bin/bash\nb..., 4096) = 159 ... write(4, Wachtwoord: , 12)= 12 (=Password: ) This shouldn't happen. The sequence is: root:~$ login blfs login: root No mail. -bash-4.2# If there is no pw, then it shouldn't even ask for one. read(4, \n, 4096) = 1 (just Enter, no password necessary) write(4, \n, 1) ... _llseek(4, 0, 0xbfeae3e0, SEEK_CUR) = -1 ESPIPE (Illegal seek) I assume the last line is the error, but I don't know what it means. If I give the password, the result is the same. I looked at a trace for my system. Do you have /etc/group? These are my opens, disregarding library and files not found: open(/etc/login.defs, O_RDONLY) = 3 open(/etc/nsswitch.conf, O_RDONLY|O_CLOEXEC) = 3 open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3 open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3 open(/etc/login.access, O_RDONLY) = 3 open(/var/log/lastlog, O_RDWR)= 3 open(/etc/group, O_RDONLY|O_CLOEXEC) = 3 open(/var/log/wtmp, O_WRONLY) = 3 open(/proc/sys/kernel/ngroups_max, O_RDONLY) = 3 open(/etc/group, O_RDONLY|O_CLOEXEC) = 3 open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3 open(/etc/localtime, O_RDONLY|O_CLOEXEC) = 3 open(/dev/tty, O_RDWR|O_NONBLOCK) = 3 open(/proc/meminfo, O_RDONLY|O_CLOEXEC) = 3 open(/etc/nsswitch.conf, O_RDONLY|O_CLOEXEC) = 3 open(/lib/libnss_files.so.2, O_RDONLY|O_CLOEXEC) = 3 open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3 open(/etc/profile, O_RDONLY) = 3 open(/root/.bash_history, O_RDONLY) = 3 open(/root/.bash_history, O_RDONLY) = 3 open(/usr/share/terminfo/x/xterm, O_RDONLY) = 3 open(/etc/inputrc, O_RDONLY) = 3 open(/root/.bash_history, O_WRONLY|O_APPEND) = 3 open(/root/.bash_history, O_RDONLY) = 3 Check that login.defs, nsswitch.conf, passwd, login.access, and group all exist. Note that shadow is not opened. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] GCC specs file contains reference to /lib/ld-linux.so on a 64 bits machine
Hi LFS Team I've read in the LFS book v7.4 at the section “6.10. Adjusting the Toolchain” that is a good idea to visually inspect the GCC specs file and that's what I did. I've noticed that there are 2 references to /lib/ld-linux.so even if I'm using a 64 bits machine. So I replaced them by /lib64/ld-linux-x86-64.so.2. Am I wrong or there is really a mistake somewhere or maybe I made something wrong during the construction of the temporary system? Generally do you have any feedback on the building of LFS on a 64 bits machine? Before upgrading to the 7.4 I was using LFS 6.4 on a 32 bits machine and had no such a problem. I read somewhere that using ldconfig is not recommended but I was obliged to use it to go ahead as I was stuck for 2 days on the compilation of the package file (problem to find the shared library libz). I use Debian 7 (wheezy) installed in a Vmware fusion VM which is in turn installed on an Apple iMac. Maybe glibc/gcc are too recent on my machine to build the temporary system... Best Regards Afshin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] GCC specs file contains reference to /lib/ld-linux.so on a 64 bits machine
On Fri, Oct 04, 2013 at 11:15:30PM +0200, Afshin wrote: Hi LFS Team I've read in the LFS book v7.4 at the section “6.10. Adjusting the Toolchain” that is a good idea to visually inspect the GCC specs file and that's what I did. I've noticed that there are 2 references to /lib/ld-linux.so even if I'm using a 64 bits machine. So I replaced them by /lib64/ld-linux-x86-64.so.2. Am I wrong or there is really a mistake somewhere or maybe I made something wrong during the construction of the temporary system? /lib64/ld-linux-x86-64.so.2 is correct. ISTR that the book has a note that the filename may vary, but I'm not going to look up the details - I've already misled one person this week :) Generally do you have any feedback on the building of LFS on a 64 bits machine? Before upgrading to the 7.4 I was using LFS 6.4 on a 32 bits machine and had no such a problem. I've been using 64-bit on LFS since before it was officially supported. In the early days, a few BLFS packages such as jpegsrc.v6b (sic) got confused and required their config files (e.g. config.guess) to be updated. Other occasional packages such as popt insisted on using /usr/lib64 instead of /usr/lib. Everything was solveable. The current LFS method of symlinking /lib64 to /lib isn't as pure or clean, but it works ok. I read somewhere that using ldconfig is not recommended but I was obliged to use it to go ahead as I was stuck for 2 days on the compilation of the package file (problem to find the shared library libz). What do you mean by the package file ? Anyway, that sounds as if you made a mistake in installing libz : libz.so.1.2.8 should end up in /lib, with a symlink from /lib/libz.so.1 and another from /usr/lib/libz.so. This is a difference between 32-bit i686 and 64-bit : the static libz.a cannot be used in a shared 64-bit library, so the link fails if a shared libz isn't found. In 32-bit the link with libz.a will succeed, which might not be what you want. I use Debian 7 (wheezy) installed in a Vmware fusion VM which is in turn installed on an Apple iMac. Maybe glibc/gcc are too recent on my machine to build the temporary system... Best Regards Afshin LOL. A debian release too recent. After picking myself up from the floor, I suggest that building in a vm, and indeed using that hardware [ broken UEFI implementations have been noted on the kernel list, and each new version seems to bring problems with HID devices not being recognized by the kernel, until someone adds the fix ] are more likely to cause problems. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
