Re: [lfs-support] wifi issues

[Ken Moffat]

On Mon, May 05, 2014 at 07:40:47AM -0400, David wrote:
> Yes, I had begun to suspect that enp134s0 was the wired connection. 
> 
> For what it's worth the entry I have in /sys/class/net is enp134s0 which is a 
> link that points to 
> ../../devicespci:00:00:1c.5/:86:00.0/net/enp134s0
> 
> I don't have lspci, it says command not found.  I assume it's part of a blfs 
> package I haven't gotten too.
> 

 Yes, lspci is part of pci-utils in BLFS.

 Have you actually installed any of the wifi tools from BLFS ?
I have no experience with getting wifi working on LFS, but I guess
that wicd is probably the easiest option.

 The basic LFS system is adequate for a wired network connection,
using a fixed IP address.  Everything else is in BLFS.

> Is there any value to booting with the arch cd and looking at what is there?
> 
 Use whatever you have for gaining information about your hardware.
On any distro, lsmod is probably going to be useful.  For wifi
hardware you may need extra firmware.

 And please do not top post on lfs lists.  Many of us also prefer
traditional short lines because they make it feasible to trim what
we are replying to, so that only relevant context is retained.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] gcc 4.9.0 - update 2

[Ken Moffat]

On Mon, May 05, 2014 at 08:41:40PM +0200, Frans de Boer wrote:
> 
> @Bruce, so maybe it is timing. Maybe it is timing combined with the type of
> processor. You use a i7 and I use an AMD Phenom II 965. Your SBU's are also
> about 60% compared to my machine.
> 
 Interesting.  My phenom is still using gcc-4.8 (I bought it for
building development versions of the books, but it is running out of
partitions - that is down to details of my backup process : rsync
over nfs to a staging area on my server, then create something akin
to generation data groups for the real backups on a different
filesystem [¹]  and isn't going to change in the near future).

 Anyway - are you using the ondemand cpufreq driver ?  If not,
forget this mail.  What I found at some point in the last year,
after the kernel added a new cpufreq driver for recent AMD machines,
was that my phenom (4 real cores, 3.4GHz max) was suddenly slower
than my SandyBridge i5 (2 real cores, but linux sees 4 CPUs because
of the hyperthreading, 3.2GHz max).  Looking at the kernel docs,
there was a mention of sampling_down_factor, with an example of
echoing 100 to it.  Unfortunately, it has to be set whenever I
change the governor, but at least it is not "per cpu" like the
governors.  So, what I now use for the ondemand governor is:

echo 100 >/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

and that again makes it faster than my intel, and it still falls
back to its slowest speed when idle (e.g. during configure scripts
some CPUs will slow down).  I have a "speed" alias in my user's
bashrc to report all MHz frequencies from /proc/cpuinfo on a single
line, it differs for each machine.

I've also got a desktop AMD A4 ("trinity APU") which only has two
cores.  Mostly, that box is not used for development and at the
moment it is running old LFS's (7.4 or older) and old stable
kernels.  But a couple of weeks ago I noticed people were reporting
problems on 3.15-rc kernels with radeons, and decided to try -rc2.
For that box there was a problem, which has now been fixed.  Along
the way, I did some kernel bisection and noticed that kernel full
builds were taking longer than I had expected.  After checking
things, I discovered that the box was mostly using its slowest
speed.  Applying the same workaround for sampling_down_factor seems
to have fixed that.

ĸen

1. GDGs - I'm sure wikipedia knows about them, a form of dataset
organisation on IBM mainframes using VSAM.  Arthur Dent would
probably describe my backups as "almost, but not completely, unlike"
GDGs - I only have relative generations, and form them with hard
links.
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[lfs-support] Backups. was Re: gcc 4.9.0 - update 2

[Ken Moffat]

Probably, more than anyone ever wanted to know -

On Mon, May 05, 2014 at 03:51:34PM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> >>
> >  Interesting.  My phenom is still using gcc-4.8 (I bought it for
> >building development versions of the books, but it is running out of
> >partitions - that is down to details of my backup process : rsync
> >over nfs to a staging area on my server, then create something akin
> >to generation data groups for the real backups on a different
> >filesystem [¹]  and isn't going to change in the near future).
> 
> Partitions or disk space?  If you use gpt, it can create 128 partitions by
> default and more if you really want to.
> 
 Disk space on my server's root disk (sda).  I have several systems
on each desktop box (each 6 to 8 GB for '/' I think), plus smaller
boot partitions and probably 30 to 40 GB for '/home'.  My disks on
the current dekstops are already so big that I allocate most of the
space to '/scratch' which is never backed up.  I use that for
building, test builds, and workfiles for audio and perhaps video.

 The first stage of the backup is to rsync to a "/staging" partition
on my server, which is the current constraint.  When the rsync
completes successfully, my script updates an associated status file.
On the server, a script wakes up every few minutes (5 minutes, I
think), looks at the status files, and processes the first which has
been updated.  So, for those days when I am running multiple
machines (not often nowadays, my kvm switch tends to give me a
damaged desktop on xorg for any machine to the right of the first
one running xorg) I try to run the first stage of the backup at
different times.  Oh, and the first backup from a new system takes
forever (over 3 hours today, after I had installed firefox).
Perhaps I ought to get a gigabit ethernet switch for my desktops.

 This then "rolls down" the existing "generations" (once there is a
full set, the oldest will then roll out on each subsequent update)
and then copies in the new version.  These "real" backups are on
RAID-1 on a different pair of disks which also include my other data
(audio files, primarily flac, some video, photos) and for the moment
there is adequate space there (typically 70-72% full, until I finish
ripping my CDs, transcribing my vinyl, buying more highres
downloads, or getting around to doing something with my photos and
films from 2011).  And yes, I do copy these to external disks from
time to time - if the worst happens, I might be recovering somewhat
old systems, but I can then use those with my recent data (including
my scripts - backed up weekly) to get back to a more sane position.

> >I've also got a desktop AMD A4 ("trinity APU") which only has two
> >cores.  Mostly, that box is not used for development and at the
> >moment it is running old LFS's (7.4 or older) and old stable
> >kernels.
> 
> $ cat /etc/lfs-release
> SVN-20120610
> 
> $ uname -a
> Linux lfs6 3.4.1-LFS-SVN-20120617 #8 SMP PREEMPT Sat Apr 27 00:38:43 CDT
> 2013 i686 GNU/Linux
> 
> $ cat /proc/cpuinfo
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 15
> model   : 4
> model name  : Intel(R) Pentium(R) 4 CPU 3.20GHz
> 
> Obviously not a development system any more, but that's what I am using now.
> 
>   -- Bruce

 I guess that it must be more useful to you than a conventional
electric heater [ I never did like the P4 ] ;-)  But 3.4.1 ?

 My own "maintained" systems (mostly, that just means firefox and
openssl get maintained, and occasional kernel updates) go back to
LFS-7.0, although not on the machine where it was built.  My oldest
"normal" systems are 7.4 - I didn't get around to testing 7.5 on the
trinity, and my server is still running 7.4 because I couldn't see
any point in updating it.  But all of these are running 3.10 or
later (3.12 on one system on the trinity).  Maybe not the latest
release of these maintained kernels, but they do get updated
from time to time.

 But then, I was running development kernels before I ever found LFS
(I had issues with a zip disk - probably due to the bious setting I
was using - and discovered the kernel was interesting).   Even my
apple G5 [ ppc64 kernel, 32-bit userspace ] would run mostly LFS-7.4
on 3.10 if I booted it [ a couple of problems, e.g. in kbd, because
of endian issues, made me use older versions - those have hopefully
now been fixed, but I haven't had time or inclination to go back to
it, and it is now mostly defunct - I got fed up with letting newer
versions of firefox compile all evening before eventually failing,
and I haven't had time to retry that for a few months. ]

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] wifi issues

[Ken Moffat]

On Mon, May 05, 2014 at 04:53:15PM -0400, David wrote:
> I was able to get the pci tools installed and lspci tells me I have
> "Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection"  which 
> is more information than I had before.
> 
> I presume now that I have to rebuild the kernel to include a module for this 
> device, if it has one. 
> 
> Any recommendation on what to do if it does not have one?

 Although some people think google no longer plays by its motto ("do
no evil"), it is still useful.  Search for linux shiloh wifi.

 For firmware, see the kernel configuration part of the xorg radeon
driver in BLFS [ also check the arch config, if you have it ].  You
might need to make a couple of attempts at reconfiguring the kernel
befoe it tells you the name of what it wants - from time to time
(for radeon) I've seen it mentioned during the boot messages, at
other times I've had to look at dmesg.  And from time to time you
may need to get newer firmware when you build newer kernels.  To
get the firmware, it is probably easiest to grab a linux firmware
tarball from a debian or ubuntu mirror - check what you need, then
look in their pool/non-free/f/firmware-nonfree directory. You can
find the cgit view of the linux-firmware project in google, but I've
never worked out how to actually _download_ from there.  You can
probably also find recent firmware in fedora's cgit [ see Going
Beyond BLFS in BLFS chapter 2 ].

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Step 5.11 Tcl-8.6.1 (7.5 stable) building errors

[Ken Moffat]

On Mon, May 19, 2014 at 05:33:28AM -0400, Marcos Menendez wrote:
> Hello,
> 
> I'm trying to install LFS based on 7.5 stable on a CentOS 6.5 x86_64.
> 
> 
> Actually I'm facing problems in step 5.11 Tcl-8.6.1
> 
> My question is if I have to unset the variables used from the previous step 
> for GCC-4.8.2 pass 2 before building tcl.
> It is not clear to me, as per the book, if I have to unset them or not:
> 
> CC=$LFS_TGT-gcc
> AR=$LFS_TGT-ar
> RANLIB=$LFS_TGT-ranlib
> CXX=$LFS_TGT-g++
> 
> 
> If I keep using them I have the following errors under config.log:
> 
[snip]

 You should not have set them in the previous step (i.e. they should
not be part of the lfs user's environment).  If you look at the gcc
instructions, each of these assignments is on a line with '\' as its
last character (i.e. '\' is a continuation) before gcc's configure
script is invoked.

 So, the book sets these only during that run of the configure
script.

 I doubt that setting them in the lfs user's environment did
anything wrong during the build of gcc, so if you unset them now you
are probably ok to go.  Except -
> 
> If I unset them and build, I have errors again:
> 
> gcc: error: unrecognized command line option '-V'
> gcc: fatal error: no input files
> conftest.c:2:3: error: unknown type name 'choke'
> conftest.c:2:3: error: expected '=', ',', ';', 'asm' or '__attribute__' at 
> end of input
> conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory
> conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory
> collect2: error: ld returned 1 exit status
> | /* Override any gcc2 internal prototype to avoid an error. */
> collect2: error: ld returned 1 exit status
> conftest.c:62:23: fatal error: net/errno.h: No such file or directory
> conftest.c:28:23: fatal error: net/errno.h: No such file or directory
> conftest.c:62:18: fatal error: zlib.h: No such file or directory
> conftest.c:28:18: fatal error: zlib.h: No such file or directory
> configure:6515: gcc -c -pipe -fvisibility=hidden -Werror conftest.c >&5
> conftest.c:40:15: error: storage size of 'buf' isn't known
> conftest.c:41:19: error: 'open64' undeclared (first use in this function)
> conftest.c:42:19: error: 'open64' undeclared (first use in this function)
> conftest.c:41:1: error: unknown type name '__int64'
> conftest.c:41:18: error: '__int64' undeclared (first use in this function)
> conftest.c:41:27: error: expected ',' or ';' before numeric constant
> conftest.c:42:21: error: duplicate case value
> conftest.c:42:13: error: previously used here
> conftest.c:45:2: error: unknown type name 'not'
> conftest.c:45:10: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'endian'
> configure:10518: checking for strerror
> configure:11035: checking for gai_strerror
> conftest.c:77:11: error: too few arguments to function 'gethostbyaddr_r'
> conftest.c:99:23: fatal error: sys/modem.h: No such file or directory
> conftest.c:65:23: fatal error: sys/modem.h: No such file or directory
> conftest.c:74:17: error: 'struct tm' has no member named 'tm_tzadj'
> conftest.c:108:1: error: unknown type name 'choke'
> conftest.c:116:1: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'int'
> | /* Override any gcc2 internal prototype to avoid an error. */
> conftest.c:116:23: fatal error: sys/filio.h: No such file or directory
> conftest.c:82:23: fatal error: sys/filio.h: No such file or directory
> ac_cv_func_gai_strerror=yes
> ac_cv_func_strerror=yes
> 
> 
> The 'make' itself doesn't show any of these errors at the end but only when I 
> search on the config.log file.
> 

 If (with the variables unset) configure ran successfully (i.e. it
created the Makefile), and make also ran successfully (no errors
reported, or alternatively status 0 when make completes [ echo $? or
perhaps 'make || echo "failed" ' ] then you do not have a problem.

 I think you don't fully appreciate what configure scripts do.  Each
one is different in detail, but they are all concerned with creating
Makefiles which will run in the current environment.  They test for
a lot of things which identify specific operating systems or which
show that a particular package is available.  If sys/filio.h
existed, it would need to be included to make certain things
available.  And you would probably be running on a BSD system, or
one with BSD ancestry such as OSX (or Solaris - I'm not sure how
much BSD is in that, but this file definitely gets mentioned).

 So, don't go looking for errors in config.log unless configure
fails to work.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] iso8859-15 spanish accented characters in lfs-7.5

[Ken Moffat]

On Tue, May 20, 2014 at 11:17:39AM +0100, ortenzia konyha wrote:
> Dear LFS support,
> how does it work the script /etc/rc.d/init.d/console  in lfs-bootscript?
> how does the variable $KEYMAP pass the argument to loadkeys?
> 
> My LFS is LFS stable 7.5
> I am working without X, only in console.
> My $LANG is ISO885915@euro
> I can see $LANG ISO885915@euro when I type set and locale
> 

 That sounds wrong - ISO885915@euro is not a language.

 The LANG and LC_ variables are mostly in the form language
(lowercase, usually two letters), underscore, country code
(uppercase, usually two letters), dot, encoding (ISO-8859-1..15,
UTF-8, and a few others) and optionally an '@something' modifier
such as '@euro'. The exceptions include C and POSIX which glibc
knows about even without installing locales.

 My general recommendation is that people should use UTF-8, to be
able to render any character which their font supports.  But if you
have a lot of files using ISO-8859-15, or correspond with people who
also use 8859-15, then I can see reasons to use that encoding.

 I was going to say "Try LANG=es_ES.ISO-8859-15@euro - you probably
need to set UNICODE=0 with that." but now that I've read the detail
of what you tried in 'vim' I don't think you need to use that legacy
encoding.

> I have tried several combinations in my /etc/sysconfig/console:
> UNICODE=1
> KEYMAP=es
> KEYMAP_CORRECTIONS="euro2"
> FONT="lat0-16 -m 8859-15"
> 
> I can see the ñ, ¡, ? and the €  in my console, I cannot see accented spanish 
> character, á, é, í, ó, ú.

 I was going to offer this suggestion as an alternative, but I think
it will probably do what you need: with those settings in
/etc/sysconfig/console (particularly UNICODE=1) I suggest you try
 LANG=es_ES.UTF-8

 NB the @euro modifier doesn't apply to es_ES.UTF-8 altohugh it is
required for es_ES.ISO-8859-15@euro.

 The KEYMAP_CORRECTIONS adds to the console keymap and should give
you the euro and cent symbols on AltGr-e and AltGr-c.
> 
> 
> the LFS-bootschript included the  /etc/rc.d/init.d/console, which installed 
> the following:
> /etc/sysconfig/console?
> 
> I compiled Linux-3.13.3 against the following: make LANG=ISO885915@euro 
> LC_ALL= menuconfig
> 
 Again, that is not a valid LANG specification.  But in that command
it only affects messages from menuconfig.  As far as I klnow,
menuconfig only outputs messages in English.

> I am in a Netbook Lenovo s2-10.
> 
> If I understand correctly the hierchy of the information is The master 
> run-level control script runs all the other bootscripts in a sequence 
> gathering information first from locale (taken from glibc) and variable 
> $LANG, then look in /etc/sysconfig/console and later look for loadkeys 
> loading a different keymap
> is that correct
> "The dead key settings depend on your locale and character set." 
> (http://unix.stackexchange.com/questions/7493/why-is-the-us-international-keyboard-layout-on-debian-different)
> 
> then, why if I compiled against ISO885915@euro, my console is not letting me 
> see spanish accented characters?
> 
> My question is about understanding LFS and if possible Linux.
> I can see the spanish accented characters using loadkeys 
> /usr/share/keymaps/es.map.gz
> 
> and in vim
> I can use
> :set enc=utf-8
> and using CTR+K a+`(accent) = á
> and so on.
> 

 I started by assuming you intended to use the 8859-15 encoding, but
from this I think you will be happy with UTF-8.

> but, why if I compiled against ISO885915@euro, my console is not letting me 
> see spanish accented characters?

 When you build the kernel, the language setting in your environment
might allow you to get translations of the warnings and any error
messages from 'make'.  But the kernel messages are all in English,
and it relies on userspace (glibc) to handle languages.
> 

> Let me see i you need more output to help me solve my problem.
> -- 
> http://lists.linuxfromscratch.org/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page

-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] iso8859-15 spanish accented characters in lfs-7.5

[Ken Moffat]

On Tue, May 20, 2014 at 03:42:21PM +0100, Ken Moffat wrote:
> On Tue, May 20, 2014 at 11:17:39AM +0100, ortenzia konyha wrote:
> > Dear LFS support,
> > how does it work the script /etc/rc.d/init.d/console  in lfs-bootscript?
> > how does the variable $KEYMAP pass the argument to loadkeys?
> > 
> > My LFS is LFS stable 7.5
> > I am working without X, only in console.
> > My $LANG is ISO885915@euro
> > I can see $LANG ISO885915@euro when I type set and locale
> > 
> 
>  That sounds wrong - ISO885915@euro is not a language.
> 
>  The LANG and LC_ variables are mostly in the form language
> (lowercase, usually two letters), underscore, country code
> (uppercase, usually two letters), dot, encoding (ISO-8859-1..15,
> UTF-8, and a few others) and optionally an '@something' modifier
> such as '@euro'. The exceptions include C and POSIX which glibc
> knows about even without installing locales.
> 
>  My general recommendation is that people should use UTF-8, to be
> able to render any character which their font supports.  But if you
> have a lot of files using ISO-8859-15, or correspond with people who
> also use 8859-15, then I can see reasons to use that encoding.
> 
>  I was going to say "Try LANG=es_ES.ISO-8859-15@euro - you probably
> need to set UNICODE=0 with that." but now that I've read the detail
> of what you tried in 'vim' I don't think you need to use that legacy
> encoding.
> 

 See below.

> > I have tried several combinations in my /etc/sysconfig/console:
> > UNICODE=1
> > KEYMAP=es
> > KEYMAP_CORRECTIONS="euro2"
> > FONT="lat0-16 -m 8859-15"
> > 
> > I can see the ñ, ¡, ? and the €  in my console, I cannot see accented 
> > spanish character, á, é, í, ó, ú.
> 
>  I was going to offer this suggestion as an alternative, but I think
> it will probably do what you need: with those settings in
> /etc/sysconfig/console (particularly UNICODE=1) I suggest you try
>  LANG=es_ES.UTF-8
> 

 After experimenting locally, I recommend you set LC_ALL instead of
LANG.  I have all the locales installed.  When I try e.g.
LANG=lb_LU.UTF-8 I get English (or C) output, but I get the expected
result if I set LC_ALL.

>  NB the @euro modifier doesn't apply to es_ES.UTF-8 altohugh it is
> required for es_ES.ISO-8859-15@euro.
> 
>  The KEYMAP_CORRECTIONS adds to the console keymap and should give
> you the euro and cent symbols on AltGr-e and AltGr-c.
> > 
> > 
> > the LFS-bootschript included the  /etc/rc.d/init.d/console, which installed 
> > the following:
> > /etc/sysconfig/console?
> > 
> > I compiled Linux-3.13.3 against the following: make LANG=ISO885915@euro 
> > LC_ALL= menuconfig
> > 
>  Again, that is not a valid LANG specification.  But in that command
> it only affects messages from menuconfig.  As far as I klnow,
> menuconfig only outputs messages in English.
> 
> > I am in a Netbook Lenovo s2-10.
> > 
> > If I understand correctly the hierchy of the information is The master 
> > run-level control script runs all the other bootscripts in a sequence 
> > gathering information first from locale (taken from glibc) and variable 
> > $LANG, then look in /etc/sysconfig/console and later look for loadkeys 
> > loading a different keymap
> > is that correct
> > "The dead key settings depend on your locale and character set." 
> > (http://unix.stackexchange.com/questions/7493/why-is-the-us-international-keyboard-layout-on-debian-different)
> > 
> > then, why if I compiled against ISO885915@euro, my console is not letting 
> > me see spanish accented characters?
> > 
> > My question is about understanding LFS and if possible Linux.
> > I can see the spanish accented characters using loadkeys 
> > /usr/share/keymaps/es.map.gz
> > 
> > and in vim
> > I can use
> > :set enc=utf-8
> > and using CTR+K a+`(accent) = á
> > and so on.
> > 
> 
>  I started by assuming you intended to use the 8859-15 encoding, but
> from this I think you will be happy with UTF-8.
> 
> > but, why if I compiled against ISO885915@euro, my console is not letting me 
> > see spanish accented characters?
> 
>  When you build the kernel, the language setting in your environment
> might allow you to get translations of the warnings and any error
> messages from 'make'.  But the kernel messages are all in English,
> and it relies on userspace (glibc) to handle languages.
> > 
> 
> > Let me see i you need more output to help me solve my problem.
> > -- 
> > http://lists.linuxfromscratch.org/listinfo/lfs-support
> > FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> > Unsubscribe: See the above information page
> 
> -- 
> das eine Mal als Tragödie, dieses Mal als Farce
> -- 
> http://lists.linuxfromscratch.org/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page

-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] How can I not recive this mail

[Ken Moffat]

On Wed, May 21, 2014 at 07:17:17AM +0800, 277360123 wrote:
> -- 原始邮件 --
> 发件人: "ALZ (phyglos.org)" ;
> 发送时间: 2014年5月21日(星期三) 4:11
> 收件人: "LFS Support List" ;
> 主题: Re: [lfs-support] iso8859-15 spanish accented characters in lfs-7.5
> 

 Try unsubscribing like it says in these three lines:
> http://lists.linuxfromscratch.org/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/b↓lfs/faq.html
> Unsubscribe: See the above information page

 Specifically, go to the link in the first of those lines, and go to
the bottom of the page where it says:

To unsubscribe from lfs-support, get a password reminder, or change
your subscription options enter your subscription email address:

 And then when you get sent a mail saying that someone is trying to
unsubscribe you, follow the instructions.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] iso8859-15 spanish accented characters in lfs-7.5

[Ken Moffat]

O Wed, May 21, 2014 at 02:13:41PM +0100, ortenzia konyha wrote:
> 
> the problem is with the KEYMAP
> at boot time LFS system reads a script called /etc/rc.d/rcS.d/S70console 
> which looks the parameter KEYMAP passed in the file  in /etc/sysconfig/console
> My /etc/sysconfig/console passes the parameter KEYMAP="es"
> (assuming that is looking for /usr/share/keymaps/i386/qerty/es.map.gz "es" is 
> the correct parameter to pass)
> 

 Yes, that was correct.  You just pass the name of a .map.gz or .map
file which is in /usr/share/keymaps.  We already know that your es
keymap is present.

 You *should* be able to have the keymap loaded by the LFS
bootscripts, in the same way that using a script to load it works
correctly.

> I tried to pass KEYMAP="es_ES.UTF-8" but /etc/rc.d/rcS.d/S70console 
> complaints at boot time and default (english) is loaded instead.
> 
> I have tried 
> https://wiki.archlinux.org/index.php/Keyboard_configuration_in_console_%28Espa%C3%B1ol%29
> but I have not the program localetcl and I am not using a virtual console.
> 

 Many things in the arch wiki are specific to arch.
> 
> Any suggestion for KEYMAP parameter?
> 

 The value you originally used, 'es'.

 You should then have dead keys for the accents:

dead_grave and dead_circumflex on the key to the right of 'P'
which probably has grave and circumflex on the key label.

dead_acute and dead_diaeresis on the key two keys to the right of
'L' which means the key between N-tilde and C-cedilla.

 Descriptions based on the Spanish map at
http://en.wikipedia.org/wiki/File:KB_Spanish.svg


 So, I suggest that you should be using UTF-8 throughout (that
includes NOT telling vim to use a different encoding unless you know
you are editing a file which is not in UTF-8).

 Are you rebooting after each change to /etc/sysconfig ?  I have
assumed you are, but I'm having difficulty working out what is
different about your setup.

 In your original post, you said

> I have tried several combinations in my /etc/sysconfig/console:
> UNICODE=1
> KEYMAP=es
> KEYMAP_CORRECTIONS="euro2"
> FONT="lat0-16 -m 8859-15"
>
>I can see the ñ, ¡, ? and the €  in my console, I cannot see
>accented spanish character, á, é, í, ó, ú.

 Please reinstate those values in /etc/sysconfig/console and reboot.
(with the corrected LC_ALL=es_ES.UTF-8).

 If you still cannot see the letters a,e,i,o,u with acute accents,
please describe what character you get for each of them.

 I do now wonder if somewhere in the system you *are* using an
iso-8859 setting.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] iso8859-15 spanish accented characters in lfs-7.5

[Ken Moffat]

On Wed, May 21, 2014 at 07:16:51PM +0100, ortenzia konyha wrote:
> Dear Mr: Moffat,

 Less formality, please.  "Ken" is fine, so is just replying without
any greeting - that is what I normally do on the lists.

> I think point 9 below is the root cause.
> 
> 8)
>  If you still cannot see the letters a,e,i,o,u
>  with acute accents,
>  please describe what
>  character you get for each of them.
> 
> I can see only this: 'a. 'e, 'i, 'o, 'u

 I was not expecting that, I expected maybe some weird symbols.
