Re: [lfs-support] OpenSSL Heartbleed-bug
CORRECTION!! >On Tue, 15 Apr 2014 20:06:03 +0200 >Aleksandar Kuktin wrote: > > >On Tue, 15 Apr 2014 19:06:14 +0200 > >loki wrote: > > 3.) Do I have to recreate the keys used for the users of OpenVPN? > > (After I update OpenSSL) > > If they were not loaded into the servers address space (and they > probably weren't), no. CVE-2014-0160 also affects clients. Therefore, you also have to regenerate and redistribute user keys. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] OpenSSL Heartbleed-bug
>On Tue, 15 Apr 2014 19:06:14 +0200 >loki wrote: > 1.) Is it enough for me to recompile only OpenSSL or do I have to > recompile OpenSSH, apache, OpenVPN? I have not yet looked at the patch that fixes CVE-2014-0160, but I imagine that you do not need to recompile anything that dynamically linkes to OpenSSL. Anything that links statically should be recompiled. How to tell? Well, you compiled it, you ought to know what went into it. :) In principle, you can run ldd on the executable in question and see if /whatever/libssl.so.* comes up in the list. If so, OpenSSL is linked in dynamically. > 2.) Do I have to recreate the selfsigned certs for WWW even if I don't > use any passwords for the private key? (After I update OpenSSL) Not if (1) it has not been compromised and (2) you don't care about it being compromised. In practice, you almost certainly care about it being compromised and, due to the fact the private key was in the same address space that is exposed by CVE-2014-0160, your private key was almost certainly leaked to anyone who bothered to look. > 3.) Do I have to recreate the keys used for the users of OpenVPN? > (After I update OpenSSL) If they were not loaded into the servers address space (and they probably weren't), no. Note that all the above answers apply anytime an attacker has read access to the servers address space. There is nothing special about the so-called "heartbleed bug" that makes it different than so many other information leak bugs. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] partitioning question
>On Wed, 02 Apr 2014 04:39:17 -0500 >William wrote: > While I am experienced with both cfdisk and fdisk, what should I boot > in order to use those utilities? Anything that: (a) has them (b) is capable of detecting your HDD and changing bits on it (i.e. has drivers for your hardware) > If I boot to a Slackware disk, could I use cfdisk from there and > keep going? Yes. > Are there any special measure that need taken? No special measures. Do what you would ordinarily do when partitioning a drive. If dual-booting, make sure you won't destroy the ability do boot any other systems present. Details depend on details. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Brand new and confused. Mostly about the 7.5 book.
>On Sun, 30 Mar 2014 14:57:22 -0700 >Al Szymanski wrote: > > Thank you all for your rapid responses. In specific, Aleksandar asked: > > Are these numbers your own estimates, or did you pick them up > > somewhere? I'm asking because they overestimate. > > These numbers came directly from the 7.5 book; 2.2.1.1. through > 2.2.1.3 : pages 12 and 13. Aha, OK. I see it now. Ever since I built my system for the third time, I have been rarely looking at the book. Especially after 7.0. The list in 2.2.1.3. and the recomendation in 2.2.1.1. are, in principle, mutually exclusive. A ~10GB root partition from 2.2.1.1. includes within itself a 5GB /usr, a 5GB /opt and "a couple of GB" /tmp. /bin, /lib and friends in / are rarely heavier than 200-300MB and can therefore be ignored in this calculation. 10GB for "system", that is, everything excluding /home, whereever you keep your sources and possibly the build dir, should be quite enough. > On a related topic : if I find an error in the 7.5 book, to whom > should the notice go? In the process of downloading each of the > required parts, I found that the source site for Bzip2 failed. I used > the Google code search and found it just fine. I also created a curl > script to make the downloading mostly a bulk job with the exceptions > of the files that come from SourceForge - can't curl them. Al I think lfs-support is good, but lfs-dev may be better. If you don't mind being on two mail-lists (and your mail program can handle it with reasonable ease), lfs-dev is better. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Brand new and confused. Mostly about the 7.5 book.
>On Sun, 30 Mar 2014 14:05:50 -0700 >Al Szymanski wrote: > > I am just trying to figure out the overall smallest size of hard > drive space needed for all of the partitions. My sums from the 7.5 > book come to 80 Gig plus whatever space I want for /home . > [ suggested partition sizes: > root LFS 10Gig > /usr/src 30-50Gig > /opt 5-10Gig > /usr 5Gig > /tmp <5Gig > swap 2xRAM > /boot 100Meg >=~81Gig ] Are these numbers your own estimates, or did you pick them up somewhere? I'm asking because they overestimate. In particular, the line for /usr/src seems way too big. My own tarball dir (which cotains everything I build) is 2.7 GB, almost ten times smaller that your low estimate. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] /run directory: Maybe a bit off topic?
>On Sun, 23 Mar 2014 12:07:49 -0400 >baho utot wrote: > I think there are not many folks that have that on a separate > partition. > > That's really the only problem with using /var/run. Although I did toy with the idea of changing my system to have /var on a separate partition. It's just that it is hard to find a really good justification for geeking out and spreading your stuff over several storage devices. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] WebKitGTK-1/Flash
>On Mon, 17 Feb 2014 12:17:29 + (GMT) >Richard wrote: > In keeping with the theme of Fernando's original suggestion, I have > the source for 'surf' and it was simple to add a dozen lines of C to > iterate over the entire plugin list and output the descriptions (and > enabled flag) for each. > > The result: only the java plugin was found. According to webkit the > flash plugin does not exist. If you are willing, it may be time to bring out the big guns. Basically, insert additional printf() statements in the code to debug the problem with not detecting plugins. The objective of such an approach is to follow the progam logic as it attempts to load the plugin and see where exactly it fails. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] systemd versus sysvinit
>On Sun, 16 Feb 2014 12:59:19 +0100 >Frans de Boer wrote: > > Dear All, > > It looks like most Linux distributions are switching to systemd from > sysvinit. As Bruce is even one of the (co-?)authors of systemd, the > knowledge is already in the house. Why would (x)LFS stick to sysvinit > while the rest of the world is moving to systemd? > > Of course, simplicity might be one reason. After all sysvinit system > is much easier to understand then the somewhat more complex systemd > system. However, if everybody was thinking like this, there would be > no progress ever. > I also think that in order to keep (x)LFS attractive to new > followers, the project should go with the flow. > > Since my days of programming are long past, I can only offer my > system resources for (test)building development versions - much as > what I do today. > > Regards, Frans. Please do not try to ignite a holy war. LFS has been, for the most part, a very peacefull place and I think everyone would like it to stay that way. As for why we would stick to sysvinit? It exposes the underlying gears and pipes to the user. That way, servicing it is easy. The only really good (yet still apologetic) argument for systemd that I heard is that some people do not know shell scripting and for them there is no difference (AKA preference) between systemd and sysvinit - they need to learn either from scratch. Systemd, in my humble opinion, has been paid for, written as is being pushed by Big Server. They ofcourse need it because they can use it to quickly boot virtual machines when they need to and, presumably, manage them all from a single place. For LFS, whose stated mission is to teach people the internals of a Linux system, systemd offers no tangible benefits apart from a dubious line in some (but not all) CV-s (to the effect that so-and-so knows how to configure systemd) yet has a major drawback in the shape of hiding the inner workings of system boot from an LFS reader (because LFS is first and foremost a book). -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Static versus Shared libraries
(Answering to both William and Bruce) Okay, so that's how you solve that! -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Static versus Shared libraries
>On Tue, 31 Dec 2013 07:49:11 -0600 >William Harrington wrote: > After your whole build is done, you can use rm to remove them. There is actually a problem with libtool and just rm-ing a static library. I don't know the specifics of it, but subsequent build attempts of other packages needing the affected libraries may fail. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Howto keep track....
>On Sun, 20 Oct 2013 18:33:53 +0200 >Frans de Boer wrote: > Like I said no page is the same and I noticed that you handle every > site in a different way using customized regex's. That is exactly the > thing I try to avoid, but given the nature of things I assume that > would be hard to accomplished using HTTP. I just had a flashback to Gopher. Gopher proponents usualy cite that exact reason as the reason the World should use Gopher instead of HTTP. Even though that is not HTTPs fault. It's really HTMLs fault. As for automated package tracking, I did an experiment using the source revision tools that various packages use (git, subversion, mercurial and others..) but had the mother of mixed success. While for some packages this works so well you would swear God gave his personal blessing, for other packages this is the worst kind of a nightmare. Using source revision tools also adds the aditional problem that in most cases you need to rebuild the ./configure script and that is often very difficult, if not impossible. And then there is the problem of both initial seeding and continuous maintenance of the 350+GB repository of repositories containing 300+ individual packages. Definitely not for the faint of heart. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] chroot into the temporary ...?
>On Wed, 25 Sep 2013 09:56:34 +0800 (CST) >Wiky wrote: > > I got it, Thank you. > > At 2013-09-25 09:49:36,"Aleksandar Kuktin" wrote: > >>On Wed, 25 Sep 2013 08:41:37 +0800 (CST) > >>Wiky wrote: > >> > >> hi, > >> It reads 'That is, we chroot into the temporary mini Linux > >> system, ..' in Section6.1 of LFS7.4. but when i run 'sudo > >> chroot /mnt/lfs', it returns 'chroot: failed to run command > >> `/bin/bash': No such file or directory'. Of > >> course /mnt/lfs/bin/bash not exists and then I tried 'sudo > >> chroot /mnt/lfs/tools', it also 'chroot: failed to run command > >> `/bin/bash': No such file or > >> directory',but /mnt/lfs/tools/bin/bash exists. I really have no > >> idea with the problem,maybe I have missed something in Ch5? > >> Thanks in advance and sorry for my English. > > > >You didn't specify which program should chroot exec() after it > >chroots itself, so it did the default: tried to execute /bin/bash. > >Since there is no such program (/mnt/lfs/bin/bash in the root > >filesystem), it failed. > > > >To fix this, you should specify which program should be executed. > >Like this: > > > >chroot /mnt/lfs /tools/bin/bash > > > >But the full command is in Chapter 6.4. so look it up there. > > > >-- > >You don't need an AI for a robot uprising. > >Humans will do just fine. Don't top post. Also, a post in the thread "LFSv7.4 stuck at section 6.9.1" gave me an idea about why you were unable to run `chroot /mnt/lfs/tools'. The bash that lives there requests the dynamic interpreter (run-time linker) /tools/lib/ld-.so and that did not exist. You can verify this by adding a symbolic link `tools' to /mnt/lfs/tools which points to `..'. Like this (command run from /mnt/lfs/tools): ln -sv .. tools With this, you should be able to do `chroot /mnt/lfs/tools' without any problems. Just don't execute Section 6. with that setup because you will have A LOT of problems and a lot of thrashing. ([thinking]...or maybe not... anyway, don't do it. not when you are building LFS for the first time) -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFSv7.4 stuck at section 6.9.1
>On Tue, 24 Sep 2013 17:37:28 -0700 (PDT) >Phoebe Bacotot wrote: > > I have a problim compiling my samba...and this output were given > > > client/smbmount.c:25:26: fatal error: linux/smb_fs.h: No such file or > directory compilation terminated. > The following command failed: > gcc -I. -I/sources/samba-3.0.30/source -O -D_SAMBA_BUILD_=3 > -I/sources/samba-3.0.30/source/popt > -I/sources/samba-3.0.30/source/iniparser/src -Iinclude -I./include > -I. -I. -I./lib/replace -I./lib/talloc -I./tdb/include -I./libaddns > -I./librpc -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE > -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE > -I/sources/samba-3.0.30/source/lib -D_SAMBA_BUILD_=3 -fPIC -c > client/smbmount.c -o client/smbmount.o make: *** [client/smbmount.o] > Error 1 > > > > can you help me how to solve this problem? Okay, so bonus points for persistence. :) This belongs to blfs-support. Join that mailgroup, post your question there and I will then help you out. And when you do that, do include a bit more of the build log. There may be more information in there. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] chroot into the temporary ...?
>On Wed, 25 Sep 2013 08:41:37 +0800 (CST) >Wiky wrote: > > hi, > It reads 'That is, we chroot into the temporary mini Linux > system, ..' in Section6.1 of LFS7.4. but when i run 'sudo > chroot /mnt/lfs', it returns 'chroot: failed to run command > `/bin/bash': No such file or directory'. Of course /mnt/lfs/bin/bash > not exists and then I tried 'sudo chroot /mnt/lfs/tools', it also > 'chroot: failed to run command `/bin/bash': No such file or > directory',but /mnt/lfs/tools/bin/bash exists. I really have no idea > with the problem,maybe I have missed something in Ch5? Thanks in > advance and sorry for my English. You didn't specify which program should chroot exec() after it chroots itself, so it did the default: tried to execute /bin/bash. Since there is no such program (/mnt/lfs/bin/bash in the root filesystem), it failed. To fix this, you should specify which program should be executed. Like this: chroot /mnt/lfs /tools/bin/bash But the full command is in Chapter 6.4. so look it up there. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] martin
>On Fri, 30 Aug 2013 13:03:11 +0800
>Carl Martin Bacus wrote:
> root:/sources/glibc-build# for tz in etcetera southamerica
> northamerica europe africa antarctica \
> > asia australasia backward pacificnew solar87 solar88 solar89 \
> > systemv; do
> > zic -L /dev/null
> > -d $ZONEINFO
> > -y "sh yearistype.sh" ${tz}
> > zic -L /dev/null
> > -d $ZONEINFO/posix -y "sh yearistype.sh" ${tz}
> > zic -L leapseconds -d $ZONEINFO/right -y "sh yearistype.sh" ${tz}
> > done
>
> [snip]
>
> root:/sources/glibc-build# cp -v zone.tab iso3166.tab $ZONEINFO
> 'zone.tab' -> '/usr/share/zoneinfo/zone.tab'
> 'iso3166.tab' -> '/usr/share/zoneinfo/iso3166.tab'
> root:/sources/glibc-build# zic -d $ZONEINFO -p America/New_York
> zic: Can't link from /usr/share/zoneinfo/America/New_York to
> /usr/share/zoneinfo/posixrules: No such file or directory
>
>
> rply ASAP.. tnx
You REALLY shouldn't tell people when to reply to you. What if William
lives a quarter of the World away from you and has just gone to bed?
In fact, judging by the timezone stamps in your e-mail headers, you two
are *ten* timezones apart. So, in reality, William is half a World away
from you and is probably sleeping right now.
To answer your question: you forgot the backslashes at the end of some
of the lines. It should look like this:
<... blah blah>; do
zic -L /dev/null \
-d $ZONEINFO \
-y "sh yearistype.sh" ${tz}
zic -L /dev/null \
-d $ZONEINFO/posix -y "sh yearistype.sh" ${tz}
The backslash at the end of the line means that the command does not
end, but continues on the next line. When you ommited that, the shell
thought that the second command of the loop was to execute the program
`-d' with $ZONEINFO as its argument. And that is where all those errors
came out of.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
signature.asc
Description: PGP signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Newbie
>On Fri, 16 Aug 2013 16:32:57 -0500 >William Harrington wrote: > > > On Aug 16, 2013, at 3:09 PM, Aleksandar Kuktin wrote: > > > As stated above, you can use the LFS live CD although it is rather > > old. > > Can't build current LFS with LFS 6.3 livecd. That's why I've updated > it. But that will soon come to an end with gcc-4.8.x targets. > > the 6.3 livecd uses gcc 4.1.2 which has no Wno-narrowing and another > variable which causes issues when cross compiling. > > I'd need to update the livecd to at least gcc 4.4 or 4.5 to get rid > of it, not a problem, just letting you know. > > A new LFS livecd needs to be available, or get rid of it and have a > wiki for people to look toward to hosts that work wtih LFS and the > commands required to get them to the point if they don't meet the > host system requirements. > > Sincerely, > > William Harrington I had a general idea that there are people who maintain the livecd, but I didn't know much more about it. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie
Hello and welcome. Feel as if at home. >On Fri, 16 Aug 2013 19:46:24 +0100 >inquiring.m...@hushmail.com wrote: > > Hello all, > > 1. I just saw the LFS site and would like to try it but can't see the > section that says how to download the source file packages ready to > work through the programme. You either have to download them yourself, one at a time, or get yourself a copy of the LFS live CD which has them all in one place. However, I am pretty certain that the LFS live CD has not been maintained for some time and therefore the packages you can find on one will almost certainly be old. > 2. I'd also like to know which LIVE CD/DVD you can recommend to use > as a base that satisfies all the criteria from the script on the host > requirements page > (http://www.linuxfromscratch.org/lfs/view/stable/prologue/hostreqs.html) > as all the distro's I've chosen (major ones like Kubuntu, CentOS, > Gentoo, etc) all fail on one or more element. Some of them fail on > BISON while others on GCC, a package I suspect to be rather important > in this endeavour. As stated above, you can use the LFS live CD although it is rather old. The other alternative is to take a distro which is close to what you need and just add the missing stuff to it. > 3. I recently bought a new computer with no OS on it just for > installing Linux on it and learning more about it so LFS seemed to be > ideal. It's a new platform with UEFI instead of the older BIOS a 3TB > HDD. I read that on drives like this, the old fdisk tool is > insufficient but the only instructions I've seen in the manual are > for the older, fdisk programme. I read something about needing to > install a FAT32 partition at the start or something like that but > wasn't sure if this was right or not as I know that FS is quite > different to any *nix based filesystems. The fdisk manual page states that fdisk was, in fact, not designed for big partitions. It further states that one should use the more advanced GNU parted for such disks. Therefore, use parted. And I'm pretty sure you can ignore that "FAT32 at the start" part. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] GPT Partitioned Drive on BIOS Station, Unable to Mount Root
One of the great things about hanging around on LFS mail-lists is that you often get to learn about new hardware (in this case Tyan stuff). Specifically, about its existance. >On Fri, 19 Jul 2013 03:13:51 +0200 >Esben Stien wrote: > > [snip] > > I've confirmed that the kernel works fine as I still have my old LFS > build on another drive on the same station. So, let me get this straight. When you put the new kernel into the old LFS, it boots like a charm but when you put that same kernel into the new LFS, it fails? Also, the old LFS is on a normal HDD, and the new LFS is on a SSD, right? If yes, then the problem seems to be either triggered by the difference in the housing drives or by differences in the userland, correct? Maybe you could try that trick in booting USBs where you configure the kernel to wait a bit before trying to boot the userland. > [snip] > > I'm on a Tyan Thunder n3600B (S2927-E) (S2927A2NRF-E) station and > I've compiled SATA chipset and XFS filesystem support into the kernel: > > CONFIG_SATA_NV=y > CONFIG_XFS_FS=y > > I'm quite stuck on this one and I'm open to anything. I've sat up the > last two days/nights trying to figure this one out and I've read the > whole internet;). > > Any pointers as to what I can try? > -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.3: Kernel hang problem
>On Sun, 30 Jun 2013 16:24:47 +0800 >Chen Qi wrote: > > Thanks for your reply. > > I tried both approaches. > No matter I used the 'defconfig + devtmpfs' approach or I used the > 'host config file' approach, I always met the following error. > ''' > VFS: Cannot open root device "sdb1" or unknown-block(0,0) Okay, now you are getting somewhere. This error appears, if it appears, after the kernel bootstrapped itself and is now trying to boot the userland. What the error MEANS is that the kernel can not find and use the filesystem for the root filesystem. Heres a checklist of the things that could prevent it from doing that, from memory: 1. It can not use the PCI bus to talk to the disk controler. Because your kernel boots itself, you can rule this out. 2. The kernel can not talk to the USB controler. Check that you have enabled the proper USB version (UHCI, OHCI.. et cetera). 3. The kernel has no concept of the USB storage device so it can not conceive of it. Make sure you have "USB mass storage" enabled. IIRC, you might also need a few other things related to mass storage. 4. The kernel does not know anything about partitions. There is a group of options regarding partitioning. Turn on appropriate (unless you have something special, that means "PC partition table"). 5. The kernel can not read the filesystem. Make sure that the filesystems you enabled in the kernel match whatever filesystem is on the partition you want to mount. Does your USB drive use the NTFS filesystem? Have you enabled the NTFS driver in the kernel? > To conclue, I have basically two questions here: > 1. Which modules/drivers are essential to make a rootfs on a USB > media mounted correctly when the kernel starts up? > 2. How could I know which kernel config items to enable from the > output of 'lspci'? Any resource on documents on this area? You also have a third option: make an initramfs and use that. I'll explain. With initramfs, your root filesystem is inside the kernel. You don't have to worry about all the things in the list I wrote above. However, you can only reasonably make a small filesystem fit into the kernel that way. This is usefull for gaining the command line because you can then hack around and see what is happening, if anything. The method for this I find most comfortable is to use `cpio' to make an archive of the filesystem and then just pass this to the kernels Makefile (there is an option, I think in the "general options" section). For this to work, first copy `init' from $LFS/sbin/init to $LFS/, then use `cpio' to make an archive, put the path to the archive into the appropriate configuration option and recompile the kernel. Take note that decompressing this big kernel can easily take 5+ minutes. So, when booting, GRUB will start the kernel, you will see a message to the effect of "uncompressing kernel" and then for several minutes nothing will happen except for the light on your USB stick blinking. This is normal. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.3: Kernel hang problem
>On Sat, 29 Jun 2013 12:51:03 +0800 >Chen Qi wrote: > > Hi all, > > I've followed all instructions in the LFS stable 7.3 book, and made a > USB containing my LFS system. > > As I don't know exactly which drivers and modules should be compiled > into my LFS kernel to make it work on my DELL laptop, I made a > 'allyesconfig' and compiled the kernel. > > I thought 'make allyesconfig' would make the kernel work. > However, when it started up, the kernel was loaded but hung at 'TCP > established hash table entries'. > > A previous message that might appear to be an error was 'ACPI png > driver unregistered'. > > Can somebody give me a hand? > > Thanks in advance. > > //Chen Qi > I think that the best option would be to assume you will have to spend a few days on this and then manually assemble the kernel options that work on your system. One possible option to speed up this process is to first find which options are necessary for booting the kernel (AKA the PCI driver, the USB driver, at least one partition system and the filesystem) and then make everything else a module. Assuming you have checked "automatic module loading", when the system boots, you can use `lsmod' to find which modules were loaded and, therefore, which things you need to enable and which you don't have to. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting incorrect search results, mentioned in Errata for section 6.10
>On Tue, 25 Jun 2013 12:56:35 +0300
>Sergey Shidlovsky wrote:
>
> Hi again! =)
>
> One more question, if you please.
>
> While adjusting toolchain, we do such search:
>
> **
> echo 'main(){}' > dummy.c
> cc dummy.c -v -Wl, --verbose &> dummy.log
>
> ...
>
> Next, verify that the new linker is being used with the correct search
> paths:
>
> grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
>
> If everything is working correctly, there should be no errors, and the
> output of the last command (allowing for platform-specific target
> triplets) will be:
>
> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/lib")
> SEARCH_DIR("/lib");
> **
>
> Errata for section 6.10 of LFS 7.3 stable book says that:
>
> **
> In Section 6.10, the results of the grep for SEARCH should not
> include: SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> **
>
> But I DO get this string in the output. Is it ok, or something went
> wrong?
>
I think you can just go on.
Whats important is that the new program requests /lib/ld-linux.so.2 (or
other, but in /lib) for its run-time linker. That linker is part of the
new glibc, which means that new libraries will be used by your program.
And besides - the next step is building of GCC which won't
use /tools//lib and thus the entire problem will just go away.
You can double-check that the problem did go away by (re)moving /tools,
but make sure you first have a working system outside of /tools.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
signature.asc
Description: PGP signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] About errors
>On Thu, 6 Jun 2013 17:49:18 +0200 >Philippe Delavalade wrote: > > [snip] > > Thanks but I have just .bash_history in /root. > > Did I missed something ? > Just add it. Or put into $HOME/.bashrc . It doesn't matter if you don't have the file RIGHT NOW, when you make it, bash will read and use it. Like this (one of several ways to do this): $ cat >> $HOME/.bashrc << EOF << your stuff goes in here >> EOF -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] why does LFS need that number of patches
>On Thu, 16 May 2013 12:37:21 -0400 >alex lupu wrote: > > Am 16.5.2013 03:03, schrieb Stefan & Rebekka Wetter: > > I wonder, why these patches are needed? > > Are the upstream-sources not able to be compiled without? > > Good questions (as they say). While trying to stay on topic, > I'll take the liberty and rephrase them to > Why are patches needed at all? > for my post and try to answer/comment. > > First, I agree with the previous respondents (patches are just needed, > some address the unique(?) configurations of (B)LFS, what would the > world be without them, just live with them etc.) > > Now that so many celebrities have come out on this, I've decided > to finally break my own silence on this subject that had been > obsessing me for years. I'll use a particular example but it's more > general (and possibly ugly, cover-up, sloppiness?, etc.) in nature. > For me, it all started on a dark and stormy night, while trying to > compile GTK+ 2.22.0 and failing. It culminated in > Bug 631910 of 2010-10-11: > https://bugzilla.gnome.org/show_bug.cgi?id=631910 (for the curious) > > In case you're there, please observe (and absorb) the Comment #1 > (and only) which quickly closed this "non" issue. > True or incompetence or cover-up, etc.? I've obsessed on this ever > since. > > [snip] > > I'd like to thank the issuers (husband and wife?) of and commentators > on this thread. You really helped me lift a heavy burden off my > chest, a burden I had to keep inside for so many years. > > Still obsessed and puzzled (evidently), but at peace with myself now, > -- Alex This appears to be a case of the developer having a sprawling system, full of various bells and wistles and simply not detecting that that particular make rule (or some other in the dependency chain) depends on something that he has, but people with sleakier system (such as you or me) don't have. I see this all the time with gtkdoc. Gtkdoc is some package which is used to generate documentation. I don't have because I don't need it. I also believe that having it is not and should not be necceasary. But the developers of just about anything have it and use it. Now, this is not something that you will see if you use releases but I am trying to use repository tarbals for everything which means I have to generate the configure. And the scripts and code which do that assume that gtkdoc is present. So every time I wish to do that, I have to hack the pre-configure files and remove all traces of gtkdoc. I just went back to analyze the bug report and your fix that you reported in the mail, and the only logical explanation is that your (or any LFS') copy of db2html did something different than the developers copy of db2html. If db2html is generated during the build procedure (and it is apparently, since I seem to not have it my $PATH), then this may be much more convoluted than just a simple version mismatch. Bottom line: this is probably because you don't have something that the developer has. Now, what that is is a much bigger question than is really worth figuring out, especially since there is already a fix. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] why does LFS need that number of patches
>On Thu, 16 May 2013 15:22:19 -0300 >Fernando wrote: > > I have sent this in the morning, about 7 hours ago, it never appeared. > > Now, I have edited some words to see if the anti-spam was blocking > them. It arrived for me, as well as the follow-up email. Perhaps Yahoo is also using the echo-block that Gmail is using? (An echo block is when your mail server removes the e-mails from the mail list that were sent by you.) -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] help, i hosed my windows partition
One other thing, although it qualifies as a false hope: it just may be possible, at least theorethically, to recover most or all of the contents of the NTFS partition. So if you did manage to nuke the few starting sectors of your NTFS partition, do not lose hope just yet - unless the damage hit a critical part of the filesystem (which is very likely - it did hit the start of the partition, after all), it should be possible to extract most or even all files and directories. Although there are no guarantees - a part of some file could have been written over, or a directory may have lost some or all of its contents. Note that this method relies on having either a library or a program available that can perform the appropriate functions. I do not know of any that exist right now, especially for NTFS, but if you have something very important that you have not backed up somewhere else, maybe either look around for such a program or keep on to the image file of the damaged filesystem (partiton) until such a program gets written (because it eventually will). -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] help, i hosed my windows partition
>On Sun, 10 Mar 2013 09:33:39 + >tilmanbregler wrote: > > [snip] > > sudo fdisk -l > > Disk /dev/sda: 750.2 GB, 750156374016 bytes > 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 4096 bytes > I/O size (minimum/optimal): 4096 bytes / 4096 bytes > Disk identifier: 0x05b005af > > Device Boot Start End Blocks Id System > /dev/sda1 * 2048 206847 102400 7 HPFS/NTFS/exFAT > /dev/sda3 206848 1465147391 732470272 5 Extended > /dev/sda5 1024004096 1449783295 212889600 83 Linux > /dev/sda6 1449785344 1465147391 7681024 82 Linux swap / Solaris > > Ideally, i'd like to create the ntfs partition starting at sector > 206848. Any ideas how i can do that, or get back my windows partition, > otherwise? > > Thanks in advance, > > Tilman In short, what you wish to do is impossible, as such. The "standard issue" PC partition table has only four slots for partitions, called "physical partitions". In the case more partitions are needed, the last partition gets subpartitioned. The subpartition table is kept at the start of the fourth partition. These subpartitions are called "virtual partitions". So you are unable to make the NTFS partition start at 206848 presumably because that is the first sector of where the virtual partition table is being kept. If you did at one point write a 5-partition table to the disk, with the NTFS partition starting beyond sector 206848, with the content between the end of /dev/sda1 and the start of NTFS partition being unaccounted for, I am afraid that the start of your NTFS partition (and, by extension, NTFS filesystem) has been nuked. If, on the other hand, you did not write a 5-partition layout to the disk, it is still possible for the resizing of the NTFS filesystem to have hosed your Windows. This possibility has to do with bootloaders and the way they find later stages. Because the Master Boot Record of either the entire disk or just a partition is very, very small, the very first stage of the bootloader also has to be very small which translates into the bootloader being very dumb. This stupidity is normaly worked around by having the first stage of the bootloader seek a preprogrammed sector on the disk, loading the second stage of the bootloader contained therein and passing control to it. What this means is that once the first stage of the bootloader gets written into the MBR, the file containing the second stage Must. Not. Be. Touched. Otherwise, the first stage will not be able to find it. [See footnote for aditional words of I-leaned-this-the-hard-way-just-like-you-now wisdom.] It is entirely possible that during the resizing of the NTFS the resizing program moved the second stage bootloader. Footnote: In the case bootloader is single-stage, like LILO is, the system operates in a similar way. Instead of searching for the second stage bootloader, LILO is searching a specific array of disk sectors for the Linux kernel. For this reason, in every case that the kernel gets changed, LILO has to be rewritten into the MBR so that the new kernel can be found. Footnote.2: You know, it may be possible to get around this problem by writing the contents of the new file into the old file. ((cat newfile > oldfile) instead of (cp newfile oldfile)) However, the contents would have to be of the same length and you would have to rely on the filesystem to not move the files around (I think ext3 does move files (reallocate the sectors for the file) in this case but ext2 does not move them; ext3 can be changed into ext2 by turning off the journal). -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Flex Tarball Signature and Other Files
>On Wed, 30 Jan 2013 04:09:37 -0200 >Listeiro 037 wrote: > > > Hi. This is my first message. > > How can I verify the signature of tarballs with a RSA key? > > flex-2.xx.tar.bz2 in the case, for example. > > I haven't found signature files (.asc, .sig) or keys of the > maintainers in sourceforge. > > Thanks. By finding the signature files and the corresponding keys. :) The practice of signing the release tarball is not widespread. If you are okay with it, you may have more luck with finding just the checksums. Also, hello and welcome to this wonderful part of the Internet. Make yourself at home. :) -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Wirenet, the first (?) real malware for Linux.
Note that this mail is cross-posted to lfs-support, blfs-support and lfs-security, with a "Reply-To" set to lfs-security. This is also the first mail on the lfs-security list in at least three years. Yaay! Anyway, the news is from august/september of 2012, so it's a little stale. However, the search function over on LWN returns NULL when asked for "wirenet". OTOH, Forbes and The Register both wrote a small article each on the subject. A bunch of other sites copy-pasted the content from each other. H-Online also wrote a /very/ interesting article on the subject, discussed below. I have discovered this only today, and purely by accident. And then I thought it would be prudent to warn the LFS community about it. https://www.virustotal.com/file/1c4ba1bf8003b9d66b4423e0503bf5489cd4de13b1a3038499d039baa553cd0e/analysis/ http://blog.webroot.com/2012/09/14/wirenet-the-password-stealing-trojan-lands-on-linux-and-os-x/ http://news.techworld.com/security/3378804/linux-users-targeted-by-password-stealing-wirenet-trojan/ http://news.drweb.com/show/?i=2679&lng=en A Russian security firm called Dr. Web has discovered (made public ?) what they call a trojan capable of infecting Windows, MacOS X and Linux. Unlike the event about a year ago when a Java worm accidentally infected the Java plugins of browsers running on Linux, this is the real deal. ELF executable, X system API calls, Linux syscalls. According to Techworld, Dr. Web received the sample from Virustotal. I have not found any infomation regarding "the dropper" (a different malicious program which installs this malware on the computer), or any information regarding the specifics of Wirenet's point and method of entry. There is also no word on the method Wirenet uses to survive the shutdown-bootup barier. The post on Webroot goes to great lengths to explain (some) details of Wirenet's operation. Wirenet goes after the password caches of Firefox, SeaMonkey, Chrome/Chromium, Opera, Pidgin and Thunderbird. No word on whether it also targets keyrings of various PGP implementations (which is THE treasure stash, IMO). Wirenet is also capable of taking screenshots, keylogging (both of these via Xlib), remote code execution and possibly other things. http://www.h-online.com/security/news/item/Hackers-turn-remote-maintenance-tool-into-trojan-1697425.html H-Online has a very interesting take on the subject matter. They basically assert that the program was written by World Wide Labs under the name NetWire as a legit (ha-ha) remote administration/remote monitoring tool, but that it got coopted to operate as a malicious trojan. In light of that, and taking into account the current lack of a clear infection/boot-cycle-survival mechanism, it is entirely possible that Wirenet is a tempest in a teapot, malware without the dropper, a horsecart without horses (I'll stop now). IOW, I am not sure if it "exists" and does damage in the wild or not. The really interesting thing here, and the thing that really got me thinking, is the fact that Wirenet neither uses nor needs to use root to do it's thing. It exist entirely in nonpriviled userspace. Which makes its mitigation hard(er then neccessary). Speaking of mitigation, the Internets main advice seems to be "Linux is invulnerable to malware and you should stop worring about this, period, new paragraf, lalalala." Needless to say, this sort of attitude can only get one killed and/or robbed. In the interest of mutual safety, I will now describe my method of using browsers, together with modifications that should make one almost completely safe from this and other similar things (ha-ha). Starting with the premise that the browser has a code execution vulnerability, which holds true for them all on at least some days (WebKit, you eternal beta, I am looking at you), you can expect the browser to drop and start Wirenet. This is my premise. I start with "a day will dawn when my browser will betray me". If this happens, Wirenet will rob my (nonexistant - I don't store my passwords with the browser) password caches blind, possibly connect to the X server and do all sorts of bad things through it. However, for years I have not trusted my browsers and I have run them as separate users, sandboxed. My browser doesn't even connect to the net. It is firewalled and connects to a locally running HTTP proxy (polipo) and then the proxy connects to the net. Until today, the script which started the browser would have left the .Xauthority file in the browsers home directory, but in the light of Wirenet, that may be a bit too risky. So now it removes .Xauthority 1 second after forking the browser. I have attached the script starting Firefox for reference. So, I think that that is probabbly the only surefire way of protecting oneself: run the browser as a separate, sandboxed user and make sure it is only exposed to the X cookie for as little as it needs. Assuming your X server is not promiscous (I have found that running Xorg 1.11 or 1.9 or so
Re: [lfs-support] Where to from Scratch?
>On Thu, 20 Dec 2012 20:25:49 + >Ken Moffat wrote: > If you logged in as root, or used 'su' (or 'sudo') then you own the > system (subject to any restrictions it imposes on you, e.g. sudo > might be tied down). More like "subject to restrictions imposed by laws of physics (but not all, especially if you try to delete stuff)". :) As for noobism, that is a state cured relatively simply (har-har). Try this: http://www.tldp.org/HOWTO/HOWTO-INDEX/howtos.html Of interest among the many, many HOWTOs: http://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html http://www.tldp.org/HOWTO/Networking-Overview-HOWTO.html http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html http://www.tldp.org/HOWTO/Filesystems-HOWTO.html Linux From Scratch HOWTO: http://www.tldp.org/guides.html#lfs Also this: http://www.netfilter.org/documentation/HOWTO/networking-concepts-HOWTO.html But before you do any of that, take your time and read the Command-line manual, written by Mandrake Linux people in the long past year 2004. They've since changed their name and now go by the name Mandriva Linux. Make sure to read the section 3.4 which explains the pipes and is the point where I fell in love with Linux, eight or nine years ago. I can't find it on the net anymore, and the manual is 1.5 megabytes large, so in the interest of not hogging the list, I will sent you a mail with the pdf. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with a linker problem
>On Sat, 1 Dec 2012 16:24:08 +0100 >Aleksandar Kuktin wrote: > I mean `ldd /path/to/bash/that/is/the/problem/bash'. > > Also, there is an easy way to test if the problem is linking with a > library from /tools. Make a symlink. > > ln -sv /usr /tools > > Then try it again. > Or maybe you can upload the offending bash binary. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with a linker problem
>On Sat, 1 Dec 2012 16:19:38 +0100
>Aleksandar Kuktin wrote:
>
> >On Sat, 01 Dec 2012 23:59:07 +1300
> >Simon Geard wrote:
> >
> > On Fri, 2012-11-30 at 11:17 -0500, Chris Staub wrote:
> > > First, check how Bash is linked: "readelf -l /bin/bash | grep
> > > interpret". Of course, this should say that it's looking for the
> > > dynamic linker in /lib. Then verify you actually have all the
> > > right libraries for Ncurses: "ls -la {/usr,}/lib/*ncurses*"
> >
> > Yes, it's using /lib64/ld-linux-x86-64.so.2, and yes, the chapter 6
> > version of ncurses *is* correctly installed. But that copy of
> > ncurses is the wide-char version, and bash has managed, somehow, to
> > link to the non-wide version. My assumption, as I said, is that
> > instead of finding the linker scripts in /usr/lib which would point
> > it to the wide version, it's found the non-wide version in /tools
> > instead.
>
> Can you do `ldd /bin/bash'?
>
I mean `ldd /path/to/bash/that/is/the/problem/bash'.
Also, there is an easy way to test if the problem is linking with a
library from /tools. Make a symlink.
ln -sv /usr /tools
Then try it again.
--
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Help with a linker problem
>On Sat, 01 Dec 2012 23:59:07 +1300
>Simon Geard wrote:
>
> On Fri, 2012-11-30 at 11:17 -0500, Chris Staub wrote:
> > First, check how Bash is linked: "readelf -l /bin/bash | grep
> > interpret". Of course, this should say that it's looking for the
> > dynamic linker in /lib. Then verify you actually have all the right
> > libraries for Ncurses: "ls -la {/usr,}/lib/*ncurses*"
>
> Yes, it's using /lib64/ld-linux-x86-64.so.2, and yes, the chapter 6
> version of ncurses *is* correctly installed. But that copy of ncurses
> is the wide-char version, and bash has managed, somehow, to link to
> the non-wide version. My assumption, as I said, is that instead of
> finding the linker scripts in /usr/lib which would point it to the
> wide version, it's found the non-wide version in /tools instead.
Can you do `ldd /bin/bash'?
--
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] next step wireless
>On Wed, 28 Nov 2012 16:22:01 +0100
>"Dr.-Ing. Edgar Alwers" wrote:
> You should configure /etc/wpa_supplicant.conf, see wikipedia link
> above. network={
> ssid="mywireless_ssid"
> psk="secretpassphrase"
> # Additional parameters (proto, key_mgmt, etc.)
> proto=WEP WPA
> }
Note that wpa_supplicant can also handle WPA and WPA2 all by itself,
regardless of hardware capabilities.
You can use wpa_gui, present in the wpa_gui directory of wpa_supplicant
to interactively configure the link parameters. Wpa_gui is not built by
default, it requires qt.
--
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Systemd's journal (was Re: Latest news in GNOME world)
WARNING!! FLAMEBAIT!!! >On Mon, 12 Nov 2012 15:26:08 -0600 >Bruce Dubbs wrote: > Third, if the logs were ascii, the bells and whistles in the link > above could be accomplished with a bash script fairly easily. FLAMEBAIT, USE ASBESTOS! Well, since UNIX and clones have survived all these years, I believe it is safe to bet they will continue surviving. :) After all, sysvinit itself has, what, 30 years under its belt? -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Best Linux Version for LFS?
>On Wed, 10 Oct 2012 18:31:31 +0100 >Ken Moffat wrote: > All distros think they own /boot : this will make updating kernels > fun if more than one distro (or LFS+distro) is involved. Not only that, but most believe they also own the master boot record. Some are even very proactive in repartitioning the hard-drive to make it conform to their idea of the world. Pro tip: If your MBR ever gets blown off, it is relatively easily fixed. First, you should make a copy of it and store this copy somewhere safe (far from the HDD under risk). dd if=/dev/sda of=copy_of_MBR bs=512 count=1 Then, if the MBR gets destroyed, copy the MBR back. dd if=copy_of_MBR of=/dev/sda conv=notrunc It also possible to reconstruct the MBR without this but it is much more difficult. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Compiling GCC pass 1 of Linux From Scratch
> checking dynamic linker characteristics... configure: error: Link tests are > not allowed after GCC_NO_EXECUTABLES. > make[2]: *** [configure-stage1-target-libstdc++-v3] Error 1 > make[2]: Leaving directory `/mnt/lfs/sources/gcc-build' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/mnt/lfs/sources/gcc-build' > make: *** [all] Error 2 I *think* I had something like this when first compiling a 32-bit subsystem for my LFS. Please, please, copy and paste more of the compilation log. At least 4-5 aditional commands executed. I will then untar my old logs and see if I can find a match. What are the architectures involved? What is the architecture you are building on and what is the target architecture? Please post the beginning of configure's output, so that it includes the architectures (host, build, target). -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Any female LFS hackers?
>On Wed, 05 Sep 2012 07:41:20 +0100 >Jasmine Iwanek wrote: > > On 2012-09-05 07:13, Oshadha Gunawardena wrote: > > Hi all, > > > > I am wondering if there are any female LFS hackers out there :P. > > This is just to get an idea about the community, please ignore if > > this message is irrelevant > > > > Thanks, > > Oshadha. > > Nope, I'm a carrot, same for elly and anyone else with a female name > on the list. q: > > -- > Jasmine Iwanek AHA! But what about the cross-culture differences? Different cultures use different names, making it impossible to reliably tell genders. I'm pushing it. :) Also, isn't this supposed to be on lfs-chat?? -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Udev installation error - LFS chapter 6
>On Mon, 20 Aug 2012 17:33:08 +0530 >Oshadha Gunawardena wrote: > > Tried that, and I managed to configure it (trace - > http://tny.cz/5f221035). But came out with a new error please refer > the below trace > > configure: error: The pkg-config script could not be found or is too > old. Make sure it > is in your PATH or set the PKG_CONFIG environment variable to the > full path to pkg-config. It appears you are missing pkg-config and/or glib. These packages were at first not in LFS, then they were added because something (can't remmember what) had pkg-config as a dependency and glib depends on glib. Later, the two packages were removed because they were adding too much cruft to the book. Now, the details of the resolution of your problem (assuming the problem is in a missing package) depend on which exact versions of the book and udev package you are using. I am not an editor and have not read the new versions of the book so I may give you bad information. However, I guess that if you take the newest release of the book and the release of udev that said book references, you will succed. Make sure to check if the particular version of the book you use has pkg-config, and if it does, do not skip it. Same for glib. In any case, match the version of udev you are trying to build with the version the book references. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Q: Is the map between physical SATA disks and GRUB2's hd fixed?
>On Fri, 20 Jul 2012 23:10:25 +0100 >Ken Moffat wrote: > Personally, I would never trust a BIOS writer to do things > correctly, nor a manufacturer of affordable motherboards to do > things straightforwardly - on one of my current boxes, the connector > where I happened to connect the DVD drive uses a different SATA > driver from the other connectors ;) You must have been very happy when you figured it out. ;) LOL -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Do you know why 2 CPUs act like a mirror in GCC test?
>On Sat, 12 May 2012 21:11:19 +0430 >Yasser Zamani wrote: > > > Hi, > > Sorry if it's off-topic; do you know why 2 CPUs act like a mirror > while I'm running "make -k check" for testing GCC-4.6.2 (6.17's > section of LFS-7.1)? it's not a problem but just I would like to > know; I've attached an image which shows this while I was not running > anything except GCC testing and Debian's System Monitor. > > I think it'll be an interesting reason that causes 2 CPU's mirror > action during all test process! > > Thanks! > > -Yasser > Probably make is running only one process at a time and Linux load-balances the cores in that it dispatches them in an alternating fashion. Try running make -j2 -k check to make make run two jobs at the same time. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Shoul I remember (keep in mind) all steps?!
>On Sat, 5 May 2012 09:43:28 -0700 (PDT) >Fernando de Oliveira wrote: > > On 05-05-2012 12:20, Yasser Zamani wrote: > > [...] > > > One more thing; sometimes I know why to run the script but I don't > > know how script works exactly. the main example is sed. I know it > > edits streams to replace or remove something but it's command in > > book is complicated for me at this time to understand. Is it > > essential to understand how it exactly works? > > Not essential. Sed is very powerful. Learning can be done by trying > to understand some of the ones in LFS book, and searching the > internet. > > Looking for "sed tutorial" with DuckDuckGo (or Google if you prefer): > > https://duckduckgo.com/?q=sed+tutorial > > a good list is given, the first item is very helpful: > > Sed - An Introduction and Tutorial - Welcome to The Grymoire! > > http://www.grymoire.com/Unix/Sed.html > > Or you can look at the info pages. >From the shell: info sed -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] usb mouse connects=disconnects repeatedly
>On Sun, 11 Mar 2012 14:45:02 -0700 >Martins Gulbis wrote: > > Well, I bought and installed a new mouse. NO CHANGE. One interesting > thing that I did notice though is that the disconnects/re-connects > occur almost exactly every 60 seconds. I am not sure what to make of > that. I am hoping that someone may know how to stop this from > happening. I believe the other alternative would be to turn off USB > Support->USB verbose debug messages and USB announce new devices and > rebuild the kernel. I believe that would at least eliminate the > messages from constantly showing up. > > Martins Just a check, did you try the mouse with some other distro? You mentioned Ubuntu, does Ubuntu (or whatever) have the same problem? -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] status report about the nouveau driver
>On Mon, 06 Feb 2012 22:28:25 -0500 >Alain Toussaint wrote: > > Hello everyone, > I still haven't done chapter 6 of the book but in > preparation, I tried to test a git kernel (v3.3.0-rc2) along with the > git sources of the nouveau driver for my nvidia card according to the > instructions there: > > http://nouveau.freedesktop.org/wiki/InstallDRM (section 1.2 in > particular). > > I also went ahead installing the latest version of the xorg-server > software (version 1.11.4), xf86-video-nouveau (git sources from an > hour ago) and the result is that the xorg-server sometime spin in an > infinite loop after anything from startup to 35 minutes after having > started up (listening to House,MD dvd's prove to be a good test for > the stability of the X server). > > the error occur at random and isn't found in my latest log (cmdline: > startx &>nouveau.log.txt) but the rest of the kernel run fine because > i press the power button normally (i.e. not holding it for 4 seconds) > and the kernel initiate an acpi shutdown event on lockup. > > for the next test, I will try a stock 3.3.0-rc2 kernel (sans the > nouveau git source) and report back. this will happen either tomorrow > or during next week-end. > > Alain > And a different experience from me: works fine. Specifically: vanilla linux 3.2.0, kernel side of the nouveau driver is in [device drivers]->[staging drivers] (you first need to enable experimental features in the menuconfig); Mesa-7.11 holds the actual Gallium 3d implementation, still a work in progress but works, mostly; Mesa requires libdrm (I use 2.4.26) which must be configured with --enable-nouveau-experimental-api; and finally the appropriate video driver for X server, xf86-video-nouveau. X server is version 1.11.1. Cue this discussion being booted to blfs-dev for being off-topic. The above setup has not generated any instability that I have been able to note. I was even able to hook it up with wine and play some 3D games, but with mixed results. Some (older) work, some (newer) don't. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Perl Problem
>On Mon, 07 Nov 2011 07:26:03 +1100 >Luke Ceddia wrote: > > Hi all, > I just started building the packages in chapter 6 when I discovered > and interesting problem. The perl binary exists in the /tools/bin > directory, I can view it with 'ls' and print it with 'cat'. Outside > the chroot environment, it runs fine. Inside the chroot environment, > however, bash refuses to execute it with the messsage > 'bash: /tools/bin/perl: No such file or directory' but it is clearly > there. I'm using Version 7 of the book on Debian Squeeze. > -Luke > Do: $ readelf -a /tools/bin/perl | grep interpreter You should get this (on 64bit): [Requesting program interpreter: /tools/lib/ld-linux-x86-64.so.2] If you get this, however: [Requesting program interpreter: /lib/ld-linux-x86-64.so.2] Then that means you did not properly reconfigure the linker and compiler. Redo Chapter 5.8. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problems in LFS 7.0 chptr 5.9 Binutils 2.21.1a - Pass 2
>On Fri, 04 Nov 2011 13:44:19 -0400 (EDT)
>Danny Vukobratovich wrote:
> I am getting this error:
>
> configure: error: cannot run C compiled programs.
> If you mean to cross configure, use '--host'.
>
> Does any one have any insight into how I can fix this? I am working
> on a 64-bit system. Thank you,
Your compiler is borked.
Look through binutils-build/config.log. It contains a log of everything
the build system did, including the detailed compiler error.
You are looking for something like this (this is a sample from xpdf):
[...]
configure:4048: checking for DOS (with DJGPP)
configure:4064: gcc -std=gnu99 -c -g -O2 conftest.c >&5
conftest.c: In function 'main':
conftest.c:14: error: '__DJGPP__' undeclared (first use in this function)
conftest.c:14: error: (Each undeclared identifier is reported only once
conftest.c:14: error: for each function it appears in.)
configure:4064: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define SYSTEM_XPDFRC "/usr/local/etc/xpdfrc"
| /* end confdefs.h. */
|
| int
| main ()
| {
| __DJGPP__
| ;
| return 0;
| }
configure:4071: result: no
[...]
--
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
kernel.org back online
Newsflash: kernel.org is back online. Repositories are available. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Building LFS using jhlfs
>On Thu, 29 Sep 2011 17:36:49 + >Jacob Alifrangis wrote: > > So what exactly was the answer, because there isn't one in the reply. The exact answer is that LFS is a book made by humans, for humans and that there is no standardized way of feeding it to the machine. Jhalfs may work, but it is under no obligation to do so. That said, please keep in mind that making a workable distro is not exactly a walk in a park for people who haven't done that before and may take as little as 3 months or as much as two years, depending on what you want to put in it and who does it. Have you considered Damn Small Linux, or Puppy Linux or PLD? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc error again
>On Thu, 28 Jul 2011 18:02:58 -0400
>"Bill Cunningham" wrote:
>
> Now it's not glibc I am concerned about my new builds of c++ and
> gfortran compilers are failing. C is the only thing that works. and
> the g++-3.2.2 that came with RH9. I'm using it to compile gcc-4.5.3
> and 4.6.1 and running into the same problem. Can't find libstd++.so.6
> or a shared like that. The thing is it's right there and the dynamic
> linker sees it. Maybe ld isn't seeing it. Something's not right.
Hi. I haven't been following this discussion, and I only skimmed over
the mails, but could you please explain in what order are you building
stuff, as well as where your stuff is and exactly which thing is where.
This looks similar to a problem I used to have when I would try to
build a complete system, with a toolchain minisystem, in the "wrong"
place.
To wit, if you build the toolchain minisystem, chroot, then build the
system glibc in /{,usr}, you will have no problems. But, if you try to
build it in some other place: /some-other-place, the process will fail.
If you did stuff by the book, make sure to see if you properly
adjusted/readjusted the compiler. See chapter 6.10.
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: I must doing this commands, and then all that was in "6.19. Ncurses-5.7" again?
>On Sun, 10 Apr 2011 15:16:01 +0400 >fuflono wrote: > > Good day. > (6.19. Ncurses-5.7) > Say, how to understand this: > ... > Note > > The instructions above don't create non-wide-character Ncurses > libraries since no package installed by compiling from sources would > link against them at runtime. If you must have such libraries because > of some binary-only application or to be compliant with LSB, build > the package again with the following commands: > > make distclean > ./configure --prefix=/usr --with-shared --without-normal \ > --without-debug --without-cxx-binding > make sources libs > cp -av lib/lib*.so.5* /usr/lib > ... > I must doing this commands, and then all that was in "6.19. > Ncurses-5.7" again? > ---Fuf > No. There are two sets of Ncurses libraries. One is build and installed by the main commands. You should be fine with only it. If you need the other, then you issue these commands. And after you do, you're done with it. Then you have two sets of Ncurses libraries. You can go on with the build. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
>On Sat, 12 Mar 2011 19:11:37 -0600
>Dan McGhee wrote:
>
> This is what I was hoping to hear--that the logic is sound,but that
> there might be a problem in the construct. I've shied away from ( )
> and {} in $ xxx statements because I'm really shaky on what they
> mean. I've also never seen the ' ' [ ] ' ' construct. I use the
> Advanced Bash Scripting Guide as my reference. Thank you for your
> feedback. I'll play with this.
Those (the '' thing) were quotes I used for inclusion in text.
Instead of writing
[ blah ]
I just wrote ''[ blah ]'' inline. Remove the quotes (luckily
they enclose empty strings so even if you don't remove them, they
should not change the meaning of the expression).
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
>On Sat, 12 Mar 2011 18:00:56 -0600
>Dan McGhee wrote:
>
>
> [snip]
>
> Following is the script from the "variable definition" through the
> logic tests. I've eliminated all the "extra" stuff.
>
> [snip]
>
> # This one recovers from a failed install
> if [ -e $logdir/make-`echo $package`.log ] && \
> [ ! -e $HOME/$package-files.list ]; then
>
> [snip]
>
> I've removed a lot of stuff in the script trying to make things
> relevant and specific to only the question. Please feel free to ask
> for additional info.
>
> [snip]
Well... DOES the script add all the logfiles it is supposed to add?
Are you /sure/? Have you checked?
The tests look kosher, as far as that matters, but I would turn my
attention to the creation of logfiles.
Other than that, my money is on the `echo $package` substitutions.
If ${package} has a space in it, that could break it.
You can fix this by doing ''[ -e "${logdir}/make-${package}.log" ]''.
Take a small package (gzip?), and build it in such a way that it breaks
at various points, then inspect the relevant directories to see what is
there and what is not.
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Glibc compile problem
>On Thu, 16 Dec 2010 21:22:19 +0800 >Harry Wei wrote: > > Hi us, >I do LFS6.3 these days. When i compile glibc-2.11.1, some errors > happen like following. I have searched on the Internet but find > nothing. I hope anyone can help me, thanks ;) >Errors like following: >... > > [errors] > >With Best Regards. >Harry Wei. > You are probably using a host system toolchain. Make sure you have properly set your PATH environment variable. And generally double-check your steps so far. Switching to a newer version of LFS would not hurt, either. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: how to test a build
>On Sat, 11 Dec 2010 00:09:04 +
>Ken Moffat wrote:
>
> The main problem with writing either hello.c or a C++ variant
> (hopefully, as .cxx, but .C and .cpp are sometimes used) is that we
> haven't got an editor. You can, or course, use the editor on the
> host system to create the program and test that it compiles
Well.. there is always the school of thought which considers a humble
'cat' to be a reasonable and usable "text inputer". :)
Something along the lines of
cat > my_cool_program.c
#include
main() {
printf("Hello World!\n");
}
:) :)
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: lastlog string
>On Thu, 25 Nov 2010 16:45:46 -0500 >Mike Hollis wrote: > > I just noticed that the printing of lastlog after login : > > Last login: Thu Nov 25 14:42:51 -0500 2010 on /dev/tty4 > > I thought this used to include the username . I poked around in > the code for Shadow to see if I could decipher the origon of this > string but got lost in a jungle of includes,stuctures,etc. > > I'm guessing that -0500 is my offset from GMT . On another partition > with LFS built in July the string is the same. A ssh login to a > remote machine with Debian installed yields : > > Last login: Thu Nov 25 16:24:34 2010 from eagle.cowpie.net > > This is all really not a big deal; It's odd that I just noticed it. > > Is this a variable that can be configured ? Well.. yes. Find it's location in the source and fix it. :) BTW, if I recall correctly, the line is printed by Bash, so you should look there. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: missing output from init scripts
>On Wed, 03 Nov 2010 10:58:08 -0600 >John Harrigan wrote: > > (disclaimer - I'm not using a standard build so I understand if no one > can help me.) > > I've mostly followed the development book and added an initrd and BSD > style init scripts. My problem is that output from the rc scripts is > not echoed to the console during boot. I do get kernel messages on > the console though. I know the rc scripts are running because I can > verify their work after logging in. > > After booting is complete, I can log in and run the rc scripts and the > output is echoed to the console. Inside the rc scripts, I can > redirect output to a file and the output is correct. > > The init script that runs from the initrd is able to echo output to > the console, but once I switch to the real root the only output I get > is kernel messages until I'm presented with the login prompt. > > Any ideas on how to debug this would be appreciated. Thanks. Do the scripts run in the proper virtual terminal? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
>On Fri, 15 Oct 2010 13:59:02 +0200 >Alberto Hernando wrote: > > Hi. > > I've put the instructions from the book in a script: > > baratito:~# cat chroot_lfs.sh > #!/bin/bash > > LFS="/media/lfs" > MAKEFLAGS="-j 2" > mount -v --bind /dev $LFS/dev > mount -vt devpts devpts $LFS/dev/pts > mount -vt tmpfs shm $LFS/dev/shm > mount -vt proc proc $LFS/proc > mount -vt sysfs sysfs $LFS/sys > > chroot "$LFS" /tools/bin/env -i \ > HOME=/root TERM="$TERM" MAKEFLAGS="$MAKEFLAGS" > PARALLELMFLAGS="$MAKEFLAGS" PS1='\u:\w\$ ' \ > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \ > /tools/bin/bash --login +h > > I just run it to enter the chroot. > > About timestamps: > > baratito:~# date > vie oct 15 13:55:00 CEST 2010 > baratito:~# sh chroot_lfs > sh: chroot_lfs: No existe el fichero o el directorio > baratito:~# date > vie oct 15 13:55:10 CEST 2010 > baratito:~# sh chroot_lfs.sh > /dev on /media/lfs/dev type none (rw,bind) > devpts on /media/lfs/dev/pts type devpts (rw) > shm on /media/lfs/dev/shm type tmpfs (rw) > proc on /media/lfs/proc type proc (rw) > sysfs on /media/lfs/sys type sysfs (rw) > root:/# date > Fri Oct 15 11:55:15 UTC 2010 > > There is really a difference. Perhaps the loop appears because the > build takes more than 2 hours? > Anyway, I did all the building with the "wrong" hour and timestamp. > And the chroot isn't in the future but the past. > Looks like the right place to look, but what? > > Alberto This actually does make sense, but only if a premise holds: that you untar the sources with the real time, and try building them with the 2-hours-in-the-past chroot time (however, in reality, 10h UTC and 12h CEST are one and the same time, but filesystem does not account for timegroups). It is simple to check this: ls -l $GLIBC_SOURCE_DIR, and see the times. If it holds true (sources have timestamps two hours in the future), then that's you problem. Perhaps untaring them once you enter chroot will do the trick (if you already do that, then the solution is more complicated). -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
>On Fri, 15 Oct 2010 11:57:30 +0200 >Alberto Hernando wrote: > > Hi. > > I'm building lfs-6.7, and I'm stuck compiling glibc in the chroot. I > have had it running for over 24 hours, and make isn't complete yet. I > don't want to stop it because there is no error, but I copied the lfs > folder to another point and started another building. Same result. > Make is all the time "leaving sources/glibc/ntpl" directory. I don't > think it's doing anything new. > The build is for intel 64 bit, with 4 Gb of ram. So far, all went > well, with more or less the times that the book says. And in my case, > 1 SBU is about 3 minutes. > > Any idea? > Thanks > The build system entered a infinite loop? Since Make determines what need to be build/rebuild by examining dependencies and timestamps, perhaps the timestamping of you files is broke? So that Make keeps thinking source files are newer that object files. How exactly did you enter chroot? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Perl Compilation Failure
>On Sat, 9 Oct 2010 12:51:47 -0500
>David Henry wrote:
>
> sh Configure -des -Dprefix=/tools -Dstatic_ext='Data/Dumper Fcntl IO
> POSIX'
>
> make perl utilities ext/Errno/pm_to_blib
>
> The result is a build failure with the following output:
>
> Running Makefile.PL in ext/POSIX
> ../../miniperl Makefile.PL INSTALLDIRS=perl INSTALLMAN1DIR=none
> INSTALLMAN3DIR=none PERL_CORE=1 LIBPERL_A=libperl.a LINKTYPE=static
> CCCDLFLAGS=
> Can't locate Cwd.pm in @INC (@INC contains: ../../lib) at
> ../../lib/File/Path.pm line 6.
It seems Cwd.pm is missing.
In a vanilla Perl source directory, it is in
${perl_srcdir}/cpan/Cwd/Cwd.pm
Perhaps Configure didn't do its job?
I only now saw the new instructions. Until now, I've been using
ancient 6.2 (and still am). It recommended running ./configure.gnu so
maybe you can try that script instead of Configure and see how it goes?
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Do I need CLFS ?
>On Sun, 19 Sep 2010 10:54:42 -0300 >Thiago Padilha wrote: > > Hi, > > My current architeture is x86_64 and I need to build for i686, my > question is : Do I need to follow the CLFS book? > I already started LFS, whenever theres a reference to '$(uname > -m)-lfs-linux-gnu' I use 'i686-lfs-linux-gnu' instead. So my > $LFS_TGT is set correctly and everything is working until gcc pass 2 > (chapter 5). I get the following error when compiling(notice that I'm > not using the /tools prefix) : > > /home/thiago/lfs/build-system/packages/lfs-toolchain/tools/x86_64-unknown-linux-gnu/bin/ld: > skipping incompatible > /home/thiago/lfs/build-system/packages/lfs-toolchain/tools/lib/libc.a > when searching for -lc > /home/thiago/lfs/build-system/packages/lfs-toolchain/tools/x86_64-unknown-linux-gnu/bin/ld: > cannot find -lc > collect2: ld returned 1 exit status > make[2]: *** [libgcc_s.so] Error 1 > make[2]: Leaving directory > `/home/thiago/lfs/build-system/packages/lfs-toolchain/src/gcc-build/x86_64-unknown-linux-gnu/libgcc' > make[1]: *** [all-target-libgcc] Error 2 > make[1]: Leaving directory > `/home/thiago/lfs/build-system/packages/lfs-toolchain/src/gcc-build' > make: *** [all] Error 2 > > Before binutils pass 2 I had the the 'i686-lfs-linux-gnu' directory > under my tools tree(I guess it was being used so far). After it I > also have 'x86_64-unknown-linux-gnu' directory, and it seems gcc > tries to use its tools on pass 2, thus giving me the error. Any help > is appreciated. > > Thanks in advance. You need to use CLFS. In this listing, the top (preceding command) is missing so I can only speculate on the exact error, but it looks as if you built some binary code (for i686, presumably) and tried to link it to x86_64 libraries. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the "nouveau" driver
>On Mon, 21 Jun 2010 11:21:27 -0500 (CDT) >al...@verizon.net wrote: > > Jun 21, 2010 10:52:35 AM, lfs-support@linuxfromscratch.org wrote: > > On my 'make menuconfig' > "Device Drivers>Graphics support> > [*] Support for frame buffer devices" screen > this is all I have: > > --- Support for frame buffer devices > [*] Enable firmware EDID > [ ] Framebuffer foreign endianness support ---> > -*- Enable Video Mode Handling Helpers > [ ] Enable Tile Blitting Support > *** Frame buffer hardware drivers *** > < > Cirrus Logic support > < > Permedia2 support > > None of the above seem to control yours, > CONFIG_FB_UVESA=m > CONFIG_FB_VESA=y > > Could these parameters be one of those "automatics"? > > -- > > Hi Andy, > > I did find your parameters in > > Device Drivers > Graphics support: > > < > Userspace VESA VGA graphics support > [ ] VESA VGA graphics support > > I disabled them as shown. > Alas, still the same problem with the recompiled kernel > (the video dies at the end of the boot-up sequence). > > I'm attaching the compressed copy of the new 'config'. > > Regards, > -- Alex Okey, I went over the settings, and I have a few suspicious things. First of, do you load the framebuffer console module? The one in drivers=>Graphics support=>Console display driver support, AKA FRAMEBUFFER_CONSOLE ?? This is an absolutely necessary module. The other module I am interested in is VIDEO_OUTPUT_CONTROL ? Third you might want to try with FB_TILEBLITTING, in drivers=>Graphics support=>Support for frame buffer devices Also, you might want to explore VGA_SWITCHEROO (not too much logic in that, I just have it compiled in, it's a shot). Turns out VESA really isn't the problem - I just discovered I had it compiled right in all this time. :) -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the "nouveau" driver
>On Sun, 20 Jun 2010 11:21:38 +0100 >Andrew Benton wrote: > > 2. I'm willing to work with a "nouveau" specialist to > > help them solve this problem if anybody is interested. > > > > Can we see your kernel config? Could you put it up somewhere like > pastebin and post a link so we can see please? > > Andy Yes, please? I've been using nouveau for months now (even before it got into staging) and had reasonably little problems with it (apart from Gallium 3D stuff). I'd really like to see the config, if you can upload it. -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: How to skip two settings
>On Wed, 16 Jun 2010 17:34:34 +0800 >Parmenides wrote: > > Hi, >When system starting, there are two settings, namely 'regional > settings' and 'edit settings', > at which the process of starting will pause and I have to press enter > key twice to finish them. > Is there any configurations by which I can skip them automatically > every time. This is in which part of the boot?? BIOS, Grub, Linux? Virtual machine? Other OS-es bootloader? Something else? -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: live and learn
>On Fri, 11 Jun 2010 13:16:24 -0500 >Mike McCarty wrote: > > Use a red colored prompt when running with root authorization. > > Hope you keep learning for a long time. > > Mike See, this is a good point. :) I should fix this on my system. -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Gnome desktop: unreadable characters
>On Tue, 01 Jun 2010 19:21:10 +0200 >Tobias Vogel wrote: > > hi, > > thanks for your quick reply. i checked the fonts-paths and could not > find anything odd about it, neither did the xorg.0.log complain about > anything in combination with fonts. > i ended up in reinstalling freetype2 and fontconfig, what finally > solved the problem, although i have no explanation for this. hope > this can help anyone else. > > thanks for your support! > > toby In hindsight, maybe fontconfig didn't cache your fonts? Or the contents of your /etc/fonts were not making much sense?? I had problems with fonts on Xorg-7.5 due to these quirks. -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GMP incorrectly detects CPU-VENDOR-OS triplet
>On Fri, 14 May 2010 22:20:32 +0100 >Ken Moffat wrote: > > On 14 May 2010 20:03, Prashant R Keshvani (Baijoo) > wrote: > > Hi, I have faced the same problem. I have used kvm to build LFS, > > when I ran configure from GMP, it generate an error saying no > > suitable compiler found for pentium2-unlnown-linux-gnu. actually my > > machine is x86_64-unknown-linux-gnu. I had to manually specify it > > using build option. > > > > Regards, > > > > I think we're still missing something here, but I don't know what it > is. The original report was 'athlon-unknown-linux-gnu', and the > problem is that he was building 64-bit - that is a 32-bit host. In > my own case, the logs show athlon64-unknown-linux-gnu for 64-bit. > > See also the discussion about ticket 2648 on -dev last weekend. > > Were you using a 32-bit vm with a 64-bit kernel ? > > ALso, was the original 'athlon-unknown-linux-gnu' reporter in a vm ? > > ĸen Wasn't it that there was some kludge about setting the enviroment variable named ABI for a succesful gmp build? I sort of remember having GMP hit me in the head last summer with it. And then it went away.. Was it when I upgraded to 64-bit? Can't remember. -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: cpuid.h not found
>On Tue, 11 May 2010 08:01:26 -0600 >Yan Mo wrote: > > [snip] > > > > > > > checking cpuid.h usability... no > > > checking cpuid.h presence... no > > > checking for cpuid.h... no > > > configure: error: gcc must provide the header > > > > > > > The file cpuid.h is provided by gcc. Since you do not have the > > file, it is possible that the gcc build in section 5.5.1 failed. > > You could try repeating that section and carefully checking the > > output. > > [snip] > > My machine also has cpuid.h in > $LFS/tools/lib/gcc/i686-lfs-linux-gnu/4.4.3/include so it makes me > wonder if something is not reverse-compatible with my 800MHz AMD > Duron. > > I choose my oldest machine to build this in order for my new system > to be compatible with as many machines as possible. Could it be those > that benefit by selling newer hardware are discouraging > reverse-compatibility??? Hmm... So, you have cpuid.h where it is supposed to be, but the working GCC does not use it? I think you should gut config.log of the failing glibc build and find the compiler output for the failing test. It will likely be somewhere in the middle of the file, and should contain the necessary information to diagnose the problem. Post it. I would also want to think of your CPU. Are you _sure_ it is i686? Ran config.guess or 'uname -m'? AFAIK, distros do not build i686 binaries, they build i486 or i586 binaries. So that can be a good place for all sorts of interesting things to happen. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.16 GCC-4.4.3 make -k check Error 2
>On Fri, 02 Apr 2010 07:26:59 -0400
>mas...@mail.com wrote:
>
>
> Hi i am using the LFS 6.6 book to build my LFS, but now im kinda
> stuck.
>
> I have compiled GCC but when i run the tests i get this:
>
> make: *** [do-check] Error 2
> make: Target `check´ not remade because of errors.
>
> Then i make installed it and did the symlinks.
>
>
> The first test checks out right.
> [Requesting program interpreter: /lib/ld-linux.so.2]
>
> The second test gives me:
> /usr/lib/crt1.o succeeded
> /usr/lib/crti.o succeeded
> /usr/lib/crtn.o succeeded
>
> But the book says it should be something like:
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crt1.o succeeded
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crti.o succeeded
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o succeeded
>
> The third test: grep -B4 '^ /usr/include' dummy.log
> /tools/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1 -quiet -v
> -isystem /usr/include dummy.c -quiet -dumpbase dummy.c -mtune=generic
> -auxbase dummy -version -o /tmp/cckbdRPw.s ignoring nonexistent
> directory "/tools/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../ #include
> "..." search starts here: #include <...> search starts here:
> /usr/include
>
> The book says:
> #include <...> search starts here:
> /usr/local/include
> /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/include
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include-fixed
> /usr/include
>
> The fourth test: grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/lib")
> SEARCH_DIR("/lib");
>
> Book says:
> SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/local/lib")
> SEARCH_DIR("/lib")
> SEARCH_DIR("/usr/lib");
>
> Fifth test: grep "/lib.*/libc.so.6 " dummy.log
> attempt to open /lib/libc.so.6 succeeded
>
> Sixth test: grep found dummy.log
> found ld-linux.so.2 at /lib/ld-linux.so.2
>
> I guess this is a cause for concern, am i right?
> and I tried recompiling gcc 4 times.
>
> Where did i go wrong, and how far should i go back to fix this?
>
> Thanks
> //Mastah
First off, you should include more information about your failure.
This is a failure of the gcc test suite. You built GCC succesfuly,
you tested your build, and it reported some failures.
To see which, issue the command
/path/to/your/gcc-sources/contrib/test_summary | grep -A7 Summ
This is from the gcc build directory.
The details are explained in Chapter 6.16 of the current stable LFS
book (vers. 6.6). To summarise, some failures in the test stage are
"normal". They occur frequently, and have not been linked to end-system
instability. Some others are not.
But first you have to see which are the failing tests and include that
information.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: write error with new version of tar
>On Fri, 19 Mar 2010 14:21:29 -0600 >Mike McCarty wrote: > > Bruce Dubbs wrote: > > Chris Staub wrote: > > [...] > > >> I do not get any kind of error message when just using "tar -tf" > >> by itself, only when piping through "head". Also, I tried piping > >> through various other programs (grep, sed...) and got nothing. > > > > I get the same error message with head: > > > > ./configure > > make > > cd src > > ./tar -tf ../../tar-1.23.tar.bz2 |head > > > > > > Me too. > > > > > > I'll report the bug. > > I wonder if "head" is closing the input pipe when it has read > all it needs, and that's causing the error. I can't reproduce > that problem with my host system, however. > > Mike I can also confirm problems with tar-1.23. What is your host system? I have Glibc-2.9, GNU Coreutils-7.6 and Bash-4.0.35, on top of Linux-2.6.23.2. Speculating: maybe the problem is not with the tar per se, but somewhere in the interface? If there is a system on which tar-1.23 behaves properly.. -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Unable to boot LFS... Help me
>On Sat, 13 Mar 2010 14:02:41 +0530 >"Sathya Narayana.R" wrote: > > Hello, > I finished my LFS 6.5 along with "package user" system. After > completing the installation of grub and everything, i booted into the > new system. > > It shows the following errors... > > > /sysmount: only root can do that > grep: /proc/mounts: No such file or directory > > Failure: > Unable to create devices without a SysFS filesystem > > After you press enter, this system will be halted and powered off Perhaps you can share some more information? How about all of the boot messages up until that point. The point for now is in answering the question of whether /sys gets mounted or not. Also, where did you get that sysmount from? How did you install the bootscripts? Are they from the lfs-bootscripts-20090812 package? -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: lose data on shutdown?
>On Fri, 12 Feb 2010 05:22:24 -0800 >"Kyle Rush" wrote: > > On Fri, February 12, 2010 5:15 am, Andrew Benton wrote: > > On 12/02/10 12:14, Kyle Rush wrote: > >> > >> I have a livecd 6.3 and book 6.3. the computer I am installing it > >> on is somewhat old, and thus 1 SBU = about one hour. I can't > >> figure out how to shut down the machine without losing everything > >> i was working on. > > > > If you've made a partition on your hard drive to work on then when > > you unmount it > > all that you've compiled will be saved there. > > The problem is when you resume work you need to make sure things > > are set up properly. > > In chapter 5 that just means su - lfs but in chapter 6 you need to > > make sure that > > you've mounted /proc, /sys and /dev > > > that's the problem. I'm in chap.5 and su - lfs doesn't work. says > error:user does not exist. > > I have set up the user lfs as instructed. > Have you set it up after resuming? As I have understood it, you booted the livecd, made the preparations, built, stoped, rebooted (or whatev) and now you can't resume. It's simple - the root filesystem of the livecd lives in RAM and goes away with the power. What's on the HDD (/mnt/lfs) does not, ofcourse. So, when you boot the livecd, make a new user and build, then all that happens above /mnt/lfs is volatile. Upon rebooting, you just have to redo ALL the enviroment setting-up. Mike and others have already explained the details. The scripts they mention should be put somewhere under /mnt/lfs, so that they themselves are not in volatile memmory. Upon rebooting, run them. But make sure you do it properly - if your script is like this: # Begin my_script.sh export LFS=/mnt/lfs export FOO="blabla" Then simle `bash my_script.sh' won't help becouse the bash you just ordered will fork a totally new process which will run my_script.sh, set its own enviroment and then die. You should do: `source my_script.sh'. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: OK, I stumbled again on glibc
>On Mon, 1 Feb 2010 10:42:51 -0800 (PST)
>brown wrap wrote:
>
>
> When I run configure it says critical programs are too old or
> missing. I am logged into that window as user lfs. I looked at the
> environament and compared it to root's env and the paths looks the
> same. But if I run configure as root, I get no complaints. Here is
> the error, it looks to me likes its complaining about as and/or ld,
> but the paths to each is the same for both users:
>
> /mnt/lfs/sources/6.4/glibc-build$ ../glibc-2.10.1/configure
> --prefix=/tools --host=$LFS_TGT
> --build=$(../glibc-2.10.1/scripts/config.guess) --disable-profile
> --enable-add-ons --enable-kernel=2.6.18
> --with-headers=/tools/include libc_cv_forced_unwind=yes
> libc_cv_c_cleanup=yesq../glibcq LDFLAGS=-L/usr/local/lib
>
> checking whether autoconf works... yes
> configure: error:
> *** These critical programs are missing or too old: as ld
> *** Check the INSTALL file for required versions.
> lfs:/mnt/lfs/sources/6.4/glibc-build$
Can you maybe show the output of that
`../glibc-2.10.1/scripts/config.guess' up there?
Also, I see you have both $LD_LIBRARY_PATH and $LDFLAGS set up to point
to your /usr/local/lib (if this is your production system, it may be
quite a good idea to drop the $LD_LIBRARY_PATH entirely and add
/usr/local/lib to your /etc/ld.so.conf). Naturally, this can not only
wreck havoc with the build process, it also defeats the "isolate the
build from the host" principle of LFS.
As for the version mismatch, I had a similar problem when trying to use
binutils-2.20 with glibc-2.9 on a pure-64 (which I just ignored and
used binutils-2.19). I have no idea as to wether this also happens on
32-bit builds.
You should also try to find out exactly which executables of the build
packages are you using. You can give it a try by either enchanting
`which gcc' `which cpp' `which cc' `which as' `which ld', or by saying
`gcc --verbose' and inspecting the bits it spits out.
If those bits are the same as the options you gave gcc when you were
compiling it (look for "--prefix=/tools"), then you are using the newly
built GCC. If not, somehow you are picking up the host GCC from the
build enviroment (I blame $LD_LIBRARY_PATH and $LDFLAGS).
Ultimately, if you have a problem with the toolchain, that is where you
must look. For example: write a dummy C program (main(){return 42;})
and try compiling it. If it fails, it will tell you more info and
direct you to the failing component. You can also use compler flags to
see which step fails: -E to only run the preprocessor, -S to only
compile C to assembly (these two rely only on GCC), and -c to assemble
and none to do the whole process. The -c and NONE options rely on a
funcional binutils package.
So that should hopefully enable you to pinpoint the failing component.
Then we can see what is wrong whith it.
But first unset the $LD_LIBRARY_PATH an $LDFLAGS enviroment variables
and then give it a try (but start from the begining - wipe the build
filesystem clean and then begin with Chapter 5).
Hope this helps. :)
-AKuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: LFS 6.5 chapter 8.3.1
>On Thu, 3 Dec 2009 03:44:43 -0500 >stosss wrote: > > I started over from scratch. I have captured log files of everything. > I ran tests on everything and captured all those tests. Everything was > going along nicely. > > In chapter 6.4 I used: > > chroot "$LFS" /tools/bin/env -i \ > HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \ > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \ > /tools/bin/bash --login +h > > compiled and installed everything. > > I skipped over chapter 6.60 stripping. > > I did use logout from chapter 6.60 and in chapter 6.61 I used: > > chroot "$LFS" /usr/bin/env -i \ > HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \ > PATH=/bin:/usr/bin:/sbin:/usr/sbin \ > /bin/bash --login > > to log back in > > completed chapter 7 > > completed chapter 8.2 > > chapter 8.3.1 ran tar -jxvf linux-2.6.30.2.tar.bz2 > > cd linux-2.6.30.2 > > then ran make mrproper and got this error message: > > make: gcc: Command not found > > What happened? It's radher hard to figure out what could cause such a mistake (without actually seeing the filesystem), but a misplaced "--prefix" option passed to the GCC configure is my likeliest bet. Upon entering the chroot enviroment did you do "set +h"? Or do you have it in bash startup files? It also might be informative if you do "readelf -l /bin/bash | grep interpet" or on some other arbitrary executable (if you still have the old chroot). And if all other options fail: "find / -iname \*gcc\*" :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Segmentation fault after stripping
>On Mon, 23 Nov 2009 16:02:12 -0500 >linux fan wrote: > > Segmentation fault occurs right after stripping in chapter05. > > I am building lfs trunk using jhalfs trunk. > > The stripping step succeeds, but the next step which is to > restore-luser-env errors. The restore-luser-env step only has to copy > the saved $(LUSER_HOME)/.bashrc.XXX back to .bashrc, but that fails: > > Building target 058-stripping > [++| ] 0 > min. 10 sec Target 058-stripping OK > > /bin/bash: line 1: 27848 Segmentation fault make > BREAKPOINT=074-gcc LUSER make: *** [mk_LUSER] Error 139 > > As you can see, the stripping succeeded, but it immediately fails on > the next bash command. > > Here is from sys.log: > Nov 23 15:25:32 lfs sudo: wnh : TTY=pts/0 ; PWD=/mnt/lfs/jhalfs ; > USER=root ; COMMAND=/bin/su - jhalfs -c source .bashrc && cd > /mnt/lfs/jhalfs && make BREAKPOINT=074-gcc LUSER > Nov 23 15:25:42 lfs kernel: make[27848]: segfault at 7b0 ip 40008fdd > sp bfccaaa0 error 4 in ld-2.11.so (deleted)[4000+1d000] > > I have the build backed up right after textinfo-ch5. > I have restored the build dir and restarted and it Segfaults every > time at the same place. > > I tried a 20 second sleep at the end of the stripping, but it still > Segfaults. > > Any ideas? As I have not tried jhalfs, a question, just to be clear: you are running the make command via automated means, after stripping, in a single slurp (from the same script)? If so, try running it manually after stripping. As in - your toolchain gets stripped, jou get your shell prompt back, and then you run the make command. That used to work for me in similar arrangements. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: building x86_64 using lsflivecd-86_64
>On Mon, 16 Nov 2009 03:32:03 -0500 >Chris Staub wrote: > > On 11/14/2009 04:54 PM, Aleksandar Kuktin wrote: > > First off, I understand that in newer versions of LFS book, the > > build process changed, so that GCC and binutils are built together. > > I still use the old method, in which binutils and GCC are build > > separately. This is reflected in this e-mail, so don't let that > > confuse you. > > Um, I don't know what you're looking at...yes, the build process > changed, at least for the first few packages in Chapter 5, but GCC > and Binutils are in fact still built separately in current > Development LFS. Right, I was looking at HLFS. Actually, the last time I seriously looked at the main LFS book, it was at version 6.2. And I just thougth that the changes made in HLFS got propagated... -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: building x86_64 using lsflivecd-86_64
>On Sat, 14 Nov 2009 22:54:49 +0100 >Aleksandar Kuktin wrote: > > [snip] > > If you opt for a 64-bit only, however, the stock LFS commands should > do the trick (I myself use ones from CLFS-1.0.0-x86_64-64, adapted > for my versions of packages/patches). > > [snip] > > Hope I was helpful. :) > -Aleksandar Kuktin P.S. Woops! I forgot to mention I don't build GRUB anymore, those binaries (the GRUB in MBR, /boot/stage1 and /boot/stage2) are leftovers from my last x86. He-he. Small detail. :) -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: building x86_64 using lsflivecd-86_64
First off, I understand that in newer versions of LFS book, the build process changed, so that GCC and binutils are built together. I still use the old method, in which binutils and GCC are build separately. This is reflected in this e-mail, so don't let that confuse you. >On Sat, 14 Nov 2009 09:56:44 -0800 (PST) >Lapohos Tibor wrote: > > Hello All, > > I the the 6.4 book thourgh, and it worked out very nicely. Now I need > a 64 bit version. I am aware that the support for 64 bit systems is > only about to come in a future release of LFS, but I would like to > give it a shot somehow, since that is what I need. In order to do > this, one needs a 64-bit compiler and kernel, which the > x86_64 lsflivecd has, at least in my understanding. Having said that, > I would like to ask a few questions: > > 1) For now, I am booting off the x86_64 lsflivecd, and I am following > the CLFS way to build a 64-bit multilib system, although > pure 64 would suffice, and somehow I find it unnatural that one would > need to cross-compile, while building for the host, on the host > itself. It just doesn't feel right. Or am I completelly wrong? This depends on the target capabilities. I have successfully built and am running/depending on a pure 64-bit system, and in my experience, for a pure 64-bit, no cross-compilers are necessary (apart from the first, which catapults your userland & kernel from x86 to x86_64). However, for a multilib, a 32-bit compiler is a requirement (which should be logical - you want to be able to build x86 binaries, right?). Thus - CLFS. If you opt for a 64-bit only, however, the stock LFS commands should do the trick (I myself use ones from CLFS-1.0.0-x86_64-64, adapted for my versions of packages/patches). However, toolchain commands need to be tweaked, in the following way: 1) --disable-multilib needs to be passed to all binutils and GCCs (ie. everytime either is configured - first toolchain, second toolchain, system - it needs to be passed). Otherwise, make tries to build a cross-compiler.* 2) the "gcc-x.y.z-pure64-1.patch" (for system and first toolchain GCC) and "gcc-x.y.z-pure64_specs-1.patch" (for second toolchain GCC) from CLFS need to be applied. Look in them for details on what they do. [*] Apparently, I have repetadely built my second toolchain binutils without this switch, so I guess that one doesn't need it. Additionally, I now see I compiled "system coreutils" with environment variable CC set to "gcc -m64". But I don't know why I put it there, the "toolchain coreutils" builds without it. O_o > 2) While on the x86_64 lsflivecd platform, by following the LSF 6.5 > instructions one should, more or less, be able to build a 64 bit > system. A few parameters would need to be modified only, right? For > example, having --target=x86_64-unknown-linux-gnu among the > compilation parameters, should on its own invoke 64-bit output > generation. A few settings could also be borrowed from the CLFS book, > in order to get 64-bit generation enabled, right? By the way, would > that not be the default gcc setting on a 64-bit platform? I mean, > automatically? I have no experience running or building a multilib system, so I can't be of much help on that. :( On a pure-64, you can do almost everything you want (some programs and packages just can't/won't build - most notably kaffe ). No special tweaks needed - my system looks exactly as it looked when I was 32-bit. > 3) The lsflivecd (x86_64) site mentions an unofficial > version of the, I suppose, 64-bit version book, that I hope would > contain some pointers for me to start with, but neither could I find > it in the mounted CD iso image nor on the webpages. Is such thing > really available? A pointer to any version or draft would be highly > appreciated. > > Thank you All in advance, > Tibor Hope I was helpful. :) -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
