Re: [lfs-support] missing systemd out
On Fri, 2014-04-25 at 14:23 +0100, Jorge Almeida wrote: On Fri, Apr 25, 2014 at 12:56 PM, Simon Geard delga...@ihug.co.nz wrote: There's no information on the site, no source code, mailing lists - just a couple of paragraphs grumbling about dbus, and a claim that it'll be released some time last year or this one. Looks like vapourware to me - Looks like unreleased software, which is what the site says it is. The author has made stuff I use everyday, like s6-* and execline, so I trust it will have substance when released. See, that's the thing - unreleased software isn't something you see a lot in the open-source world. Even from the earliest stages of a new project, you expect to find a source repo, a web site with some info about the design and goals, etc. Lacking those things, I can only be skeptical about what state the project might be in. Simon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
On Thu, 2014-04-24 at 20:16 +0100, Jorge Almeida wrote: Ok. I know about skabus, but it's not clear whether it will be able to function as drop-in replacement for dbus. I would love to get rid of dbus completelly. There's no information on the site, no source code, mailing lists - just a couple of paragraphs grumbling about dbus, and a claim that it'll be released some time last year or this one. Looks like vapourware to me - certainly not something that'll displace dbus... Simon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
On Fri, Apr 25, 2014 at 12:56 PM, Simon Geard delga...@ihug.co.nz wrote: There's no information on the site, no source code, mailing lists - just a couple of paragraphs grumbling about dbus, and a claim that it'll be released some time last year or this one. Looks like vapourware to me - Looks like unreleased software, which is what the site says it is. The author has made stuff I use everyday, like s6-* and execline, so I trust it will have substance when released. certainly not something that'll displace dbus... That's another matter. I'm not sure it's supposed to displace dbus for softwares made to use dbus. Jorge -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] configure package texinfo 5.2 failure
I can't configure this texinfo package because it complaint Perl and Encode module. Here is my output when issue the command: ./configure --prefix=/tools and output: checking for a BSD-compatible install... /tools/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /tools/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether UID '1001' is supported by ustar format... yes checking whether GID '1001' is supported by ustar format... yes checking how to create a ustar tar archive... gnutar checking for perl... /tools/bin/perl checking Perl version and Encode module... no configure: error: perl = 5.7.3 with Encode required by Texinfo. The problem ocurred in chapter 5.32, LFS 7.5. Help me, I'm a novice. My system's specification: Elementary luna 0.2 x86_64 -- based on Ubuntu 12.04 LTS. So far this is my 1st problem in the road. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] configure package texinfo 5.2 failure
Aislan de Sousa Maia wrote: I can't configure this texinfo package because it complaint Perl and Encode module. Here is my output when issue the command: ./configure --prefix=/tools and output: checking for a BSD-compatible install... /tools/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /tools/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether UID '1001' is supported by ustar format... yes checking whether GID '1001' is supported by ustar format... yes checking how to create a ustar tar archive... gnutar checking for perl... /tools/bin/perl checking Perl version and Encode module... no configure: error: perl = 5.7.3 with Encode required by Texinfo. The problem ocurred in chapter 5.32, LFS 7.5. Help me, I'm a novice. My system's specification: Elementary luna 0.2 x86_64 -- based on Ubuntu 12.04 LTS. What is the output of the host systems requirements script in Section vii? -- 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] configure package texinfo 5.2 failure
Here is the version-check's output: bash, version 4.2.25(1)-release /bin/sh - /bin/bash Binutils: (GNU Binutils for Ubuntu) 2.22 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc bzip2, Version 1.0.6, 6-Sept-2010. Coreutils: 8.13 diff (GNU diffutils) 3.2 find (GNU findutils) 4.4.2 GNU Awk 3.1.8 /usr/bin/awk - /usr/bin/gawk gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 (Ubuntu EGLIBC 2.15-0ubuntu10.5) 2.15 grep (GNU grep) 2.10 gzip 1.4 Linux version 3.8.0-38-generic (buildd@lamiak) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #56~precise1-Ubuntu SMP Thu Mar 13 16:22:48 UTC 2014 m4 (GNU M4) 1.4.16 GNU Make 3.81 patch 2.6.1 Perl version='5.14.2'; GNU sed version 4.2.1 tar (GNU tar) 1.26 xz (XZ Utils) 5.1.0alpha g++ compilation OK libgmp.la: not found libmpfr.la: not found libmpc.la: not found 2014-04-25 19:32 GMT-03:00 Bruce Dubbs bruce.du...@gmail.com: Aislan de Sousa Maia wrote: I can't configure this texinfo package because it complaint Perl and Encode module. Here is my output when issue the command: ./configure --prefix=/tools and output: checking for a BSD-compatible install... /tools/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /tools/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether UID '1001' is supported by ustar format... yes checking whether GID '1001' is supported by ustar format... yes checking how to create a ustar tar archive... gnutar checking for perl... /tools/bin/perl checking Perl version and Encode module... no configure: error: perl = 5.7.3 with Encode required by Texinfo. The problem ocurred in chapter 5.32, LFS 7.5. Help me, I'm a novice. My system's specification: Elementary luna 0.2 x86_64 -- based on Ubuntu 12.04 LTS. What is the output of the host systems requirements script in Section vii? -- Bruce -- 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] configure package texinfo 5.2 failure
Aislan de Sousa Maia wrote: Here is the version-check's output: bash, version 4.2.25(1)-release /bin/sh - /bin/bash Binutils: (GNU Binutils for Ubuntu) 2.22 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc bzip2, Version 1.0.6, 6-Sept-2010. Coreutils: 8.13 diff (GNU diffutils) 3.2 find (GNU findutils) 4.4.2 GNU Awk 3.1.8 Needs to be Gawk-4.0.1 or later. Typo? -- Bruce /usr/bin/awk - /usr/bin/gawk gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 (Ubuntu EGLIBC 2.15-0ubuntu10.5) 2.15 grep (GNU grep) 2.10 gzip 1.4 Linux version 3.8.0-38-generic (buildd@lamiak) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #56~precise1-Ubuntu SMP Thu Mar 13 16:22:48 UTC 2014 m4 (GNU M4) 1.4.16 GNU Make 3.81 patch 2.6.1 Perl version='5.14.2'; GNU sed version 4.2.1 tar (GNU tar) 1.26 xz (XZ Utils) 5.1.0alpha g++ compilation OK libgmp.la: not found libmpfr.la: not found libmpc.la: not found -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] configure package texinfo 5.2 failure
On 04/26/2014 12:59 AM, Bruce Dubbs wrote: Aislan de Sousa Maia wrote: Here is the version-check's output: bash, version 4.2.25(1)-release /bin/sh - /bin/bash Binutils: (GNU Binutils for Ubuntu) 2.22 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc bzip2, Version 1.0.6, 6-Sept-2010. Coreutils: 8.13 diff (GNU diffutils) 3.2 find (GNU findutils) 4.4.2 GNU Awk 3.1.8 Needs to be Gawk-4.0.1 or later. Typo? -- Bruce Apparently it doesn't, since it's only used by glibc package and 4.0.1 was only required by certain version because of some kind of bug. His error is rather misconfigured perl in /tools. My /tools/lib/perl5/5.18.2 has Encode.pm file and Encode directory, which is what texinfo configure looks for. His apparently doesn't which seems a missed step in chapter 5 perl installation. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] configure package texinfo 5.2 failure
My /tools/lib/perl5/5.18.2 has Encode.pm file and Encode directory too. I followed step-by-step carefully the installation's section for Perl. I'm going to redo this section again. About Gawk, I updated it just right now. 2014-04-25 20:15 GMT-03:00 Armin K. kre...@email.com: On 04/26/2014 12:59 AM, Bruce Dubbs wrote: Aislan de Sousa Maia wrote: Here is the version-check's output: bash, version 4.2.25(1)-release /bin/sh - /bin/bash Binutils: (GNU Binutils for Ubuntu) 2.22 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc bzip2, Version 1.0.6, 6-Sept-2010. Coreutils: 8.13 diff (GNU diffutils) 3.2 find (GNU findutils) 4.4.2 GNU Awk 3.1.8 Needs to be Gawk-4.0.1 or later. Typo? -- Bruce Apparently it doesn't, since it's only used by glibc package and 4.0.1 was only required by certain version because of some kind of bug. His error is rather misconfigured perl in /tools. My /tools/lib/perl5/5.18.2 has Encode.pm file and Encode directory, which is what texinfo configure looks for. His apparently doesn't which seems a missed step in chapter 5 perl installation. -- Note: My last name is not Krejzi. -- 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] configure package texinfo 5.2 failure
My /tools/lib/perl5/5.18.2 has Encode.pm file and Encode directory too. I followed step-by-step carefully the installation's section for Perl. I'm going to redo this section again. About Gawk, I updated it right now. 2014-04-25 20:15 GMT-03:00 Armin K. kre...@email.com: On 04/26/2014 12:59 AM, Bruce Dubbs wrote: Aislan de Sousa Maia wrote: Here is the version-check's output: bash, version 4.2.25(1)-release /bin/sh - /bin/bash Binutils: (GNU Binutils for Ubuntu) 2.22 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc bzip2, Version 1.0.6, 6-Sept-2010. Coreutils: 8.13 diff (GNU diffutils) 3.2 find (GNU findutils) 4.4.2 GNU Awk 3.1.8 Needs to be Gawk-4.0.1 or later. Typo? -- Bruce Apparently it doesn't, since it's only used by glibc package and 4.0.1 was only required by certain version because of some kind of bug. His error is rather misconfigured perl in /tools. My /tools/lib/perl5/5.18.2 has Encode.pm file and Encode directory, which is what texinfo configure looks for. His apparently doesn't which seems a missed step in chapter 5 perl installation. -- Note: My last name is not Krejzi. -- 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] configure package texinfo 5.2 failure
Yay!! I don't know why, but now texinfo configure and no more complaints about Perl and Encode module. My only two configure's warnings below: configure: WARNING: Could not find a terminal library among tinfo ncurses curses termlib termcap terminfo configure: WARNING: The programs from `info' directory will not be built. It's problematic or nothing for me worry about ? And about the problem above, I just update Gawk for 4.0.1 and redo installation for Perl according to the LFS says. 2014-04-25 21:41 GMT-03:00 Aislan de Sousa Maia aislan.sousam...@gmail.com : That's funny. I run Perl tests and get all tests successful. 2014-04-25 21:18 GMT-03:00 Aislan de Sousa Maia aislan.sousam...@gmail.com: My /tools/lib/perl5/5.18.2 has Encode.pm file and Encode directory too. I followed step-by-step carefully the installation's section for Perl. I'm going to redo this section again. About Gawk, I updated it right now. 2014-04-25 20:15 GMT-03:00 Armin K. kre...@email.com: On 04/26/2014 12:59 AM, Bruce Dubbs wrote: Aislan de Sousa Maia wrote: Here is the version-check's output: bash, version 4.2.25(1)-release /bin/sh - /bin/bash Binutils: (GNU Binutils for Ubuntu) 2.22 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc bzip2, Version 1.0.6, 6-Sept-2010. Coreutils: 8.13 diff (GNU diffutils) 3.2 find (GNU findutils) 4.4.2 GNU Awk 3.1.8 Needs to be Gawk-4.0.1 or later. Typo? -- Bruce Apparently it doesn't, since it's only used by glibc package and 4.0.1 was only required by certain version because of some kind of bug. His error is rather misconfigured perl in /tools. My /tools/lib/perl5/5.18.2 has Encode.pm file and Encode directory, which is what texinfo configure looks for. His apparently doesn't which seems a missed step in chapter 5 perl installation. -- Note: My last name is not Krejzi. -- 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] configure package texinfo 5.2 failure
On 04/26/2014 02:50 AM, Aislan de Sousa Maia wrote: Yay!! I don't know why, but now texinfo configure and no more complaints about Perl and Encode module. My only two configure's warnings below: configure: WARNING: Could not find a terminal library among tinfo ncurses curses termlib termcap terminfo configure: WARNING: The programs from `info' directory will not be built. It's problematic or nothing for me worry about ? It's okay, you don't need info program from chapter 5 texinfo anyways. It has something to do with no libncurses.so compatibility library installed in chapter 5 build like in chapter 6. And about the problem above, I just update Gawk for 4.0.1 and redo installation for Perl according to the LFS says. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] configure package texinfo 5.2 failure
Nice to know, @Armin K! Thanks guys!!! 2014-04-25 22:01 GMT-03:00 Armin K. kre...@email.com: On 04/26/2014 02:50 AM, Aislan de Sousa Maia wrote: Yay!! I don't know why, but now texinfo configure and no more complaints about Perl and Encode module. My only two configure's warnings below: configure: WARNING: Could not find a terminal library among tinfo ncurses curses termlib termcap terminfo configure: WARNING: The programs from `info' directory will not be built. It's problematic or nothing for me worry about ? It's okay, you don't need info program from chapter 5 texinfo anyways. It has something to do with no libncurses.so compatibility library installed in chapter 5 build like in chapter 6. And about the problem above, I just update Gawk for 4.0.1 and redo installation for Perl according to the LFS says. -- Note: My last name is not Krejzi. -- 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] gcc-4.9.0 failure
On 04/24/2014 02:51 AM, Ken Moffat wrote: On Thu, Apr 24, 2014 at 12:23:28AM +0200, Frans de Boer wrote: I could not compile 4.9.0 since it always fails when staring to configure for 'libvtv' as showed next: [snip] Any suggestion? Frans. http://wiki.linuxfromscratch.org/lfs/ticket/3552 Pierre seems to be on the case - so far, two extra configure switches in chapter 5 one extra switch in binutils pass 2. ĸen Thanks, I expected indeed the --disable-libvtv. The other one is unclear to me yet. I will run tests too and follow the mentioned thread. Frans. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
On Wed, 2014-04-23 at 14:47 +0100, Jorge Almeida wrote: On Wed, Apr 23, 2014 at 10:26 AM, TheOldFellow theoldfel...@gmail.com wrote: I'm also avoiding d-bus and sysklogd as I have better alternatives. Richard, Would you elaborate on alternatives to dbus? There are none - if something needs dbus, it needs dbus, no substitutes. But there are sometimes alternative apps that don't require dbus. Simon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] gcc-4.9.0 changes
Ok, followed the advises from ticket #3552, now binutils chapter 6 reports failures: Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/lto.exp ... FAIL: PR ld/12758 FAIL: PR ld/12760 FAIL: LTO 3 symbol FAIL: PR ld/13183 FAIL: LTO 3a FAIL: LTO 11 Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/plugin.exp ... Concerning LTO, thus induced by gcc-4.9.0. Chapter 5 is completed without any errors, added --disable-werror to the binutils configure...Seems that others having no problem, so what could be wrong? Frans. -- 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-4.9.0 changes
Le 24/04/2014 17:28, Frans de Boer a écrit : Ok, followed the advises from ticket #3552, now binutils chapter 6 reports failures: Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/lto.exp ... FAIL: PR ld/12758 FAIL: PR ld/12760 FAIL: LTO 3 symbol FAIL: PR ld/13183 FAIL: LTO 3a FAIL: LTO 11 Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/plugin.exp ... Concerning LTO, thus induced by gcc-4.9.0. Chapter 5 is completed without any errors, added --disable-werror to the binutils configure...Seems that others having no problem, so what could be wrong? Frans. I have exactly the same failures. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
Jorge Almeida wrote: On Wed, Apr 23, 2014 at 10:26 AM, TheOldFellow theoldfel...@gmail.com wrote: I'm also avoiding d-bus and sysklogd as I have better alternatives. Richard, Would you elaborate on alternatives to dbus? For example, I need to use okular (although I hate its terminal-spamming) and I believe (speaking from memory) that it requires dbus. Any alternative to dbus, in this case? Jorge Sorry, I misled you. I don't have one right now, but I'm thinking of using this when it's released. http://skarnet.org/software/skabus/ In the mean time I plan to avoid anything that won't run without d-bus, as I am very anti anything from that particular stable. Bloatware. Richard. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
On Thu, Apr 24, 2014 at 7:35 PM, TheOldFellow theoldfel...@gmail.com wrote: Jorge Almeida wrote: On Wed, Apr 23, 2014 at 10:26 AM, TheOldFellow theoldfel...@gmail.com wrote: Sorry, I misled you. I don't have one right now, but I'm thinking of using this when it's released. http://skarnet.org/software/skabus/ In the mean time I plan to avoid anything that won't run without d-bus, as I am very anti anything from that particular stable. Bloatware. Ok. I know about skabus, but it's not clear whether it will be able to function as drop-in replacement for dbus. I would love to get rid of dbus completelly. Cheers Jorge -- 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-4.9.0 changes
Pierre Labastie wrote: Le 24/04/2014 17:28, Frans de Boer a écrit : Ok, followed the advises from ticket #3552, now binutils chapter 6 reports failures: Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/lto.exp ... FAIL: PR ld/12758 FAIL: PR ld/12760 FAIL: LTO 3 symbol FAIL: PR ld/13183 FAIL: LTO 3a FAIL: LTO 11 Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/plugin.exp ... Concerning LTO, thus induced by gcc-4.9.0. Chapter 5 is completed without any errors, added --disable-werror to the binutils configure...Seems that others having no problem, so what could be wrong? Frans. I have exactly the same failures. Looking at a full build, I have: 077-binutils-2.24:FAIL: PR ld/12758 077-binutils-2.24:FAIL: PR ld/12760 077-binutils-2.24:FAIL: LTO 3 symbol 077-binutils-2.24:FAIL: PR ld/13183 077-binutils-2.24:FAIL: LTO 3a 077-binutils-2.24:FAIL: LTO 11 093-coreutils-8.22:FAIL: tests/misc/nohup.sh 093-coreutils-8.22:# FAIL: 1 093-coreutils-8.22:FAIL: tests/misc/nohup 093-coreutils-8.22:# FAIL: 1 106-perl-5.18.2:FAILED at test 104 106-perl-5.18.2:FAILED at test 84 131-systemd-212:FAIL: test-strv 131-systemd-212:FAIL: test-bus-creds 131-systemd-212:FAIL: test-journal-flush 131-systemd-212:# FAIL: 3 133-util-linux-2.24.1:last: last ipv6... FAILED (last/ipv6) 133-util-linux-2.24.1:last: last ... FAILED (last/last) 133-util-linux-2.24.1: 2 tests of 127 FAILED -- 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] gcc-4.9.0 changes
On 04/24/2014 09:38 PM, Bruce Dubbs wrote: Pierre Labastie wrote: Le 24/04/2014 17:28, Frans de Boer a écrit : Ok, followed the advises from ticket #3552, now binutils chapter 6 reports failures: Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/lto.exp ... FAIL: PR ld/12758 FAIL: PR ld/12760 FAIL: LTO 3 symbol FAIL: PR ld/13183 FAIL: LTO 3a FAIL: LTO 11 Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/plugin.exp ... Concerning LTO, thus induced by gcc-4.9.0. Chapter 5 is completed without any errors, added --disable-werror to the binutils configure...Seems that others having no problem, so what could be wrong? Frans. I have exactly the same failures. Looking at a full build, I have: 077-binutils-2.24:FAIL: PR ld/12758 077-binutils-2.24:FAIL: PR ld/12760 077-binutils-2.24:FAIL: LTO 3 symbol 077-binutils-2.24:FAIL: PR ld/13183 077-binutils-2.24:FAIL: LTO 3a 077-binutils-2.24:FAIL: LTO 11 These are new to me. Using gcc-4.8.2 did not yield these results. 093-coreutils-8.22:FAIL: tests/misc/nohup.sh 093-coreutils-8.22:# FAIL: 1 093-coreutils-8.22:FAIL: tests/misc/nohup 093-coreutils-8.22:# FAIL: 1 These are older and can be avoided by echo exit 0 tests/misc/nohub.sh 106-perl-5.18.2:FAILED at test 104 106-perl-5.18.2:FAILED at test 84 These are also new to me. 131-systemd-212:FAIL: test-strv 131-systemd-212:FAIL: test-bus-creds 131-systemd-212:FAIL: test-journal-flush 131-systemd-212:# FAIL: 3 I am not sure of the above. 133-util-linux-2.24.1:last: last ipv6... FAILED (last/ipv6) 133-util-linux-2.24.1:last: last ... FAILED (last/last) 133-util-linux-2.24.1: 2 tests of 127 FAILED Errors are known as well as the reason too. -- Bruce I use bash scripts with set +h and set -e, so any error is terminating execution. Some scripts have set +e; make check/tests ; set -e to catch known errors with no known (grave) severity. So new errors or lack of errors are not being seen, unless I run the scripts manually and check every output. It's clear that gcc-4.9.0 does introduce some new failures in tests. Maybe because the maintainers of those other packages are behind? It seems that new software - or software depended on new software - should be tested manually, and if all is working out, enable the set +e to generate the whole TC and/or BSS part in one go. Frans. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] error when trying to cross compile glibc-2.19
Thanks all. Indeed changing the target name, was the solution to be able to build. Marian On Apr 19, 2014, at 12:42 AM, mar...@byteanywhere.com wrote: Thanks all for the replays. I am trying to create a cross compiler using the steps for building LFS when the temporary tools are build. I suggest you look at how we do that in CLFS at http://cross-lfs.org/view/git/index.html or our current http://cross-lfs.org/~kb0iic/CLFS-GIT-SYSTEMD/html/index.html Those will provide you a better understanding of what you may be doing wrong. One critical step is changing your target triplet so the tools know that it is cross compiling. Sincerely, William Harrington -- 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] missing coreutils-8.22-shuf-segfault-1.patch
2014-04-23 13:55 GMT+08:00 Bruce Dubbs bruce.du...@gmail.com: xinglp wrote: 2014-04-23 11:39 GMT+08:00 Armin K. kre...@email.com: On 04/23/2014 05:15 AM, xinglp wrote: http://www.linuxfromscratch.org/patches/lfs/development/coreutils-8.22-shuf-segfault-1.patch not found. There's only svn://svn.linuxfromscratch.org/patches/trunk/coreutils/coreutils-8.22-shuf-segfault.patch I don't care about the online book, there's no such file in the svn I fixed it just now. Saw it, thanks. -- Bruce -- 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
[lfs-support] missing systemd out
Am I right in thinking that ACL, ATTR are not needed if systemd is being avoided? What else has had to be added so that systemd compiles? I'm also avoiding d-bus and sysklogd as I have better alternatives. Richard. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
2014-04-23 17:26 GMT+08:00 TheOldFellow theoldfel...@gmail.com: Am I right in thinking that ACL, ATTR are not needed if systemd is being avoided? What else has had to be added so that systemd compiles? I'm also avoiding d-bus and sysklogd as I have better alternatives. Richard. Viceversa, I'd like to know if I don't want sysvinit. I've removed sysklogd sysvinit bootscript and some adjusting of chapter7. -- 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] missing systemd out
2014-04-23 17:26 GMT+08:00 TheOldFellow theoldfel...@gmail.com: Am I right in thinking that ACL, ATTR are not needed if systemd is being avoided? What else has had to be added so that systemd compiles? I'm also avoiding d-bus and sysklogd as I have better alternatives. Richard. Viceversa, I'd like to know what can be removed if I don't want sysvinit. I've removed sysklogd sysvinit bootscript and some adjusting of chapter7. -- 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] missing systemd out
sorry for typo. :-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
On 04/23/2014 12:04 PM, xinglp wrote: 2014-04-23 17:26 GMT+08:00 TheOldFellow theoldfel...@gmail.com: Am I right in thinking that ACL, ATTR are not needed if systemd is being avoided? What else has had to be added so that systemd compiles? I'm also avoiding d-bus and sysklogd as I have better alternatives. Richard. Viceversa, I'd like to know what can be removed if I don't want sysvinit. I've removed sysklogd sysvinit bootscript and some adjusting of chapter7. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page Both of you are correct, what you ask can be done. However, it might be a good idea not to drop non-systemd/non-dbus packages (such as acl, attr, libcap, etc) so they can be asumed that they're always installed and be removed from BLFS in the future. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
Armin K. wrote: On 04/23/2014 12:04 PM, xinglp wrote: 2014-04-23 17:26 GMT+08:00 TheOldFellow theoldfel...@gmail.com: Am I right in thinking that ACL, ATTR are not needed if systemd is being avoided? What else has had to be added so that systemd compiles? I'm also avoiding d-bus and sysklogd as I have better alternatives. snip Both of you are correct, what you ask can be done. However, it might be a good idea not to drop non-systemd/non-dbus packages (such as acl, attr, libcap, etc) so they can be asumed that they're always installed and be removed from BLFS in the future. Excellent point, I'd forgotten that. Usually though, complex software in BLFS has a 'better' mix of required and recommended dependencies, and includes instructions for those. Richard. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
On Wed, Apr 23, 2014 at 10:26 AM, TheOldFellow theoldfel...@gmail.com wrote: I'm also avoiding d-bus and sysklogd as I have better alternatives. Richard, Would you elaborate on alternatives to dbus? For example, I need to use okular (although I hate its terminal-spamming) and I believe (speaking from memory) that it requires dbus. Any alternative to dbus, in this case? Jorge -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing systemd out
TheOldFellow wrote: Am I right in thinking that ACL, ATTR are not needed if systemd is being avoided? What else has had to be added so that systemd compiles? I'm also avoiding d-bus and sysklogd as I have better alternatives. You may find http://www.linuxfromscratch.org/hints/downloads/files/eudev-alt-hint.txt helpful. -- 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-4.9.0 failure
I could not compile 4.9.0 since it always fails when staring to configure for 'libvtv' as showed next: ... make[3]: Leaving directory `/mnt/lfs/sources-tc/gcc-build/x86_64-bld-linux-gnu/libgcc' make[2]: Leaving directory `/mnt/lfs/sources-tc/gcc-build/x86_64-bld-linux-gnu/libgcc' Checking multilib configuration for libvtv... mkdir -p -- x86_64-bld-linux-gnu/libvtv Configuring in x86_64-bld-linux-gnu/libvtv configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-bld-linux-gnu checking target system type... x86_64-bld-linux-gnu checking for --enable-vtable-verify... no checking for host support for vtable verification... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for x86_64-bld-linux-gnu-strip... /tools/x86_64-bld-linux-gnu/bin/strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by make... GNU checking for x86_64-bld-linux-gnu-gcc... /mnt/lfs/sources-tc/gcc-build/./gcc/xgcc -B/mnt/lfs/sources-tc/gcc-build/./gcc/ -B/tools/x86_64-bld-linux-gnu/bin/ -B/tools/x86_64-bld-linux-gnu/lib/ -isystem /tools/x86_64-bld-linux-gnu/include -isystem /tools/x86_64-bld-linux-gnu/sys-include checking for C compiler default output file name... configure: error: in `/mnt/lfs/sources-tc/gcc-build/x86_64-bld-linux-gnu/libvtv': configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libvtv] Error 1 make[1]: Leaving directory `/mnt/lfs/sources-tc/gcc-build' make: *** [all] Error 2 lfs:/mnt/lfs/sources-tc/gcc-4.9.0$ I first assumed that it was the gcc compiler not eating the -V switch, but apparently that's not the case because I intercepted that and changed it to '-v' to no avail. Any suggestion? Frans. -- 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-4.9.0 failure
On Thu, Apr 24, 2014 at 12:23:28AM +0200, Frans de Boer wrote: I could not compile 4.9.0 since it always fails when staring to configure for 'libvtv' as showed next: [snip] Any suggestion? Frans. http://wiki.linuxfromscratch.org/lfs/ticket/3552 Pierre seems to be on the case - so far, two extra configure switches in chapter 5 one extra switch in binutils pass 2. ĸ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
Re: [lfs-support] ACL check errors: are they important?
On Mon, 21 Apr 2014 22:14:31 +0100 Ken Moffat zarniwh...@ntlworld.com wrote: From memory (so, I might be wrong) the book doesn't ever create a 'users' group in LFS... So, I _guess_ that the 'users' group exists on your host system and you will need to create it in LFS to get these tests to work. ĸen You're right. I do have a users group on my host system. But how does that affect the lfs partition? At this stage, we are in a chroot jail, using freshly-built software. Doesn't that mean complete independence from the host except for the running kernel and its virtual file systems? There would have been no previous need for a users group or a daemon user on LFS because acl was not included in the basic system and therefore there were no acl tests to be run. That must still be the case for LFS with sysVinit. But acl is apparently required for systemd, so I think it would make sense for section 6.6 to be different in the systemd edition of the book. Hazel -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 22/04/2014 13:31, Hazel Russman a écrit : On Mon, 21 Apr 2014 22:14:31 +0100 Ken Moffat zarniwh...@ntlworld.com wrote: From memory (so, I might be wrong) the book doesn't ever create a 'users' group in LFS... So, I _guess_ that the 'users' group exists on your host system and you will need to create it in LFS to get these tests to work. ĸen You're right. I do have a users group on my host system. But how does that affect the lfs partition? At this stage, we are in a chroot jail, using freshly-built software. Doesn't that mean complete independence from the host except for the running kernel and its virtual file systems? There would have been no previous need for a users group or a daemon user on LFS because acl was not included in the basic system and therefore there were no acl tests to be run. That must still be the case for LFS with sysVinit. But acl is apparently required for systemd, so I think it would make sense for section 6.6 to be different in the systemd edition of the book. I filed a ticket about that. It seems that the bin group membership of the daemon user is not needed. Could you confirm? Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Tue, 22 Apr 2014 13:42:58 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: It seems that the bin group membership of the daemon user is not needed. Could you confirm? Confirmed. It is also not necessary to set real home directories or shells for the bin and daemon users as specified in BLFS. /dev/null and /bin/false work perfectly well for these. Hazel -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 22/04/2014 17:51, Hazel Russman a écrit : On Tue, 22 Apr 2014 13:42:58 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: It seems that the bin group membership of the daemon user is not needed. Could you confirm? Confirmed. It is also not necessary to set real home directories or shells for the bin and daemon users as specified in BLFS. /dev/null and /bin/false work perfectly well for these. Hazel Thanks for checking. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Pierre Labastie wrote: Le 22/04/2014 17:51, Hazel Russman a écrit : On Tue, 22 Apr 2014 13:42:58 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: It seems that the bin group membership of the daemon user is not needed. Could you confirm? Confirmed. It is also not necessary to set real home directories or shells for the bin and daemon users as specified in BLFS. /dev/null and /bin/false work perfectly well for these. Hazel Thanks for checking. Well I did some more checking. daemon does need to be a member of bin to pass all the 'make root-tests', but reall home directories/shells are not required. I'll update the book. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] missing coreutils-8.22-shuf-segfault-1.patch
http://www.linuxfromscratch.org/patches/lfs/development/coreutils-8.22-shuf-segfault-1.patch not found. There's only svn://svn.linuxfromscratch.org/patches/trunk/coreutils/coreutils-8.22-shuf-segfault.patch -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing coreutils-8.22-shuf-segfault-1.patch
On 04/23/2014 05:15 AM, xinglp wrote: http://www.linuxfromscratch.org/patches/lfs/development/coreutils-8.22-shuf-segfault-1.patch not found. There's only svn://svn.linuxfromscratch.org/patches/trunk/coreutils/coreutils-8.22-shuf-segfault.patch Patches get copied when online book is generated and that still wasn't the case since the patch was added. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] missing coreutils-8.22-shuf-segfault-1.patch
2014-04-23 11:39 GMT+08:00 Armin K. kre...@email.com: On 04/23/2014 05:15 AM, xinglp wrote: http://www.linuxfromscratch.org/patches/lfs/development/coreutils-8.22-shuf-segfault-1.patch not found. There's only svn://svn.linuxfromscratch.org/patches/trunk/coreutils/coreutils-8.22-shuf-segfault.patch Patches get copied when online book is generated and that still wasn't the case since the patch was added. I don't care about the online book, there's no such file in the svn $ svn ls svn://svn.linuxfromscratch.org/patches/trunk/coreutils|grep 8.22 coreutils-8.22-i18n-1.patch coreutils-8.22-i18n-2.patch coreutils-8.22-i18n-3.patch coreutils-8.22-i18n-4.patch coreutils-8.22-shuf_segfault.patch -- Note: My last name is not Krejzi. -- 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] missing coreutils-8.22-shuf-segfault-1.patch
xinglp wrote: 2014-04-23 11:39 GMT+08:00 Armin K. kre...@email.com: On 04/23/2014 05:15 AM, xinglp wrote: http://www.linuxfromscratch.org/patches/lfs/development/coreutils-8.22-shuf-segfault-1.patch not found. There's only svn://svn.linuxfromscratch.org/patches/trunk/coreutils/coreutils-8.22-shuf-segfault.patch I don't care about the online book, there's no such file in the svn I fixed it just now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] kmod-17
Linux From Scratch - Version SVN-20140418 Everything fine, including installation of xz, but kmod-17 clearly isn't happy with the layout of the libs for xz. root:/sources/kmod-17# make make --no-print-directory all-recursive Making all in . CC libkmod/libkmod.lo CC libkmod/libkmod-list.lo CC libkmod/libkmod-config.lo CC libkmod/libkmod-index.lo CC libkmod/libkmod-module.lo CC libkmod/libkmod-file.lo CC libkmod/libkmod-elf.lo CC libkmod/libkmod-signature.lo CC libkmod/libkmod-hash.lo CC libkmod/libkmod-array.lo CC libkmod/libkmod-util.lo CCLD libkmod/libkmod-util.la CCLD libkmod/libkmod.la /usr/lib/liblzma.so: file not recognized: Is a directory collect2: error: ld returned 1 exit status Makefile:1211: recipe for target 'libkmod/libkmod.la' failed make[2]: *** [libkmod/libkmod.la] Error 1 Makefile:1803: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 Makefile:1030: recipe for target 'all' failed make: *** [all] Error 2 I've probably done something wrong:( Richard. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] ACL check errors: are they important?
I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. -- *** malformed-restore.test *** 13 commands (13 passed, 0 failed) *** sbits-restore.test *** 17 commands (17 passed, 0 failed) *** utf8-filenames.test *** 7 commands (7 passed, 0 failed) *** setfacl-X.test *** 24 commands (24 passed, 0 failed) *** getfacl-noacl.test *** 22 commands (22 passed, 0 failed) *** getfacl-recursive.test *** 12 commands (12 passed, 0 failed) *** cp.test *** 22 commands (22 passed, 0 failed) *** misc.test *** [91] $ setfacl -m g:users:rw,g:daemon:r f -- failed setfacl: Option -m: Invalid argument near character 3 != ~ [95] $ getfacl --omit-header f -- failed user::rw- == user::rw- user:bin:rw- == user:bin:rw- user:daemon:r-- == user:daemon:r-- group::r--== group::r-- mask::rw- != group:daemon:r-- other::r--!= group:users:rw- != mask::rw- ~ != other::r-- ~ != [108] $ setfacl -x g:users f -- failed setfacl: Option -x: Invalid argument near character 3 != ~ [112] $ getfacl --omit-header f -- failed user::rw- == user::rw- user:bin:rw- == user:bin:rw- user:daemon:r-- == user:daemon:r-- group::r--== group::r-- mask::rw- != group:daemon:r-- other::r--!= mask::rw- != other::r-- ~ != [128] $ getfacl --omit-header f -- failed user::rw- == user::rw- user:bin:rw- == user:bin:rw- group::r--== group::r-- mask::rw- != group:daemon:r-- other::r--!= mask::rw- != other::r-- ~ != [233] $ setfacl -nm u:daemon:rx,d:u:daemon:rx,g:users:rx,g:daemon:rwx d/d -- failed setfacl: Option -m: Invalid argument near character 29 != ~ [237] $ getfacl --omit-header d/d -- failed user::rwx == user::rwx user:bin:rwx #effective:r-x == user:bin:rwx #effective:r-x group::r-x!= user:daemon:r-x mask::r-x != group::r-x other::---!= group:daemon:rwx #effective:r-x default:user::rwx != group:users:r-x default:user:bin:rwx #effective:r-x != mask::r-x default:group::r-x!= other::--- default:mask::r-x != default:user::rwx default:other::---!= default:user:bin:rwx #effective:r-x != default:user:daemon:r-x ~ != default:group::r-x ~ != default:mask::r-x ~ != default:other::--- ~ != [263] $ getfacl --omit-header d/l -- failed user::rwx == user::rwx user:bin:rwx #effective:r-x == user:bin:rwx #effective:r-x group::r-x!= user:daemon:r-x mask::r-x != group::r-x other::---!= group:daemon:rwx #effective:r-x default:user::rwx != group:users:r-x default:user:bin:rwx #effective:r-x != mask::r-x default:group::r-x!= other::--- default:mask::r-x != default:user::rwx default:other::---!= default:user:bin:rwx #effective:r-x != default:user:daemon:r-x ~ != default:group::r-x ~ !=
Re: [lfs-support] kmod-17
Le 21/04/2014 17:50, TheOldFellow a écrit : Linux From Scratch - Version SVN-20140418 Everything fine, including installation of xz, but kmod-17 clearly isn't happy with the layout of the libs for xz. root:/sources/kmod-17# make make --no-print-directory all-recursive Making all in . CC libkmod/libkmod.lo CC libkmod/libkmod-list.lo CC libkmod/libkmod-config.lo CC libkmod/libkmod-index.lo CC libkmod/libkmod-module.lo CC libkmod/libkmod-file.lo CC libkmod/libkmod-elf.lo CC libkmod/libkmod-signature.lo CC libkmod/libkmod-hash.lo CC libkmod/libkmod-array.lo CC libkmod/libkmod-util.lo CCLD libkmod/libkmod-util.la CCLD libkmod/libkmod.la /usr/lib/liblzma.so: file not recognized: Is a directory collect2: error: ld returned 1 exit status Makefile:1211: recipe for target 'libkmod/libkmod.la' failed make[2]: *** [libkmod/libkmod.la] Error 1 Makefile:1803: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 Makefile:1030: recipe for target 'all' failed make: *** [all] Error 2 I've probably done something wrong:( Richard. what does ls -l /usr/lib/lilzma.so return ? (should be a link to ../lib/liblzma.so.xxx, where xxx is the version number). If it is not a link or a link to something which is not a library, you'd better go back to the last line of Xz installation. Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On 04/21/2014 06:13 PM, Hazel Russman wrote: I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. Drop the root-tests, they are broken anyways. I couldn't even get them to run with daemon user present. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Mon, 21 Apr 2014 18:32:49 +0200 Armin K. kre...@email.com wrote: Drop the root-tests, they are broken anyways. I couldn't even get them to run with daemon user present. I didn't do the root tests. These were the standard ones invoked with make tests though of course I was logged in as root when I did them. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] kmod-17
Pierre Labastie wrote: Le 21/04/2014 17:50, TheOldFellow a écrit : Linux From Scratch - Version SVN-20140418 Everything fine, including installation of xz, but kmod-17 clearly isn't happy with the layout of the libs for xz. root:/sources/kmod-17# make make --no-print-directory all-recursive Making all in . CC libkmod/libkmod.lo CC libkmod/libkmod-list.lo CC libkmod/libkmod-config.lo CC libkmod/libkmod-index.lo CC libkmod/libkmod-module.lo CC libkmod/libkmod-file.lo CC libkmod/libkmod-elf.lo CC libkmod/libkmod-signature.lo CC libkmod/libkmod-hash.lo CC libkmod/libkmod-array.lo CC libkmod/libkmod-util.lo CCLD libkmod/libkmod-util.la CCLD libkmod/libkmod.la /usr/lib/liblzma.so: file not recognized: Is a directory collect2: error: ld returned 1 exit status Makefile:1211: recipe for target 'libkmod/libkmod.la' failed make[2]: *** [libkmod/libkmod.la] Error 1 Makefile:1803: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 Makefile:1030: recipe for target 'all' failed make: *** [all] Error 2 I've probably done something wrong:( Richard. what does ls -l /usr/lib/lilzma.so return ? (should be a link to ../lib/liblzma.so.xxx, where xxx is the version number). If it is not a link or a link to something which is not a library, you'd better go back to the last line of Xz installation. Regards Pierre Indeed this is where the problem lies. ls -l /usr/lib/liblzma.so lrwxrwxrwx 1 root root 10 Apr 21 16:19 /usr/lib/liblzma.so - ../../lib/ However the real problem is in the last line of the xz installation, as you rightly say, because: $(readlink /usr/lib/liblzma.so) returns ../../lib/ but it is bash-script that is beyond me. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 21/04/2014 18:13, Hazel Russman a écrit : I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. You do not say that you have mounted your filesystem with acl and user_xattr. Those options must be specified when mounting the lfs partition, possibly in the fstab... Distributions usually do not do that by default. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 21/04/2014 18:13, Hazel Russman a écrit : I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 21/04/2014 19:25, Pierre Labastie a écrit : Le 21/04/2014 18:13, Hazel Russman a écrit : I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre s@/etc:group@/etc/group@ sorry. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] kmod-17
Le 21/04/2014 19:01, TheOldFellow a écrit : Pierre Indeed this is where the problem lies. ls -l /usr/lib/liblzma.so lrwxrwxrwx 1 root root 10 Apr 21 16:19 /usr/lib/liblzma.so - ../../lib/ However the real problem is in the last line of the xz installation, as you rightly say, because: $(readlink /usr/lib/liblzma.so) returns ../../lib/ but it is bash-script that is beyond me. Yes If the link is wrong, readlink returne a wrong link. Sometimes computers are coherent... With Xz-5.0.5, the link should be to ../../lib/liblzma.so.5.0.5 Creating it should save you an xz reinstall. I do not know whether the packages between Xz and kmod should be recompiled, though. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Mon, 21 Apr 2014 19:25:10 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre Thank you very much. That was the source of the problem. Adding the users group cleared all the remaining errors. But I notice that this group, like the daemon user, are not specified in section 6.6 where /etc/passwd and /etc/group are created. Should they be? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Mon, Apr 21, 2014 at 06:36:19PM +0100, Hazel Russman wrote: On Mon, 21 Apr 2014 19:25:10 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre Thank you very much. That was the source of the problem. Adding the users group cleared all the remaining errors. But I notice that this group, like the daemon user, are not specified in section 6.6 where /etc/passwd and /etc/group are created. Should they be? From memory (so, I might be wrong) the book doesn't ever create a 'users' group in LFS. What we as individuals have to do may differ. I came here via RedHat-6 and Mandrake-7 and shared /home between the systems I was running at the time. So /home/ken is owned by user 500 and group 1000 : I create ken as user 500 and add a users group of 1000 whenever I build a new system. When I was using ppc I had a user/group combination from debian-based systems - the numbers were quite different. So, I _guess_ that the 'users' group exists on your host system and you will need to create it in LFS to get these tests to work. ĸ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
[lfs-support] LFS 7.5 - Ch. 6.37 - Inetutils check.
Happy EASTER ! Just a small note that the check will fail on the ping localhost test if IPv6 is not configured on the base system. This shouldn't actually be a FAIL but a WARNING. But I guess that's for the maintainer to change :) Regards, D. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] LFS as a Xen DomU ?
Hi List I’ve built an LFS 7.5 image, which I’m able to boot using QEMU. I’d like to convert this to a Xen compatible system I could use to launch a DomU on Xen 4.1. Has anyone on the list managed to run an LFS 7.5 image as a DomU on Xen? If, so, how? Thanks in advance, Traiano -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] error when trying to cross compile glibc-2.19
One update is that step 5 when building glibc, the compilation fails due to errno.h rpc_main.c:37:19: fatal error: errno.h: No such file or directory #include errno.h Hi Thanks all for the replays. I am trying to create a cross compiler using the steps for building LFS when the temporary tools are build. Those steps should allow me to use the cross compiler, but obviously i am not doing something correctly. I just used the path from cross-tools package 0.43 but not using anything from there. One reason for which i am trying to create the cross compiler, is that i saw you build for LFS gcc 4.8.2 and glibc-2.19, which are not supported anymore by that tool or others. This are the steps is used. I didnt created a lfs user, but if you think thats the cause of the problem i can create it and try that way as well. The host is x86_64 with kernel 3.7.10 I have a symlink between: ls -ld /tools lrwxrwxrwx 1 root root 47 Apr 17 08:08 /tools - /home/marian/crosstool/x86_64-unknown-linux-gnu/ export PREFIX=/home/marian/crosstool/x86_64-unknown-linux-gnu export TARGET=x86_64-unknown-linux-gnu export SYSROOT=/home/marian/crosstool/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root export PATH=/tools/bin:/bin:/usr/bin 1. Binutils ../binutils-2.24/configure --prefix=/tools --with-sysroot=$SYSROOT --with-lib-path=/tools/lib --target=$TARGET --disable-nls --disable-werror binutils compiles fine. no errors. 2. Kernel headers make headers_check make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /tools/include 3. From some other docs i saw they install the glibc headers as well here. I have tried this, but the same error is happening when building gcc or glibc. System glibc headers mkdir glibc-build cd glibc-build ../glibc-2.19/configure --prefix=/tools --host=$TARGET --build=$(../glibc-2.19/scripts/config.guess) --disable-profile --enable-kernel=2.6.32 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes --without-selinux make -k install-headers install_root=/ 4. GCC stage 1 ../gcc-4.8.2/configure --target=$TARGET --prefix=/tools --with-sysroot=$SYSROOT --with-newlib --without-headers --with-local-prefix=/tools --with-native-system-header-dir=/tools/include --disable-nls --disable-shared --disable-multilib --disable-decimal-float --disable-threads --disable-libatomic --disable-libgomp --disable-libitm --disable-libmudflap --disable-libquadmath --disable-libsanitizer --disable-libssp --disable-libstdc++-v3 --enable-languages=c,c++ --with-mpfr-include=$(pwd)/../gcc-4.8.2/mpfr/src --with-mpfr-lib=$(pwd)/mpfr/src/.libs Here if i use make, i get the same error, that compiler can not create executables. From config log, the error is that cross gcc is not able to find a couple of libs (which seems generated by glibc) crt1.o, crti.o, crtn.o and libc.so Thus from other docs i have seen these being used, so i have tried to continue using them: make all-gcc make all-target-libgcc make install-gcc make install-target-libgcc 5. building glibc fails building in sunrpc folder, for some rpc_* files, with the same same error, saying that those libs can not be found. ../glibc-2.19/configure --prefix=/tools --host=$TARGET --build=$(../glibc-2.19/scripts/config.guess) --disable-profile --enable-kernel=2.6.32 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes --without-selinux -- 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] error when trying to cross compile glibc-2.19
This is the gcc compile error
configure:8604: checking whether the C compiler works
configure:8626:
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/build-gcc/./prev-gcc/xgcc
-B/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/build-gcc/./prev-gcc/
-B/tools/x86_64-unknown-linux-gnu/bin/
-B/tools/x86_64-unknown-linux-gnu/bin/
-B/tools/x86_64-unknown-linux-gnu/lib/ -isystem
/tools/x86_64-unknown-linux-gnu/include -isystem
/tools/x86_64-unknown-linux-gnu/sys-include-g -O2 -gtoggle
-static-libstdc++ -static-libgcc conftest.c 5
/tools/x86_64-unknown-linux-gnu/bin/ld: cannot find crt1.o: No such file
or directory
/tools/x86_64-unknown-linux-gnu/bin/ld: cannot find crti.o: No such file
or directory
/tools/x86_64-unknown-linux-gnu/bin/ld: cannot find -lc
/tools/x86_64-unknown-linux-gnu/bin/ld: cannot find crtn.o: No such file
or directory
collect2: error: ld returned 1 exit status
configure:8630: $? = 1
configure:8668: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU MP
| #define PACKAGE_TARNAME gmp
| #define PACKAGE_VERSION 5.1.3
| #define PACKAGE_STRING GNU MP 5.1.3
| #define PACKAGE_BUGREPORT gmp-b...@gmplib.org, see
http://gmplib.org/manual/Reporting-Bugs.html;
| #define PACKAGE_URL http://www.gnu.org/software/gmp/;
| #define PACKAGE gmp
| #define VERSION 5.1.3
| #define WANT_ASSEMBLY 1
| #define WANT_FFT 1
| #define HAVE_HOST_CPU_none 1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:8673: error: in
`/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/build-gcc/gmp':
configure:8675: error: C compiler cannot create executables
See `config.log' for more details
One update is that step 5 when building glibc, the compilation fails due
to errno.h
rpc_main.c:37:19: fatal error: errno.h: No such file or directory
#include errno.h
Hi
Thanks all for the replays.
I am trying to create a cross compiler using the steps for building LFS
when the temporary tools are build.
Those steps should allow me to use the cross compiler, but obviously
i am not doing something correctly.
I just used the path from cross-tools package 0.43
but not using anything from there. One reason for which i am trying
to create the cross compiler, is that i saw you build for LFS gcc 4.8.2
and glibc-2.19, which are not supported anymore by that tool or others.
This are the steps is used. I didnt created a lfs user,
but if you think thats the cause of the problem i can create it and try
that way as well. The host is x86_64 with kernel 3.7.10
I have a symlink between:
ls -ld /tools
lrwxrwxrwx 1 root root 47 Apr 17 08:08 /tools -
/home/marian/crosstool/x86_64-unknown-linux-gnu/
export PREFIX=/home/marian/crosstool/x86_64-unknown-linux-gnu
export TARGET=x86_64-unknown-linux-gnu
export
SYSROOT=/home/marian/crosstool/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root
export PATH=/tools/bin:/bin:/usr/bin
1. Binutils
../binutils-2.24/configure --prefix=/tools --with-sysroot=$SYSROOT
--with-lib-path=/tools/lib --target=$TARGET --disable-nls
--disable-werror
binutils compiles fine. no errors.
2. Kernel headers
make headers_check
make INSTALL_HDR_PATH=dest headers_install
cp -rv dest/include/* /tools/include
3. From some other docs i saw they install the glibc headers as well
here.
I have tried this, but the same error is happening when building gcc or
glibc.
System glibc headers
mkdir glibc-build
cd glibc-build
../glibc-2.19/configure --prefix=/tools --host=$TARGET
--build=$(../glibc-2.19/scripts/config.guess) --disable-profile
--enable-kernel=2.6.32 --with-headers=/tools/include
libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes
--without-selinux
make -k install-headers install_root=/
4. GCC stage 1
../gcc-4.8.2/configure --target=$TARGET --prefix=/tools
--with-sysroot=$SYSROOT --with-newlib --without-headers
--with-local-prefix=/tools
--with-native-system-header-dir=/tools/include --disable-nls
--disable-shared --disable-multilib --disable-decimal-float
--disable-threads --disable-libatomic --disable-libgomp
--disable-libitm
--disable-libmudflap --disable-libquadmath --disable-libsanitizer
--disable-libssp --disable-libstdc++-v3 --enable-languages=c,c++
--with-mpfr-include=$(pwd)/../gcc-4.8.2/mpfr/src
--with-mpfr-lib=$(pwd)/mpfr/src/.libs
Here if i use make, i get the same error, that compiler can not
create
executables. From config log, the error is that cross gcc is not able
to find a couple of libs (which seems generated by glibc) crt1.o,
crti.o,
crtn.o and libc.so
Thus from other docs i have seen these being used, so i have tried to
continue using them:
make all-gcc
make all-target-libgcc
make install-gcc
make install-target-libgcc
5. building glibc fails building in sunrpc folder,
for some rpc_* files, with the same same error, saying that those libs
can
Re: [lfs-support] error when trying to cross compile glibc-2.19
On 19.4.2014 7:42, mar...@byteanywhere.com wrote: Hi Thanks all for the replays. I am trying to create a cross compiler using the steps for building LFS when the temporary tools are build. Those steps should allow me to use the cross compiler, but obviously i am not doing something correctly. I just used the path from cross-tools package 0.43 but not using anything from there. One reason for which i am trying to create the cross compiler, is that i saw you build for LFS gcc 4.8.2 and glibc-2.19, which are not supported anymore by that tool or others. This are the steps is used. I didnt created a lfs user, but if you think thats the cause of the problem i can create it and try that way as well. The host is x86_64 with kernel 3.7.10 I have a symlink between: ls -ld /tools lrwxrwxrwx 1 root root 47 Apr 17 08:08 /tools - /home/marian/crosstool/x86_64-unknown-linux-gnu/ export PREFIX=/home/marian/crosstool/x86_64-unknown-linux-gnu export TARGET=x86_64-unknown-linux-gnu The trick is in this line. To cross compile glibc for the same arch, target triplet needs to be different or you are nothing other but simply compiling. I ran into similar issue when I bootstrapped 32 bit glibc on 64 bit os. That's one reason lfs uses $LFS_TGT-*lfs*-linux-gnu, not $LFS_TGT-*unknown*-linux-gnu for pass1 of both binutils and gcc. export SYSROOT=/home/marian/crosstool/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root export PATH=/tools/bin:/bin:/usr/bin 1. Binutils ../binutils-2.24/configure --prefix=/tools --with-sysroot=$SYSROOT --with-lib-path=/tools/lib --target=$TARGET --disable-nls --disable-werror binutils compiles fine. no errors. 2. Kernel headers make headers_check make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /tools/include 3. From some other docs i saw they install the glibc headers as well here. I have tried this, but the same error is happening when building gcc or glibc. System glibc headers mkdir glibc-build cd glibc-build ../glibc-2.19/configure --prefix=/tools --host=$TARGET --build=$(../glibc-2.19/scripts/config.guess) --disable-profile --enable-kernel=2.6.32 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes --without-selinux make -k install-headers install_root=/ 4. GCC stage 1 ../gcc-4.8.2/configure --target=$TARGET --prefix=/tools --with-sysroot=$SYSROOT --with-newlib --without-headers --with-local-prefix=/tools --with-native-system-header-dir=/tools/include --disable-nls --disable-shared --disable-multilib --disable-decimal-float --disable-threads --disable-libatomic --disable-libgomp --disable-libitm --disable-libmudflap --disable-libquadmath --disable-libsanitizer --disable-libssp --disable-libstdc++-v3 --enable-languages=c,c++ --with-mpfr-include=$(pwd)/../gcc-4.8.2/mpfr/src --with-mpfr-lib=$(pwd)/mpfr/src/.libs Here if i use make, i get the same error, that compiler can not create executables. From config log, the error is that cross gcc is not able to find a couple of libs (which seems generated by glibc) crt1.o, crti.o, crtn.o and libc.so Thus from other docs i have seen these being used, so i have tried to continue using them: make all-gcc make all-target-libgcc make install-gcc make install-target-libgcc 5. building glibc fails building in sunrpc folder, for some rpc_* files, with the same same error, saying that those libs can not be found. ../glibc-2.19/configure --prefix=/tools --host=$TARGET --build=$(../glibc-2.19/scripts/config.guess) --disable-profile --enable-kernel=2.6.32 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes --without-selinux -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] error when trying to cross compile glibc-2.19
Le 19/04/2014 07:42, mar...@byteanywhere.com a écrit : I have a symlink between: ls -ld /tools lrwxrwxrwx 1 root root 47 Apr 17 08:08 /tools - /home/marian/crosstool/x86_64-unknown-linux-gnu/ export PREFIX=/home/marian/crosstool/x86_64-unknown-linux-gnu export TARGET=x86_64-unknown-linux-gnu export SYSROOT=/home/marian/crosstool/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root export PATH=/tools/bin:/bin:/usr/bin I think there are at least 2 problems in the above: 1) TARGET=x86_64-unknown-linux-gnu: you have not told what your host is, but I assume it is a 64 bit PC running linux. In this case, the host is already x86_64-unknown-linux-gnu, so the build systems of binutils and gcc do not understand that you want to create a cross compiler. As explained in LFS page 5.2, you need to slightly deviate from that by changing the vendor name from unknown to something else. Of course, if your host is not a 64 bit PC, the preceding does not apply. 2) SYSROOT=/home/marian/crosstool/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root SYSROOT is the _root_ of the new system disk image, where the linker will look for the target libraries. Using --with-sysroot=$SYSROOT --with-lib-path=/tools/lib below means that the linker will look into $SYSROOT/tools/lib for target libraries. Clearly, those directories do not exist. What I would recommend is to use the LFS section 4.4 setup. If you do not want to do that, you should at least have: PREFIX=/whatever/tools SYSROOT=/whatever ln -s /whatever/tools / 1. Binutils ../binutils-2.24/configure --prefix=/tools --with-sysroot=$SYSROOT --with-lib-path=/tools/lib --target=$TARGET --disable-nls --disable-werror binutils compiles fine. no errors. 2. Kernel headers make headers_check make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /tools/include 3. From some other docs i saw they install the glibc headers as well here. I have tried this, but the same error is happening when building gcc or glibc. System glibc headers mkdir glibc-build cd glibc-build ../glibc-2.19/configure --prefix=/tools --host=$TARGET --build=$(../glibc-2.19/scripts/config.guess) --disable-profile --enable-kernel=2.6.32 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes --without-selinux make -k install-headers install_root=/ That's a very bad idea, you have overwritten your host headers, unless you did not run this command as user root, in which case you have done nothing... You should have seen errors, though. This step is not needed anyway. 4. GCC stage 1 ../gcc-4.8.2/configure --target=$TARGET --prefix=/tools --with-sysroot=$SYSROOT --with-newlib --without-headers --with-local-prefix=/tools --with-native-system-header-dir=/tools/include --disable-nls --disable-shared --disable-multilib --disable-decimal-float --disable-threads --disable-libatomic --disable-libgomp --disable-libitm --disable-libmudflap --disable-libquadmath --disable-libsanitizer --disable-libssp --disable-libstdc++-v3 --enable-languages=c,c++ --with-mpfr-include=$(pwd)/../gcc-4.8.2/mpfr/src --with-mpfr-lib=$(pwd)/mpfr/src/.libs Did you run the for file in [...] done part? Here if i use make, i get the same error, that compiler can not create executables. From config log, the error is that cross gcc is not able to find a couple of libs (which seems generated by glibc) crt1.o, crti.o, crtn.o and libc.so Those are not found by the linker because it looks for them in $SYSROOT/tools/lib/somepath, which does not exist. Also, the compiler thinks it is a native compiler if the TARGET is not different from the host, and the algorithm to find the files is different. Thus from other docs i have seen these being used, so i have tried to continue using them: make all-gcc make all-target-libgcc make install-gcc make install-target-libgcc You should be able to run just make. 5. building glibc fails building in sunrpc folder, for some rpc_* files, with the same same error, saying that those libs can not be found. See what happens when you correct the errors above (TARGET and SYSROOT, I think). Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] error when trying to cross compile glibc-2.19
On Apr 19, 2014, at 12:42 AM, mar...@byteanywhere.com wrote: Thanks all for the replays. I am trying to create a cross compiler using the steps for building LFS when the temporary tools are build. I suggest you look at how we do that in CLFS at http://cross-lfs.org/view/git/index.html or our current http://cross-lfs.org/~kb0iic/CLFS-GIT-SYSTEMD/html/index.html Those will provide you a better understanding of what you may be doing wrong. One critical step is changing your target triplet so the tools know that it is cross compiling. Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] LFS 7.5 - Chapter 6 - glibc patch
Heya, the patch for glibc in Chapter 6 is missing in the tar package as well as in the download links. Had to download it through the book, Chapter 3. Regards, Daniel -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.5 - Chapter 6 - glibc patch
loki wrote: the patch for glibc in Chapter 6 is missing in the tar package as well as in the download links. I see that it is missing in the tarball, but which download link are you referring to? It does appear to be missing from the 7.5 md5sums and wget-list files also. I'll fix that later today. -- 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] LFS 7.5 - Chapter 6 - glibc patch
On Sat, 2014-04-19 at 15:41 -0500, Bruce Dubbs wrote: loki wrote: the patch for glibc in Chapter 6 is missing in the tar package as well as in the download links. I see that it is missing in the tarball, but which download link are you referring to? It does appear to be missing from the 7.5 md5sums and wget-list files also. I'll fix that later today. -- Bruce http://www.linuxfromscratch.org/lfs/download.html And then for instance: http://ftp.lfs-matrix.net/pub/lfs/lfs-packages/7.5/ http://ftp.osuosl.org/pub/lfs/lfs-packages/7.5/ Those are the 2 I tried.. Regards, D. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.5 - Chapter 6 - glibc patch
loki wrote: On Sat, 2014-04-19 at 15:41 -0500, Bruce Dubbs wrote: loki wrote: the patch for glibc in Chapter 6 is missing in the tar package as well as in the download links. I see that it is missing in the tarball, but which download link are you referring to? It does appear to be missing from the 7.5 md5sums and wget-list files also. I'll fix that later today. -- Bruce http://www.linuxfromscratch.org/lfs/download.html And then for instance: http://ftp.lfs-matrix.net/pub/lfs/lfs-packages/7.5/ http://ftp.osuosl.org/pub/lfs/lfs-packages/7.5/ Yes, those are both mirrors so they should be the same. I'll get it fixed up. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] binutils 2.24 Pass-2 (Section 5.9 version 7.5)
Discovered the variable CC was set incorrectly for my second pass binutils build. I assume I can simply re-execute the build with the correct setting(s) or are there things I should physically delete 1st? And if just a re-build is OK, is this true in general? My mistake was keying the TGT part of the $LFS_TGT variable in lower case. -- Jim -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] binutils 2.24 Pass-2 (Section 5.9 version 7.5)
Mcgroder, James wrote: Discovered the variable CC was set incorrectly for my second pass binutils build. I assume I can simply re-execute the build with the correct setting(s) or are there things I should physically delete 1st? And if just a re-build is OK, is this true in general? My mistake was keying the TGT part of the $LFS_TGT variable in lower case. As early as you are in Chapter 5, I'd recommend restarting that chapter. Be sure to delete any build/extracted directories and re-extract from the tarballs. -- 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] binutils 2.24 Pass-2 (Section 5.9 version 7.5)
Mcgroder, James wrote: Discovered the variable CC was set incorrectly for my second pass binutils build can I simply re-execute the build with the correct setting(s)? Bruce Dubbs wrote: As early as you are in Chapter 5, I'd recommend restarting that chapter. Be sure to delete any build/extracted directories and re-extract from the tarballs. Thanks Bruce - will do. Also, appreciate the advice on deleting and re-extracting the tar balls... was thinking I could have left them sit from pass-1. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] error when trying to cross compile glibc-2.19
Hi, I am getting the following error trying to build LFS 5.7 x86_64-unknown-linux-gnu-gcc -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE -DIS_IN_build -include /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/config.h rpc_main.c \ -o /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o -MMD -MP -MF /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o.dt -MT /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o -c rpc_main.c:37:19: fatal error: errno.h: No such file or directory #include errno.h ^ compilation terminated. I configured : ../glibc-2.19/configure --prefix=/tools --host=$TARGET --build=$(../glibc-2.19/scripts/config.guess) --disable-profile --enable-kernel=3.7.10 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes --without-selinux I am running on linux 3.7.10. I am not sure how to get this working. I build gcc using: make all-gcc make all-target-libgcc make install-gcc make install-target-libgcc because otherwise if i use make, i also get error saying that the compiler can not create executables. Thanks, Marian -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] error when trying to cross compile glibc-2.19
On Fri, Apr 18, 2014 at 10:37:48PM +0300, mar...@byteanywhere.com wrote:
Hi,
I am getting the following error trying to build LFS 5.7
For anybody confused by '5.7', that is section 5.7 not the LFS
version ;-) With glibc-2.19 you are either using LFS-7.5 or a
recent version of the development book.
x86_64-unknown-linux-gnu-gcc -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE
-DIS_IN_build -include
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/config.h
rpc_main.c \
When I see a version of crosstool in the directory name, together
with your heading about cross-compiling, I think that I don't know
what you are doing! The LFS book is written for people building in
/mnt/lfs, with a symlink from /tools to /mnt/lfs/tools.
There is no requirement that /mnt/lfs needs to be a separate
filesystem, but you do need to be able to access it as /mnt/lfs -
from time to tiem I do test builds using a directory which I have
bound to /mnt/lfs. Perhaps you are doing the same, but referencing
crosstool implies you may well be doing something very different.
In particular, you probably have not followed section 4.3 - we tell
people to log in as the lfs user. Or perhaps the lfs user does have
write access in /home/marian - some potential to overwrite your own
files.
-o
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o
-MMD -MP -MF
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o.dt
-MT
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o
-c
rpc_main.c:37:19: fatal error: errno.h: No such file or directory
#include errno.h
^
compilation terminated.
If you are indeed following the book, I think that perhaps you
didn't install the kernel headers. There are _variants_ of errno.h
in those. But I think this is probably a crosstool issue : glibc
itself provides errno.h, so at this point in the process I guess it
comes from the host system. Or alternatively, it should be coming
from the glibc you are building - in that case, either your disk is
full or the extracted source appears to be incomplete.
It would definitely help if you can explain what you are trying to
do.
I configured :
../glibc-2.19/configure --prefix=/tools --host=$TARGET
--build=$(../glibc-2.19/scripts/config.guess) --disable-profile
--enable-kernel=3.7.10 --with-headers=/tools/include
libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes
--without-selinux
I am running on linux 3.7.10. I am not sure how to get this working.
I build gcc using:
make all-gcc
make all-target-libgcc
make install-gcc
make install-target-libgcc
Yes, you are doing something different from the book - we are able
to build pass-1 gcc using just make and make install.
because otherwise if i use make, i also get error saying that the
compiler can not create executables.
Thanks,
Marian
We don't support real cross-compilation, if that is what you are
trying to do. If your host system is x86_64-unknown-linux-gnu then
you should be able to build LFS for x86_64.
But one of the things you need to learn, even if you are not
following the book, is how to debug the C compiler cannot create
executables message. It's actually quite easy - in both gcc and
binutils, configure is run in several directories. As it runs,
it creates output in config.log in that directory, then moves on
to the next directory and does the same thing - until it fails.
So, to debug the gcc build problem (and your solution suggests that
you are really cross-compiling), you need to find the newest
config.log (or log configure's stdout and stderr and work out which
directory it was in by reading the log). Then open up that
config.log in e.g. vim ('view' for safety, I suppose) or else in
'less'. Search for the message:
/C\ compiler\ cannot
('/' to search in vim or less, '\ ' to escape the spaces so that
they are treated as part of the text to search for.)
When you find that error message, look at the lines above it
(probably a few screens worth, say 50 to 100 lines). You should see
a message about what is being tested, a program fragment getting
created, and then it is fed to the compiler to see if it will
compile. Throughout any config.log you will see many error messages,
typically because your system does not support a particular feature,
or does not have a specific file. That is normal, but here you have
a real error.
Sometimes, a missing header might trigger it - that seems unlikely
for this particular error, particularly since you compiled pass 1
binutils just before gcc. Perhaps there was a typo in $LFS_TGT when
you built binutils. Usually, either gcc or ld is objecting to
something in the compile, or occasionally there is a problem with
ld. Either way, you will see the error message in config.log, a few
lines above C
Re: [lfs-support] error when trying to cross compile glibc-2.19
On Apr 18, 2014, at 2:37 PM, mar...@byteanywhere.com wrote: /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/ glibc-build/sunrpc/cross-rpc_main.o -MMD -MP -MF /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/ glibc-build/sunrpc/cross-rpc_main.o.dt -MT /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/ glibc-build/sunrpc/cross-rpc_main.o This is from kegel's cross-tools package 0.43 http://kegel.com/crosstool/ It's old, ancient, and newer tools cross compile much better, plus, LFS doesn't use cross-tools. What are you doing? Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] error when trying to cross compile glibc-2.19
Hi Thanks all for the replays. I am trying to create a cross compiler using the steps for building LFS when the temporary tools are build. Those steps should allow me to use the cross compiler, but obviously i am not doing something correctly. I just used the path from cross-tools package 0.43 but not using anything from there. One reason for which i am trying to create the cross compiler, is that i saw you build for LFS gcc 4.8.2 and glibc-2.19, which are not supported anymore by that tool or others. This are the steps is used. I didnt created a lfs user, but if you think thats the cause of the problem i can create it and try that way as well. The host is x86_64 with kernel 3.7.10 I have a symlink between: ls -ld /tools lrwxrwxrwx 1 root root 47 Apr 17 08:08 /tools - /home/marian/crosstool/x86_64-unknown-linux-gnu/ export PREFIX=/home/marian/crosstool/x86_64-unknown-linux-gnu export TARGET=x86_64-unknown-linux-gnu export SYSROOT=/home/marian/crosstool/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root export PATH=/tools/bin:/bin:/usr/bin 1. Binutils ../binutils-2.24/configure --prefix=/tools --with-sysroot=$SYSROOT --with-lib-path=/tools/lib --target=$TARGET --disable-nls --disable-werror binutils compiles fine. no errors. 2. Kernel headers make headers_check make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /tools/include 3. From some other docs i saw they install the glibc headers as well here. I have tried this, but the same error is happening when building gcc or glibc. System glibc headers mkdir glibc-build cd glibc-build ../glibc-2.19/configure --prefix=/tools --host=$TARGET --build=$(../glibc-2.19/scripts/config.guess) --disable-profile --enable-kernel=2.6.32 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes --without-selinux make -k install-headers install_root=/ 4. GCC stage 1 ../gcc-4.8.2/configure --target=$TARGET --prefix=/tools --with-sysroot=$SYSROOT --with-newlib --without-headers --with-local-prefix=/tools --with-native-system-header-dir=/tools/include --disable-nls --disable-shared --disable-multilib --disable-decimal-float --disable-threads --disable-libatomic --disable-libgomp --disable-libitm --disable-libmudflap --disable-libquadmath --disable-libsanitizer --disable-libssp --disable-libstdc++-v3 --enable-languages=c,c++ --with-mpfr-include=$(pwd)/../gcc-4.8.2/mpfr/src --with-mpfr-lib=$(pwd)/mpfr/src/.libs Here if i use make, i get the same error, that compiler can not create executables. From config log, the error is that cross gcc is not able to find a couple of libs (which seems generated by glibc) crt1.o, crti.o, crtn.o and libc.so Thus from other docs i have seen these being used, so i have tried to continue using them: make all-gcc make all-target-libgcc make install-gcc make install-target-libgcc 5. building glibc fails building in sunrpc folder, for some rpc_* files, with the same same error, saying that those libs can not be found. ../glibc-2.19/configure --prefix=/tools --host=$TARGET --build=$(../glibc-2.19/scripts/config.guess) --disable-profile --enable-kernel=2.6.32 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes --without-selinux -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] OpenSSL Heartbleed-bug
Hey all, unfortunatly you can't find much heartbleed bug info on the net for administrators. So I will try my luck here. I have some https websites and a openvpn server. My questions are: 1.) Is it enough for me to recompile only OpenSSL or do I have to recompile OpenSSH, apache, OpenVPN? 2.) Do I have to recreate the selfsigned certs for WWW even if I don't use any passwords for the private key? (After I update OpenSSL) 3.) Do I have to recreate the keys used for the users of OpenVPN? (After I update OpenSSL) Thanks in advance, L -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] OpenSSL Heartbleed-bug
Em 15-04-2014 14:06, loki escreveu: Hey all, unfortunatly you can't find much heartbleed bug info on the net for administrators. So I will try my luck here. I have some https websites and a openvpn server. My questions are: 1.) Is it enough for me to recompile only OpenSSL or do I have to recompile OpenSSH, apache, OpenVPN? 2.) Do I have to recreate the selfsigned certs for WWW even if I don't use any passwords for the private key? (After I update OpenSSL) 3.) Do I have to recreate the keys used for the users of OpenVPN? (After I update OpenSSL) Thanks in advance, L Not sure, but one site seemed good for me: http://heartbleed.com/ IIRC, they discuss that you need to recreate. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] OpenSSL Heartbleed-bug
On Tue, 15 Apr 2014 19:06:14 +0200 loki l...@pancevo.rs wrote: 1.) Is it enough for me to recompile only OpenSSL or do I have to recompile OpenSSH, apache, OpenVPN? I have not yet looked at the patch that fixes CVE-2014-0160, but I imagine that you do not need to recompile anything that dynamically linkes to OpenSSL. Anything that links statically should be recompiled. How to tell? Well, you compiled it, you ought to know what went into it. :) In principle, you can run ldd on the executable in question and see if /whatever/libssl.so.* comes up in the list. If so, OpenSSL is linked in dynamically. 2.) Do I have to recreate the selfsigned certs for WWW even if I don't use any passwords for the private key? (After I update OpenSSL) Not if (1) it has not been compromised and (2) you don't care about it being compromised. In practice, you almost certainly care about it being compromised and, due to the fact the private key was in the same address space that is exposed by CVE-2014-0160, your private key was almost certainly leaked to anyone who bothered to look. 3.) Do I have to recreate the keys used for the users of OpenVPN? (After I update OpenSSL) If they were not loaded into the servers address space (and they probably weren't), no. Note that all the above answers apply anytime an attacker has read access to the servers address space. There is nothing special about the so-called heartbleed bug that makes it different than so many other information leak bugs. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] OpenSSL Heartbleed-bug
CORRECTION!! On Tue, 15 Apr 2014 20:06:03 +0200 Aleksandar Kuktin akuk...@gmail.com wrote: On Tue, 15 Apr 2014 19:06:14 +0200 loki l...@pancevo.rs wrote: 3.) Do I have to recreate the keys used for the users of OpenVPN? (After I update OpenSSL) If they were not loaded into the servers address space (and they probably weren't), no. CVE-2014-0160 also affects clients. Therefore, you also have to regenerate and redistribute user keys. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] If only use systemd, which packages can be skipped in chapter06
sysvinit, sysklogd, something else? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
On 04/06/2014 09:09 PM, Bruce Dubbs wrote: baho utot wrote: On 04/06/2014 08:33 PM, William Harrington wrote: On Apr 6, 2014, at 7:20 PM, baho utot wrote: the configure should be: ./configure --disable-nologin as nologin was previously installed by shadow Does util-linux nologin binary overwrite shadow's? If so, that is desired because util-linux ships a better nologin binary. I am using rpm package manager. It causes a conflict when a file is already installed by another package. You then have to remove one of them from one of the packages. Coreutils will also overwrite groups program because it is better than shadow's groups binary. There isn't a groups executeable installed by shadow. Yes, we do disable that. Then why not disable nologin in shadow as well? Why over write only one of them? Rather, shadow, if not wanting to install groups or nologin installed, could edit Makefile.in to exclude those. On my builds I just rm the duplicate file from one of the packages before it is packaged up by rpm so I don't have to edit any of the Makefiles. For the book the later package will over write the earlier package, and you will not know the over write has occurred. That seems like the correct behavior to me. -- Bruce but not consistent as above -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
baho utot wrote: On 04/06/2014 09:09 PM, Bruce Dubbs wrote: baho utot wrote: On 04/06/2014 08:33 PM, William Harrington wrote: On Apr 6, 2014, at 7:20 PM, baho utot wrote: the configure should be: ./configure --disable-nologin as nologin was previously installed by shadow Does util-linux nologin binary overwrite shadow's? If so, that is desired because util-linux ships a better nologin binary. I am using rpm package manager. It causes a conflict when a file is already installed by another package. You then have to remove one of them from one of the packages. Coreutils will also overwrite groups program because it is better than shadow's groups binary. There isn't a groups executeable installed by shadow. Yes, we do disable that. Then why not disable nologin in shadow as well? Why over write only one of them? Rather, shadow, if not wanting to install groups or nologin installed, could edit Makefile.in to exclude those. On my builds I just rm the duplicate file from one of the packages before it is packaged up by rpm so I don't have to edit any of the Makefiles. For the book the later package will over write the earlier package, and you will not know the over write has occurred. That seems like the correct behavior to me. but not consistent as above Do you want to submit a 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] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
On 04/07/2014 08:03 AM, Bruce Dubbs wrote: baho utot wrote: On 04/06/2014 09:09 PM, Bruce Dubbs wrote: baho utot wrote: On 04/06/2014 08:33 PM, William Harrington wrote: On Apr 6, 2014, at 7:20 PM, baho utot wrote: the configure should be: ./configure --disable-nologin as nologin was previously installed by shadow Does util-linux nologin binary overwrite shadow's? If so, that is desired because util-linux ships a better nologin binary. I am using rpm package manager. It causes a conflict when a file is already installed by another package. You then have to remove one of them from one of the packages. Coreutils will also overwrite groups program because it is better than shadow's groups binary. There isn't a groups executeable installed by shadow. Yes, we do disable that. Then why not disable nologin in shadow as well? Why over write only one of them? Rather, shadow, if not wanting to install groups or nologin installed, could edit Makefile.in to exclude those. On my builds I just rm the duplicate file from one of the packages before it is packaged up by rpm so I don't have to edit any of the Makefiles. For the book the later package will over write the earlier package, and you will not know the over write has occurred. That seems like the correct behavior to me. but not consistent as above Do you want to submit a patch? -- Bruce Attached is the patch --- LFS-BOOK-7.5-NOCHUNKS.html.original 2014-04-07 17:48:50.0 -0400 +++ LFS-BOOK-7.5-NOCHUNKS.html 2014-04-07 17:57:29.986548068 -0400 @@ -17341,6 +17341,13 @@ pre class=userinput kbd class=commandmv -v /usr/bin/passwd /bin/kbd /pre + p +remove nologin as a better version is installed by util-linux: + /p + pre class=userinput +kbd class=commandrm -v /sbin/nologin/kbd + +/pre /div div class=configuration lang=en xml:lang=en h3 class=sect2 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
baho utot wrote: On 04/07/2014 08:03 AM, Bruce Dubbs wrote: Do you want to submit a patch? Attached is the patch LOL. That's html. The book is in xml docbook. I'll see what I can do. -- 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] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
On Mon, Apr 7, 2014 at 5:24 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
LOL. That's html. The book is in xml docbook.
I'll see what I can do.
I've looked at the patch briefly. I'm pretty sure that using rm to
remove an executable is a bad idea in a system that might not always
have package management. I'd also note that shadow will likely install
man pages for the executable, and the patch does not have any
instructions to handle that.
Bruce, my suggestion would be to add a new sed based off the one for
disabling the groups executable. I'd imagine that something like this
would do the trick:
sed -i 's/nologin$(EXEEXT) //' src/Makefile.in
find man -name Makefile.in -exec sed -i 's/nologin\.8 / /' {} \;
William
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
William Immendorf wrote:
On Mon, Apr 7, 2014 at 5:24 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
LOL. That's html. The book is in xml docbook.
I'll see what I can do.
I've looked at the patch briefly. I'm pretty sure that using rm to
remove an executable is a bad idea in a system that might not always
have package management. I'd also note that shadow will likely install
man pages for the executable, and the patch does not have any
instructions to handle that.
Bruce, my suggestion would be to add a new sed based off the one for
disabling the groups executable. I'd imagine that something like this
would do the trick:
sed -i 's/nologin$(EXEEXT) //' src/Makefile.in
find man -name Makefile.in -exec sed -i 's/nologin\.8 / /' {} \;
Yes, I was going to do that. Thanks for the instructions tho. Saves me
some time.
-- 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] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
On 04/07/2014 06:53 PM, Bruce Dubbs wrote:
William Immendorf wrote:
On Mon, Apr 7, 2014 at 5:24 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
LOL. That's html. The book is in xml docbook.
I'll see what I can do.
I've looked at the patch briefly. I'm pretty sure that using rm to
remove an executable is a bad idea in a system that might not always
have package management. I'd also note that shadow will likely install
man pages for the executable, and the patch does not have any
instructions to handle that.
Bruce, my suggestion would be to add a new sed based off the one for
disabling the groups executable. I'd imagine that something like this
would do the trick:
sed -i 's/nologin$(EXEEXT) //' src/Makefile.in
find man -name Makefile.in -exec sed -i 's/nologin\.8 / /' {} \;
Yes, I was going to do that. Thanks for the instructions tho. Saves me
some time.
-- Bruce
This works
sed -i 's/nologin$(EXEEXT)/ /' src/Makefile.in
find man -name Makefile.in -exec sed -i 's/nologin\.8 / /' {} \;
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] how about auto create udev-lfs-xxx.tar.bz2 automatically
in lfs-book, do the following job:
local udevlfs=$(grep udev-lfs-version packages.ent);
udevlfs=${udevlfs#*\}; udevlfs=${udevlfs%\*}
local udevlfsver=${udevlfs##*-}
sed -i s/VERSION=.*/VERSION=${udevlfsver}/ udev-lfs/Makefile.lfs
mv udev-lfs ${udevlfs}
tar -Scaf ${udevlfs}.tar.bz2 ${udevlfs}
http://anduin.linuxfromscratch.org/sources/other/udev-lfs-20140406.tar.bz2
has wrong version udev-lfs-20140406/Makefile.lfs line:6
VERSION=20140306
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] how about auto create udev-lfs-xxx.tar.bz2 automatically
xinglp wrote:
in lfs-book, do the following job:
local udevlfs=$(grep udev-lfs-version packages.ent);
udevlfs=${udevlfs#*\}; udevlfs=${udevlfs%\*}
local udevlfsver=${udevlfs##*-}
sed -i s/VERSION=.*/VERSION=${udevlfsver}/ udev-lfs/Makefile.lfs
mv udev-lfs ${udevlfs}
tar -Scaf ${udevlfs}.tar.bz2 ${udevlfs}
http://anduin.linuxfromscratch.org/sources/other/udev-lfs-20140406.tar.bz2
has wrong version udev-lfs-20140406/Makefile.lfs line:6
VERSION=20140306
I know. It will be fixed tonite. The VERSION in the Makkefile.lfs
should be 20140406. For now, make that change manually and continue.
Isn't bleeding edge fun?
BTW, I don't anticipate udev-lfs changing any more with systemd version.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] udev-lfs-20140305.tar.bz2 not found.
http://anduin.linuxfromscratch.org/sources/other/udev-lfs-20140305.tar.bz2 att -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Thanks
Thanks to all for the book and the help on the lists. Apart from minor console and network config issues, down to my errors, everything works fine. Thanks -- rob -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] udev-lfs-20140305.tar.bz2 not found.
xinglp wrote: http://anduin.linuxfromscratch.org/sources/other/udev-lfs-20140305.tar.bz2 Yes, it should be 20140306. I fixed that last night. The on-line version of the book is correct as well as the svn source. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
the configure should be: ./configure --disable-nologin as nologin was previously installed by shadow -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
On Apr 6, 2014, at 7:20 PM, baho utot wrote: the configure should be: ./configure --disable-nologin as nologin was previously installed by shadow Does util-linux nologin binary overwrite shadow's? If so, that is desired because util-linux ships a better nologin binary. Coreutils will also overwrite groups program because it is better than shadow's groups binary. Rather, shadow, if not wanting to install groups or nologin installed, could edit Makefile.in to exclude those. Sincerely, WIlliam Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
On 04/06/2014 08:33 PM, William Harrington wrote: On Apr 6, 2014, at 7:20 PM, baho utot wrote: the configure should be: ./configure --disable-nologin as nologin was previously installed by shadow Does util-linux nologin binary overwrite shadow's? If so, that is desired because util-linux ships a better nologin binary. I am using rpm package manager. It causes a conflict when a file is already installed by another package. You then have to remove one of them from one of the packages. Coreutils will also overwrite groups program because it is better than shadow's groups binary. There isn't a groups executeable installed by shadow. I could list the files installed by shadow and coreutils here if needed Rather, shadow, if not wanting to install groups or nologin installed, could edit Makefile.in to exclude those. On my builds I just rm the duplicate file from one of the packages before it is packaged up by rpm so I don't have to edit any of the Makefiles. For the book the later package will over write the earlier package, and you will not know the over write has occurred. Sincerely, WIlliam Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.5 Chapter 6.61. Util-linux-2.24.1
baho utot wrote: On 04/06/2014 08:33 PM, William Harrington wrote: On Apr 6, 2014, at 7:20 PM, baho utot wrote: the configure should be: ./configure --disable-nologin as nologin was previously installed by shadow Does util-linux nologin binary overwrite shadow's? If so, that is desired because util-linux ships a better nologin binary. I am using rpm package manager. It causes a conflict when a file is already installed by another package. You then have to remove one of them from one of the packages. Coreutils will also overwrite groups program because it is better than shadow's groups binary. There isn't a groups executeable installed by shadow. Yes, we do disable that. Rather, shadow, if not wanting to install groups or nologin installed, could edit Makefile.in to exclude those. On my builds I just rm the duplicate file from one of the packages before it is packaged up by rpm so I don't have to edit any of the Makefiles. For the book the later package will over write the earlier package, and you will not know the over write has occurred. That seems like the correct behavior to me. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] linuxfromscratch.org web site
I am in the process of collecting information on usinf eudev in my rpm lfs builds I have found a broken link on the http://www.linuxfromscratch.org/hints/download.html page. When clicking the link for Hints Tarball (Generated daily) I get Page not found! Perhaps you mistyped the URL? In the case of a broken link, please contact the webmaster. BTW Is there info on using eudev in LFS as I don't want to go down the init|systemd toggle path? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] linuxfromscratch.org web site
Date: Sat, 05 Apr 2014 09:16:24 -0400 From: baho utot baho-u...@columbus.rr.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: [lfs-support] linuxfromscratch.org web site I am in the process of collecting information on usinf eudev in my rpm lfs builds I have found a broken link on the http://www.linuxfromscratch.org/hints/download.html page. When clicking the link for Hints Tarball (Generated daily) I get Page not found! Perhaps you mistyped the URL? In the case of a broken link, please contact the webmaster. Had a quick nose around - don't see the tarball. BTW Is there info on using eudev in LFS as I don't want to go down the init|systemd toggle path? - presumably svn co the relevant commit, via trac (lfs-wiki-...); ca end-March . akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] linuxfromscratch.org web site
Date: Sat, 05 Apr 2014 14:27:12 +0100 From: lf...@cruziero.com (akhiezer) To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] linuxfromscratch.org web site Date: Sat, 05 Apr 2014 09:16:24 -0400 From: baho utot baho-u...@columbus.rr.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: [lfs-support] linuxfromscratch.org web site I am in the process of collecting information on usinf eudev in my rpm lfs builds I have found a broken link on the http://www.linuxfromscratch.org/hints/download.html page. When clicking the link for Hints Tarball (Generated daily) I get Page not found! Perhaps you mistyped the URL? In the case of a broken link, please contact the webmaster. Had a quick nose around - don't see the tarball. - that was at main lfs site. Seems to be on osuosl mirror though: http://lfs.osuosl.org/hints/downloads/hints.tar.bz2 ; link seems to work - but didn't check currency of contents c. hth, akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] linuxfromscratch.org web site
akhiezer wrote: Date: Sat, 05 Apr 2014 14:27:12 +0100 From: lf...@cruziero.com (akhiezer) To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] linuxfromscratch.org web site Date: Sat, 05 Apr 2014 09:16:24 -0400 From: baho utot baho-u...@columbus.rr.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: [lfs-support] linuxfromscratch.org web site I am in the process of collecting information on usinf eudev in my rpm lfs builds I have found a broken link on the http://www.linuxfromscratch.org/hints/download.html page. When clicking the link for Hints Tarball (Generated daily) I get Page not found! Perhaps you mistyped the URL? In the case of a broken link, please contact the webmaster. Had a quick nose around - don't see the tarball. - that was at main lfs site. Seems to be on osuosl mirror though: http://lfs.osuosl.org/hints/downloads/hints.tar.bz2 ; link seems to work - but didn't check currency of contents c. I found one on higgs, but it is dated December 2012. The hints have not been updated much in the last few years. Looking at the date stamps, it looks like the only hint that have changed since then is eudev-alt-hint.txt that was added yesterday. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] few typos - new eudev hint.
Apols if this is the wrong list to send to. Ref new eudev hint: http://www.linuxfromscratch.org/hints/downloads/files/eudev-alt-hint.txt A few typos: -- * and it's manpages: s/it's/its/ * For it's brief time s/it's/its/ * s/utilzied/utilized/ ((Or even 'utilised'; but that's more a matter of taste/geo.)) * Prepare Eudev for compliation: (smirks aside): s/compliation/compilation/ * (( Acknowledgements: Acknowledgments: ? - i.e. no 'e' immed after the 'g' ; but again, perhaps more a matter of geog/taste.)) -- Msg copied to hint auth - emladdr at top of hint. rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] SVN-20140331 section 7.2.1
Robin wrote:
Refers to udev (systemd) and not eudev.
The instructions on eudev don't include creating
/etc/udev/rules.d/70-persistent-net.rules
only /etc/udev/rules.d/55-lfs.rules
Is it okay to use udev instructions from LFS 7.5 to create the database?
Yes, it is. It need the init-net-rules.sh, write_net_rules, and
rule_generator.functions scripts.
Or you can just add it manually:
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, \
ATTR{address}==00:25:64:38:ec:dd, ATTR{dev_id}==0x0, \
ATTR{type}==1, KERNEL==eth*, NAME=eth0
Change the MAC address to match your ethernet device.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] EXT3-fs (sda4): error: couldn't mount because of unsupported optional features (240) , during kernel boot
Hi, EXT3-fs (sda4): error: couldn't mount because of unsupported optional features (240) EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities What can be the reason for this error? Answers will be appreciated. Thanks. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