That looks as if your dead keys are either not working, or are being
read so quickly that the system thinks you pressed them twice, which
will normally generate the accent itself instead of an accent on the
next key you type.
> 
> 9)  QUOTE: "do now wonder if somewhere in the system you  *are* using an  
> iso-8859 setting" UNQUOTE.
> I somewhere during the building LFS set my global variable  
> LANG=es_ES.iso8859@euro but I cannot find the place where I did.
> I cannot find the file where this settings are recorded
> is somewhere in bash, maybe?
> 
> Maybe this should be changed?
> Do you know how?
> 
 I think ALZ has probably pointed to that (/etc/profile).  If not,
take a look at what you have in ~/.bash_profile and ~/.bashrc.  On
my machines, where the basic setup predates much of what is now in
BLFS, I set LC_ALL in both of those : "my system, my rules"

 Please try everything ALZ has suggested in his latest reply.

 Oh, and can you stop top-posting, please ?  Most linux mailing
lists prefer to see replies after the part of the text you are
replying to.  I know some mailers make that hard (I'm looking at
you, gmail).

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] iso8859-15 spanish accented characters in lfs-7.5

[Ken Moffat]

On Sat, May 24, 2014 at 01:39:40PM +0200, ALZ (phyglos.org) wrote:
> On 05/21/2014 11:57 AM, ortenzia konyha wrote:
> >Dear ALZ
> >your settings fro /etc/sysconfig/console
> ># Begin
> >  /etc/sysconfig/console
> >
> >  KEYMAP="es"
> >  KEYMAP_CORRECTIONS="euro2"
> >  FONT="lat0-16 -m 8859-15"
> >
> >  # End
> >  /etc/sysconfig/console
> >
> >work for me either for ñ, ¿. ¡ and € in console but I cannot see accented
> >  spanish character, á, é, í, ó, ú.
> >
> 
> I can now CONFIRM this behavior after building a clean LFS SVN-20140519.
> 
> Just after first boot, in console prompt, accented characters like à are
> displayed as 'a. All other characters are well placed, like Ñ, ç, €, etc.
> This happens also using a spanish AT keyboard with /etc/sysconfig/console
> set to:
> 
> KEYMAP="es"
> KEYMAP_CORRECTIONS="euro2"
> FONT="lat0-16 -m 8859-15"
> 
> Setting also this values in /etc/sysconfig/rc.site does not correct the
> problem.
> 
> Executing "#loadkeys /usr/share/keymaps/i386/qwerty/es" seems to correct the
> problem with accents, but this is lost after reboot.
> 
> >What I am trying to do is to se the encoding in console.
> >What it works for me is to use at the prompt the following;
> >loadkeys /usr/share/keymaps/i386/qerty/es.map.gz
> >but I would like it to have it loaded at boot time, if possible.
> >
> 
> This is a quick workaround to temporary fix this:
> 
> # mv /etc/rc.d/init.d/console /etc/rd.c/init.d/console.ORIG
> 
> # cat > /etc/rc.d/init.d/console << "EOF"
> 
> cd /usr/share/keymaps/i386/qwerty
> 
> loadkeys es
> loadkeys euro2
> 
> setfont lat0-16 -m 8859-15
> 
> EOF
> 
> # reboot
> 
> This temporary fix allows to type characters like à in console after boot.
> 
> ALZ.

 Thanks for confirming this.

@ALZ :  Are you using unicode ?  And are you using a framebuffer ?

@ortenzia : Are you using a framebuffer ?

 I've raised ticket #3591
http://wiki.linuxfromscratch.org/lfs/ticket/3591
but at the moment I don't have a clue what has broken.

 I do remember there were issues with loadkeys in kbd-2.0 (some maps
suce as, I think, croatian, were reproted to not load), but I thought
those issues were fixed in 2.0.1, at least for x86.  And anyway,
loadkeys is obviously working for you guys.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] iso8859-15 spanish accented characters in lfs-7.5

[Ken Moffat]

On Sat, May 24, 2014 at 04:18:58PM +0200, ALZ (phyglos.org) wrote:
> On 05/24/2014 03:58 PM, Bruce Dubbs wrote:
> 
> >If you can put a few echo statements in /etc/init.d/console and see
> >where there is a problem, I can update the script.
> >
> >   -- Bruce
> 
> Thanks Bruce. After some troubleshooting I've realized that in LFS this two
> commands are not equivalent:
> 
> #loadkeys es
> 
> #loadkeys /usr/share/keymaps/i386/qwerty/es
> 
> The former is what LFS bootscripts end executing from /etc/sysconfig/console
> (from KEYMAP=es) while the later is the right command to be run to solve
> this issue.
> 
> So, the way to set /etc/sysconfig/console in order to work with spanish
> accented vowels in LFS 7.5 + SVN right now is:
> 
> # Begin /etc/sysconfig/console
> 
> KEYMAP="/usr/share/keymaps/i386/qwerty/es"
> KEYMAP_CORRECTIONS="euro2"
> FONT="lat0-16 -m 8859-15"
> 
> # End /etc/sysconfig/console
> 
> I don't know the root cause of this behavior. Either Viktor and I do have a
> rare kernel option set when compiling the kernel and "#loadkeys es" invokes
> some default kernel table (just speculating here), or kbd-2.0.1 needs now
> the full path to be set in LFS rc.d scripts.
> 
> The Changelog inside kbd sources says that at kdb-1.5.3 an enviroment
> variable LOADKEYS_KEYMAP_PATH is introduced. In fact, when doing
> 
> #export LOADKEYS_KEYMAP_PATH=/usr/share/keymaps/i386/qwerty
> #loadkeys es
> 
> the expected behavior is now obtained.
> 
> If LFS scripts are to be updated after kbd-1.5.3+ is now beyond my LFS
> knowledge.
> 
> ALZ.
> 

 I find that strange, but I cannot dispute those results on your
machines.  On my own, things are different - despite the comment in
the console script "Native English speakers probably don't have
/etc/sysconfig/console at all" I do have one of these, both for my
own font and for my own keymap (uk-utf : uk with a lot of extras
added).  And my map does get loaded.

 At the moment I'm timing a xulrunner build in X on 7.5, so I went
to a tty on this machine and tried (as root) "loadkeys es" - got a
spanish keymap.  I didn't try changing the font (mine already covers
all Spanish glyphs, except a couple only used in Asturian).  I also
did not try setting the euro2 override.

 Took me a while to find where '-' had moved to, then I typed
"loadkeys uk-utf" - it failed, I got an error message (something
about hte file's content and EOL) despite loadkeys uk-utf working
during bootup.  For now, 'loadkeys uk' worked.

 I then booted another machine, with a recent copy of LFS-svn, and
confirmed that it was definitely using my uk-utf map after booting.

 My tests have all been on x86_64, with a framebuffer console.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] LFS 6.3 questions

[Ken Moffat]

On Fri, Jun 06, 2014 at 08:38:54AM -0400, wayne wrote:
> Hello,
>I have a problem with my host system which is Linuxmint 11. It does not
> have Bison v2.4.1-1, or Gcc v5.2-8. How do I cope with this? My OS is past
> the "end of life."
> 

 For gcc, I am confused about which version you were looking for.
But it does not matter, because building LFS-6.3 would be a waste of
your time - it is old, perhaps even too old to build a still-supported
kernel.  As a technical exercise it is probably possible - if the
packages from the distro are still available.  You would have to
install whatever is needed to compile programs (perhaps a
"build-essentials" meta-package), then (again, assuming that
upgrades for bison and gcc/g++ are not available), build newer
versions of those packages.  There might even be partially-useful
instructions in older versions of LFS, but you would probably need
to install to /usr/local, and put that at the head of your PATH.  A
lot of work, for not much benefit :-(

> The system I am running is a Dell Dimension 4500S which is about 12 yrs
> old,this system won't support 64 bit but it will support 32 bit OS's. The OS
> is about 5 yrs old and is past "End of life".
> 73
> N1QGC
> wayne

 If it supports i686, then any recent distro will do (but you might
have to pass a command-line switch when booting, if it does not
support pae - all distros derived drom ubuntu apparently require that
switch now, and it is mentioned in their release notes).

 And then, if you really want to use LFS, you can add all the
necessary packages to compile programs.  But for a machine which is
so old, you are probably lacking RAM and disk space.

 If it does not support i686, I guess you could try puppy linux or
(probably) debian.  Trying to build for i586 (or i486) on any
current linux system is probably painful.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] KDE Question - akonadiserver always at 100%

[Ken Moffat]

On Mon, Jun 09, 2014 at 01:50:07PM -0500, Bruce Dubbs wrote:
> I just finished doing an install of KDE-4.13.1.  It starts fine and I don't
> really notice any interface issues (other than the designed ones :).
> 
> However, I do notice in top:
> 
>   PID USER   VIRT   RES  SHR  S  %CPU %MEM TIME+ COMMAND
> 24929 bdubbs 250796 9552 7688 R  98.3 0.1  824:28.64 akonadiserver
> 
> Having a process using basically all of a core is not something I want.  A
> few google entries discuss the same thing, but they are a few years old.
> 
> This happens even when the window manager is idle (blanked) and I am only
> accessing the system via ssh.
> 
> Does anyone here know what is happening and how to fix this?
> 
>   -- Bruce
> 
 I think akonadi is the application which indexes _everything_ for
the so-called semantic desktop which is one of the features of kde4.
If I am right, it was one of the reasons I gave up on kde4 - in those
days I only had single core processors.  ISTR that when I found out
what was using so much CPU I looked at what it was using and found
it was creating gigabytes of index which I did not want.  OTOH, I
ran kde4 with a few extras on one machine for an hour or so a few
months ago and did not notice akonadi.  But, I probably didn't check
'top' or look at the sizes of the dotfiles.

 Is this a kde upgrade or a new install ?  For a new install I would
be tempted to leave it for a few hours, to see if it completes.  If
it does, I would monitor it for a few days to see if it continues to
use a lot of CPU for long periods, e.g. when files in ~/ change.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] KDE Question - akonadiserver always at 100%

[Ken Moffat]

On Mon, Jun 09, 2014 at 04:01:35PM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> 
> >  Is this a kde upgrade or a new install ?  For a new install I would
> >be tempted to leave it for a few hours, to see if it completes.  If
> >it does, I would monitor it for a few days to see if it continues to
> >use a lot of CPU for long periods, e.g. when files in ~/ change.
> 
> It's a new install, but kde has been running now for about 24 hours.  My
> home directory is 361M, with ~/.local/share/akonadi sitting at 143M. The
> only things approaching large there are
> 
> -rw-rw 1 bdubbs bdubbs  64M Jun  7 23:51 ib_logfile1
> -rw-rw 1 bdubbs bdubbs  64M Jun  8 23:46 ib_logfile0
> 
> and as you can see, they haven't changed in the last 16 hours or so.
> 
> I will probably end up using xfce as a 'normal' desktop, but wanted to
> investigate KDE.
> 
>   -- Bruce

 Actually I think I was confusing it with nepomuk (sorry!), so my
suggestion is irrelevant.  I haven't used kmail in recent times (my
mboxes are on my _server_), so I can't offer any useful ideas.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Need help regarding eth0 not found and key board mis behaving

[Ken Moffat]

On Tue, Jun 10, 2014 at 01:47:40PM +0530, BSV Ramesh wrote:
> 
> and another is with  keyboard , (for example if i type X  it prints Y , if
> i press Up arrow it prints  " - "  ..  ).
> 

 This is LFS-7.5 ?  If so, setting up the keyboard is covered in
section 7.10, Configuring the Linux Console.

 If this is a laptop keyboard, a few keys will probably have odd
values - that might explain the up arrow.

 Does this keyboard work correctly in your host system ?  I assume
you could not get this far if it was badly broken.

 What is the layout of your keyboard ?  The default (if you do not
specify anything) is the U.S. QWERTY layout.

 And what did you specify in /etc/sysconfig/console ?  Probably,
we should check all the entries there, in case it is a problem with
the encoding.  Are you using a UTF-8 locale ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Final Prep Item for LFS-7.5--kernel rebuild

[Ken Moffat]

On Fri, Jun 13, 2014 at 09:57:27PM -0500, Dan McGhee wrote:
> 
>   Here is the result of :
> 
> >CONFIG_BROKEN_ON_SMP=y
> >CONFIG_GENERIC_SMP_IDLE_THREAD=y
> ># CONFIG_SMP is not set
> >CONFIG_HAVE_TEXT_POKE_SMP=y
> >CONFIG_SCSI_SAS_HOST_SMP=y
> 
> AFAIK I need only set CONFIG_SMP and I will enable all the cores on my
> processor.  (In older days, I seem to remember specifying the number
> somewhere in the kernel configuration file, but I couldn't find anything
> like that on 3.10.10).
> 
 If you build for SMP, you probably do not want
CONFIG_BROKEN_ON_SMP.  As its name suggests, it is for things which
do not work correctly on SMP.  As of 3.15.0 the drivers which might
be relevant are mentioned in the Kconfig files in :

drivers/net/hamradio/
drivers/i2c/busses/
drivers/isdn/i4l/
init/

 There are also references in the powerpc, sh, and mips
architectures.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] failing to configure Texinfo package

[Ken Moffat]

On Sat, Jun 14, 2014 at 06:38:18PM +0200, Stefano Stoduto wrote:
> Hi, I'm trying to follow the lfs book for the first time and I'm having
> some issues during the configure phase of the Texinfo package.
> 
> I looked in the mailing list archive, and the very same problem has been
> reported here:
> 
> http://www.linuxfromscratch.org/pipermail/lfs-support/2014-April/046811.html
> 
> but, although the guys solved the problem for that instance, they didn't
> actually come to a reason for it and I'm not being so lucky: the problem is
> still there for me.
> 

 We thought that perl was incorrectly installed in chapter 5, but in
that first example we did not know the details of how it was wrong.
But now that I look at this, you are nearly at the end of chapter 6
and so you are using the new version of perl in chroot.

> The version of the LFS book I'm reading is 7.5, and the problem came out in
> chapter 5.32 when I execute the command:
> 
> ./configure --prefix=/tools
> 
> which gives the following 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 '1002' is supported by ustar format... yes
> checking whether GID '1002' 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.
> 
> Executing the command "uname -a" on my host system will output:
> 
> Linux localhost 3.2.0-4-486 #1 Debian 3.2.46-1 i686 GNU/Linux
> 

 The test in configure is:
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking Perl version and
Encode module" >&5
$as_echo_n "checking Perl version and Encode module... " >&6; }
if $PERL -e "use 5.007_003; use Encode;" > /dev/null 2>&1; then
  perl_version_requirement='yes'
else
  perl_version_requirement='no'
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$perl_version_requirement" >&5
$as_echo "$perl_version_requirement" >&6; }
if test z"$perl_version_requirement" = 'zno' ; then
  as_fn_error $? "perl >= 5.7.3 with Encode required by Texinfo."
"$LINENO" 5
fi

type -pa perl
perl -e "use 5.007_003; use Encode;" ; echo $?
perl --version | grep version
(That last grep is because 5.18.2 outputs a total of 12 lines for
the version information.)

 You say you have /bin/sh pointing to bash, which is correct.  Was
it pointing to dash earlier in your build ?  Have you rebuilt perl
to try to fix this ?  If so, did you remove the perl source and
re-extract it ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] failing to configure Texinfo package

[Ken Moffat]

On Sat, Jun 14, 2014 at 11:55:59PM +0100, Ken Moffat wrote:
> On Sat, Jun 14, 2014 at 06:38:18PM +0200, Stefano Stoduto wrote:
> > Hi, I'm trying to follow the lfs book for the first time and I'm having
> > some issues during the configure phase of the Texinfo package.
> > 
> > I looked in the mailing list archive, and the very same problem has been
> > reported here:
> > 
> > http://www.linuxfromscratch.org/pipermail/lfs-support/2014-April/046811.html
> > 
> > but, although the guys solved the problem for that instance, they didn't
> > actually come to a reason for it and I'm not being so lucky: the problem is
> > still there for me.
> > 
> 
>  We thought that perl was incorrectly installed in chapter 5, but in
> that first example we did not know the details of how it was wrong.

 Scrap the next two lines, I misread where you were, and corrected
the rest of my reply, but failed to remove these two lines.

> But now that I look at this, you are nearly at the end of chapter 6
> and so you are using the new version of perl in chroot.
> 

> > The version of the LFS book I'm reading is 7.5, and the problem came out in
> > chapter 5.32 when I execute the command:
> > 
> > ./configure --prefix=/tools
> > 
> > which gives the following 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 '1002' is supported by ustar format... yes
> > checking whether GID '1002' 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.
> > 
> > Executing the command "uname -a" on my host system will output:
> > 
> > Linux localhost 3.2.0-4-486 #1 Debian 3.2.46-1 i686 GNU/Linux
> > 
> 
>  The test in configure is:
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking Perl version and
> Encode module" >&5
> $as_echo_n "checking Perl version and Encode module... " >&6; }
> if $PERL -e "use 5.007_003; use Encode;" > /dev/null 2>&1; then
>   perl_version_requirement='yes'
> else
>   perl_version_requirement='no'
> fi
> { $as_echo "$as_me:${as_lineno-$LINENO}: result:
> $perl_version_requirement" >&5
> $as_echo "$perl_version_requirement" >&6; }
> if test z"$perl_version_requirement" = 'zno' ; then
>   as_fn_error $? "perl >= 5.7.3 with Encode required by Texinfo."
> "$LINENO" 5
> fi
> 

 And the remaining questions *are* for your current position in
chapter 5 : -
> type -pa perl
> perl -e "use 5.007_003; use Encode;" ; echo $?
> perl --version | grep version
> (That last grep is because 5.18.2 outputs a total of 12 lines for
> the version information.)
> 
>  You say you have /bin/sh pointing to bash, which is correct.  Was
> it pointing to dash earlier in your build ?  Have you rebuilt perl
> to try to fix this ?  If so, did you remove the perl source and
> re-extract it ?
> 
> ĸen
> -- 
> Nanny Ogg usually went to bed early. After all, she was an old lady.
> Sometimes she went to bed as early as 6 a.m.
> -- 
> http://lists.linuxfromscratch.org/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page

-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] failing to configure Texinfo package

[Ken Moffat]

On Sun, Jun 15, 2014 at 10:41:32PM +0200, Stefano Stoduto wrote:
> The output for those commands is:
> 
> type -pa perl
> 
> /usr/bin/perl
> 

 _Now_, in chapter 5, you are using the _host_ system's perl, which
meets all the requirements.  And so, you ought to be able to
"successfully" configure texinfo.

 I used double quotes on "successfully" because you should NOT be
using the host system's perl at this point in the build.  Have you
gone back in to the LFS build and somewhow not set $PATH, so that
everything in /tools/bin is ignored ?

 If that is the case, please go back in *correctly* and retry those
commands.  By that, I mean you need to go back in as if you were
going to continue in chapter 5.  The obvious problem in what you
have reported here is your PATH (we know you installed a newer
version of perl in /tools).

 [ Alternatively, if you have stayed in /mnt/lfs as user lfs, and
ran those commands as user lfs, then I cannot explain what is
happening ]
> ---
> 
> perl -e "use 5.007_003; use Encode;" ; echo $?
> 
> 0
> 

 The system version of perl in /usr/bin works.  But we need to find
out about the version in /tools/bin.
> ---
> 
> perl --version | grep version
> 
> This is perl 5, version 14, subversion 2 (v5.14.2) built for
> i486-linux-gnu-thread-multi-64int
> 

 That was a test to see if you were using the system version, and on
this occasion it showed you were.

> About the /bin/sh link, yes it was a link to dash, but I corrected it when
> I read the "Host System Requirements" in the Preface of the book, so I
> suppose it was correct when I built perl.
> 
ok
> When I encountered the problem building Texinfo I tried to rebuild perl,
> and since I already had deleted the sources I extracted them again.

ok

 The critical settings for chapter 5 are in section 4.4.  A quick
look at that suggests (to me) that only your PATH is wrong.  BUT,
when you are building chapter 5, you need to be user lfs with the
settings from section 4.4.

 Note:  If you ever have to go back to chapter 5 (for example,
because you did something wrong and only discovered that during
chapter 6) then things might be different - directories might be
owned by root instead of user lfs.
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Discovered a Major System "OOOPS" in Binutils Pass 1

[Ken Moffat]

On Sun, Jun 15, 2014 at 04:46:02PM -0500, Dan McGhee wrote:
> If it's what I think it is, it's more than an "OOOPS" for me, but I'm trying
> to be socially acceptable.  This is a little long and involved.
> 
> Configure failed on binutils-2.24 with what turned out to be
> 
> 
> > gcc: error while loading shared libraries: libgcc_s.so.1: cannot open
> >shared object file: No such file or directory
> 
> Now comes the really bad part.  'ls -al /usr/lib | grep libgcc' gives
> 
> >lrwxrwxrwx   1 root root 22 Oct 20  2013 libgcc_s.so ->
> >/tools/lib/libgcc_s.so
> >lrwxrwxrwx   1 rootroot 24 Oct 20 2013
> >libgcc_s.so.1 -> /tools/lib/libgcc_s.so.1
> 
> It looks like I got bit by my beloved Package Users system.  The install
> error log showed
> 
> >*** The file or link: "/usr/lib/../lib64/libgcc_s.so.1" is owned by root
> >and not gcc-4.8.1
> >*** The file or link: "/usr/lib/../lib64/libgcc_s.so"  is owned by "root"
> >and not "gcc-4.8.1"
> >*** The file: "/usr/lib/libgcc_s.so" is owned by "root" and not
> >"gcc-4.8.1"
> 

 A painful lesson, you have my sympathies.  As a general rule,
move /tools to a new name before you boot the system (or, after, and
then reboot to check it still boots).  When it boots without /tools,
you can remove it and create a symlink to /mnt/lfs/tools ready for
your next build.

> gcc-4.8.1 is the "user" that built gcc.  And it looks like, because the link
> could not be removed, the library never got installed and I got bitten
> really hard by my Package User System.  I darkly remember seeing that
> message at the time and didn't do any further checking. I've never had
> anything like this happen before.
> 

 Sadly, it is weird and unique issues like this which cause me to
suggest that the hint is more trouble than it is worth.  I am sure
that some people have no problems with it, and therefore we only see
the people who got bitten by it, but personally I would not touch it
with the proverbial barge pole.  So, not "I told you so" but "for
any script, try to understand _how_ it will fail".

 In my own case, I changed my scripts at some point in the last year
or so (to get better logging - anything changed during the package
should get into a "modified" log, including (in BLFS) system files
in e.g. /var which are often irrelevant), and I am *perhaps* now up
to speed with how it fails (in my case, understanding how little
information I get now that I have moved to 'set -e' instead of
testing $? everywhere, and being aware that my top-level scripts,
e.g. for chapter 6 or for everything I build in Xorg, can manage to
continue even after failures _if_ I omit a '&&' on a package script).

 For detecting files overwritten by another package, yes, package
users seems to work - my own routines _mainly_ will catch this in my
logs (if I can be bothered to look : it does not get flagged up
strongly and I only really care when we are heading for a new LFS
release).  But, I build over 350 packages in a typical desktop BLFS
install.  I see no benefit to having that many users on my system.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Multiple CPU cores, Make and Parallel Builds

[Ken Moffat]

On Sun, Jun 15, 2014 at 09:10:12AM -0500, William Harrington wrote:
> 
> Also, you should consider using number of processors with +1.
> Also, some build systems will fail to complete with even number of jobs. (In
> the past CD Paranoia would fail to build in such an instance and the
> Makefile would need to be patched)  All of the packages in LFS should be
> fine with an even number, but don't use it with the idea that because it has
> always worked in the past, it will work with all future build systems.
> 
> A system with lots of RAM will have a limiting factor of CPU time with a
> long build (test this with a gcc build).
> One task per CPU plus one pending task for occasional I/O blocks is a good
> setting.
> 
> With little amount of RAM there is a limiting factor of nat having very many
> jobs, which will make them swap out. There's no general figure. Most
> machines these days will not have that problem. So this can probably be
> disregarded.
> 
> It may be beneficial to have more jobs. If each compiler process is small
> and touches a lot of data then then disk I/O could be a blocking factor. In
> that case, you'll want several jobs per cpu at once so there is always one
> job using each CPU while others are waiting for I/O
> 
> All of this is variable depending on the build job and available RAM. There
> is an optimum setting, which after having too many jobs will pollute the
> cache too much.
> 
> You will need to experiment. Normally with your quad core machine, -j5 will
> be fine.
> 
 William, many thanks for that detailed exposition.  I have (often)
seen people recommending N+1 jobs, but without any explanation of
why it could be a good idea.  Until a couple of years ago, all my
machines were single processor : and when I tested, -j2 seemed to be
a lot slower than -j1.  I have also seen kernel devs mentioning that
they use large numbers of jobs.  You persuaded me to take the time to
build my normal kernel configs (for 3.15.0) on each of my desktop
boxes.  Each of these machines has motherboard graphics, which steal
some of the RAM, and in 32-bit mode there might be other things
stealing memory from the 32-bit address space (I do not use PAE -
bounce buffers offend me :)

 On my least-powerful box (AMD A4-5300, 2x3.4GHz) in 64-bit mode my
most recent system is LFS-7.4.  There, -j3 is slightly slower than
j2.

 Remaining notes are for LFS-svn-20140514.

 The A4 in 32-bit mode reports 2.5GB memory.  There. -j3 is faster
(by 30 seconds) than -j2, and -j4 is similar to -j2.

 The Phenom (4x3.4GHz, 7.9GB reported memory, 64-bit only) takes
approximately the same time for -j4 to -j8.  -j6 is fastest by about
two seconds, then it starts to slow down again, but these
differences are really lost in the noise.

 My intel SandyBridge i3-2120 is interesting.  64-bit only, 3.9GB of
RAM is reported.  It has two real cores, but 4 with hyperthreading
(so, four penguins).  This is actually faster than the Phenom (for
their own respective configs - the contents might be very different)
at -j1 and -j2, but it gains not much benefit from the third and
fourth jobs.  At -j5 it is slightly slower than with -j4.

 Of course, the results of running multiple C++ jobs in parallel
might be very different.

 I also suspect that things do change with different versions of the
toolchain.  So, test now, and test again in the future!  ;-)

 Brief summary - on my system which still does 32-bit builds, -j N+1
appears to be beneficial.  For all of my 64-bit builds, -j N is
about as good as it gets.

 This is with (cheap, slow) spinning rust (and ext4).  I'm sure that
people using SSDs might get very different results.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Multiple CPU cores, Make and Parallel Builds

[Ken Moffat]

On Sun, Jun 15, 2014 at 11:34:05AM -0400, Baho Utot wrote:
> On Sunday, June 15, 2014 03:58:44 PM Pierre Labastie wrote:
> > Le 15/06/2014 14:52, Dan McGhee a écrit :
> > > I know--this is the way LFS is wired--to follow the book precisely. Then
> > > all should be well.  If, however, I have a make failure whose cause I
> > > can't determine from the log, how can I recognize it as a failure based
> > > on too many jobs running at the same time? Or, better, failure based on a
> > > target completion before its dependencies are complete.
> > 
> > Try building with "make -j1"... Actually, remove the build directory and
> > unpack again before that. If the build succeeds with -j1, then it was a
> > parallel job failure.
> > 
> > According to Baho Utot, all packages in LFS are now "parallel job safe".
> > Not long ago, I know that dejagnu and man-db were not. With jhalfs
> > automation, we are conservative, and the list of packages built with -j1
> 
> I have tested -j1 to -j8 baoth on i686 and x_86_64.
> I ahve a eight core amd with 16GB ram and a very old dual core lapdog with 2 
> GB ram.  Both pass the multi core builds.  I have scripted the build with the 
> layout per the bbok and I also have a build that has LFS plus the rpm package 
> manager.  Both build system pass multi core builds and are reproducable.
> 
> The scripts are at:
> 
> https://github.com/baho-utot/LFS-SCRIPTED
> 
> https://github.com/baho-utot/LFS-RPM
> 
> 
> > is:
> > 
> > attr autoconf coreutils dejagnu gettext gperf groff man-db vim
> > 
> > However, many of those packages build with -jN. But the tests do not pass.
> > 
> > Pierre
> 
> I can provide log files to show that those packages multi core build as per 
> the book, without error.
> 
[ I kept the whole post for context ]

 On my builds, the only things in LFS where I specified -j1 were
udev variants, and then only because distros seemed to use -j1.  For
eudev, -jN seems fine (or at least, the reported test failure in
1.6, without any clear indication of what failed, did not appear to
be related to a -jN build).

 In BLFS, I mostly do not run tests.  I build the following with -j1
: nss, shared-mime-info, exiv2, ghostscript (my note says it failed
to find .libs/libopengpeg which looks like a typo, and I'm not sure
if -j1 is still needed with my current options), cdparanoia (I
suppose William's comment applies there), json-c, cyrus-sasl, bind.
Those last three are not part of my normal builds.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Multiple CPU cores, Make and Parallel Builds

[Ken Moffat]

On Sat, Jun 14, 2014 at 10:05:48PM -0500, Bruce Dubbs wrote:
> Dan McGhee wrote:
> >
> >This concept and "-j" have now become important to me and I'd like to
> >learn some more before I start.
> 
> man make
> 
> https://www.gnu.org/software/make/manual/html_node/Parallel.html#Parallel
> 
 I'm going off on a tangent here, and this is for beyond-BLFS,

 One of the packages I build on my desktops is mediainfo (originally
this was to let me check the durations of the streams in a video
when I was having difficulty getting youtube to accept it - ISTR
that was NOT the problem, and I now used it to check the tags in my
flac files).

 With recent versions, this has a bash script which appears to be
trying to use all the cores during the build (and I cannot see
anything _obviously_ wrong in what it is doing).  For me, on a box
with 4 cores (real or hyperthreaded) the desktop becomes unresponsive
(even the clock stops updating for long periods of time), but the
build does eventually complete and the system is again usable.  But
on my box with only two cores it does not complete in the amount of
time I have been prepared to wait.

 My guess is that for some reason the script decides there are far
more cores than actually exist, and that is what brings the box to
its knees (ISTR the code is C++, so everything probably assumes that
memory is an infinite resource).  In this case, I use a sed to
force it to use regular "make" (and therefore -j1 because the script
which runs the compile ignores $MAKEFLAGS) instead of the Zen_Make
function in the tarball's script.

 From this, I draw two conclusions :

1. Running too many jobs in parallel _will_ bring a system to its
knees.

2. Some packages are just _different_. ;-)

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Step 6.52 Kmod-16 LFS 7.5 stable --> make check failed for test-modprobe

[Ken Moffat]

On Mon, Jun 16, 2014 at 03:07:33PM +0200, Marcos Menendez wrote:
> Hello,
> 
> I had the following failure when running the make check for kmod-16:
> 
> 
> root:/sources/kmod-16# cat test-suite.log  
> ===
>kmod 16: ./test-suite.log
> ===
> 
> # TOTAL: 10
> # PASS:  9
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> .. contents:: :depth: 2
> 
> FAIL: testsuite/test-modprobe
> =
> 
> sh: error while loading shared libraries: libz.so.1: cannot open shared 
> object file: No such file or directory

> I searched for libz.so.1 and it exists on the chroot system:
> 
> root:/sources/kmod-16# find / -name libz.so.1
> /lib/libz.so.1
> 
> 

 Please take a look at the zlib instructions (section 6.11).  At the
end of those, we move the shared library to /lib and recreate
/usr/lib/libz.so : I guess that either you missed the last command
there: ln -sfv ../../lib/$(readlink /usr/lib/libz.so) /usr/lib/libz.so
or else something went wrong and the symlink is broken.  It should
point to ../../lib/libz.so.1.2.8

 A possible side-effect from this is that anything trying to link to
libz might have included the static library, libz.a.  I'm not sure
which, if any, packages would be affected by that.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] failing to configure Texinfo package

[Ken Moffat]

On Mon, Jun 16, 2014 at 10:03:52AM +0200, Stefano Stoduto wrote:
> 
> You're right, my fault. I forgot to log in as lfs user before run those
> commands.
> The correct output is:
> 
> type -pa perl
> 
> /tools/bin/perl
> /usr/bin/perl
> 
ok
> ---
> 
> perl -e "use 5.007_003; use Encode;" ; echo $?
> 
> Can't locate Encode.pm in @INC (you may need to install the Encode module)
> (@INC contains: /usr/local/lib/perl5/site_perl/5.18.2/i686-linux
> /usr/local/lib/perl5/site_perl/5.18.2
> /usr/local/lib/perl5/5.18.2/i686-linux /usr/local/lib/perl5/5.18.2 .) at -e
> line 1.
> BEGIN failed--compilation aborted at -e line 1.
> 2
> 

 It looks as if @INC is the problem.  I don't have a version of
/tools handy, but I can see that perl is configured for /usr/local
which is its default location.  Fortunately, it is not installed
there because the lfs user cannot write there, and anyway we
installed it by copying to /tools.

 So, something seems to be wrong in the command
sh Configure -des -Dprefix=/tools

 After running that command, a file config.sh is created.  I've just
done that andin my case there are some lines (starting at line 891
in my case) -

prefix='/tools'
prefixexp='/tools'
privlib='/tools/lib/perl5/5.18.2'
privlibexp='/tools/lib/perl5/5.18.2'

 I assume you got different values.  If you no longer have that
file, please try again (just the configure command, then check the
file).

 The only likely explanation I can see is a problem with the shell
on the host system.

> 
> One thing I forgot to mention, and that might cause the problem, is that
> the host system I'm using is a remote computer in my LAN, and I'm logging
> in through SSH to perform the steps from a windows machine (I'm using
> PuTTY). Don't know if this can be a problem.
> 
> I always login in the system as a regular user and then issue the command
> 
> su - lfs
> 
> to switch to the lfs user, as mentioned in section 4.3
> 

 I don't think remote access that will be related to this problem.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] failing to configure Texinfo package

[Ken Moffat]

On Mon, Jun 16, 2014 at 09:22:30PM +0200, Stefano Stoduto wrote:
> On 16 June 2014 16:49, Ken Moffat  wrote:
> 
> > On Mon, Jun 16, 2014 at 10:03:52AM +0200, Stefano Stoduto wrote:
> >
> >  It looks as if @INC is the problem.  I don't have a version of
> > /tools handy, but I can see that perl is configured for /usr/local
> > which is its default location.  Fortunately, it is not installed
> > there because the lfs user cannot write there, and anyway we
> > installed it by copying to /tools.
> >
> >  So, something seems to be wrong in the command
> > sh Configure -des -Dprefix=/tools
> >
> >  After running that command, a file config.sh is created.  I've just
> > done that andin my case there are some lines (starting at line 891
> > in my case) -
> >
> > prefix='/tools'
> > prefixexp='/tools'
> > privlib='/tools/lib/perl5/5.18.2'
> > privlibexp='/tools/lib/perl5/5.18.2'
> >
> >  I assume you got different values.  If you no longer have that
> > file, please try again (just the configure command, then check the
> > file).
> 
> 
>  I still got the config.sh file from the last compilation. The lines you
> mentioned are at line 891 in my case too, they are:
> 
> prefix='/usr/local'
> prefixexp='/usr/local'
> privlib='/usr/local/lib/perl5/5.18.2'
> privlibexp='/usr/local/lib/perl5/5.18.2'
> 
> I suppose that this indicates that I am using the host perl installation.
> So what should I do?

 No, it means that you configured perl for /usr/local (i.e.
something was wrong in the configure command, or it did not work as
we expect) but installed it in /tools.  Because we do an "install by
copying" for perl in chapter 5, that can happen.

 The question is, why did it get configured for /usr/local when you
appear to be correctly copying the commands.  At the moment, I think
the following are the two most-likely alternatives:

(a) you did not key the command in full, or mistyped the -Dprefix
part.  If you have still have the command in the LFS user's history,
you can check that.  If you do not have that information, try it
again and see if the results in config.sh change.

(b) your shell is not working as we expect.  If '(a)' did not solve
the problem, please try:

(b1) /usr/bin/bash Configure -des -Dprefix=/tools
and look to see if that gives any difference in that part of
config.sh

(b2) /tools/bin/bash Configure -des -Dprefix=/tools
and again look at those lines in config.sh.

 For both of those, the path to bash is required so that we know
which version is being used.

 At the moment, I am trying to understand why the command appears to
be doing the wrong thing.  If you have dash (the host's original
/bin/sh) you could also try

(b3) dash Configure -des -Dprefix=/tools
to get more possible evidence.

 It is, of course, possible that something else entirely is causing
the problem on this particular host distro.  As you originally
noted, this is not the first time the error has happened.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] failing to configure Texinfo package

[Ken Moffat]

On Tue, Jun 17, 2014 at 01:05:45AM +0200, Stefano Stoduto wrote:
> On 16 June 2014 22:56, Ken Moffat  wrote:
> 
> 
> > (a) you did not key the command in full, or mistyped the -Dprefix
> > part.  If you have still have the command in the LFS user's history,
> > you can check that.  If you do not have that information, try it
> > again and see if the results in config.sh change.
> >
> 
> That was the solution!
> 
> You're probably going to hate me... I looked at the command history and
> discovered that I forgot the '-' dash before the 'Dprefix'! And I managed
> to get it wrong every time! I should start copy-paste the commands from the
> book, I will probably cause much less trouble.
> 
> Adding the dash made the correct lines show up in the config.sh file, and
> the Texinfo package compiled successfully.
> Thank  you so much for the support. Now the challenge is to go through
> chapter 6 :)
> 
> ... I still can't believe this! Mistyped it every time!

 We all make mistakes - I'm glad you found out the problem and let
the list know.  Everything is for the best, in the best of all
possible worlds.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Step 6.52 Kmod-16 LFS 7.5 stable --> make check failed for test-modprobe

[Ken Moffat]

On Tue, Jun 17, 2014 at 10:12:30AM +0200, Marcos Menendez wrote:
> Hello,
> 
> I remember to have done that step clearly but I have a look at it again:
> 
Please do not top post, unless you have to - it makes understanding
your reply very hard.

[ snip what is in /lib ]
> 
> 
> Regarding libz.so, I run again the following to be sure:
> 
> root:/sources/kmod-16# ln -sfv ../../lib/$(readlink /usr/lib/libz.so) 
> /usr/lib/libz.so
> '/usr/lib/libz.so' -> '../../lib/../../lib/libz.so.1.2.8'
> 
> I check it:
> 
> root:/sources/kmod-16# ls -la /usr/lib/libz.so
> lrwxrwxrwx 1 root root 33 Jun 17 10:51 /usr/lib/libz.so -> 
> ../../lib/../../lib/libz.so.1.2.8
> 
> 
> Here I see that it doesn't point to ../../lib/libz.so.1.2.8 as you mentioned 
> before but instead it points to ../../lib/../../lib/libz.so.1.2.8 which 
> doesn't look right to me...
> 
> 
> I'm confused right now...
> 
 OK, it seems to be a "run once" command.  I had not spotted that.
What it is apparently supposed to do is take the target from the
libz.so which was installed into /usr, and then remake the symlink
but pointing to /lib.

 To fix it now, try

ln -sfv ../../lib/libz.so.1.2.8 /usr/lib/libz.so

 and then run

ls -l /usr/lib/libz.so

 to check that what I have suggested is correct.

 it should show this:

lrwxrwxrwx 1 root root 23 May 19 15:41 /usr/lib/libz.so -> 
../../lib/libz.so.1.2.8

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Step 6.52 Kmod-16 LFS 7.5 stable --> make check failed for test-modprobe

[Ken Moffat]

On Wed, Jun 18, 2014 at 10:09:12AM +0200, Marcos Menendez wrote:
> Hello,
> 
> Sorry for the top post before.
> 
 But you are still doing it.

> One question before we continue: What did you mean with a "run once command"?
> 

 A command which you can only run one time.  In this case, it uses
the results of running readlink on a symlink to *overwrite* the
symlink.  On the next run, the result from readlink will be
different.

> Now to continue, I corrected the symlink and now I have this:
> 
> root:/sources/kmod-16# ls -la /usr/lib/libz.so 
> lrwxrwxrwx 1 root root 23 Jun 18 10:32 /usr/lib/libz.so -> 
> ../../lib/libz.so.1.2.8
> 
> I run again the 'make check' but had the very same error. I deleted the kmod 
> folder and started over but nothing changed: it fails in the same part.
> 
> Sorry for, maybe, asking the obvious, but, if the error complains about  
> libz.so.1 why are we working on libz.so to fix the problem? I can't figure 
> out the connection between both files...
> 

 I looked at what was in the book's instructions for zlib.  I then
assumed that one or more of the commands for moving files to /lib
and then fixing the symlink had been missed or gone wrong.  In my
own case, I have been bitten by something similar - we used to have
the version hardcoded, and I forgot to change that when a new
version of zlib came out.

 I have assumed that the "connection" is that ldd finds a reference
to libz.so in the test program, and then looks for it.  Because the
symlink is pointing to libz.so.1 I assume that will give this sort
of error.  Perhaps I am mistaken.  If so, I apologise and you will
have to find somebody else who understands the error better than I
do.

 But first, what does 'file /usr/lib/libz.so' say ?

 And if you do have to top post, trim the old text.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Vim-7.4 Fails to Configure at the end of Ch. 5

[Ken Moffat]

On Sun, Jun 22, 2014 at 04:27:16PM -0500, Dan McGhee wrote:
> In building LFS-7.5 and as is my habit, I was trying to install Vim-7.4 into
> /tools before I started Ch. 6.  I did this at the same point last year when
> I built LFS-7.4, and all went well.  I like having vim available right at
> the beginning of Ch. 6 in the chroot environment.  However, this time
> vim-7.4 failed to configure with the following terminal output:
> 
> >checking --with-tlib argument... empty: automatic terminal library
> >selection
> >checking for tgetent in -ltinfo... no
> >checking for tgetent in -lncurses... no

 Based on what you say after this, I think you probably need to try
something like --with-tlib=/toolz/lib/libncursesw.so : the book
doesn't need non-wide libncurses in /tools, so (from a quick look at
my logs) we don't install it there.

> >checking for tgetent in -ltermlib... no
> >checking for tgetent in -ltermcap... no
> >checking for tgetent in -lcurses... no
> >no terminal library found
> >checking for tgetent()... configure: error: NOT FOUND!
> >  You need to install a terminal library; for example ncurses.
> >  Or specify the name of the library with --with-tlib.
> 
> This failure occurs, with identical output, whether I build as user lfs or
> as root in the chroot environment.
> 
> This, without all the other stuff, is what the configure log gives:
> 
> >3560  configure:10388: checking for tgetent in -lcurses
> >  3561  configure:10413: gcc -o conftest -g -O2 -I/usr/local/include
> >-L/usr/local/l
> >ib conftest.c -lcurses  -lnsl  >&5
> >  3562 
> > /toolz/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linu
> >x-gnu/bin/ld: cannot find -lcurses
> >  3563  collect2: error: ld returned 1 exit status
> 
> As I said this did not happen the last time I tried to do this.  I used
> `.configure --prefix=/toolz --enable-multibyte`
> 
> The use of "/toolz" is not a type-o.  It is my trying to recover from the
> major error that I made in building LFS-7.4 in which the links from
> /usr/lib/{libgcc_s.so*,libstdc++*} to /tools/lib--established at the
> beginning of Ch. 6--did not get removed.  I am reasonably sure, checked and
> double-checked, that I got "/toolz" everywhere "/tools" was indicated.
> However... The sanity checks of Ch. 5 passed and I have reread the
> book and don't believe I have missed or interchanged any major steps.
> However.
> 
> Because of this error, I want to make sure that my temporary tool chain
> works without error.  At this point, now, I am not sure. `./configure
> --help` indicates that I can use the switch "--with-tlib=library" but I
> don't know what to put there.  I'd like some guidance to see if it works.
> 
> Depending on the results of this troubleshooting, I could scrap my build so
> far and start over.  My instincts tell me that I made a mistake, but so far
> I haven't been able to figure it out.  I'm asking for help to resolve this
> situation.
> 
> Thanks,
> Dan
> 

 Your approach sounds good, but any problems you find will probably
not be common to the rest of us.  ISTR that at one time /tools was
hardcoded in at least one gcc patch, but I think that using your own
prefix (with corresponding name in /mnt/lfs) has probably worked for
a few years now.

 When you are developing on your own, do not be too ready to scrap a
build.  Yes, sometimes that is necessary, but it is often useful to
get everything out of the build (i.e. look at what exists, look at
configure scripts, try to identify why things do not work) before
you trash it.

 In this case, building vim in /tools is already outside the book (a
reasonable idea, particularly for manual builds, but if I need to
edit things I get root on the host system to edit the chroot file),
so most of us do not have any idea about what might go wrong there,
even before using /toolz.  If my suggestion above for tlib does not
fix this, I suggest that you take a look at cross-lfs : the details
are probably very different, but ISTR that vim got built somewhere
before chroot - perhaps only in the 'boot' option.  Of course,
whatever they do (or don't do) might not help here.  And also take a
look at vim's configure script in case the likely fix is fairly
obvious (some configure scripts are mostly _fairly_ easy to parse,
others are not - I have no idea what the tlib part of vim's
configure looks like).

 Good luck, and enjoy the learning.

 Also, if pointing tlib to libncursesw does let it compile, it needs
to be tested at run time (i.e. in chroot) to see if you can do
adequate edits : I guess that ASCII is the only thing needed before
vim has been built in chroot.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Vim-7.4 Fails to Configure at the end of Ch. 5

[Ken Moffat]

On Mon, Jun 23, 2014 at 11:10:30AM -0500, Dan McGhee wrote:
> On 06/22/2014 05:50 PM, Ken Moffat wrote:
> >On Sun, Jun 22, 2014 at 04:27:16PM -0500, Dan McGhee wrote:
> >>In building LFS-7.5 and as is my habit, I was trying to install Vim-7.4 into
> >>/tools before I started Ch. 6.  I did this at the same point last year when
> >>I built LFS-7.4, and all went well.  I like having vim available right at
> >>the beginning of Ch. 6 in the chroot environment.  However, this time
> >>vim-7.4 failed to configure with the following terminal output:
> After Ken's response, I checked CLFS and using his suggestions have tried to
> build vim-7.4 again.  With added configure options, and both as user and
> root in chroot the compile fails with this terminal output:
> 
> >checking --with-tlib argument... ncurses
> >checking for linking with ncurses library... configure: error: FAILED
> 
> I am using this configure command:
> 
> >CPPFLAGS=-I/toolz/include LDFLAGS=-L/toolz/lib ./configure --prefix=/toolz
> >--exec-prefix=/toolz --enable-multibyte
> >--with-tlib={ncurses,/toolz/lib/libncursesw.so}
> 
> The {ncurses,/toolz/lib/libncursesw.so} is there too show that I used both
> options two separate times.

try

echo "INPUT(-lncursesw)" >/tools/lib/libncurses.so

 We do the equivalent in chapter 6.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Vim-7.4 Fails to Configure at the end of Ch. 5

[Ken Moffat]

On Mon, Jun 23, 2014 at 07:56:42PM +0100, Ken Moffat wrote:
> 
> try
> 
> echo "INPUT(-lncursesw)" >/tools/lib/libncurses.so
> 
>  We do the equivalent in chapter 6.
> 
 Baho's configure switches look nicer than my suggestion.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Checking Understanding of Native Language Support

[Ken Moffat]

On Tue, Jun 24, 2014 at 11:10:39AM -0500, Dan McGhee wrote:
> I want to verify my understanding of Native Language Support.
> 
> If I build a package and use either --disable-nls or --without-nls,
> whichever is appropriate, in the configure phase, then the package installs
> in the language corresponding to my locale and there is no capability for
> someone who speaks, for example, Spanish to change the locale and see
> everything in Spanish.  Is this correct?
> 
> Thanks,
> Dan
> 

 I'm fairly sure packages built with this option will normally
install messages in English, irrespective of which locale you are in
when you build it.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Checking Understanding of Native Language Support

[Ken Moffat]

On Tue, Jun 24, 2014 at 11:40:28AM -0500, Dan McGhee wrote:
> On 06/24/2014 11:27 AM, Ken Moffat wrote:
> >On Tue, Jun 24, 2014 at 11:10:39AM -0500, Dan McGhee wrote:
> >>I want to verify my understanding of Native Language Support.
> >>
> >>If I build a package and use either --disable-nls or --without-nls,
> >>whichever is appropriate, in the configure phase, then the package installs
> >>in the language corresponding to my locale and there is no capability for
> >>someone who speaks, for example, Spanish to change the locale and see
> >>everything in Spanish.  Is this correct?
> >>
> >>Thanks,
> >>Dan
> >>
> >  I'm fairly sure packages built with this option will normally
> >install messages in English, irrespective of which locale you are in
> >when you build it.
> >
> >ĸen
> Thanks, Ken.  I was reading about nls in gcc and suddenly I realized that I
> was confused and wanted to "hone" my understanding.  :)
> 
> Actually, my goal is to build packages without having to scroll through
> blocks of non-English messages to get to the English portion--consolekit for
> one.
> 
> Dan
> 

 I think you might be talking about something different,  the option
'--disable-nls' is usually for warning and informational messages,
like "No such file or directory".  You do not scroll through them,
you get one.  If nls is enabled _and_ that message has been translated
for your locale's language in the package, you get the translation.
Otherwise, you get the English text.

 Your description of scrolling sounds more like desktop files (I do
not have ConsoleKit on this system, and I do not remember ever seeing
any multilingual output from it).  For example, exo from xfce has
installed /usr/share/xfce4/helpers/debian-sensible-browser.desktop [
really ? ] on my current system, and it starts off:

[Desktop Entry]
Version=1.0
Icon=debian
Type=X-XFCE-Helper
Name=Debian Sensible Browser
Name[ar]=متصفح ديبيان
Name[ast]=Debian Sensible Browser
Name[be]=Прадвызначаны Гартач у Debian
Name[bg]=Дебиан Sensible браузър
Name[bn]=ডেবিয়ান সংবেদনশীল ব্রাউজার
Name[ca]=Navegador sensible de Debian

 The asturian entry is because the name has not been translated.
I don't have a font for the bengali text on this machine, so I just
get boxes there.  For me, the arabic, belarusian, bulgarian and
catalan all render ok - even if I cannot claim to read the first
three. [ I am also amused that the bulgarian entry transliterates
Debian, but the belarusian entry doesn't.  Human languages and
writing systems are fun ;-) ]

 I suppose it is possible that omitting nls somewhere in the desktop
might change this, but I have no experience of where to look (and no
interest : I use a wm which doesn't use these new-fangled desktop
files, and on another machine of mine which has a lot more fonts I
am fairly sure all these languages will render).

 OTOH, I suppose that disabling nls might slightly speed up the
build for monoglot English speakers.  Equally, it is probably
untested in many places.

 Summary - it might do what you want, or it might not.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] some preliminary comments and a stopping point

[Ken Moffat]

On Sat, Jun 28, 2014 at 07:33:30PM -0700, logical american wrote:
> To all:
> 
> Here are some things I noticed while currently following v7.5 of the LFS
> book
> 
> 1. In the Chapter 3.1 Introduction  for creating the LFS partition, I
> actually
> was able to successfully do this as an original logged-in usr on openSuse
> v13.1 by
> running the Partition editor inside Yast while running under the live
> openSuse v13.1 KDE Desktop dvd which I had to download and iso image burn,
> and then reboot to, in order to avoid problems with mount setting up on
> the original /sda drive as / which stopped everything as the partition
> editor will
> not work on a mounted partition (well it will, but chaos can result)
> 
> After coming up under live KDE desktop, I could then access all 3 hard
> drives and partition them at will (and my own peril)
> 
> The partition editor both created the partition and formatted the filesystem
> as ext4, and I choose my 3rd drive just to be safe on both.
> 
> However when it came time to actually create directories, I was forced to
> use root privileges to do so, since the partition editor had created
> everything as root owner and group.
> 
> So my first question?
> 
> Should creating the lfs user and lfs group be done before doing any
> work on creating work spaces on the hard drive?
> 
 That seems unnecessary - you need to have root privileges to
create a filesystem.  Yes, you do need root privileges to let the
lfs user write to the new filesystem.

> 2. After creating the lfs user and lfs group, and setting up the bash
> environment, I used the following commands on the $LFS partition.
> 
>%chown -R lfs sources
>%chown -R lfs tools
>%chgrp -R lfs sources
>%chgrp -R lfs tools
> 
> Running
> 
>%ls -adl *
> 
> showed what I expected to see: (plus also all nested subdirectories and
> files)
> 
> drwx-- 2 root root 16384 Jun 28 10:54 lost+found
> drwxrwxrwt 3 lfs  lfs   4096 Jun 28 18:38 sources
> drwxr-xr-x 2 lfs  lfs   4096 Jun 28 18:46 tools
> 
> (The lost+found folder came from the partition editor operations)
> 
> 3. I am now stopped at Section 5.3 General Compilation Instructions because
> the assumed CLI commands do NOT match
> 
>   %which bash
> /bin/bash
> 
>   %which sh
> /bin/sh
> 
 Seems correct in itself.  Try ls -l /bin/sh but I don't think it is
likely to point to anything other than bash on opensuse.

>   %which gawk
> /bin/gawk
> 
>   %which bison
> which: no bison in (/tools/bin:/bin:/usr/bin)
> 
> I am on openSuse which uses Yast, not bison or yacc.  Does bison need to
> be installed?  I assume that the "sh" is set incorrectly also, although
> syntactically it is correct.
> 

 You are making guesses, but coming up with the wrong answers ;-)
We all have to start somewhere, so I will point out two things:

1. Yast is a package manager, it does not give the functionality
provided by bison or yacc.  You definitely need to install whichever
package provides those (almost certainly, 'bison' in opensuse).
First, try 'which yacc' just in case that is installed.

2. There is a list of host system requirements in the Prologue, and
within that is a script version-check.sh : you need to run that, and
to read and understand the results.  If anything is missing, you need
to install it.

 In general, distros provide binaries so that you can run their
version of linux.  But being able to _compile_ programs often
requires additional packages : a compiler (gcc), header files from
several of the packages, other packages such as bison.  If the
headers are packaged separately, they are probably called
"development" versions of the package.  Google found a very old link
which suggests that you need to use yast to _at_least_ install
"C/C++ Compiler and Tools".

 As a quick "rule of thumb", if you have not previously compiled
anything on this system then get to the stage where you think you
have met the requirements, and then try to compile binutils.

 By that, I mean you should create a binutils-build directory and
run ../binutils-x.y.z/configure from there (for a test build, just
use configure without options, as if you were going to build it for
/usr/local, then run make, then make
DESTDIR=/somewhere/you/can/write/binutils-test install.

 Do all that as a regular user (preferably, as yourself, not user
lfs - so the DESTDIR might be /home/randall/binutils-test if your
username is randall.  If that completes ok (echo $? gets a value of
0) then you will be able to see what got installed in the DESTDIR,
and you are probably in a position to start -  since most people
here know almost nothing about opensuse, it might be that you will
still need to install other packages.

> - Randall
> 
> -- 
> CONFIDENTIAL: This email message and/or any attachments is for the sole use 
> of the intended recipient(s) and may contain confidential information. Any 
> unauthorized review, use, copying, dissemination, disclosure, retention or 
> distribution is strictly prohibited. If you a

Re: [lfs-support] Step 8.3 Linux-3.13.3 - 7.5 stable --> LANG= variable value

[Ken Moffat]

On Mon, Jun 30, 2014 at 04:10:25PM +0200, Marcos Menendez wrote:
> Hello, 
> 
> Before I start with the kernel compilation I would like someone to clarify me 
> some things.
> 
> At step 
> 
> make LANG= LC_ALL= menuconfig
> 
> the book says 
> 
> 
> "This establishes the locale setting to the one used on the host. This is 
> needed for a proper menuconfig ncurses interface line drawing on UTF-8 linux 
> text console.
> 
> Be sure to replace  by the value of the $LANG variable 
> from your host. If not set, you could use instead the host's value of $LC_ALL 
> or $LC_CTYPE."
> 
> 
> My host is configured with LANG=en_US.UTF-8 but my chroot has been configured 
> for LANG=es_ES.ISO-8859-15 (my /etc/sysconfig/console is configured for 
> Spanish too).
> 
 Why not use es_ES.UTF-8 ?

> I would like to know the following:
> 
> 1) If the make LANG= refers to the one configured at chroot 
> or at the host.

 I believe we expect that your host system will be set up with the
locale you desire,  You can, of course, use any valid locales which
you wish (if you have installed them), so it does not really matter.

> 2) Is this just a temporal use of the LANG= variable for the make command to 
> just work fine?

 Temporary - it is in the environment when you run menuconfig.

> 3) Will this have as a result the compiled kernel to be 'associated' with 
> that LANG= value and only?
> 
 No, the kernel messages are always in English.

 For a Spanish keyboard, a problem showed up recently (dead keys not
working correctly - 'es' was picking up the olpc/ version, I think).
The fix is in the svn book (specify the relative path to the desired
keymap, if my memory is right) and might also be in the Errata for
7.5.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] comments during LFS 7.5 install and a final question

[Ken Moffat]

On Mon, Jun 30, 2014 at 04:45:16PM -0700, logical american wrote:
> Some comments while creating the LFS 7.5 system on an openSuse v13.1
> platform, I hope
> they might be usable to others.
> 
> 1 In the section Host System Requirements -
> 
>   The openSuse v13.1 zypper command enables program versions to be found:
> 
>   Example:
> 
>   %zypper info bash | grep Version
>   Version: 4.2-68.1.5
> 
>   but the version-check.sh script in LFS 7.5 book is already available.
> 
> 2. However the version-check.sh script had to be changed slightly to
>find the libgmp, libmpfr and libmpc libraries, as they
>were under /usr/local/lib* not /usr/lib in openSuse v13.1.
> 
 If that is true (and I have no reason to doubt you, but it seems
very unlikely - /usr/local is traditionally where the system owner
put things which are not part of the distribution), then it sounds
as if it is broken - recent versions of gcc need them, and things in
/usr should never require things in /usr/local.
> -- CHANGED TO 
> for lib in lib{gmp,mpfr,mpc}.la; do
>   echo $lib: $(if find /usr/local/lib* -name $lib|
>grep -q $lib;then :;else echo not;fi) found
> done
> unset lib
> ---
> 
> 3. gmp-6.0.0.tra.lz had to have the lzip package installed on openSuse v13.1
>in order to unzip this type of archive. (to me a recent change)
> 

 We do not care what hoops you have to jump through to get the host
distro to a suitable state where it can build LFS!  The details will
differ for each host distro.

>I choose to try to install gmp-6.0.0 since I use this library very much
> and it installed successfully.
> 

 I do not have the 7.5 book in front of me at the moment, but that
sounds as if you think it is OK to randomly try newer versions of
packages.  Sometimes it is ...
> 4. SPECIAL NOTE: gcc-4.9.0 will NOT install, evidently enough changes have
> occurred between it and gcc-4.8.2 to prevent
>LFS v7.5 from being able to compile this newer package.
> 

 and at other times it is not.  If you are building your _first_ LFS
system (but, reading the end of your mail, I think you are not even
building LFS), it is best to follow the most recent release.  Once
you understand how to configure it for your own hardware, and have
decided that you like it, then it is fine to follow the development
book (LFS-svn).  Of course now that we have many packages in BLFS,
the preferred route is probably to build enough of BLFS to make the
system useful (either as a desktop or a server, according to
whatever interests you).

 The recent versions of LFS-svn are probably reasonably OK in 64-bit
(there are some questions about 32-bit with gcc-4.9.0 : some people
think it is now OK, but very few people seem to have tried it).

> 5. Gawk "make check" failed unexpectedly (to me) with a message seemingly
> indicating that mpfr was not supported by the system, which is not true,
> since it was previously just built.
> 
> make[2]: Leaving directory `/lfs/gawk-4.1.0/test'
>  Done with shared library tests 
>  Starting MPFR tests 
> MPFR tests not supported on this system
>  Done with MPFR tests 
> make[2]: Entering directory `/lfs/gawk-4.1.0/test'
> 2 TESTS FAILED
> make[2]: Leaving directory `/lfs/gawk-4.1.0/test'
> make[1]: Leaving directory `/lfs/gawk-4.1.0/test'
> 

 From what you say later, you seem to still be in chapter 5.  At
that point, running the tests is a fool's game : there are many
things on the host system which can cause failure.  Even in chroot
when you are only reliant on the new system, there are sometimes
oddities which cause failures only for a few people.

> 6. Texinfo ./configure --prefix=/tools came up with a warning (unexpected to
> me, since ncurses was built)
> 
> 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.
> 

 No idea if that is normal, and I have no interest : chapter 5 is a
temporary system, the only thing which matters is that it should be
"good enough" to build chapter 6.
> -- End of comments to the LFS v7.5 install.
> 
> As to some other comments made upon my previous postings:
> 
> I appreciate the comments by both Bruce Dubbs and Christ Staub. Thanks for
> being pointed back to checking the Host System Requirements, which I did
> skip by glancing over the pages, instead of carefully reading them (which I
> did today)
> 
> Someone laughed about the mail disclaimer, that actually was from my Windows
> XP laptop which I was using as as Q&D mailout.

 That was me - I have no idea what Q&D means (I dare say I could
probably google it), my point was that if you send something like
that to _any_ public mailing list, you lack credibility.
> 
> One final question now that I have completed Chapter 5, except for stripping
> off the debug symbols and making the ownership change to root:
> 
>   Can

Re: [lfs-support] Adding a splash/boot screen for grub2

[Ken Moffat]

On Tue, Jul 15, 2014 at 10:59:24AM +0200, Marcos Menendez wrote:
> Hello,
> 
> After having finished my LFS I'm having some problems trying to accomplish 
> something that I thought it was easy:
> A boot screen.
> 
> I have read the following hints but they are out-of-date:
> 
> http://www.linuxfromscratch.org/hints/downloads/files/bootsplash.txt
> http://www.linuxfromscratch.org/hints/downloads/files/grub2.txt
> 
> I was searching through the GRUB2 docs at 
> 
> https://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents
> 
> but I couldn't find anything there too.
> 

 This is not something I would want to do, but take a look at
http://community.linuxmint.com/tutorial/view/1357
which I found by googling for grub2 bootsplash.

 Also, perhaps, look at plymouth e.g.
https://wiki.debian.org/plymouth
which provides a graphic animation while the kernel is booting.

[...]
> 
> Another thing is the 'update-grub'. It is not present in the installation of 
> grub2 used by LFS but every single page on the internet makes mention to it 
> as the command you need to run after a change in grub.cfg.
> 
> I discovered that it is just a script that runs the following
> 
> grub-mkconfig -o /boot/grub/grub.cfg
> 
> but as mentioned in the LFS grub installation page, it ruins the custom LFS 
> grub.cfg.
> 
 It ruins it because -o /boot/grub/grub.cfg overwrites it.  And what
you get, if you have multiple systems, is a pair of "normal" and
"recovery" variants (I've never understood what the recovery variant
is for) for every kernel/system combination.

 All you need to do is
#vim /boot/grub/grub.cfg

 Having a rescue CD (or rescue usb stick, I suppose) and a backup of
how the cfg was before you changed it is probably a good idea, just
in case the edit goes catastrophically wrong (I think that has
happened to me once).

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Adding a splash/boot screen for grub2

[Ken Moffat]

On Tue, Jul 15, 2014 at 11:14:25AM -0500, Bruce Dubbs wrote:
> 
> I forget how to get unifont.pf2, but the image is
> 
> Targa image data - RGB - RLE 1024 x 768
> 
> 
> You can create that with gimp.
> 
>   -- Bruce
 Those got mentioned in a reference I found this morning, probably
for linux mint : unifont was recommended as the best font (I looked
at the current ttf version a few days - interesting because of its
coverage, but not especially pretty or bold).

 It looks as if grub probably understands png and tga formats for
the pictures.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Adding a splash/boot screen for grub2

[Ken Moffat]

On Tue, Jul 15, 2014 at 06:54:46PM +0100, Ken Moffat wrote:
> 
>  It looks as if grub probably understands png and tga formats for
> the pictures.
> 
 But on reading more closely, perhaps png does not work.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] LFS 7.5 Chaper 4.4 setting up the environment

[Ken Moffat]

On Wed, Jul 16, 2014 at 05:30:05PM +, Michael Bradshaw wrote:
> im still having the same problem:
> 
> lfs@AOTdevcom ~ $ cat > ~/.bash_profile << "EOF"
> > exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
> > EOF
> lfs@AOTdevcom ~ $ cat > ~/.bashrc << "EOF"
> > set +h
> > umask 022
> > LFS=/mnt/lfs
> > LC_ALL=POSIX
> > LFS_TGT=$(uname -m)-lfs-linux-gnu
> > PATH=/tools/bin:/bin:/usr/bin
> > export LFS LC_ALL LFS_TGT PATH
> > EOF
> lfs@AOTdevcom ~ $ source ~/.bash_profile
> dircolors: no SHELL environment variable, and no shell type option given
> lfs@AOTdevcom ~ $ 
> 
 Please note: we do NOT like people who top-post on lfs lists,
and after a while some of us will stop caring about your posts.
If you have to use brain-damaged mailers, such as on phones or
in webmail, we might make allowances - but your mailer is
hiding its identity so for the moment I will assume you are wilfully
following the mickeysoft way of doing things  ;)

 Now, you said below that you are using mint (with xfce).  Mint is
derived from 'buntu (insert old "friends don't let friends use
ubuntu" joke - I'm actually replying from an old ubuntu system on my
underpowered netbook, using ssh to connect to my home server where
the mail is, so this really *is* a joke) and therefore you *really*
need to run version-check.sh from the Host System Requirements in the
preface.  There are a number of potential issues when building from
ubuntu or any other debian-derived distro, and in this context I
guess that dash, or perhaps distro scripts to allow for multiple
shells, might be involved.

 I have only rarely used dash, which seems to be standard in ubuntu
and perhaps even in debian, but I have seen strange errors when
trying to set environment variables on the way into chroot from
systemrescuecd (when I had copied an existing LFS to a new machine
and was chrooting to set up grub) which I think uses zsh, so I
assume this is probably a shell problem.

 You might also try adding SHELL=/bin/bash to your command.

 One further thought : was that an error (the command failed) or
just a warning ?  Try 'echo $?' _immediately_ after running that
command : 1 shows there was an error, 0 is ok.

ĸen
> 
> From: lfs-support  on behalf 
> of akhiezer 
> Sent: Monday, July 14, 2014 3:20 PM
> To: LFS Support List
> Subject: Re: [lfs-support] LFS 7.5 Chaper 4.4 setting up the environment
> 
> > From: Michael Bradshaw 
> > To: "lfs-support@lists.linuxfromscratch.org"
> >  
> > Date: Mon, 14 Jul 2014 19:46:03 +
> > Subject: [lfs-support] LFS 7.5 Chaper 4.4 setting up the environment
> >
> >
> >
> > Hello everyone!
> >
> >
> > First LFS build here and I have run into a problem. I'm trying to set up 
> > the environment to build in:
> >
> >
> > lfs@AOTdevcom ~ $ cat > ~/.bash_profile << "EOF"
> > > exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
> > > EOF
> >
> > lfs@AOTdevcom ~ $ cat > ~/.bashrc << "EOF"
> > > set +h
> > > umask 022
> > > LFS=/mnt/lfs
> > > LC_ALL=POSIX
> > > LFS_TGT=$(uname -m)-lfs-linux-gnu
> > > export LFS LC_ALL LFS_TGT PATH
> > > EOF
> 
> 
> Should be:
> --
> cat > ~/.bashrc << "EOF"
> set +h
> umask 022
> LFS=/mnt/lfs
> LC_ALL=POSIX
> LFS_TGT=$(uname -m)-lfs-linux-gnu
> PATH=/tools/bin:/bin:/usr/bin
> export LFS LC_ALL LFS_TGT PATH
> EOF
> --
> ; i.e. you missed the 'PATH=...' line.
> 
> 
> rgds,
> akh
> 
> 
> 
> 
> > lfs@AOTdevcom ~ $ source ~/.bash_profile
> > dircolors: no SHELL environment variable, and no shell type option given
> > lfs@AOTdevcom ~ $
> >
> >
> > I dont understand what went wrong, as far as i can tell it is exactly as 
> > the book has it. I looked through all the posts since 7.5 came out, i 
> > couldnt find anything specifically over this.
> >
> >
> > my distro that im building the LFS on is Mint 17 XFCE 32 on an old dell 
> > laptop
> >
> >
> > thank you for your help ahead of time!
> >
> >
> > -Michael
> 
> 
> --
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
> -- 
> http://lists.linuxfromscratch.org/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page

-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Errors in rebooting the completed system

[Ken Moffat]

On Wed, Jul 23, 2014 at 10:07:22PM +0200, a...@phyglos.org wrote:
> 
> In this case, "msdos" is the type, or class, of your disk partitions.
> 
> I don't see why you look for the linux kernel in partition 6 (msdos6) and
> set then your root filesystem in sda2. Maybe you are using logical
> partitions?
> 
 That doesn't seem _so_ unusual, although it was definitely worth
you mentioning it (in case it is part of the problem).

 When I first started using linux, I had a mix of primary and
logical msdos partitions (nowadays, I only use logical unless windows
is also on that box).  Disks used to get slower, the further into
the disk you put the filesystem [ as reported, in those days, with
hdparm ] - smaller tracks on the inside, so more frequent head
movement.  So, I consider that putting /boot at the end of the disk
is worthwhile - it only gets used when booting, which is
intrinsically slow (most time spent in the bios), and when writing
out a new kernel.

 Whether it makes any real difference with modern disks, I do not
know.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Linux kernel ATI Radeon configuration

[Ken Moffat]

On Thu, Jul 24, 2014 at 07:16:10AM -0500, Douglas R. Reno wrote:
> On Wed, Jul 23, 2014 at 11:20 PM, Douglas R. Reno 
> wrote:
> 
> > Hello all,
> >
> > I have installed LFS on my Toshiba Satellite C655D-S5529. I was using
> > kernel version 3.8.1 for a week because that is all I had at the time. With
> > any new version of the kernel I install, my laptop hangs when the console
> > framebuffer goes to load after "tsc clocksource" and soon displays a white
> > screen. I have an ATI Radeon HD 6350M (the "Evergreen" type), and I have
> > installed the proper firmware (I got it from a Debian Wheezy package). On
> > 3.8.1 it will only happen if I turn on the kernel modesetting. On all
> > future versions I select the "ATI Radeon: Y" in the kernel configuration as
> > I do in 3.8.1 and it still freezes like it did with the modesetting on.
> > What can I do to get it to boot?
> >
> > The firmware is working properly I believe (X is using the ATI driver).
> > Any help would be appreciated. Also, even 3.8.1 with the "ATI Radeon: Y"
> > selected I dont get my penguins and the resolution is huge.
> >
> > Douglas R. Reno
> >
> Hello all,
> 
> I was able to fix the problem myself last night. For future reference, I
> have a "Evergreen" type but I require PALM_* firmware. I just upgraded to
> kernel version 3.14.4 and I was able to get it booting OK, albeit a delay
> in startup by about 60 seconds and no penguins :-(. X won't allow by to go
> above 1024x768, so I think I will have to create a custom file to fix that.
> 
> Thank you,
> 
> Douglas R. Reno

 I've just seen your earlier post, and I was about to say that a
white screen sounds as if the firmware is missing - in this case, I
guess I should say ẗhe _correct_ firmware was missing.

 The delay of 60 seconds suggests that firmware is NOT being loaded
(it is a timeout).  I'm not up to speed with udev (systemd) changes
re userspace firmware loaders - I know there was a change in 3.16-rc
where the new option was enabled, but the help text implied it
should not be used on a recent system (and in fact for me it did not
make any difference) - but perhaps changing your setting of
CONFIG_FW_LOADER_USER_HELPER might make a difference. [ At the
moment I'm on my intel, which does not use firmware, so I am not
sure whether setting =y or not setting this worked on my radeons in
3.14 ].

 The absence of penguins suggests either that you have not enabled
the picture in your kernel config, or else that you are NOT in a
framebuffer :-(  One or other of those might explain why you cannot
get more than 1024x768.

 Yeah, firmware is "fun", and the items which are needed in one
kernel release might change in a later release :-(

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Linux kernel ATI Radeon configuration

[Ken Moffat]

On Thu, Jul 24, 2014 at 08:38:49PM +0100, Ken Moffat wrote:
> 
>  The delay of 60 seconds suggests that firmware is NOT being loaded
> (it is a timeout).  I'm not up to speed with udev (systemd) changes
> re userspace firmware loaders - I know there was a change in 3.16-rc
> where the new option was enabled, but the help text implied it
> should not be used on a recent system (and in fact for me it did not
> make any difference) - but perhaps changing your setting of
> CONFIG_FW_LOADER_USER_HELPER might make a difference. [ At the
> moment I'm on my intel, which does not use firmware, so I am not
> sure whether setting =y or not setting this worked on my radeons in
> 3.14 ].

 Re that paragraph: please note that I build my firmware into the
kernel (i.e. copy it to /lib/firmware when I build the system, then
set up my .config for that).  That is regarded as non-optimal (the
firmware is stored in kernel memory, which is not swappable, and
therefore that memory cannot be reused once the firmware has been
loaded), but it does seem to work comparatively reliably.  Depends
how much memory you have, of course, but also how much firmware you
need, which is why distros will not want to do it (they typically
have all possible firmware available, and loaded as-needed).

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Linux kernel ATI Radeon configuration

[Ken Moffat]

On Thu, Jul 24, 2014 at 05:13:23PM -0500, Douglas R. Reno wrote:
> Ken,
> 
> Right before the 60 second delay I get a error regarding "firmware direct
> load failed with error code -2". Could this be why my penguins aren't
> showing up? And for the penguins, do I have to enable the ATI Radeon option
> in the Framebuffer drivers and/or Generic VESA Framebuffer driver?
> 
> Douglas R. Reno

 I've not seen that message - google has a couple of results, but
nothing useful in them.  Maybe you only get it if you don't build
the firmware into the kernel, I'm not sure.

 On a radeon running 3.16.0-rc6, and with firmware built into the
kernel, the following settings look relevant for the penguins:

#
# Direct Rendering Manager
#
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_TTM=y

CONFIG_DRM_RADEON=y

CONFIG_FB=y

 and perhaps also (I'm running with these)

CONFIG_FIRMWARE_EDID=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MODE_HELPERS=y

CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y

 and your choice from
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

 FWIW, my firmware settings on this RS780 in 3.16-rc are as follows,
and I do not pretend to fully understand all of them (other than
knowing that I have to put the specified bin files in
/lib/firmware/radeon/ to build it like this, and also that your
firmware requirements are differnet from mine.

#
# Generic Driver Options
#
[...]
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin radeon/RS780_pfp.bin 
radeon/RS780_me.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
CONFIG_FW_LOADER_USER_HELPER=y

 That last one is the one which apparently changed in 3.16, and
which might break things on recent systems.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] LFS-7.5 Fails to Start after BIOS and Windows Update [SOLVED]

[Ken Moffat]

On Sun, Aug 17, 2014 at 05:10:03PM -0500, Dan McGhee wrote:
> On 08/16/2014 06:49 AM, Richard Melville wrote:
> >
> >I don't think it's a kernel issue.  I'd check your disk assignment/UUIDs
> >in the BIOS and grub to make sure the correct partitions are being called.
> >Of course, I could be wrong.
> No, Richard, you weren't wrong, but part of the problem was the kernel.
> When I moved from Windows 8 to Windows 8.1, the update added another
> partition AFTER the EFI Boot Partition.  Therefore, all the following
> partitions were raised by one number.  My LFS partitions moved from
> /dev/sda6 to /dev/sda7.  This, because I use the kernel efi stubs to boot,
> necessitated a reconfigured kernel because I pass "root=/dev/sdax, ro" in
> the kernel.

 Ugh!  That sounds horrible, I'm very glad you fixed it.  Replying
because of something a few paragraphs later:

>  I know more now, and
> when I get to that part in my LFS-7.5 build--maybe I should wait until 7.6
> now--

 Now that we are close to 7.6, and the main thing likely to differ
from current svn is the next glibc release, I think that it might be
a good time to wait : there is no point building an out of date
system.  Meanwhile, get your scripts, at least for those parts of
BLFS which you *really* want to build, up to date.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] 6.40 automake

[Ken Moffat]

On Wed, Aug 20, 2014 at 02:56:27PM -0500, Douglas R. Reno wrote:
> I was thinking uneXpected passes (for tests that were not supposed to pass
> but did. EXpected FAILures that passed rather than failed) that is just
> what I think it is though. I am not entirely sure.
> 
> Douglas R. Reno

 One of the best write-ups is at
http://www.delorie.com/gnu/docs/dejagnu/dejagnu_6.html

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Booting my LFS for the first time

[Ken Moffat]

On Sat, Aug 23, 2014 at 03:15:46PM +0200, Ronnie van Aarle wrote:
> One last thing, there is no need to change your kernel modules from linked
> to builtin. They are stored in /boot/modules and if you see the four
> penquins, this means grub is setup right and your system has acces to that
> path.

 That is not correct.  If you see the penguins, that ONLY means grub
has loaded a kernel (with framebuffer support), and that kernel has
started to initialise itself.

 In LFS, we do not use an initrd so everything which is required
before modules can be loaded MUST be built in.  The primary things
are the correct device drivers for your disk controller(s), and the
filesystems.

 Under SCSI device support on a typical recent x86 machine, enable
SCSI disk support, SCSI CDROM support, SCSI generic support (the
last two are for the CD/DVD device, so that you can burn a backup).

 Within Serial ATA and Parallel ATA drivers (libata) enable whatever
matches your hardware.  In a distro, use lsmod to see what got
loaded or lspci -v and google to see what chipsets you have, and
which drivers they use.

 Anything which is not needed before userspace has been brought up
(e.g. the network driver) can be a module.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] version 7.5 5.20 file-5.17 make problem, libz.so.1 Solved

[Ken Moffat]

On Sat, Aug 23, 2014 at 10:02:07AM -0400, Jean-Marc Pigeon wrote:
> I follow the book at my best, but:
> - Working within  VPS (openvz)
> - x86_64
> - doing all the jobs via RPM (binutils.spec, gcc.spec
> and so on) within a Makefile.
> 
 I will suggest that trying to use RPM while you are learning about
how LFS builds things is not a good idea.  Once you have
successfully built, and booted, LFS at least once then you can think
about using any package management system of your choice, if you
wish to.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Booting my LFS for the first time

[Ken Moffat]

On Sat, Aug 23, 2014 at 06:19:07PM +0200, Ronnie van Aarle wrote:
> I just googled grub configuration to make sure.
> 

 For the last time, please do NOT top post on this list.

> Unless you explicitly embed the grub menu configuration options in the grub
> image, grub loads its configuration file from /boot/grub/grub.cnf.
> 
> This means that system bios provides access to the storage device
> containing the boot files.
> 

 That seems a reasonable view of grub (I try not to delve into its
details - ALL bootloaders are nasty, because of what they have to
do).  But grub is not the issue - we agree that it has passed
control to a kernel.  And in LFS we do not tell grub to pass an
initrd to the kernel.

> Hardware device drivers and other features that must be compiled into the
> kernel also do not show 'm' as an option the kernel configuration menu.
> 

 If you have no sane configuration for your particular machine,
there is a very good chance that some of what you need is not
selected in whatever default config you happen to choose as a
starting point (e.g. 32-bit x86 or 64-bit x86_64, but people might
choose other configs as their starting point).  Similarly, a distro
config will have almost everything which it is possible to select,
but selected as modules.  Distros build to run on as many machines
as possible, using an initrd.

> However, I'm not exactly sure what runlevel, but from the stage where the
> kernel gets in control of handling the devices and the filesystem, from
> there on the right kernel objects for handling this must be available,
> loaded and initialized.

 Basically, once you get to udev (or udev_retry) in the LFS
bootscripts, in rcS.d before you get to a runlevel.  Before the
first of those, we mount proc, sysfs, and /run, then try to
auto-load modules [ might work, if the module is for specific
and recognizable hardware, but I would not rely on it in general ],
and we bring up the loopback interface.

 Between starting udev and retrying it we bring up swap, check the
filesystems, mount the filesystems defined in /etc/fstab for
automatic mounting, and clean out temporary directories.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] mount -o noatime ?

[Ken Moffat]

On Sun, Aug 31, 2014 at 11:05:07PM +0200, Emanuele Rusconi wrote:
> On 31 August 2014 22:49, Bruce Dubbs  wrote:
> >
> > The next time I build the book. I'll try with noatime and see if I can tell
> > any performance differences.
> 
> noatime is suggested when working with audio (see
> http://wiki.linuxaudio.org/wiki/system_configuration , for example). I never
> benchmarked it, to be honest, because I wouldn't know how to do that properly.
> I just trusted the source, and it seems reasonable to me.
> 

 Yes, for your completed new system.  But for building it, like
Bruce I have no idea.  I just run "mount -t ext4 /dev/sdaN
/mnt/lfs" when I'm building.  Any audio is on the host, not
/mnt/lfs.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] differences between en_US, en_US.iso88591, and en_US.utf8

[Ken Moffat]

On Sun, Aug 31, 2014 at 07:11:09PM -0700, Michael Havens wrote:
> Hola! I am in section 7.13 and am now attempting to figure out my locale. I
> live in the United States and speak English well not British English,
> but anyways! So I run 'locale -a' and get this list: I am told the first
> two letters represent the language and the second two letters represent the
> country. but what about the characters after that? in my particular case I
> would choose en_US, en_US.iso88591, or en_US.utf8. If I remember correctly
> from what I've seen I should select en_US.iso88591 but I am not sure. I
> also would like to know what the differences are between the three and why
> I should select one over the other... if that is not two much trouble...
> okay after a little more looking found that:
> 
>The only difference between en_US and en_US.utf8 is that the former uses
> ISO-8859-1 for a character set, while the latter uses UTF-8. *Prefer UTF-8.*
> The only difference in these is in what characters they are capable of
> representing. ISO-8859-1 represents characters common to many Americans
> (the English alphabet, plus a few letters with accents), whereas UTF-8
> encodes all of Unicode, and thus, just about any language you can think of.
> UTF-8, today, is a defacto standard encoding for text. (Which is why you
> should prefer it.)
> 
> I am assuming from the previous text (found here
> )
> that  en_US is an alias for en_US.iso88591 . It seems I am correct in that
> assumption:
> 'LC_ALL=en_US locale charmap' reveals
> ISO-8859-1
> I am thinking it is an alias! Am I correct?
> 

 It used to be.  For modern glibc, I have no idea.  Why not just use
the extra six characters and specify en_US.UTF-8 ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] differences between en_US, en_US.iso88591, and en_US.utf8

[Ken Moffat]

On Sun, Aug 31, 2014 at 10:03:47PM -0700, Michael Havens wrote:
>  It used to be.  For modern glibc, I have no idea.  Why not just use
> 
> > the extra six characters and specify en_US.UTF-8 ?
> >
> > en_US.UTF-8? Really? I was thinking the right thing to do was to  use
> en_US.iso88591 because en_US locale is it's alias. So, you are saying to
> use en_US.UTF-8?

 To add to what Simon said -

 Yes, ναι, да, kyllä, já, jā, có [ translations taken from google
translate, limited to to those characters which I expect to be able
to read in a tty ¹ ].  In ISO-8859-1 you would not be able to read
the cyrillic or greek, and I dare say that the macron on the a
probably doesn't render either.  Unfortunately, translations of
'yes' do not show up some of the Eastern European latin characters
which are fairly commonly encountered, such as c with caron č, l
with stroke ł, o with double acute ő.

 For example, there was a post on one of the lists last week from
somebody in Vietnam - in his sig he used the vietnamese version of
his name with diacritical marks not commonly used in european
languages (I think there was an 'i' with a dot below it : no I
cannot read that in a tty unless I restrict my console font to
vietnamese, but I can read it in a graphical term with some fonts
installed).  And we often get Eastern Europeans on the lists - it
is nice to be able to read people's names ins their postings.

 I saved this before sending it, and on the version of glibc in
LFS-7.4 [ my mail is on my server ] I can confirm that en_US was
indeed latin-1, and unable to make sense of some of my examples,
so I guess it always will be.

¹ Using my own LatGrkCyr fonts, of course ;-)

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] differences between en_US, en_US.iso88591, and en_US.utf8

[Ken Moffat]

On Mon, Sep 01, 2014 at 11:45:06AM -0500, Bruce Dubbs wrote:
> 
> Simon has some legitimate comments, but I don't use any setting for
> locale/LANG.  In my case, the man pages don't work properly:
> 
> LANG=en_US.UTF-8 man man
> 
> gives me things like:
> 
>  The manual page associated with each of these arguâ<80><90>
> 
> LANG=en_US.UTF-8 ls
> 

 My locale settings are
LANG=en_GB.UTF-8
LC_ALL=en_GB.UTF-8

 At the moment I'm on an old 7.5 system to test something else, but
there 'man man' is fine for me.  Pasting, and allowing mutt to
reformat it -

DESCRIPTION
   man  is the system's manual pager. Each page argument given
to man is normally the name of
   a program, utility or function.  The manual page associated
with each of  these  arguments
   is  then found and displayed.

(also checked in a tty, again no problem).  Your result almost looks
like a "unicode in legacy charset" result, but I cannot see any
reason why the middle of 'arguments' would generate unicode, nor
highlighting codes.  Very odd.

> also gives me a sort order that is not case sensitive. I do not like that.
> 

 A case-sensitive sort order is something that really annoys me,
so I am pleased tant en_GB.UTF-8 is case insensitive.  I guess that
is another example of "you can't please everyone".

> Note that graphical applications like mail clients and browsers often have
> their own independent locale settings.
> 
>   -- Bruce

 I was not aware of that.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] section 9.3

[Ken Moffat]

On Sat, Sep 06, 2014 at 03:01:30PM -0700, Michael Havens wrote:
> :-)~MIKE~(-:
> 

 Huh ?  You are sending text-plain and html, but AFAICS neither of
them contains anything except:

· your MIKE identification

· the mail you were replying to, including the imprecation not to
top-post

 So to me, you appear to be top-posting AND replying without any
content.  If you like, I can create a special place for you in
~/.procmailrc.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] section 9.3

[Ken Moffat]

On Sun, Sep 07, 2014 at 02:17:08PM -0700, Michael Havens wrote:
> 
> all fixed. except GPM says to run some commands as root which implies I
> should not be building as root. What user should I be building as?
> 
> :-)~MIKE~(-:

 Before you boot the new system, I don't think you have much choice.
Actually, I _suppose_ you could add your normal user (in fact, doing
that before booting _is_ a good idea, then if all goes well you can
log in as a user when the system boots), but then that user will
need a writable directory, and you will have to su to the user, and
then back to root for the install - that does not seem particularly
beneficial.

 For BLFS, we encourage a separation of what a normal user can do,
and what has to be done as root.  That does not mean that all of us
"obey" that - I am aware of various methods to build as a user, and
then install as root, and when I last overhauled my own scripts I
tried doing that, but I did not consider that it was beneficial (I
like to leave my main scripts (e.g. build xorg, or build gtk
toolkits with teir deps, or build firefox with its av deps) running,
which can take more than an hour on a slow machine - and having to
enter a password because sudo has timed out is painful.

 Security is an interesting game.  Building as a user certainly
limits your scope to cause damage, but if you have come to LFS then
you already own the box.  Backups are always good.

 Summary: it's your system, you will have to maintain it - do
whatever suits you.

 And thanks for bottom-posting.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] section 9.3

[Ken Moffat]

On Mon, Sep 08, 2014 at 03:15:53PM -0700, Michael Havens wrote:
> Before BLFS.
> I'm installing gpm and these are the errors make and make install gives me.
> Now it seems that (after googling 'fatal error: gpm.h: No such file or
> directory') that there is no problem but I need to verify this. Upon
> looking at this closer that is all I need to ask about.
> 
> root:/sources/gpm-1.20.7# grep -iE 'error|fail' {make,install,check}.fail
> make.fail:Makefile:90: recipe for target '.depend' failed
> make.fail:make[1]: [.depend] Error 1 (ignored)
> make.fail:prog/display-buttons.c:39:57: fatal error: gpm.h: No such file or
> directory
> make.fail:prog/display-coords.c:40:57: fatal error: gpm.h: No such file or
> directory
> make.fail:prog/get-versions.c:25:57: fatal error: gpm.h: No such file or
> directory
> make.fail:Makefile:90: recipe for target 'dep' failed
> make.fail:make[1]: [dep] Error 1 (ignored)
> make.fail:prog/display-buttons.c:39:57: fatal error: gpm.h: No such file or
> directory
> make.fail:prog/display-coords.c:40:57: fatal error: gpm.h: No such file or
> directory
> make.fail:prog/get-versions.c:25:57: fatal error: gpm.h: No such file or
> directory
> make.fail: #define CHECKFAIL(count)   ((count)==0 && noneofthem())
> make.fail:prog/mouse-test.c:569:4: note: in expansion of macro ‘CHECKFAIL’
> make.fail:CHECKFAIL(typecount);
> make.fail: #define CHECKFAIL(count)   ((count)==0 && noneofthem())
> make.fail:prog/mouse-test.c:622:4: note: in expansion of macro ‘CHECKFAIL’
> make.fail:CHECKFAIL(typecount);
> make.fail: #define CHECKFAIL(count)   ((count)==0 && noneofthem())
> make.fail:prog/mouse-test.c:671:4: note: in expansion of macro ‘CHECKFAIL’
> make.fail:CHECKFAIL(typecount);
> install.fail:Makefile:90: recipe for target 'dep' failed
> install.fail:make[1]: [dep] Error 1 (ignored)
> install.fail:prog/display-buttons.c:39:57: fatal error: gpm.h: No such file
> or directory
> install.fail:prog/display-coords.c:40:57: fatal error: gpm.h: No such file
> or directory
> install.fail:prog/get-versions.c:25:57: fatal error: gpm.h: No such file or
> directory
> install.fail:Makefile:117: recipe for target 'install' failed
> install.fail:make[1]: [install] Error 2 (ignored)
> grep: check.fail: No such file or directory
> root:/sources/gpm-1.20.7# tail check.fail
> tail: cannot open ‘check.fail’ for reading: No such file or directory
> root:/sources/gpm-1.20.7#

 Looking at my own log from 7.5, I see all of those.  It's a wonder
that it works at all, but it does.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] all done

[Ken Moffat]

On Tue, Sep 09, 2014 at 06:35:41PM -0700, Michael Havens wrote:
> On Tue, Sep 9, 2014 at 6:14 PM, Michael Havens  wrote:
> 
> >
> > okay I got the GUI computer going again. So I type in:
> >
> >pico /boot/grub/grub.cfg
> >
> > and the very first lines say:
> >
> >#
> ># DO NOT EDIT THIS FILE
> >#
> ># It is automatically generated by grub-mkconfig using templates
> ># from /etc/grub.d and settings from /etc/default/grub
> >#

 Don't believe it ;-)  Actually, chmod +w probably helps.  In LFS we
don't normally use grub-mkconfig.  If somebody has a machine where
they are trying to keep at least one non-LFS distro up-to-date, then I
guess grub-mkconfig might be worth exploring.  But for normal LFS
users, vim /boot/grub/grub.cfg is the way to go.

 The grub-mkconfig script is an interesting beast, and occasionally
useful : my experience is that it generally tries to match every
kernel it can find, to every linux system it finds, with two
versions (normal and recovery, or something like that).  But a few
days ago I changed one of my disks to GPT partitions and it was
reassuring to know what grub was calling my /boot partition -
something like hd0,gpt2 I think.
> >
> > I inspected the two files it mentions to see if there was an obvious way
> > to add:
> >
> >  menuentry "GNU/Linux, Linux 3.13.3-lfs-7.5" {
> > linux   /boot/vmlinuz-3.13.3-lfs-7.5 root=/dev/sda2 ro
> >  }
> >
> > but I didn't see one. (I am thinking I need to change the '/dev/sda2' to
> > '.../sda6' because that is the partition I put lfs on)

 Yes, add it at the end of grub.cfg but change it to the LFS partition.

> > Maybe I should do a boot partition.

 If you do not already have a suitable small partition, you will
need to repartition.  In that case, it is probably best to get as
much as you can from the current build - I don't think you have
booted LFS yet, so it is possible that your kernel config might be
less than perfect.  In any case, a completed LFS is sparse, most
people want quite a lot of other things - until your LFS/BLFS is as
useful to you as your debian system, keep both of them.

 When you repartition, make good backups and understand that the
partition numbers might change (for LFS, the root= on the grub
command line, and any partitions mentioned in fstab).  Planning is
useful, so is flexibility - in the last fortnight I have
repartitioned all three of my desktop systems (BLFS nowadays is so
big ;) - the first was a breeze, the second had problems using a
particular external disk on a current kernel (still haven't checked
if that is a continuing problem - I fell back to 3.14), and for the
third my network did not work with SystemRescueCD which was a
surprise (most of my backups are on nfs).  So, I guess that
repartitioning is not something to do without some prior thought.
> >
> > :-)~MIKE~(-:
> >
> 
> I  just noticed something in grub.conf:
> 
>### BEGIN /etc/grub.d/40_custom ###
># This file provides an easy way to add custom menu entries.  Simply
>type
>the
># menu entries you want to add after this comment.  Be careful not to
>change
># the 'exec tail' line above.
>### END /etc/grub.d/40_custom ###
> 
> So is this blurb telling us TO edit the file even though the first lines in
> the file tell us not to?
> I think I need a boot partition because I plan on reformatting the debian
> partition when I finish with this.
> :-)~MIKE~(-:

 No, it is telling you to put weird things (e.g. memtest86) in the
40_custom file.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] all done

[Ken Moffat]

On Tue, Sep 09, 2014 at 09:00:13PM -0700, Michael Havens wrote:
> On Tue, Sep 9, 2014 at 7:43 PM, Ken Moffat  wrote:
> 
> >  Don't believe it ;-)  Actually, chmod +w probably helps.
> 
> 
> did you want me to add the write bit to my lfs?
> 
> 
> vim /boot/grub/grub.cfg is the way to go.
> >
> 
> don't get mad. I used pico.

 LOL, I had moved on to 'joe' by the time I started using lfs.
[...]
> 
> It was less than perfect (darn). after rebooting and selecting the lfs OS
> the response I got was an immediate:
> 
>error: file not found
> 
> then it also said to press any key to continue which took me back to the
> grub menu. The real bad thing is that it didn't tell me which file was not
> found.
> 

 The error is in grub.cfg - I suspect you have not copied the lfs
kernel to the debian /boot partition.  So, if the lfs kernel is on
sda6 along with the lfs system, try

set root='hd0,6'

but ONLY do that in the lfs entry.

> > people want quite a lot of other things - until your LFS/BLFS is as
> > useful to you as your debian system, keep both of them.
> >
> 
> My LFS box has a huge drive. I have 6 partitions currently and sticking
> another one on in the unpartitioned space will be no problem. Is there a
> way to get lfs to recognize them by label or (what is it called...) UUID(?).
> :-)~MIKE~(-:

 The kernel itself does not know about UUIDs.  They are handled in
the initrd, and LFS does not use an initrd.  For ext2/3/4 you can
_mount_ by label [ man e2label ] which allows things like this in
/etc/fstab :

LABEL=home /home auto defaults,noatime  12

but I believe the grub entry still needs to point to root=/dev/sdaX
and therefore it would not help.

Also, for LFS the UUID stuff in grub.cfg is not needed, and will
cause pain if you ever have to restore backups to a new disk.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] all done

[Ken Moffat]

On Wed, Sep 10, 2014 at 01:12:27PM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> 
> >  The error is in grub.cfg - I suspect you have not copied the lfs
> >kernel to the debian /boot partition.  So, if the lfs kernel is on
> >sda6 along with the lfs system, try
> >
> > set root='hd0,6'
> >
> >but ONLY do that in the lfs entry.
> 
> Wrong syntax I think.  The traditional syntax is:
> 
> set root=(hd0,6)
> 
 Not wrong, but perhaps different from what you are used to.

 This is what I'm using on the i686 7.6 system I have just built -
menuentry "LFS-7.6-minimal i686 3.16.2 (sda9)" {
insmod ext2
set root='hd0,msdos15'
linux   /vmlinuz-3.16.2-sda9 root=/dev/sda9 ro
}

What I have in my various grub.cfg files is based on what
grub-mkconfig itself offered.
> 
> You can specify a partition uuid.  No initrd required.  For example:
> 
> linux /bzImage root=PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e ro
> 
> The partition UUID is not the same as a filesystem UUID and the partition
> table must be of type GPT (another advantage of GPT).  To find it, type
> something like:
> 
> $ blkid /dev/sdb1
> /dev/sdb1: UUID="e337b2bd-3899-4307-b374-e1c4cb1b5b8e" TYPE="ext4"
> PARTLABEL="Linux filesystem" PARTUUID="4a1bdb85-2937-4c44-96bc-c9387c43779a"
> 
> There are advantages and disadvantages.  A disadvantage is, as stated above,
> when restoring a backup.  An advantage is more consistency on large hard
> drives where partitions may be created and deleted more frequently.
> 
 Interesting, I had forgotten about partition UUIDs because I have
only just tried GPT partitions.

 Since we are now mentioning them, for the boot disk (presumably
/dev/sda) on a machine using a bios [ rather than EFI, which is a
hornet's nest of possibilities ] with a GPT partition, the
recommendation in http://www.gnu.org/software/grub/manual [ section
3.4 ] is that partition 1 should be a BIOS Boot Partition.  This is
NOT the /boot partition. Unfortunately, links will not let me copy
and paste.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] all done

[Ken Moffat]

On Wed, Sep 10, 2014 at 11:15:07AM -0700, Michael Havens wrote:
> On Wed, Sep 10, 2014 at 8:36 AM, Ken Moffat  wrote:
> 
> >
> >  The error is in grub.cfg - I suspect you have not copied the lfs
> > kernel to the debian /boot partition.  So, if the lfs kernel is on
> > sda6 along with the lfs system, try
> >
> > set root='hd0,6'
> >
> > but ONLY do that in the lfs entry.
> >
> >
> 
> error: invalid filename `set'
> I think I did that wrong: this is the menu entry I tried:
> 
>menuentry "GNU/Linux, Linux 3.13.3-lfs-7.5" {
> linux set root='hd0,6'  /boot/vmlinuz-3.13.3-lfs-7.5 root=/dev/sda6
> ro
>}
> 
> I think I put the set root in the wrong place. I tried moving it to
> another location (after menuentry) but that wasn't right. What to do now?
> 
> 
> :-)~MIKE~(-:

 This is what I am using for the system I have just booted:
menuentry "LFS-7.6-minimal i686 3.16.2 (sda9)" {
insmod ext2
set root='hd0,msdos15'
linux   /vmlinuz-3.16.2-sda9 root=/dev/sda9 ro
}

Again, my insmod is because that is what grub generated, and you
might not need it.  Set goes on a separate line before the linux
command.

FWIW, 'minimal' means no-acl, and possibly omits some other things -
I've already done one by-the-book 7.6 build on x86_64.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] UDEV-208 Fails to Compile in LFS-7.5

[Ken Moffat]

On Sat, Sep 13, 2014 at 06:35:12PM -0500, Dan McGhee wrote:
> I am sorry to ask a question like this when most of you are working hard to
> release 7.6.  I'm pushing to finish 7.5 to make sure my scripts all work and
> to "play" with GRUB for UEFI.

 For that, when you get there, you might want to talk to the person
who posted on -dev this week : his posts will be in the archives.
> 
> Udev-208 fails during "make" with
> 
> >LINK build/udevd
> >/usr/bin/ld: cannot find -lblkid
> >collect2: error: ld returned 1 exit status
> >udev-lfs-208-3/Makefile.lfs:232: recipe for target 'build/udevd' failed
> >make: *** [build/udevd] Error 1
> 
> ls -al /usr/include | grep id gives:
> 
> >lrwxrwxrwx  1 udev-208 udev-208 20 Sep 13 22:46 blkid ->
> >/toolz/include/blkid
> >lrwxrwxrwx  1 udev-208 udev-208 19 Sep 13 22:46
> >uuid -> /toolz/include/uuid
> [I removed the other two results]
> 
> and ls -al /toolz/include | grep id gives:
> 
> >drwxr-xr-x  2 root root   4096 Jun 16 18:56 blkid
> >drwxr-xr-x  2 root root   4096 Jun 16 18:56 uuid
> and blkid.h and uuid.h exist in their appropriate directories.

 But that is not the problem.  The compiler presumably found them,
but it is the linker (ld) which cannot find the _libraries_.
> 
> echo $LD_LIBRARY_PATH gives "/toolz/lib."

 Is that full-stop a typo in your post, or a typo from your script ?
And do /toolz/lib/libblkid.so* and also /toolz/lib/libuuid.so* exist
(each should have .so, .so.1, .so.1.something variants, two of which
are symlinks) ?
> 
> (Please don't ask about "toolz."  I screwed up in 7.4 and must use /toolz
> instead of /tools until I get another complete {,B}LFS system)
> 
> As most people know, I use the Package Users System.  I've tried building as
> user=udev-208 and root.  I get the failure in both situations.  In
> situations like this, my experience tells me that the solution is something
> terribly simple.  I *think* I have checked the obvious simple stuff, but I'm
> out of ideas.
> 
> Thanks,
> Dan
> 
> 
 Scripts can be fun ;-)

en
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] In Systemd Version 7.6-systemd-rc2 Networking Not Working

[Ken Moffat]

On Sun, Sep 14, 2014 at 06:10:08PM -0400, Alan Feuerbacher wrote:
> 
> Hmm. Up to this point I've done most BLFS stuff on the host system, because
> I found several years ago that it was much easier having all the tools
> available that are not yet installed on the target system.
> 
> What are the implications of doing most BLFS stuff on the host system in
> chroot, as opposed to doing it on the running target system? In my
> ignorance, I would have thought that using chroot on the target system was
> the way to go.
> 
> Alan
> 
 Building in BLFS in chroot is mostly ok.  Occasionally, people get
strange errors : one package, probably firefox, has a note that in
chroot you need to specify the shell : I have no opinion on whether
or not that is true (specifically, it was true for somebody, so I
suppose I have no opinion on whether it is _still_ true and applies
to _all_shells_.

 In chroot, there are three things you cannot test:

1. booting, in particular: does the kernel config work for you, and
is your grub config ok ?  For both of these, I would prefer to find
out sooner rather than later.  Mostly. I edit the grub file on the
host system. and build from the same kernel on the (LFS) host.  And
in _all_ cases I build some of BLFS at the end of LFS (e.g. fcron,
nfs, openssh, rsync, links, some of alsa).

2. bootscripts or systemd units.

3. in general, you cannot test if what you have just built actually
works when you run it.

 So, if I'm dubious about the kernel, or grub, configs then I will
try to boot the new system to check them.  Sometimes, I build past
firefox in chroot so that the new system will be partially-usable,
other times I boot and accept a limited usability while I build the
rest of it [ fun if it doesn't build, e.g. my experience last week
with the ati xorg driver ].

 But once you have built LFS a few times, you really ought to be
looking at scripting it (and, from my experience, understanding what
happens _when_ your scripts fail).  They don't have to be your own
scripts, but sticking with the project and building it all by copy
and paste is a tedious process.

ken [ again, I forgot that urxvt under xfce under lxdm is ignoring
my AltGr key, but this time I spotted it before posting! ]
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] make[2]: *** [magic.mgc] Segamentation fault (core dumped)

[Ken Moffat]

On Wed, Sep 17, 2014 at 09:31:10AM +0800, Jeffrey Toseng wrote:
> On Wed, Sep 17, 2014 at 5:06 AM, Pierre Labastie 
> wrote:
> 
> > Back to your problem...
> > No problem with version-check.sh?
> >
> Thanks Pierre for your advice.
> 
> No version-check.sh script found searching from root folder of
> lfs-packages-7.5 and all its subfolders.
> 

Please see
http://www.linuxfromscratch.org/lfs/view/stable/prologue/hostreqs.html

You appear to be running on ubuntu, so it is almost certain that the
basic host system is NOT in a fit state to build LFS (e.g. /bin/sh
linked to dash, perhaps awk linked to mawk, maybe other things).

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Error building binutils-pass2

[Ken Moffat]

On Thu, Sep 18, 2014 at 10:00:08PM +0200, hans kaper wrote:
> Whether I try to build LFS 7.5 or a recent SVN, whether I use LFS 7.4 or Mint 
> 13 as host, whether I use a laptop or a desktop, I always get the same error 
> in building binutils-pass2:
> 
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... configure: error: in 
> `/mnt/lfs/sources/binutils-build':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.
> 
> In that config.log I see no relevant details.
> 
> Building the other tools-packages gave no errors, but one thing that struck 
> me though was the result of the test after building glibc:
>   [Requesting program interpreter: /tools>-linux.so.2]
> 
> I copy-pasted the commands and inspected them very carefully but did not find 
> any clues.
> 
> I do something systematically wrong, but what?
> 
> 
> 
> Hans.

 Binutils, like a few other packages, will run configure scripts in
multiple directories, and each will produce its own config.log in
that directory - if it gets that far.

 But your comment on the requesting program interpreter horrifies
me.  /tools>-linux.so.2 is a very weird filename, '>' should not
appear in it (ignoring for the moment that fact that /lib/ld has
beeen replaced by that character, and therefore your result is
manifestly NOT in the expected form.

 Trying to continue anyway after an error like that will end in
tears.  Much better to ask for help before wasting cycles building
libstdc++.

 I think your attempts to run the seds for linux64.h, linux.h,
sysv4.h in gcc pass 1 have gone seriously wrong.  How are you
entering them ?  Are you pasting from a PDF ?  If so, please use an
html version of the book.

 Also, please note that we copy each of those files to a .orig
version, so when you next try gcc (using fresh source and build
directories, please) you can run just
find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h
before you run the command, and make a note of the files you are
going to alter.  Some of them will may be for other architectures or
operating systems, so concentrate on the x86 (i386?) linux files.

 After making a list of the files, run the command.  Then take one
of the files and run 'diff filename.orig filename | less' : you
should be able to see what changed, and you should see things like
'/tools/lib/ld-linux.so.2'.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Why not always use a longterm support kernel?

[Ken Moffat]

On Sun, Sep 28, 2014 at 01:35:53PM -0500, William Harrington wrote:
> 
> I guess since 2.6 it did change from how it was before then, since new 
> feature development now takes place in the same revision number.
> 
 Yes, 2.5 was very unpleasant.  The "rule" now is "no regressions" -
obviously, there are occasional exceptions, and other cases where
nobody noticed - so, the more people who run a current kernel, the
sooner regressions will be noticed.

> 3.2 has up to release 63 , EOL 14 September 2014

 I thought this was still being maintained, but it is so old that
nobody using LFS is likely to care.

> 3.4 has up to release 104, EOL 25 September 2014 (Or possibly in October 2014)

 Still maintained, with a new maintainer.  But again, too old for
LFS users to care about.

> 3.10 has up to release 55, 17 September 2014 slated EOL September 2015

> 3.12 has up to release 28, 7 September 2014 till 2016

> 3.14 has up to release 19, 17 September 2014 till August 2016

 So, anybody who now wants a stable kernel (e.g. for a server where
they do not intend to frequently update kernels) should probably be
using 3.14.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

[lfs-support] Bash-4.2 (for older systems)

[Ken Moffat]

 For anybody still running bash-4.2, and who does not wish to update
to 4.3 (which apparently needs current readline - Fernando reported
that broke apps linked agaisnt readline, such as fcron, until they
were recompiled) I've now uploaded bash-4.2-fixes-13 to patches.

 This contains everything which was in the upstream 4.2 patches when
I looked (maybe an hour or two ago), critically it includes Florian
Weimer's patch to add prefix and suffix for environment variables
which contain shell functions [ bash42-050 ] - but I see that Bruce
has now updated 4.3 again, not sure if that means there will be more
changes for 4.2.

 I'm lucky - I don't have any public-facing systems, or users apart
from myself, so I hope that anybody else using bash-4.2 has already
either used the upstream patches, or moved to 4.3 and current
readline.  But somehow, I doubt that ;-)

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 7.6: Failure at 6.9. Glibc-2.20

[Ken Moffat]

On Mon, Sep 29, 2014 at 09:26:47PM +, Andrew Woodward wrote:
> Hello,
> 
> First time attempting LFS.
> 
> I've got as far as Chapter 6, section 6.9 Glibc-2.20. I'm getting the 
> following errors:
> 
> FAIL: math/test-ildoubl
> FAIL: math/test-ldouble
> FAIL: posix/tst-getaddrinfo4
> Summary of test results:
>   3 FAIL
>1719 PASS
> 121 XFAIL
>   3 XPASS
> 
> The book mentions the "posix/tst-getaddrinfo4", but there is nothing 
> about the other two errors. I can't find any information on these 
> failures.
> 
> I've checked back and can't see what (if anything) I've missed or done 
> wrong.
> 
> 
> Build environment:
> Linux Mint 17 (Qiana) / Mate 1.8
> Linux andrew 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 
> 2014 x86_64 x86_64 x86_64 GNU/Linux
> AMD Athlon(tm) II X4 640 Processor
> 
> 
> 
> Any advice appreciated.
> 
 Normal for some *AMD* x86_64 boxes - I have three, the older two
(Athlon II x2, phonon) both show these 3 failures, my Intel
SandyBridge and my AMD Trinity (x86_64) do not.

 FWIW, I also build i686 on the Trinity, and there it gets 5
failures:

FAIL: malloc/tst-malloc-usable
FAIL: math/test-ldouble
FAIL: nptl/tst-cleanupx4
FAIL: posix/tst-getaddrinfo4
FAIL: rt/tst-cputimer1

 No problems from any of these.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Bash-4.2 (for older systems)

[Ken Moffat]

On Tue, Sep 30, 2014 at 02:38:14PM +0200, loki wrote:
> On Tue, 2014-09-30 at 08:00 -0300, Fernando de Oliveira wrote:
> 
> > On 30-09-2014 04:10, loki wrote:
> > > On Mon, 2014-09-29 at 21:58 +0100, Ken Moffat wrote:
> > >
> > >> For anybody still running bash-4.2, and who does not wish to update
> > >> to 4.3 (which apparently needs current readline - Fernando reported
> > >> that broke apps linked agaisnt readline, such as fcron, until they
> > >> were recompiled) I've now uploaded bash-4.2-fixes-13 to patches.
> > >
> > >
> > > Heya,
> > >
> > > I'm interested in what kind of problems Fernando had with fcron. Because
> 
> 
> 
> 
> > Failed to start/restart. But I noticed that it depends on the version, 
> > fcron problem was not reproduced in another machine. But LLVM2-2.02.96 
> > failed for both.
> > 
> 
> 
> Ok, thx, Read it. Fortunatly I don't have fcron above 3.1.2 :) For them
> I can say that they don't have any problems. The oldest fcron that I'm
> driving is 3.0.4. 
> (Yup, I have some very very old servers running very old LFS :)  -
> kernel 2.6)
> 
> Regards,
> Daniel
> 
 I think you might be missing the point - Fernando only reported
problems for the packages/versions he is running.  My impression is
that _anything_ linked to libreadline.so.6 *might* have a problem
because of changes between 6.2 and 6.3 : I don't have any systems as
old as yours, but it is possible that something with a 2.6 kernel
might be linking to libreadline.so.5. Use 'ldd' to check that.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Can someone please enlarge on this explanation?

[Ken Moffat]

On Tue, Sep 30, 2014 at 02:09:41PM +0100, Hazel Russman wrote:
> 
> I don't have the logs anymore because I always remove my build directories 
> immediately after installing. But I've just diffed the two compiled libraries 
> and they're identical!
> 
 Logs can be useful things - sometimes, a package gets
mis-installed, or nobody noticed that the behaviour was different in
a newer version [ probably not the case for a released version of
hte book ].  So, keeping them is worthwhile.  Mine are in /home/logs
: for LFS, I bind that at [/mnt/lfs]/logs and create a
LFS-version/tools directory which user lfs can write in.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Compile error in LFS 7.6: cross GCC - chapter 5.5.1

[Ken Moffat]

On Sun, Oct 05, 2014 at 12:14:59AM +0300, Andrei Banu wrote:
> Hi,
> 
> I am attempting LFS version 7.6 but I got stuck on chapter
> 5.5.1 (cross GCC compile).
> 
> The host is CentOS 6.5 / 64bit:
> Linux 2.6.32-431.el6.x86_64 #1 SMP
> 
> The /configure worked ok. The error came during make.
> 

 gcc (also binutils, and a few other packages) run 'configure in
various directories after 'make' is invoked.  Also, gcc will
eventually run a second build to check itself.
> The error message is this:
> 
> 
> checking how to run the C++ preprocessor... /lib/cpp
> configure: error: in `/mnt/lfs/sources/gcc-build/gcc':
> configure: WARNING: C++ preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details.

 This _looks_ like the error, in that I do not recall seeing it in
my own logs.

> checking for unordered_map... no
> checking for tr1/unordered_map... no
> checking for ext/hash_map... no
> checking dependency style of g++... none
> configure: error: no usable dependency style found
> make[1]: *** [configure-gcc] Error 1
> make[1]: Leaving directory `/mnt/lfs/sources/gcc-build'
> make: *** [all] Error 2

 But, that does appear to be the test which caused it to fail.

 My initial guess was that you missed the last line from the
configure command on that page : --enable-languages=c,c++ and
you can check that in your command history (e.g. use the
up-arrow from bash's command line).  BUT forget htat, I see
that test in my own log, when it is configuring in ./gcc - in
my case it got the correct answer ('gcc3').

 So, first run 'find -name config.log | xargs ls -l' :
that should tell you which of them was most recently accessed.
If that is ./config.log, the atime must have been updated when you
looked at it (unusual for a modern system), so look at the next
newest (or oall of them which have the same time.

 Search for 'no usable dependency style found' and then look at the
lines just above that : configure sets up a test, logs what it is
going to run, runs it, reports any error, and then eventually
produces the error message.  It is the command it ran, and the error
message which resulted directly from that, which matters.

ĸen
> 
> I am not sure which parts from config.log I should paste
> in here as it's 1000 lines long but I'll go ahead and paste
> some:
> 
> configure:4799: checking for C++ compiler version
> configure:4808: g++ --version >&5
> ../gcc-4.9.1/configure: line 4810: g++: command not found
> configure:4819: $? = 127
> configure:4808: g++ -v >&5
> ../gcc-4.9.1/configure: line 4810: g++: command not found
> configure:4819: $? = 127
> configure:4808: g++ -V >&5
> ../gcc-4.9.1/configure: line 4810: g++: command not found
> configure:4819: $? = 127
> configure:4808: g++ -qversion >&5
> ../gcc-4.9.1/configure: line 4810: g++: command not found
> configure:4819: $? = 127
> configure:4823: checking whether we are using the GNU C++ compiler
> configure:4842: g++ -c   conftest.cpp >&5
> ../gcc-4.9.1/configure: line 1751: g++: command not found
> 

 This says that in _that_ test, g++ was not found : for me, that
is tested for early on in configure (before 'make') and correctly
reports

checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes

 Which is a *different* first message (mine checked for 'g++',
and later, still from the initial run of 'configure', I can see:

checking where to find the target c++... just compiled

 Does your host system have a working C++ compiler ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Compile error in LFS 7.6: cross GCC - chapter 5.5.1

[Ken Moffat]

On Sun, Oct 05, 2014 at 01:17:53AM +0300, Andrei Banu wrote:
> Hi,
> 
> The missing g++ was the problem. But I don't understand how was I able
> to compile binutils without a working compiler? Anyway, I installed a
> gcc-c++
> and now it's working.
> 
> Thanks a lot!
> 
> Kind regards!

 You had a working compiler for C, but not for C++.  Binutils only
needs a C compiler.  In the past, gcc used to be able to compile g++
using a C compiler, but that changed : probably with gcc-4.8.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Where to find the newlib source when compiling GCC pass 1?

[Ken Moffat]

On Wed, Oct 08, 2014 at 11:23:15PM +0200, Christer Solskogen wrote:
> On 06.10.2014 13:06, Pierre Labastie wrote:
> 
> >Since we do not want libgcc2 to containing any code which requires libc
> >support, we pass --with-newlib --without-headers (equivalent to
> >--with-headers=no). And this is needed!
> >
> 
> Show me where that will be a problem.
> I've created (stage1) cross-compilers like this multiple times, on multiple
> linux distros without any problems:
> 
> ${SRCDIR}/bin/gcc/configure --prefix=${TOOLS} --target=${CROSS_TARGET}
> --disable-shared --disable-threads  --without-headers
> --disable-decimal-float --disable-multilib --enable-languages=c
> --disable-libquadmath --disable-libssp --disable-libgomp --disable-libatomic
> --disable-libmudflap --libexecdir=${TOOLS}/lib --disable-nls
> 

 Are you saying it is not required in LFS, because you have built
LFS while omitting those switches ?  Your mail is not clear, at
least to me.  Building stage1 pseudo-cross-compilers without then
building LFS seems a pointless activity (although I have done the
equivalent myself a couple of times, to build a kernel on ppc64
with 32-bit userspace, and I am sure people could do the same for
i686 userspace with an x86_64 kernel), but your post leaves me
confused about how far you have gone in building LFS.

 If something is not needed, and you have built LFS enough times to
prove that to your satisfaction, why have you not mentioned it
before ?

 I will also note that your command is apparently running configure
in a bin/gcc directory - that makes me dubious about what you say,
we run the toplevel configure script.

 Unrelated to that, why do you care about libexecdir in /tools ?
Even the people who hate /usr/libexec usually seem OK with what
happens in /tools because that is a temporary part of the build.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] 64-bit Blues

[Ken Moffat]

On Wed, Oct 15, 2014 at 01:51:28AM +0800, Роберт Киммель wrote:
> 
> On 15/10/14 0:54, Bruce Dubbs wrote:
> > No.  There is no arch/x86_64 directory, even on a 64-bit system in the
> > standard LFS build.  Also, if it were the problem, you wouldn't have
> > gotten far enough to to get it to search for /sbin/init (unless it is
> > a 32-bit kernel).  I'm not sure about CLFS though.
> >
> 
> The CLFS instructions refer to an arch/x86_64 directory, and it looks
> like I must have created one, judging by the scripts I used.
> 

 [ Coming late to this thread ] arch/x86_64/boot in the kernel tree is a
symlink to keep the old debian installer working.  It was added just
after the unification of the x86/x86_64 architectures.

> Within the 32-bit system, I just compiled a kernel, and (as you said),
> there is no arch/x86_64 directory, just arch/x86.  My build scripts copy
> the .config file (renamed) to the /boot directory, and I just had a look
> at the .config file from my attempt at a 64-bit build, and, there it is,
> about line 5 of the .config file, the 64-bit option is not set.
> 
> So it looks like it is possible to build a 32-bit kernel from within a
> 64-bit system, and it also looks like that's what I did :(
> 

 That happens if you build multilib, it can also happen with a
64-bit kernel and 32-bit userspace.
> I tried to recompile with the 64-bit option set, from within my 32-bit
> system, and that produced an error.  So it looks to me like 64-bits can
> build 32-bits, but 32-bits can't build 64-bits.  (I did check multiple
> times during the build of my partial CLFS that I really was building a
> 64-bit system, and "uname" told me I was.  Just as a double-check, the
> executables from my 64-bit build don't work when I try to execute them
> from within my 32-bit system.)
> 
> So I guess I have to figure out how to cross-compile the kernel only, or
> rebuild my partial 64-bit CLFS, so I can then build a 64-bit kernel.
> 

 For the kernel (only) cross-compilation is comparatively easy (see
below).

> > No. You have to start with the architecture you are running with.  You
> > probably want to divide up the partition so you have extra space, but
> > you didn't list your partitioning so we can't give a good recommendation.
> >
> 
> I have one quite large ext4 partition, which has my 32-bit LFS.  There
> is also a much smaller ext4 partition, which is big enough to hold a
> working LFS, but may not be big enough to compile one (about 60% full
> with a bare-bones LFS in it).  This smaller partition currently has my
> non-functioning attempt at a 64-bit build.
> 
> So if I can't figure out how to cross-compile a 64-bit kernel from
> within the 32-bit system, I guess I'll have to tar up the broken 64-bit
> system, build a 64-bit partial CLFS in the smaller partition (again),
> and compile a 64-bit kernel in that partition.  (Or just pinch the CLFS
> kernel.)  Then tar the CLFS system up, move the tar file to the big ext4
> partition, and untar the broken 64-bit LFS into the smaller partition,
> move the newly compiled and hopefully working kernel into that
> partition, and see whether it boots.
> 
> I'm really wishing I hadn't accidentally deleted my tarred up half-CLFS :(
> 
> OK, thanks for the advice.  Unfortunately not physically present with
> the machine for another week.  I'd like to chroot into the 64-bit
> system, and build DHCP, openssl, and openssh, but the chroot doesn't
> work, since it is a different architecture than the currently
> functioning system . . .
> 
> Thanks again.
> 
> РК

 I will suggest that you should prioritise saving the files, and
repartitioning (from a live disk - SystemRescueCD works well enough
for me, although on some of my boxes a recent version did not have a
working network which was "interesting" - most of my backups are on
nfs.  For building new systems, having several partitions for '/'
gives more options for rescue, and for trying things out.

 After that, build a 64-bit kernel.  The instructions are
essentially the same as LFS binutils pass 1 and gcc pass 1, but
with --target=x86_64-unknown-linux-gnu.  Use a special prefix to keep
them separate from your normal tools, e.g. /opt/gcc64.  In the
kernel, you need to cross-compile - ensure the new gcc and ld are on
your PATH and then 'make CROSS_COMPILE=something- menuconfig' or
whatever.  The 'something' will be the name-prefix of the new gcc
and ld, I do not have any real cross-tools areound to check.  Pass
it for each step of the build, including modules_install.

 Remember to select the option to let it execute 32-bit programs.

 That new kernel ought to be able to let you build a new system, but
caution: if uname -m is x86_64, programs you build on the host system
might thing they are on x86_64 and fail to build because the
toolchain is actually i?86.  This is the reason for 'linux32' and
'linux64'.

 It should also be able to boot the new system.  Whether that system
is 64-bit or 32-bit is a different question.  I can

Re: [lfs-support] LFS 7.6 binutils pass1 ; configure issue

[Ken Moffat]

On Wed, Oct 22, 2014 at 09:45:49PM +0200, Denis Mugnier wrote:
> Hi,
> 
> A french user tells us on the frecnh lfs forum that he has an issue with the
> configure script of binutils  (step 5.4).
> We don't find the solution, so I post here ;o))
> 
> The configure stop with the error :
> 
> |gcc: error trying to exec 'as': execvp: Too many levels of symbolic links


> configure:4284: $? = 1
> configure:4321: result:
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:4327: error: in `/mnt/LFS/sources/binutils-build':
> configure:4331: error: C compiler cannot create executables
> 
> the version-check result :|http://hastebin.com/xucuyulibe.coffee
> the binutils configure log : http://hastebin.com/inawikivog.tex

 Actually, that latter looks more like the results of 'printenv',
but seen through a mist [ I would describe the colours as off-white
and pale cyan, on a darkish green background - perhaps a text
browser fares better (/me tries links : no, just a blank page apart
from 'hastebin' at top right when links is invoked from either urxvt
or the xfce terminal!) ]

> host : Debian wheezy 7.6
> 
> 
> An idea of way to solve this issue ?
> 
> Many thanks,
> 
> Denis
> 

 Since this is pass 1 of binutils, I suppose that 'as' is just
/usr/bin/as, but perhaps something has got garbled.

 What does ls $(which as) say ?  I expect it to say /usr/bin/as but
perhaps something in debian's famed 'alternates' is causing it to
either never get there, or else to take an excessively long number
of symlinks.

ĸen
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] UEFI and GPT Structure

[Ken Moffat]

On Fri, Oct 24, 2014 at 06:08:56PM -0500, Bruce Dubbs wrote:
> Dan McGhee wrote:
> >I started this thread so that I wouldn’t hijack my own over on -dev.
> >
> 
> “...set up a new system based on UEFI and GPT. Our new system will dual
> boot: it will work with both UEFI and BIOS firmware. “ The disk created
> was 10GB.
> >
> >I am not able to “copy and paste” the partition table after the
> exercise from running . So I will attempt to recreate the table:
> 
> >Number Start  End  SizeCode Name
> >12048  411647  200.MiB EF00 EFI System
> >2  342047  1007.0 KiB  EF02 BIOS boot partition
> >3  411648  821247  200.0 MiB   8300 Linux /boot filesystem
> >4  82124820971486  200.0 MiB   8300 Linux /root filesystem
> >
> >I hope that table comes through holding the formatting.
> 
> Not quite.  I reformatted a bit by removing tabs/spaces.
> 
> However, I think the format of the disk above is poor.  The partitions are
> out of order.  1 and 2 are reversed.  Also, the BIOS boot partition is not
> aligned on a 1MiB boundary.  On a modern disk, is the loss of 1007.0 KiB
> really important?  That's less than a floppy disk.
> 
> When you copied, the size of partition 4 is way off.  Should be around 10G
> by my calculation.
> 
> No swap partition?  Personally, I think a /home partition is always useful.
> Change the system, but not user data. But that's really a different
> discussion.
> 

 Just a comment on the bios boot partition's alignment:  I forget
exactly how I set this up, and it is too late to look through my
notes tonight, but gdisk on this machine shows:

Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D7E3F344-D44D-1E7E-40B5-479D3F1E4309
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 16072685 sectors (7.7 GiB)

Number  Start (sector)End (sector)  Size   Code  Name
   1  34  204833   100.0 MiB   EF02  BIOS boot partition
   2  204834 2301985   1024.0 MiB  0700  Linux/Windows data
 etc

 So to me, sector 34 for the bios boot partition looks correct
(that's the one where grub lives, isn't it ?)

 sda2 is /boot, the other partitions are whatever suits me.

 As it happens, I now use 15GB for each potential '/', (I like to
keep old systems semi-usable, and to have multiple development
systems, but *anybody* intending to use LFS long-term ought to have
at least two potential '/' partitions).

 To me, an example with only a single 10GB system for '/' is fine for
a vm, but not a good thing to show as an example if people are going
to be following it on real disks (repartitioning a real disk, even
with good backups, is always a pain, and restoring the data is
usually a slow job).

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS

[Ken Moffat]

On Mon, Oct 27, 2014 at 09:47:32PM -0400, Patrick Kennedy wrote:
> I was finally able to boot up my new LFS 7.6 creation today.  :-)
> 
> It seems eth0 might work.  However, I don't see a "route" command.  Nor do
> I see a "dhclient" command.
> 
> What is the basic way you initialize the NIC card?  Obviously, it will be
> more glorious if it can connect to the Internet, but at least I am making
> headway.
> 
> ~Patrick

 The LFS book provides commands to set up eth0 with a fixed address.
For dhclient, see BLFS (specifically, dhcp).

 LFS uses iproute2, so if you *need* an equivalent of route, look at
e.g. http://baturin.org/docs/iproute2/ -  but you probably do NOT
need a route command.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] dns settings in the static configuration

[Ken Moffat]

On Sat, Nov 01, 2014 at 04:55:18PM -0500, Bruce Dubbs wrote:
> Alexey Orishko wrote:
> >On Sat, Nov 1, 2014 at 8:57 PM, Bruce Dubbs  wrote:
> >>How would someone dynamically create resolv.conf without some daemon like
> >>dhcpcd?
> >
> >If DNS servers are stated in ifconfig.eth0, why can't ipv4-static
> >create resolv.conf?
> >Thus all required configuration would be kept in the single file.
> >It also helps to maintain all settings intact while switching between
> >static/dhcp configs (since resolv.conf would be overwritten)
> 
> You are free to change the scripts any way you prefer, but I don't think
> many users would like that method.  Actually I disable update of resolv.conf
> in dhcpcd and always use 8.8.8.8 and 8.8.4.4 (google) no matter where I am.
> Others may want a caching name server and use 127.0.0.1.
> 
> Your distro may want something different.
> 
>   -- Bruce

 In my own case, I normally use dhclient (partly, to check that it
still works on new builds), but on the occasions when my external
connection dies I sometimes switch to a static IP to get from my
desktop to my server (the server has apache for the books, backuops,
and sources and my notes on nfs).

 What I do not understand is the *concept* of switching between
static and dhcp as a regular thing to do.  My experience is that ALL
modern broadband connection devices seem to offer dhcp, so what is
the benefit of a static connection (apart, perhaps, from a few
seconds when booting : in my case, waiting for the BIOS to initialise
the machine is the slowest part of booting, but some speed freaks
apparently prefer systemd [ /me spits. :-) ]

 If you are building a distro for other people, I am sure you can
script things, in your preferred scripting language, to do what you
suggest.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 7.6 boots read only

[Ken Moffat]

On Tue, Nov 04, 2014 at 11:30:04AM -0600, Bruce Dubbs wrote:
> Anthony Price wrote:
> 
> >cat /etc/lfs-release shows 7.6
> >
> >findmnt gives the error message can't read /proc/mounts
> 
> Hmm.  /proc is not mounted.  That happens in the very first boot script.
> 
> >I wonder if it would be useful to go back to the book 7.2 and reinstall
> >the bootscripts..
> 
> Well you could do that or edit /etc/sysconfig/rc.site to uncomment
> 
> #IPROMPT="yes" # Whether to display the interactive boot prompt
> #itime="3"# The ammount of time (in seconds) to display the prompt
> 
> 
> And then go through the boot scripts one at a time to see what is happening.
> 
>   -- Bruce

 In the past I have sometimes had odd failures between the kernel
handing over to init and getting a prompt.  In those cases I add
"init=/bin/sh" to the grub command line, then do as Bruce suggests
and step through the bootscripts - although, since we know that the
first bootscript is failing, it probably won't make a difference
here (unless something is seriously broken).

 But the reference to rc.shutdown worries me - like Bruce, I have
never seen it mentioned on an LFS system, and strings /sbin/shutdown
does not find any reference to it.  It sounds like something from a
different distro.

 Is it possible that you have got a bogus "root= " entry in your
grub.cfg, which starts the LFS kernel, but tells it to use some
other filesystem (on which you have had another distro) as '/' ?
Or, alternatively, things from a previous distro are scattered on
the LFS-7.6 partition ?  Yes, I see that you have set
/etc/lfs-release on that partition, but something is VERY odd here.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 7.6 boots read only

[Ken Moffat]

On Wed, Nov 05, 2014 at 08:52:57AM +, Anthony Price wrote:
> On 04/11/14 18:04, Ken Moffat wrote:
> >On Tue, Nov 04, 2014 at 11:30:04AM -0600, Bruce Dubbs wrote:
> >>Anthony Price wrote:
> >>
> >>>cat /etc/lfs-release shows 7.6
> >>>
> >>>findmnt gives the error message can't read /proc/mounts
> >>Hmm.  /proc is not mounted.  That happens in the very first boot script.
> >>
> >>>I wonder if it would be useful to go back to the book 7.2 and reinstall
> >>>the bootscripts..
> >>Well you could do that or edit /etc/sysconfig/rc.site to uncomment
> >>
> >>#IPROMPT="yes" # Whether to display the interactive boot prompt
> >>#itime="3"# The ammount of time (in seconds) to display the prompt
> >>
> >>
> >>And then go through the boot scripts one at a time to see what is happening.
> >>
> >>   -- Bruce
> >  In the past I have sometimes had odd failures between the kernel
> >handing over to init and getting a prompt.  In those cases I add
> >"init=/bin/sh" to the grub command line, then do as Bruce suggests
> >and step through the bootscripts - although, since we know that the
> >first bootscript is failing, it probably won't make a difference
> >here (unless something is seriously broken).
> >
> >  But the reference to rc.shutdown worries me - like Bruce, I have
> >never seen it mentioned on an LFS system, and strings /sbin/shutdown
> >does not find any reference to it.  It sounds like something from a
> >different distro.
> >
> >  Is it possible that you have got a bogus "root= " entry in your
> >grub.cfg, which starts the LFS kernel, but tells it to use some
> >other filesystem (on which you have had another distro) as '/' ?
> >Or, alternatively, things from a previous distro are scattered on
> >the LFS-7.6 partition ?  Yes, I see that you have set
> >/etc/lfs-release on that partition, but something is VERY odd here.
> >
> >ĸen
> Appending init=/bin/sh doesn't help. It merely dumps me at a prompt where I
> can't even log in.
> 
 That is correct - the start of userspace.  At that prompt you are
root, but on a read-only filesystem.  Root can then run through the
bootscripts *in order* i.e. from /etc/rcS.d/ S00mountvirtfs,
S05modules, etc and after all of those, I suppose, the scripts in
rc3.d if hte error has not shown up.

> grub.cfg appears to be correct - the lfs install is on /dev/sda8 and
> grub.cfg reads:
> <>
> set default=0
> set timeout=5
> 
> insmod ext2
> set root=(hd0,8)
> 
> menuentry "GNU/Linux, Linux 3.16.2-lfs-7.6" {
> linux   /boot/vmlinuz-3.16.2-lfs-7.6 root=/dev/sda8 ro
> 
> 
> This partition was created and formatted immediately before starting the lfs
> build.
> 

 OK, it does look correct.

> The other distro in use is xubuntu 14.10 - this does not use rc.shutdown and
> there is no file of that name anywhere on the system.
> 

 OK, it sounds like something from a gentoo-variant, or perhaps
slackware.

> At the grub startup screen the e(dit) option shows the lfs kernel but the c
> option does not.
> Using the c option's completion feature I can establish a path /mnt/lfs/ but
> there is no kernel listed

 I'm not sure what you are trying to do.  On my systems I have a
separate /boot partition, and from there the concept of /mnt/lfs does
not make sense [ /mnt/lfs would be meaningful on a root filesystem,
but only if whatever was intended to be at /mnt/lfs had been mounted
before you tried to access it ].

 You are referencing the LFS kernel in /boot, which is presumably a
directory on the xubuntu root filesystem (I think you said that
earlier, but here I am just deconstructing what you posted here).

 We know that grub finds a kernel by that name, all you need to do
to force init=/bin/sh (if you still want to do that) is
temporarily add that to the end of the existing commands.
> 
> Another oddity which may give (someone) a clue is that running update-grub
> from the host lists actual kernels from the host distro but not the lfs
> installation. The output is:
> 
> <>
> Found linux image: /boot/vmlinuz-3.16.0-24-generic
> Found initrd image: /boot/initrd.img-3.16.0-24-generic
> Found linux image: /boot/vmlinuz-3.16.0-23-generic
> Found initrd image: /boot/initrd.img-3.16.0-23-generic
> Found memtest86+ image: /boot/memtest86+.elf
> Found memtest86+ image: /boot/memtest86+.bin
> Found Linux From Scratch (7.6) on /dev/sda8
> 

 I try to avoid running update-grub, or at least save the existing
grub.cfg first, becasue in LFS we do not set things up for
update-grub, 

Re: [lfs-support] [blfs-support] Yet another LibreOffice post

[Ken Moffat]

On Wed, Nov 05, 2014 at 08:44:44PM -0600, Bruce Dubbs wrote:
> alex lupu wrote:
> >HI Bruce,
> >
> >On Wed, Nov 5, 2014 at 8:41 PM, Bruce Dubbs  wrote:
> >

 I have not, so far, seen alex's latest post, only this reply, but I
am fairly sure that is what often happens when personal replies are also
sent to the list : mailman sometime imposes a delay before the post
to the list gets sent out.

 Personally, I am wondering what has prompted these posts (I include
the post about attachments, which apparently only included a
standard list 'footer' as the attachemnt, along with both html and
plain multipart versions of the mail - that makes me assume alex is
using his OSX system ;)

 Alex:

1. Until recently, BLFS has always used -j1 for timings.  For LO that
recently changed in svn, and the change was matched with a comment
about how many jobs were used.

 What is your problem with that ?  On your machine, the time for
building binutils using make -j1 will differ from mine.  The SBU time
is only a rough guide, and one _big_ packages (LO is probably the
biggest), the difference will be magnified.

2. You built LFS, but you are scared about dollar signs ?  Really ?
Personally, I used to prefer back-ticks for subshells, but the
effect is the same, is it not ?

3. And since I am now replying : what _was_ that post about whether
it is ok to send attachments about ?  In any week we usually get
*several* attachments on the support lists.  Whether they are useful
is a different matter.

ĸen, currently winding down for the night after finding _another_
problem in a binary texlive installation : I *loathe* binaries, but
you are free to differ.
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] HW issues

[Ken Moffat]

On Sat, Nov 08, 2014 at 02:16:05AM -0600, Bruce Dubbs wrote:
> Bruce Dubbs wrote:
> 
> Just for discussion, here is the dmesg log from my experiment with
> CONFIG_HIGHMEM64G.  I also tried to set mem=4G on the kernel command line,
> but that did not seem to have any effect.
> 
> http://anduin.linuxfromscratch.org/~bdubbs/files/dmesg-test
> 

 I just booted the i686 system on my AMD A4 - that has 4GB less the
integrated graphics (it used to allocate 512MB for that, but I found
an option hidden in the BIOS to reduce that, a little) and now get
3.8 GB (decimal GB) of memory shown in top - that is with
HIGHMEM64G.

 Unfortunately, I could not see any equivalent to your 3.4 kernel's
HIGHMEM and LOWMEM, mine only got mentioned for the graphics.

 Do you have a copy of memtest86 ?  If you do, I would try running
it - first, to see how much memory it will test (maybe something is
occupied, e.g. by a PCI device, and unavailable), and second to give
some confidence that the upgraded memory works.  I once had an AMD64
motherboard where filling all the memory slots meant I had to reduce
the memory speed to avoid memory failures.

 Also, 3.4 is a longterm stable kernel, latest is 3.4.104.  Unlike
Douglas, I do not think that a newer kernel is likely to find more
RAM, but it should be a better place from which to move forward.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] HW issues

[Ken Moffat]

On Sat, Nov 08, 2014 at 03:39:23PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> 
> Yes, I tried memtest and it only recognized 3.1G.
> 

 In that case, it is not a kernel problem.  I can remember some of
my whatever-was-cheap hardware over the years : many motherboards
were definitely not built in the expectation that people would fit
all the memory which could in theory be used.

 I never touched Dell machines with the proverbial barge-pole, and
certainly in _this_ country they were often not cheap, but I suspect
somebody saved a cent by putting something in the address space
because "nobody would really want to use 4GB of RAM with this on
Windows XP" (the PDF at
www.dell.com/support/home/us/en/19/product-support/product/precision-370/manuals
specifically mentions XP).  Yes, I know that XP supported up to 4GB.
But the link at http://www.dpreview.com/forums/post/25007815
suggests that not all XP systems managed to make 4GB usable.  At
least you are doing better than the 2.5GB at the bottom end of the
range in that post.

 Perhaps something in
http://en.community.dell.com/support-forums/desktop/f/3514/t/19449295
might either help, or console, you ?

 FWIW, motherboard manufacturers who talk about a Mobo "supporting"
a certain amount of RAM usually mean "it boots with sticks of that
nominal capacity and we do not know, or care, how much of the RAM you
can actually use".  No idea if Dell was like that for this product,

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] HW issues

[Ken Moffat]

On Sat, Nov 08, 2014 at 07:29:09PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> >On Sat, Nov 08, 2014 at 03:39:23PM -0600, Bruce Dubbs wrote:
> >>Ken Moffat wrote:
> >>
> >>Yes, I tried memtest and it only recognized 3.1G.
> >>
> >
> >  In that case, it is not a kernel problem.  I can remember some of
> >my whatever-was-cheap hardware over the years : many motherboards
> >were definitely not built in the expectation that people would fit
> >all the memory which could in theory be used.
> >
> >  I never touched Dell machines with the proverbial barge-pole, and
> >certainly in _this_ country they were often not cheap, but I suspect
> >somebody saved a cent by putting something in the address space
> >because "nobody would really want to use 4GB of RAM with this on
> >Windows XP" (the PDF at
> >www.dell.com/support/home/us/en/19/product-support/product/precision-370/manuals
> >specifically mentions XP).  Yes, I know that XP supported up to 4GB.
> >But the link at http://www.dpreview.com/forums/post/25007815
> >suggests that not all XP systems managed to make 4GB usable.  At
> >least you are doing better than the 2.5GB at the bottom end of the
> >range in that post.
> >
> >  Perhaps something in
> >http://en.community.dell.com/support-forums/desktop/f/3514/t/19449295
> >might either help, or console, you ?
> >
> >  FWIW, motherboard manufacturers who talk about a Mobo "supporting"
> >a certain amount of RAM usually mean "it boots with sticks of that
> >nominal capacity and we do not know, or care, how much of the RAM you
> >can actually use".  No idea if Dell was like that for this product,
> 
> Good points Ken.  I've decided it is a HW issue and will let it go.  My
> biggest problem was the speed of SM and not that I cna build it with
> optimization, that is handled.
> 
> Speaking of SM, many pages give errors now for jpegs (but not all jpegs).  I
> did update to libjpeg-turbo-1.3.1, as a part of the upgrade, so I don't know
> if that's it or not.  I am rebuilding SM with internal jpeg to see if that
> makes a difference.
> 
>   -- Bruce
> 
 Might be the jpeg symlinks!

 With turbo, the libjpeg.so.7 or libjpeg.so.8 version is ostensibly
older than what jpegsrc provided.  When ldconfig runs, e.g. during
the SM or firefox install, it will see that and remake the symlink
to point to the jpegsrc version.

 My ff upgrade script now checks to see what version libjpeg.so is
pointing to (8.0.2 on LFS-7.6), then checks what .so.7 or .so.8
pointed to [ on old systems with jpegsrcv7 I used to build turbo as
if it was v7 when I upgraded to it ] and if necessary remakes the
symlinks to point to the turbo version.  I guess I might now have
got rid of all my systems which originally used jpegsrc, but I'm not
sure, so for the moment I keep my block of shell script which fixes
that.

 That would also apply to any other library update on that system.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] HW issues

[Ken Moffat]

On Sun, Nov 09, 2014 at 06:59:42AM -0300, Fernando de Oliveira wrote:
> On 09-11-2014 00:50, Bruce Dubbs wrote:
> > Ken Moffat wrote:
> > 
> >>   Might be the jpeg symlinks!
> >>
> > 
> > What I have right now is:
> > 
> >   1536932 Jul  1  2012 libjpeg.a
> >   775 Nov  6 19:56 libjpeg.la
> >16 Nov  6 19:56 libjpeg.so -> libjpeg.so.8.0.2
> >16 Nov  6 19:56 libjpeg.so.8 -> libjpeg.so.8.4.0
> >424688 Nov  6 19:56 libjpeg.so.8.0.2
> >   1027563 Jul  1  2012 libjpeg.so.8.4.0
> >   956 Jul  2  2012 libopenjpeg.la
> >20 Jul  2  2012 libopenjpeg.so -> libopenjpeg.so.1.5.0
> >20 Jul  2  2012 libopenjpeg.so.1 -> libopenjpeg.so.1.5.0
> >564664 Jul  2  2012 libopenjpeg.so.1.5.0
> >   805 Nov  6 19:56 libturbojpeg.la
> >21 Nov  6 19:56 libturbojpeg.so -> libturbojpeg.so.0.0.0
> >21 Nov  6 19:56 libturbojpeg.so.0 -> libturbojpeg.so.0.0.0
> >463705 Nov  6 19:56 libturbojpeg.so.0.0.0
> > 
> > I think you are saying that libjpeg.so.8 should be pointing to
> > libjpeg.so.8.0.2.  Is that right?
> > 

 Yes
> > I made the change to the libjpeg.so.8 symlink, restarted SM, and the
> > jpegs seem to come up now.  Should we be saying something about that in
> > the book?  It should be as simple as 'rm -f /usr/lib/libjpeg.so*' before
> > libjpeg-turbo's make install.
> 
> I agree. Comment would be helpful, just before it: If you are updating
> from older libjpeg or jpegsrc... I have had this idea since long, with
> respect to libjpeg, Ken may remember.
> 

 Yes, I remember.  It would do no harm if anyone has still to
upgrade from the old jpegsrc.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS-7.2, Ch6.17, gcc-4.7.1 test failures

[Ken Moffat]

On Sat, Nov 22, 2014 at 12:20:33PM -0800, Paul Rogers wrote:
> I changed the subject line as requested.
> >
> > For one failure, I'd ignore it and continue.
> >
> 
> I notice your test cases were build for x86_64, mine for i686.  As I
> said, I did a C&P into a wrapper script, but my error causes the "make
> check" to drop out.  That alone makes it seem pretty important.

 By "drop out" you mean, "only got this far, then stopped", or
"failed after reporting all the results ?"  The latter sounds like
normal behaviour for non-ignored errors.

 As it happens, I do still have my grep from 32-bit for LFS-7.2,
but it only reports two instances of ignored errors.

 I will also point out that 7.2 was something like 2 years ago and
few people here are likely to remember any details.  On "one
unexpected failure" I agree with Bruce : Carry on.  But two more
comments below :

> Using
> /usr/local/src/gcc-4.7.1/libstdc++-v3/testsuite/config/default.exp$

 /usr/local ??
> 
> Seems to me the ABI check is rather important.  (First time through I
> did try installing anyway, but then building e2fsprogs died in a
> mysterious way, so I backed-up to rebuilding GCC.)  I think I need to
> to find a fix for this.  Any ideas?  (TIA, as always.)

 If you are following the book (and the references to /usr/local in
what you pasted make me doubt that), people _might_ be able to help
on the e2fsprogs issue.  But only if you explain the problem. Saying
it "died in a mysterious way" is not a useful error report.

 Also, you said earlier that you were using your own package
manager, or perhaps just your own scripts.  The great thing about
writing our own scripts is that when they break, we get to keep all
the pieces.  I'm sure Bruce still remembers that I had a problem in
my own scripts when we moved to a newer bison version (3.0, I guess),
and it took me _ages_ to work around it (by using a km_ namespace for
my functions, and KM_ namespace for my variables.  I never did
discover exactly _which_ function or variable caused the problem. For
me, that was a tedious and painful learning-experience, I hope you
are able to resolve your problem more swiftly.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS-7.2, Ch6.17, gcc-4.7.1 test failures

[Ken Moffat]

On Sat, Nov 22, 2014 at 05:00:20PM -0800, Paul Rogers wrote:
> Allow me to address your last point first, the scripts that I make/use:
> 
[...]
> As I mentioned initially, this is my fifth LFS build, these scripts have
> been used many times, just minor mods as are in the book, version to
> version.  There is one function that is very, very close to just what's
> in the book.  I'm very, very careful to not depart from what works in
> new and original ways.  My package manager uses before/after snapshots,
> totally out of the way during install.
> 

 OK, I was just pointing out that we cannot know what is in your
scripts.  I will assume you have made all the changes from the
previous version of the book (me, I often miss something here or
there - either it blows up and is obvious, or I can go for a long
time without noticing the difference.  So, it always pays to review
if there is any doubt.

> I registered my first LFS build in 2004.  I've seen some of the stuff
> you get on the mailing list.  You're right to be a little cautious, even
> if abi_check failures aren't a common problem.  I'll take responsibility
> for my scripts, but they DO work on the KISS principle. [Heck, that's
> why I use LFS!!! ;-) ]
> 
> > > I notice your test cases were build for x86_64, mine for i686.  As I
> > > said, I did a C&P into a wrapper script, but my error causes the
> > > "make check" to drop out.  That alone makes it seem pretty
> > > important.
> >
> > By "drop out" you mean, "only got this far, then stopped", or "failed
> > after reporting all the results ?"  The latter sounds like normal
> > behaviour for non-ignored errors.
> 
> I use this: (make -k check 2>&1 | tee log.check && exit $PIPESTATUS) &&
> The $PIPESTATUS, with "#!/bin/bash -e" means if the make produces an
> error code, bash drops the script, even if tee produces a 0.  That's
> what's happening--make check is erroring out, leaving a log file.
> 

 My current scripts (probably my third or fourth major rewrite - I
needed to improve my logging of what got installed - mostly fail on
any non-zero return (there are a few places where I had to turn that
off, for conditional commands).  And I also build lfs-dev, where
test failures often happen as versions change..  So, many of my test
invocations end ' || true'.  In other words, I do not regard a
failing test, even in the toolchain, as necessarily catastrophic -
for me, what matters is whether the resulting system does what I
want.  And if a test fails, a non-zero status is to be expected.

> > I will also point out that 7.2 was something like 2 years ago and few
> > people here are likely to remember any details.  On "one unexpected
> > failure" I agree with Bruce : Carry on.
> 
> I would have, but if the make check errors out, that's not a normal
> unexpected error.  make really wanted to quit!
> 

 It's your system, and your time.  I used to think that 'perfect'
test results were good.  But all the tests do is check for a
recurrence of past errors.  And with different hardware, different
things can cause tests to break (e.g. Bruce's toolchain results
often look better than mine).

 Also, I repeat what Bruce said - for one or two errors in the tests
for a toolchain package, carry on.

> > But two more comments below :
> >
> > > Using /usr/local/src/gcc-4.7.1/libstdc++-v3/testsuite/config
> > > /default.exp$
> >
> > /usr/local ??
> 
> I have chosen to do all my development in /usr/local/src.  That's OK
> with LSB, isn't it?  Once the target FS is created, that's where I
> move my scripts, tarballs, patches directories.  Is that any problem?
> Never has been.
> 

 Building there is ok, if somewhat unusual.  It just seems like an
odd place to build things which are part of the base system, and
will be installed in /bin or /usr/bin.  I did not pay too much
attention to the files, or I would have realised it was the build
tree.

> > If you are following the book (and the references to /usr/local in
> > what you pasted make me doubt that), people _might_ be able to help on
> 
> Not rigidly, no, but in all important respects.  (Look, I'm not out to
> waste my time or yours, and my profrssional career was in computing and
> computing management, beginning as a programmer in 1966.)
> 
> > the e2fsprogs issue.  But only if you explain the problem. Saying it
> > "died in a mysterious way" is not a useful error report.
> 
> The way it failed made me suspect the compiler.  I need a reliable
> compiler before wasting time with e2fsprogs.
> 

 Other things can happen (heat, component failure, transient errors).
A quick look at an x86_64 log for e2fsprogs-1.42.5 suggests that it
uses 'CC' as the compiler, not 'CXX', so a libstdc++ ABI change seems
unlikely to impact e2fsprogs.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See t

Re: [lfs-support] LFS-7.2, Ch6.17, gcc-4.7.1 test failures

[Ken Moffat]

On Sat, Nov 22, 2014 at 11:55:50PM -0800, Paul Rogers wrote:
> 
> I want the binaries to be built to run on lesser hardware than what I
> build on, of course, and some configures in the past have taken their
> -march from the hardware I build on.  I don't want that to be a
> requirement!  Consequently in the BLFS builds especially I have the
> following in root's environment and all BLFS scripts using configure
> specify CTARGET:
> 
>  export CHOST="i686-pc-linux-gnu"
> 
>  export CTARGET="i686-pc-linux-gnu"
> 
>  export CFLAGS="-march=i686"
> 
>  export CXXFLAGS="-march=i686"
> 

 Those sound pretty generic, but not necessarily "lesser" than your
build machine.  To me, for _LFS_ "lesser" implies i486, i586, or
those short-lived not-quite i686 CPUs (Cyrix?).  I believe that for
LFS, all recent (for intel, P3 and newer, for AMD athlon and newer)
x86 CPUs in 32bit mode will build for i686.

 For BLFS, where some packages take advantage of CPU facilities,
that statement does not hold.

 And I cannot forcing i686 causing any problem for you (unless you
were to try it on something less than i686).

 You discount my assertion that although a single failing test will
cause 'make check' to report an error, it does not matter.  Now that
you are certain your scripts match the version of the book you are
using, I think there is very little to be gained until you have a
failure to build a package.  Yes, it is _possible_ that you might
eventually have to backtrack.  It is also possible that you have
overlooked, or not been aware of, something else entirely.  Bad
memory, or transient memory problems, are the sort of things which
come to mind.  And if you get transient memory problems then I think
either sunspots or solar flares are the sort of things we usually
blame, after spending a couple of days totally failing to replicate
the problem).  There are also all sorts of reports that a few
toolchain tests have failed on certain CPU models, or on certain
kernels : I always recommend upgrading the host to the kernel you
intend to use on the new system, if you can, but that does not solve
the "fails on this model" failures.

> I remember admonitions from 6.1 about CFLAGS/CXXFLAGS, so those are
> specifically unset when building binutils/glibc/gcc.  I looked, but 7.2
> doesn't have the same admonitions.  Are they still an issue?  Can they
> be contaminating my build now?

 If you do not set them, then by definition they cannot contaminate
your build.  For my own builds (i.e. when I am *not* trying to test
every last detail of LFS for a release) I pass -O2 to those flags.
Again, unlikely to make a difference to LFS packages, except that it
removes debug information.  I think the problem was probably with
the more exotic options.

 Also, if you are either running services which are publically
accessible, or have real users, or if you use a desktop connected to
the internet, then I think it is a far better use of your time to
keep your software up to date (to reduce the attack surface) than to
review the history of how LFS got to where it is.  But it's your
time and your systems.

 I'm currently diverting myself to using qemu to review how some
other distros, and even FreeBSD, do some things.  So I do understand
the concept of doing things because they are interesting - and also
how to make incorrect assumptions, to have to backtrack, and how to
spend a lot of frustrating time trying possible solutions which turn
out to make no difference at all.  My choice, but I cannot _lightly_
recommend this approach.  Do what you wish, and take a break if you
stop enjoying it.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS-7.2, Ch6.17, gcc-4.7.1 test failures

[Ken Moffat]

On Sun, Nov 23, 2014 at 12:43:05PM -0800, Paul Rogers wrote:
> > From: Ken Moffat 
> >
> >  OK, I was just pointing out that we cannot know what is in your
> 
> Yes, I don't post them only because I don't want to waste your time
> trying to understand them.

 That's fine.  I was only pointing out that attempting to provide
useful responses to "e2fsprogs did not build" is total guesswork.
> 
> Do you want the bash-4.2 ShellShock patch file posted?  It might be
> worth an erratum.

 We are unlikely to do an erratum - LFS has been using 4.3 for some
years.  But I did upload 4.2-fixes-13 in the early stages of the
shellshock fixes, and Armin updated it to -14 for later fixes.  I
still have one or two old desktop systems which I try to keep semi
usable.

> 
> > time without noticing the difference.  So, it always pays to review if
> > there is any doubt.
> 
> Been through twice, starting again. ;-)
> 
 Sometimes works.

> >  Also, I repeat what Bruce said - for one or two errors in the tests
> >  for a toolchain package, carry on.
> 
> Well, I don't know about the abi_check.  I thought because the make
> scripts dropped out the upstream folk didn't think that was a
> recoverable error.  You think it's negligible?
> 

 Wish I had seen this before my earlier reply.  Yes.  'make -k
check' means the check will continue past the first set of errors
(i.e. whichever directory fails), but it still reports a failure.
I think one failure from "a lot of tests" in gcc (or binutils, or
glibc) is not indicative of a crisis.

> >  Building there is ok, if somewhat unusual.  It just seems like an odd
> >  place to build things which are part of the base system, and
> 
> I use /usr/local/src for all my building, LFS/BLFS/other, and I like to
> keep all of it together.  LSB isn't strict about what goes there.
> 

 It doesn't actually matter where you build.  Nowadays, I mostly
build BLFS (as root throughout) in /scratch because it doesn't
get backed up and I do not wish to backup the transient build
directories.  For LFS I build chapter 5 in /mnt/lfs/building because
my sources are on an nfs mount.   For testing BLFS or LFS packages I
build as a user in /scratch/ken with a DESTDIR install to see what
gets installed [ used to use ~/ but I don't need the large and slow
backups for e.g. firefox or libreoffice ], and the same for kernel
upgrades and for testing development kernels.  For the book(s) I also
do a real install, and use the package (either see if it works for
what _I_ do, or else see if it still acts as a valid dependency for
whichever other packages need it.

 It doesn't matter _where_ you build, but certain locations imply
historical baggage.

> >  Other things can happen (heat, component failure, transient errors).
> >  A quick look at an x86_64 log for e2fsprogs-1.42.5 suggests that it
> >  uses 'CC' as the compiler, not 'CXX', so a libstdc++ ABI change seems
> >  unlikely to impact e2fsprogs.
> 
> Maybe not, but eventually it'd bite me.  So what about my root
> environment variables?  Could it be those?  Is there some (other) way I
> can ensure it builds for any i686?  (Expect the compressors & encrypters
> would use the most advanced enhanced instructions they can find, unless
> told not to.)

 If you use binaries, a change can certainly impact you.  If the
ABI did indeed change (google found some hits which implied that it
probably did during the 4.7 series), anything compiled using this
version either works, or like the failing test it relies on
behaviour that has changed.  If _common_ applications fall into that
category, google usually knows about them after the change begins to
show up in distros.  So in this case I do not think there is anything
to worry about.

 For encrypters, you are in BLFS territory.  For gzip, bz2, xz (or
lzma) I think they will mostly use C code, and the compiler will
decide how to convert that to assembler.  Perhaps gcc does recognize
some optimizations, but probably only if you force it to compile for
a specific machine variant.  Compare that to many audio/video packages
which do go out of their way to get the most out of the processor.
Certainly, zip/unzip can use assembler - but it's generic "i386" or
"i686" instructions.

 For the toolchain, the major linux "customers" are the distros.
The main distros aim to cover as much hardware as possible with one
binary, so using speedups that only apply to a few processors is not
something they often choose.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS-7.2, Ch6.17, gcc-4.7.1 test failures

[Ken Moffat]

On Mon, Nov 24, 2014 at 04:05:15PM -0800, Paul Rogers wrote:
> 
> I can diddle the make check sequence so it doesn't drop out easily
> enough ("make -k check || :"), but I regard that as a very bad habit to
> adopt!  The book says running the tests and generally good results is
> critical.
> 
 Emphasis on *generally*.  You appear to have had *one* failed test.

> > Did you try to run ../gcc-4.9.2/contrib/test_summary?
> 
> I did the first time it quit.  Looked OK.
> 

 Indeed.

> > > Do you want the bash-4.2 ShellShock patch file posted?  It might be
> > > worth an erratum.
> >
> >  We are unlikely to do an erratum - LFS has been using 4.3 for some
> 
> [ ! some > 2 ]
> 
> > years.  But I did upload 4.2-fixes-13 in the early stages of the
> > shellshock fixes, and Armin updated it to -14 for later fixes.  I
> > still have one or two old desktop systems which I try to keep
> > semi usable.

 You are lucky to have the time to nit-pick about how long we have
been using 4.3 ;)  Maybe I meant 'releases' and typed 'years'.  The
point is that we _minimally_ support our current release.

> 
> My patchset goes up to 4.2-53.  The ShellShock patches are very recent.
> 
 You obviously did not understand what I wrote.  Take a look at the
dates on those two patches.  Our _fixes_ versions use different
numbering from upstream's individual patches.

 Also, upstream _has_ now released 4.3.30, instead of just patches.
If you are building 4.2, you could check in case there is a similar
rolled-up tarball.

> >  Wish I had seen this before my earlier reply.  Yes.  'make -k check'
> >  means the check will continue past the first set of errors (i.e.
> >  whichever directory fails), but it still reports a failure. I think
> >  one failure from "a lot of tests" in gcc (or binutils, or glibc) is
> >  not indicative of a crisis.
> 
> No, I didn't think so.  OK, answer me this, since I'm NOT an automake
> jockey.  (Just got a book about it at Powell's by Vaughn, et al., but
> whoa, way above my pay grade!)  What's the difference between setting up
> make to anticipate errors and having an error abort the whole make
> process?  Is one of the former likely to slip past by accident and turn
> into one of the latter?  Does gcc upstream make that sort of error?
> 

 'make -k' will carry on for as long as it can run dependencies.
Then, it will stop and return the status.  If you use it for a
testsuite, it can usually run the remaining tests after error(s).
And then it reports a failure if any test failed.  If you were to
use it for a compile, it might continue for a long time until it
tried to link something which used whichever object file(s) had not
been created.

 Your 3 questions do not make any sense to me.  I do not understand
the phrase "setting up make to anticipate errors".  Make always
tests that each individual command completed with status 0, unless
you pass -k to tell it to carry on for as long as it can.

> 
> Never have been comfortable with Flash--it's one of those Attack
> Surfaces!
> 
 I was thinking about things like ffmpeg and some of the AV
libraries.  Things which for example use SSE3 variants if they are
available.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 20141104-systemd

[Ken Moffat]

On Sun, Nov 30, 2014 at 10:14:34PM +0100, Dr.-Ing. Edgar Alwers wrote:

> I personally dont understand why "systemd flame wars" happened.
> With many thanks to _all_ developers,

 That is no reason to try to start another systemd flame war ;-)

 Use whatever you wish, but do not force it on the rest of us.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] "Waking up in a different bed"

[Ken Moffat]

On Tue, Dec 02, 2014 at 10:44:19AM -0800, Paul Rogers wrote:
> For the most part my attitude about the complexities of udev rules has
> been: "As long as it boots and stuff is there, let sleeping dogs lie."
> 
> As I was building 7.2 the box started throwing machine checks!  I like
> to use HDD adapters so drives can be plugged in using one of the 5 1/4"
> slots on the front.  So I popped out the drive and slammed it into a
> different box and kept going!  That meant udev found a different CD/DVD
> drive & NIC.  No problem, don't need 'em; don't WANT the NIC active!
> Different video too, but that was covered by regenerating xorg.conf.
> This wasn't expected to be a permanent "move", just hurdling the
> roadblock.
> 
> This is an unusual thing for me to do.  But I guess I should make a
> little script that makes sure everything necessary gets changed.  I
> suppose that should include deleting the udev persistent net/cd rules.
> Yes?  Anything else?  (It can keep it's "identity" in /etc, for the
> most part.)
> 
> (I ran through Ch6 last evening with no real problems, now I'm
> studying Ch7 before charging in.  That's what brought this question
> up.)

 I've never moved a system during a build.  I have several times
used an existing LFS system to initialise a new box, and in the LFS
part the only things I recall having to change are the nic rule (in
qemu, it got renamed to eth128 until I fixed it!) and the hostname.
I've also imported my 7.6 i686 system to qemu and mostly fixed that
up, currently using it to build recent LFS/BLFS-svn.

 For the kernel, my configs are machine-specific so I need to fix up
CPU and cpu-related e.g. cpufreq and on 32-bit highmem (64G on my
nominally 4G real machine, 4G in my qemu systems which only get 2G)
(no lowest-common denominator CPU for me, except in qemu), network
driver, and (for framebuffers, kms, Xorg) the FB and DRM settings.

 In BLFS, I've also had to rebuild Mesa (BLFS-7.6) to run in qemu,
because it was trying to use things available to the cpu I had used
to build it, and those caused llvm errors to be reported - you might
want to remember that for when you eventually get to LFS-7.6 ;-)

 And I do not think this is worth scripting, I only do it very
occasionally (and the kernel changes aren't really scriptable for
me).  But for rolling out a distro from your build machine to your
other boxes, perhaps worthwhile.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Marching from LFS-7.2 through BLFS

[Ken Moffat]

On Sat, Dec 13, 2014 at 09:17:12AM -0800, Paul Rogers wrote:
> Four previous LFS builds isn't a enough to make a trend, but in the past
> I've generally found it desireable to patch the kernel from the version
> in LFS, so I try to do that before building stuff in BLFS.  Sometimes
> that's been for hardware drivers, sometimes flaws, even to get to a LTS
> version.  But sometimes the kernel changes the API so the update isn't
> transparent.  (kernel-2.6.25 is a prereq for building LFS-7.2 afterall.)
> I've looked through the announcements in kernelnewbies.org, but nothing
> leapt out at me.
> 
> So, my question to the list is: from 3.5.2 is there a recommendable
> level of the kernel that I can transparently patch up to, that would
> represent a compatible "sweet spot" of some sort?

 In general, Linus tries to avoid breaking userspace.

 But you have not explained which version of BLFS you are going to
build on your LFS-7.2.  Much of 7.6 and current svn has not been
tested on older versions of LFS.  Certainly, when I updated versions
of _firefox_ on old systems I had problems in the LFS-7.0/7.1 area
("problematic" gcc versions).

 As a general rule: update to a current LTS kernel.  Recent 3.14
seems good.  But (depending on *which* BLFS version you are
building), check the packages in BLFS to see which kernel options
you will need.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Marching from LFS-7.2 through BLFS

[Ken Moffat]

On Sat, Dec 13, 2014 at 10:27:47AM -0800, Paul Rogers wrote:
> Sorry, Ken, I got a version of the BLFS book that was contemporaneous
> with LFS-7.2, "Version 2012-11-02".  It always seems to say: "This
> package is known to build and work properly using an LFS-7.2 platform."
> 8-)

 Well in that case, any old kernel - there have been _so_many_
vulnerability fixes since then (kernel, nss, ssl, xorg).

 I don't have any problem with you building old versions of things,
but I would not use them, except with extreme caution.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Marching from LFS-7.2 through BLFS

[Ken Moffat]

On Sat, Dec 13, 2014 at 05:05:37PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> >On Sat, Dec 13, 2014 at 10:27:47AM -0800, Paul Rogers wrote:
> >>Sorry, Ken, I got a version of the BLFS book that was contemporaneous
> >>with LFS-7.2, "Version 2012-11-02".  It always seems to say: "This
> >>package is known to build and work properly using an LFS-7.2 platform."
> >>8-)
> >
> >  Well in that case, any old kernel - there have been _so_many_
> >vulnerability fixes since then (kernel, nss, ssl, xorg).
> 
> Don't forget bash.
> 
 LOL - Paul knows about shellshock, he initially thought we had not
provided patches for 4.2.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] login as root or lfs to begin

[Ken Moffat]

On Sun, Dec 14, 2014 at 08:33:09PM +, openstud...@kewla.com wrote:
> lfs:/mnt/lfs/sources$ ls -l $LFS/sources  
> total 330724 
> -rw--- 1 root root   238860 Dec 15 01:45 XML-Parser-2.42_01.tar.gz 
> -rw--- 1 root root   386604 Dec 15 01:45 acl-2.2.52.src.tar.gz 
> -rw--- 1 root root   343692 Dec 15 01:45 attr-2.4.47.src.tar.gz 
> -rw--- 1 root root  1214744 Dec 15 01:45 autoconf-2.69.tar.xz 
> -rw--- 1 root root  1488984 Dec 15 01:45 automake-1.14.1.tar.xz 

 So, only root, or somebody who is in the 'root' group (if that
even exists) can read those files.  That sounds ok for a normal
system, but your lfs user will need to be able to read them.

 I assume you created $LFS/sources as root, so now root needs to
chown those files.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Grub query

[Ken Moffat]

On Fri, Dec 19, 2014 at 06:22:03PM +, spiky wrote:
> 
> On 12/19/14 18:12, Cliff McDiarmid wrote:
> >Hi
> >Just installed a new LFS with systemd.  I've created a partition for the
> >boot dir. for Grub.  I have a question about booting other LFSs using this
> >method.
> >The instructions say: 'move all files in the current |/boot| directory
> >(e.g. the linux kernel you just built in the previous section) to the new
> >partition'.   I've done this.  But what happens when there are other
> >kernels and System.maps from other LFSs?  Do I copy these over, if so, how
> >does one differentiate between System.maps?
> >thanks
> >Cliff
> 
> Hi I leave the System.map file in each distro and I tend to use the same
> kernel for all lfs builds, If I have just built a new lfs with a newer
> kernel I rebuild the newer kernel in older lfs, this way there is only 1
> kernel in the boot partition, And create the grub.cfg as needed.
> 

 That sounds dangerous, but perhaps I'm misunderstanding.

 My desktops usually have several available systems, but in practice
I mostly boot either the latest svn build, or the current release.
The main times I boot the others are when I'm updating a package
(typically, only firefox-nss-sqlite) or when I think it would be
good to move an old system to a newer kernel.  But I also like to
keep an eye on -rc kernels for my current systems (I've been bitten
_so_many_ times by bugs, most of which were specific to particular
hardware ;)  So, I have _many_ kernels in /boot, with names
identifying which rootfs they are for.

 What I think might be dangerous is building what is ostensibly the
same kernel version, even with an identical config, but using
different compilers, and using modules - if I am reading you
correctly then you first build e.g. 3.18.0 with current gcc, then
later build it with an older gcc _and_ overwrite the original 3.18.0
kernel.  I would expect modules from the current system to not be
loadable in that situation.

 Having multiple kernels _per_system_ is good - something to fall
back to if it turns out to have a problem.  And occasionally, a
kernel problem only applies to certain versions of gcc!

 But as to system.map files, I have not installed those for years.

 I didn't initially respond to Cliff because his html-only mails
were hard to read.  So, thanks for copying it into a plain-text form
;-)

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Kernel choices

[Ken Moffat]

On Sun, Jan 04, 2015 at 10:18:10AM -0800, Paul Rogers wrote:
> So, my LFS-7.2 install is complete, and apparently functional.  Last
> month I asked about updating the kernel in the LFS-7.2 I've been
> building.  Ken suggested going fro the 3.5.2 up to 3.14.  I decided to
> make that in two jumps, stopping first at 3.10.62-LTS.
> 
> There were interruptions.  I've built that now, but during boot there
> appears to be something dumping some data on the console about once a
> second!  It's hard to tell exactly when it starts.  When it gets to the
> Login prompt, I've only got about one second to use Shift-PgUp before
> the next console write jerks me back.  At that point it's "00 00 00  00
> 00 00"; no identifier of who's doing it or what it means I've seen.  It
> might be after udev starts, but I'm not sure.  It's got to be something
> introduced in the 3.10.62 kernel, because I don't see this with 3.5.2.
> So I've a few questions:
> 

 It is possible that one of the drivers is dumping this rubbish.  On
my netbook, I started with ubuntu, and sanitised their config enough
to boot before I ever tried to put LFS on it.  But with LFS I was
getting similar messages in my log (so, the log was huge).  In that
case, dropping an unnecessary driver fixed it (something in the
network or wifi area, built as a module).

 More generally, setting LOGLEVEL in /etc/sysconfig/console is the way
to quieten the log.  From a quick look at old bootscripts, and the
output from 'dmesg --help' you can set the loglevel using 'dmesg -n N'
where N is from 1 to 8.

 I normally run with LOGLEVEL="4" in /etc/sysconfig/console, but you
might need to tweak it if a driver acquired a silly default setting.
So, try your choice of

1 emerg
2 alert
3 crit
4 err
5 warn
6 notice
7 info
8 debug

(i.e. use the highest setting which gives what you need without an
unusable console - for most people, 4 or less is probably the way to
go).  If it is indeed a very noisy driver, you might need to
temporarily set a lower level until you are able to read dmesg or
the log to see where it is coming from.

 I also have to doubt what you say about "introduced in the 3.10.62
kernel" - what we know is that it did not happen in 3.5.2, but did
happen in 3.10.62.  If you *had to* bisect what changed (for
excessive logging, I doubt that will be necessary!) you would
probably need to check 3.10.0 (and then bisect between 3.5.0 (sic)
and 3.10.0 from Linus' tree if it showed up in 3.10.0), or else
bisect between 3.10.0 and 3.10.62 in the stable 3.10 tree if it is
indeed new during 3.10.

 In 3.18.1 the kernel has a setting for the default loglevel,
CONFIG_MESSAGE_LOGLEVEL_DEFAULT : for me, that is set to =4 which
matches my sysconfig setting.  I do not recall when that option
first appeared, but it is possible that you might have it, but
with a larger value.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Kernel choices

[Ken Moffat]

On Sun, Jan 04, 2015 at 11:41:34AM -0800, Paul Rogers wrote:
> >
> >The best starting place for the kernel is 'make defconfig'.  'make
> >help' gives a lot of other options.  Generally the help page for each
> >option gives a reasonable summary, but takes a long time to go through
> >everything.
> 
> Indeed, and even so, it's not clear what they "mean", what the
> implications are.  Particularly so for new options.  I don't have time
> to follow all the kernel lists about things that seem to be irrelevant
> to my "here and now".

 By the time a kernel is released (i.e. the '.0' version), its help
is often useful, but of course occasionally missing or misleading.

 When you take your previous config and run 'make oldconfig', try
looking at the help if you are not certain.  If in doubt, make a
note of the option so that you can revisit it, or google, if you
have problems.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style