Re: [lfs-support] gcc-4.9.0 failure
On Thu, Apr 24, 2014 at 12:23:28AM +0200, Frans de Boer wrote: > I could not compile 4.9.0 since it always fails when staring to > configure for 'libvtv' as showed next: > [snip] > > Any suggestion? > > Frans. http://wiki.linuxfromscratch.org/lfs/ticket/3552 Pierre seems to be on the case - so far, two extra configure switches in chapter 5 one extra switch in binutils pass 2. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Mon, Apr 21, 2014 at 06:36:19PM +0100, Hazel Russman wrote: > On Mon, 21 Apr 2014 19:25:10 +0200 > Pierre Labastie wrote: > > > > Looking more closely at your log, it seems that acl's are enabled, > > because the line beginning with [95]: 'getfacl --omit-header f' > > correctly returns acl entries: user::rw- > > user:bin:rw- > > user:daemon:r-- > > Actually, the line beginning with [91], which returns the first > > error, seems to choke on g:users:rw. Do you have a "users" group > > in /etc:group? > > > > Pierre > > Thank you very much. That was the source of the problem. Adding the > "users" group cleared all the remaining errors. But I notice that this > group, like the daemon user, are not specified in section 6.6 > where /etc/passwd and /etc/group are created. Should they be? > From memory (so, I might be wrong) the book doesn't ever create a 'users' group in LFS. What we as individuals have to do may differ. I came here via RedHat-6 and Mandrake-7 and shared /home between the systems I was running at the time. So /home/ken is owned by user 500 and group 1000 : I create ken as user 500 and add a users group of 1000 whenever I build a new system. When I was using ppc I had a user/group combination from debian-based systems - the numbers were quite different. So, I _guess_ that the 'users' group exists on your host system and you will need to create it in LFS to get these tests to work. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] error when trying to cross compile glibc-2.19
On Fri, Apr 18, 2014 at 10:37:48PM +0300, mar...@byteanywhere.com wrote:
> Hi,
>
> I am getting the following error trying to build LFS 5.7
>
For anybody confused by '5.7', that is section 5.7 not the LFS
version ;-) With glibc-2.19 you are either using LFS-7.5 or a
recent version of the development book.
> x86_64-unknown-linux-gnu-gcc -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE
> -DIS_IN_build -include
> /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/config.h
> rpc_main.c \
When I see a version of crosstool in the directory name, together
with your heading about cross-compiling, I think that I don't know
what you are doing! The LFS book is written for people building in
/mnt/lfs, with a symlink from /tools to /mnt/lfs/tools.
There is no requirement that /mnt/lfs needs to be a separate
filesystem, but you do need to be able to access it as /mnt/lfs -
from time to tiem I do test builds using a directory which I have
bound to /mnt/lfs. Perhaps you are doing the same, but referencing
crosstool implies you may well be doing something very different.
In particular, you probably have not followed section 4.3 - we tell
people to log in as the lfs user. Or perhaps the lfs user does have
write access in /home/marian - some potential to overwrite your own
files.
> -o
> /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o
> -MMD -MP -MF
> /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o.dt
> -MT
> /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o
> -c
> rpc_main.c:37:19: fatal error: errno.h: No such file or directory
> #include
>^
> compilation terminated.
If you are indeed following the book, I think that perhaps you
didn't install the kernel headers. There are _variants_ of errno.h
in those. But I think this is probably a crosstool issue : glibc
itself provides errno.h, so at this point in the process I guess it
comes from the host system. Or alternatively, it should be coming
from the glibc you are building - in that case, either your disk is
full or the extracted source appears to be incomplete.
It would definitely help if you can explain what you are trying to
do.
>
> I configured :
>
> ../glibc-2.19/configure --prefix=/tools --host=$TARGET
> --build=$(../glibc-2.19/scripts/config.guess) --disable-profile
> --enable-kernel=3.7.10 --with-headers=/tools/include
> libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes
> --without-selinux
>
> I am running on linux 3.7.10. I am not sure how to get this working.
> I build gcc using:
>
> make all-gcc
> make all-target-libgcc
> make install-gcc
> make install-target-libgcc
Yes, you are doing something different from the book - we are able
to build pass-1 gcc using just make and make install.
>
> because otherwise if i use make, i also get error saying that the
> compiler can not create executables.
>
> Thanks,
> Marian
>
We don't support real cross-compilation, if that is what you are
trying to do. If your host system is x86_64-unknown-linux-gnu then
you should be able to build LFS for x86_64.
But one of the things you need to learn, even if you are not
following the book, is how to debug the "C compiler cannot create
executables" message. It's actually quite easy - in both gcc and
binutils, "configure" is run in several directories. As it runs,
it creates output in "config.log" in that directory, then moves on
to the next directory and does the same thing - until it fails.
So, to debug the gcc build problem (and your solution suggests that
you are really cross-compiling), you need to find the newest
config.log (or log configure's stdout and stderr and work out which
directory it was in by reading the log). Then open up that
config.log in e.g. vim ('view' for safety, I suppose) or else in
'less'. Search for the message:
/C\ compiler\ cannot
('/' to search in vim or less, '\ ' to escape the spaces so that
they are treated as part of the text to search for.)
When you find that error message, look at the lines above it
(probably a few screens worth, say 50 to 100 lines). You should see
a message about what is being tested, a program fragment getting
created, and then it is fed to the compiler to see if it will
compile. Throughout any config.log you will see many error messages,
typically because your system does not support a particular feature,
or does not have a specific file. That is normal, but here you have
a real error.
Sometimes, a missing header might trigger it - that seems unlikely
for this particular error, particularly since you compiled pass 1
binutils just before gcc. Perhaps there was a typo in $LFS_TGT when
you built binutils. Usually, either gcc or ld is objecting to
something in the compile, or occasionally there is a problem with
ld. Either way, you will see the error mess
Re: [lfs-support] EXT3-fs (sda4): error: couldn't mount because of unsupported optional features (240) , during kernel boot
On Fri, Apr 04, 2014 at 09:01:56AM -0700, Golam Md. Shibly wrote: > cat /etc/fstab => > # Begin /etc/fstab > > # file system mount-point type options dump fsck > # order > > /dev/sda4 / ext4 defaults 1 1 [...] > > On Friday, April 4, 2014 9:39 PM, Ken Moffat wrote: > > So, do you have a problem [ i.e. it failed to boot ] or are you > just concerned about reported errors ? > You didn't answer the question, so I assume you are just concerned about reported errors. You seem to have been able to log in to the LFS system to run that 'cat'. So this is nothing to worry about. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] EXT3-fs (sda4): error: couldn't mount because of unsupported optional features (240) , during kernel boot
On Fri, Apr 04, 2014 at 05:05:23PM +0100, akhiezer wrote: > > > > This looks perfectly normal. There is a kernel option to allow > > ext4 to handle ext2 and ext3 filesystems. I think you probably made > > an ext4 filesystem on sda4, and after this it should get mounted as > > ext4. I see something like these messages on every boot. > > > (( - thought you didn't like auto - at least automounting - stuff being > done to your disks? ;) Why let it d*ck about when you can tell it, "it's > $__". > )) > I don't like something deciding what I happen to want to do this time when I plug in a usb stick or external drive. Adding auto in my fstab was initially a convenience for when I moved to ext4, and is retained in the expectation I will probably change to something else in future. In any case, I think that the message happens even if the rootfs has been specified as ext4 (if the kernel has been built to allow ext4 to mount ext2 and ext3, which might give a smaller kernel) - that seems to fit with what Golam has now posted. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] EXT3-fs (sda4): error: couldn't mount because of unsupported optional features (240) , during kernel boot
On Fri, Apr 04, 2014 at 07:31:51AM -0700, Golam Md. Shibly wrote: > Hi, > > EXT3-fs (sda4): error: couldn't mount because of unsupported optional > features (240) > EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities > > What can be the reason for this error? > > > Answers will be appreciated. > > Thanks. This looks perfectly normal. There is a kernel option to allow ext4 to handle ext2 and ext3 filesystems. I think you probably made an ext4 filesystem on sda4, and after this it should get mounted as ext4. I see something like these messages on every boot. So, do you have a problem [ i.e. it failed to boot ] or are you just concerned about reported errors ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Brand new and confused. Mostly about the 7.5 book.
On Sun, Mar 30, 2014 at 11:44:19PM +0100, Ken Moffat wrote: > > swap : yes. The traditional theory was 2 x physical memory, but I > might go with more than that if physical memory is small (e.g. <= > 4GB). On what is now a small disk I would not go overboard with the > swap. > I managed to come away from Al's post with the impression that he had an 80GB disk, which is where "what is now a small disk" came from. He actually said that he thought LFS needed 80GB. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Brand new and confused. Mostly about the 7.5 book.
On Sun, Mar 30, 2014 at 11:31:59PM +0200, Aleksandar Kuktin wrote: > >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. > I think we are all following Al in asking the wrong question ;-) Surely, the first question ought to be "What partitions will suit _my_ usage ?". In my own builds, /sources is an nfs mount (and it contains in excess of 20GB : I pruned it last week, but it has source for most of the packages in BLFS, so that I could test them for 7.5. My own builds are motly on desktops, and in general I have the following as separate filesystems : /, /boot, /home and swap. I _only_ use LFS, so I need at least two partitions which can be used for '/', and I also allocate my remaining space [ modern disks are stupidly big for desktop users ] to /scratch which does _not_ get backed up. Also, if you have the space in /home, you can keep the sources there. Re the other places mentioned : /usr/src : why do anything here ? In BLFS you are recommended to _not_ build as root (although I do in my scripts) and by default /usr/src is only writable by root. Similarly, anyone who says that the kernel tree belongs in /usr/src/linux is living in the distant past - that idea was obsolete even when I first used linux at the turn of the millenium. Building newer kernels in ~/ is good. /opt : Sometimes it is useful to keep this separate, but unless you intend to put TeX or KDE in /opt I would NOT make it separate. Even if you do intend to use those space-hogs, a bigger '/' [ ideally with room for TWO versions of /opt ] will make building a newer version on the current system _much_ easier. If you do separate /opt, please remember that its programs and libraries will link to libs in '/lib' and '/usr/lib', so sharing /opt between multiple systems on the same machine is not usually possible. Perhaps I should stress that the recommended upgrade path for LFS is to build a new system. So, if you have /opt as a separate filesystem for the first LFS you will need a simialr amount of space for the replacement system. IMHO, far better to make '/' big, with /opt and /usr part of the root filesystem. But whatever you do, if you keep building LFS or similar systems you will eventually find that your partitioning no longer meets your requirements. A rescue CD is essential [ please let me mention systemrescuecd, even though it uses zsh and is therefore not always plain-sailing when entering chroot ]. /usr : A separate /usr is a very old idea. Useful if you are on a network where /usr is an nfs mount shared by several machines. I'm sure there are other use cases, but I can't think of any at the moment. For most of us, giving /usr on its own filesystem makes no sense. /tmp : This is separate ? ken@ac4tv ~ $mountpoint /tmp /tmp is not a mountpoint At one time we used to mount a tmpfs on /tmp, but somewhere along the way (perhaps between 6.8 and 7.0) we stopped doing that, which from my POV was a shame. But I cannot see any good reason to give /tmp its own filesystem. swap : yes. The traditional theory was 2 x physical memory, but I might go with more than that if physical memory is small (e.g. <= 4GB). On what is now a small disk I would not go overboard with the swap. /boot : yes, it makes things easier when you upgrade your LFS syustem by building a fresh system. For me, at the moment I have <3 MB in /boot/grub, and <5 MB per kernel - and I've got a lot of those, but they are generally slimmed-down to match my hardware. Sticking a finger i nthe air, 100MB lookss adequate. For *servers*, some other directories might benefit from having their own filesystem, it all depends on what you are doing. I've seen a use-case for separating /var/log, and I myself separate /var/tmp on my server - I also have other non-standard filesystems there. That is all a question of what fits best with what you intend to do. I used to use 6GB partitions for '/' with /sources separate (nfs), but my desktop builds increased to cover more of what is in BLFS. I now use 8GB, but that is not enough for all of the desktop alternatives, and doesn't give enough space for TeX even on my normal desktop [ I put TeX in my /sccratch partition, and bind it if I need to use it, but for a "full-ish" des
Re: [lfs-support] 64 bit host machine build question
On Thu, Mar 20, 2014 at 09:15:35PM -0400, Jonathan Arnold wrote:
> I'm doing the 5.7 glibc-2.19 step and everything seems to be going
> along swimmingly. But the test program mentioned in the Caution isn't
> exactly what is desired:
>
> lfs:/mnt/lfs/sources/glibc-build$ echo 'main(){}' > dummy.c
> lfs:/mnt/lfs/sources/glibc-build$ $LFS_TGT-gcc dummy.c
> lfs:/mnt/lfs/sources/glibc-build$ readelf -l a.out | grep ': /tools'
> [Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]
>
> While the Caution says to expect the /tools/lib64 part, it doesn't say
> anything about the '-x86-64' I have appended to the name. Is this going
> to be okay or is something amiss here?
>
Your result looks fine. When you get to section 6.10 you will see
that we add the phrase "allowing for platform-specific differences in
dynamic linker name". If you look at your host system, the linker
will be ld-linux-x86-64.so for 64-bit x86_64.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Blank screen when booting with 3.13.3 kernel. - LFS 7.5
On Wed, Mar 12, 2014 at 08:52:55PM -0500, rhubarbpie...@gmail.com wrote: > > Louis, > > Actually, I got several responses quickly. I just sent you one which > echoed my situation. I'm hoping Armin will glean something from the log > file. > Also, take a look at https://lkml.org/lkml/2014/3/13/71 (HP Compaq nc6120 - I don't think you ever mentioned what sort of laptop this was). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Blank screen when booting with 3.13.3 kernel. - LFS 7.5
On Wed, Mar 12, 2014 at 02:29:52PM -0500, rhubarbpie...@gmail.com wrote: > > On 03/12/14 12:11, Duc Tran wrote: > >On 03/12/2014 11:11 PM, Armin K. wrote: > >>On 03/12/2014 05:09 PM, rhubarbpie...@gmail.com wrote: > >>>On 03/12/14 10:19, Merell L. Matlock, Jr. wrote: > On 03/12/14 10:54, Armin K. wrote: > >On 03/12/2014 03:46 PM, rhubarbpie...@gmail.com wrote: [ keeping all that, I've lost track of who wrote what ;-) ] > >>Could you post your kern.log from /var/log after you boot? (you can get > >>it from chroot after reboot iirc). Compress it before sending or it > >>might get blocked. > >> > >I also had no success after deselecting Sony Vaio Programmable I/O Control > >Device Support. > A couple of things I noticed, the first of which is relevant to this, and hte second of which might make things more comfortable when you have this issue sorted. First: Mar 12 13:22:40 lfs kernel: [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness Mar 12 13:22:40 lfs kernel: [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness This is supposedly fixed with "acpi_backlight=vendor" but I think you said that didn't help. Later, some messages showing the console was created : Mar 12 13:22:40 lfs kernel: fbcon: inteldrmfb (fb0) is primary device Mar 12 13:22:40 lfs kernel: Console: switching to colour frame buffer device 160x50 Mar 12 13:22:40 lfs kernel: i915 :00:02.0: fb0: inteldrmfb frame buffer device So it seems that the console is there, but without the backlight. Does your config have all of the CONFIG_BACKLIGHT settings which you had in 3.10 ? Looking at one of the _many_ matches for "ACPI: No _BQC method" I found an old one which led me to suggest that you try i915.invert_brightness=1 in the boot args. If that helps, you might need to take it upstream : there seem to be a horrendous number of variations in intel graphics chips/implementations, and breakage of some models seems to happen from time to time. This option is documented in the kernel's Documentation/kernel-parameters.txt file. I assume that you are putting the options in the right place, on the same line as root= ? I'm sure you are, but best to check. Iff none of this helps, it might be a kernel regression. Ideally, try to isolate where it happened (e.g. try 3.13.0, 3.12.0, 3.11.0 until you find one that works, and then perhaps move forward through its stable releases to find out where it broke). It's also possible that this has worked sometimes, but not others, on your hardware. *** But first try the latest 3.13 just in case it has already been fixed *** Second: I don't know what size of screen you have (inches or cm, as well as pixels), but 160x50 might be a bit tiny to read - if so, after you can get a display, change (or add) video=x in the boot args where is the number of horizontal pixels on your screen, and is the vertical. On my old 1600x1200 4:3 screen I can also pass 1024x768 or 800x600, but I don't know what your screen size is, or if there are any conventional smaller sizes which would fit onto it. If you are trying this, copying the grub stanza for the kernel but with something different in the menuentry such as your x and just adding the video= will let you see it it helps and still be able to go back to the first one. Using a bigger consolefont can also help - on my netbook I use a 12x22 font to make it easier to read. That requires setting font support, fonts, and Sun 12x22 in the kernel, and the LFS sysconfig will need to either _not_ specify a font (i.e. use the kernel's sun font which is ok for American), or use one of the 12x22 fonts from kbd to get wider coverage. NB specifying a 12x22 font in LFS on the current kernel which probably doesn't support 12x22 will not load the 12x22. If you want to try 12x22, then I suggest you try it in the kernel and look at the kernel messages before userspace drops back to whatever font you are currently using. Then you can decide is 12x22 is useful for you, and either continue, and change the font in LFS, or give it up as "too big". ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Exotic lfs compiling question
On Thu, Feb 20, 2014 at 04:49:29PM +0100, loki wrote: > > Kernel is 2.6.35.3. > For the future, you _might_ want to think about using a long-term-supported stable kernel (at the moment, 3.10), or even updating your kernel once or twice a year. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Basic Kernel Configuration
On Sun, Feb 16, 2014 at 01:04:12AM +0100, Armin K. wrote: > Hello there, > > I have been spending my time on LFS IRC for a long time now and have > noticed that most users who come for help there get stuck at configuring > their kernel. > > Thus, I have written a rather basic guide on how to configure the kernel > to get your machine to boot for the first time (disk controllers and > filesystem drivers), but not other hardware specific stuff. > > You can see it here: > > http://www.linuxfromscratch.org/~krejzi/basic-kernel.txt > > Any suggestions or additions are welcome. > > Cheers. > Just a couple of suggestions: 1. SATA etc "So I select the first two modules below." s/modules/drivers/ - people coming from a distro might be used to building everything as a module and take it too literally. 2. filesystems - I would be inclined to drop specific mention of reiser3, and cover it by "Additionally, any other filesystem not listed here.", but perhaps some distro(s) used to use it in the last couple of years. I guess that defconfig covers almost everything else that is commonly needed to get a bootable .config. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.55 man-DB 2.6.6
On Sat, Feb 15, 2014 at 08:36:45PM +0100, Frans de Boer wrote: > I did a rebuild with glibc-2.18 and there is no difference. All other > variables like flex-2.5.37 and using man-db-2.6.5 did not help. So I > just put some set +eset -e around the make check and continue with > the next package. We'll see where it goes wrong. > > Frans. > It seems to work fine, at least in an LFS/BLFS context. Bruce has now experienced this failure too. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.55 man-DB 2.6.6
On Thu, Feb 13, 2014 at 06:08:46PM +0100, Frans de Boer wrote: > On 02/13/2014 05:29 PM, Armin K. wrote: > > On 02/13/2014 04:42 PM, Frans de Boer wrote: > >> During testing I get "col: Invalid or incomplete multibyte or wide > >> character" as output for the man-6 test. I found references which date > >> back to 2009 with the same errors, but no solution is found. > >> > >> So, I doubt I'll be the first to notice this. > >> Any suggestions? > >> > >> Regards, Frans. > >> > > > > Ken also reported it few days back on lfs-dev, but it seems that there's > > no solution for that one, too. > > > > http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg19395.html > > > Yes, exactly the same error. I also checked my glibc logs as well as the > actual contents of the 'locale-archive'file. Could not find any error. > > Maybe the answer is in the past, since this was noticed in 2009 too. I > will look furtherer into it, because it will have impact as reported in > 2009. > By the way, I tried this with 2.6.4 and 2.6.5 with the same result. I do > not remember this when building with glibc-2.18. I will check that too. > My build was with glibc-2.18 - I don't expect problems from 2.19, but if they do happen it would be nice to correctly attribute the problem - I've seen too many fixes in distros over the years where they blamed the wrong part of hte toolchain. And all the other testsuites were reasonably ok. > Frans. > > PS: I am glad I finally have made an automated build, same me sooo much > time and energy. Great. I just wish I could quickly spot all the changes in LFS and BLFS between my own builds, without looking line-by-line at the diffs. Fortunately, Armin is good at identifying what I've done wrong when I report problems in BLFS ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Lfs building problems
On Mon, Feb 10, 2014 at 01:32:27PM -0800, Jerry Trymander wrote: > The problem is that in my case, for instance, the mpfr dir already exists. So > my question is: is the mpfr left as a result of the build process failure at > some previous step? > If not, am I suppose to delete the mptr dir or should it be left as it is? > The same problem occurs with a number of xxx-build dirs. > Otherwise, despite the fact that, so far, I cannot build the LFS, the book is > excellent. Always delete the directories (souce as well as any build dir) before you build a package in a later stage. Deleting them after completing the package's install is best, providing you remembered to do everything in the install. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Wed, Jan 29, 2014 at 05:39:39AM +, Ken Moffat wrote: > On Wed, Jan 29, 2014 at 03:10:42AM +0000, Ken Moffat wrote: > > On Wed, Jan 29, 2014 at 04:53:21AM +0200, Markku Pesonen wrote: > > > > > > The binutils testsuite creates detailed logs in binutils/binutils.log, > > > ld/ld.log, and gas/testsuite/gas.log in the binutils-build directory. > > > I have found them to be very useful in figuring out unexpected test > > > failures. > > > > > Thanks! I've just blown the first attempt away, but I'll have a > > look at these in the second attempt. > > > Verily, it was written: > cannot find -ldl > > So, the ld testsuite needs /usr/lib/libdl.a for the -static tests. > > But now I wish I'd gone to bed hours ago : I'm still getting the > same 5 failures- > ld-elf.exp Forget that. I'd been up all night in the hope of getting these tests to all pass, and I guess I must have got too tired. Apologies to the binutils devs for suggesting that the summary and ld.log differed, I was wrong. I _thought_ I had rerun my script, i.e. remove the directories, untar, patch (to see which linker was used), make, make check, halt and with my own log from make check logged as LFS-7.4.-3 (third build on this machine). I certainly checked that the date/time (to the minute) of my check log and ld.log agreed, but I now guess that I must have rerun 'make check' by hand and I'm surprised that I managed to read the initial ld.log after the check log had been created, find libdl.a.hidden, rename it, and rerun make check (or perhaps just make check in ld) before the minute changed. I could have sworn that I got the "not remade because of errors" message. Maybe I reran make check, glanced at the screen with sleepy eyes, and read the earlier 'not remade' message. Whatever, now that I've woken the box from suspend (don't ask about yesterday :) I _did_ rerun my script and all the tests passed, with a status of 0. Spelled out in detail not because it is interesting, or counts as an adequate excuse, but because I believe that technical / support issues are like an exam - "show working". Sorry for the noise. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Wed, Jan 29, 2014 at 03:10:42AM +, Ken Moffat wrote:
> On Wed, Jan 29, 2014 at 04:53:21AM +0200, Markku Pesonen wrote:
> >
> > The binutils testsuite creates detailed logs in binutils/binutils.log,
> > ld/ld.log, and gas/testsuite/gas.log in the binutils-build directory.
> > I have found them to be very useful in figuring out unexpected test
> > failures.
> >
> Thanks! I've just blown the first attempt away, but I'll have a
> look at these in the second attempt.
>
Verily, it was written:
cannot find -ldl
So, the ld testsuite needs /usr/lib/libdl.a for the -static tests.
But now I wish I'd gone to bed hours ago : I'm still getting the
same 5 failures-
ld-elf.exp
static preinit array
static init array
static fini array
static init array mixed : all still fail
ifunc.exp - could not link a static executable : still fails
For the first four, ld.log tells me PASS !! :
Executing on host: sh -c {/building/binutils-build/ld/ld-new -m
elf_x86_64 -o tmpdir/preinit -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o
-L/building/binutils-2.23.2/ld/testsuite/ld-elf -static
tmpdir/preinit.o -lz -ldl -L/usr/lib/../lib64 --start-group
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc.a
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc_eh.a -lc
--end-group /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o
/usr/lib/../lib64/crtn.o 2>&1} /dev/null ld.tmp (timeout = 300)
spawn [open ...]^M
Running: tmpdir/preinit > tmpdir/preinit.out
diff tmpdir/preinit.out
/building/binutils-2.23.2/ld/testsuite/ld-elf/preinit.out
PASS: static preinit array
Executing on host: sh -c {/building/binutils-build/ld/ld-new -m
elf_x86_64 -o tmpdir/init -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o
-L/building/binutils-2.23.2/ld/testsuite/ld-elf -static
tmpdir/init.o -lz -ldl -L/usr/lib/../lib64 --start-group
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc.a
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc_eh.a -lc
--end-group /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o
/usr/lib/../lib64/crtn.o 2>&1} /dev/null ld.tmp (timeout = 300)
spawn [open ...]^M
Running: tmpdir/init > tmpdir/init.out
diff tmpdir/init.out
/building/binutils-2.23.2/ld/testsuite/ld-elf/init.out
PASS: static init array
Executing on host: sh -c {/building/binutils-build/ld/ld-new -m
elf_x86_64 -o tmpdir/fini -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o
-L/building/binutils-2.23.2/ld/testsuite/ld-elf -static
tmpdir/fini.o -lz -ldl -L/usr/lib/../lib64 --start-group
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc.a
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc_eh.a -lc
--end-group /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o
/usr/lib/../lib64/crtn.o 2>&1} /dev/null ld.tmp (timeout = 300)
spawn [open ...]^M
Running: tmpdir/fini > tmpdir/fini.out
diff tmpdir/fini.out
/building/binutils-2.23.2/ld/testsuite/ld-elf/fini.out
PASS: static fini array
Executing on host: sh -c {/building/binutils-build/ld/ld-new -m
elf_x86_64 -o tmpdir/init-mixed -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o
-L/building/binutils-2.23.2/ld/testsuite/ld-elf -static
tmpdir/init-mixed.o -lz -ldl -L/usr/lib/../lib64 --start-group
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc.a
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc_eh.a -lc
--end-group /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o
/usr/lib/../lib64/crtn.o 2>&1} /dev/null ld.tmp (timeout = 300)
spawn [open ...]^M
Running: tmpdir/init-mixed > tmpdir/init-mixed.out
diff tmpdir/init-mixed.out
/building/binutils-2.23.2/ld/testsuite/ld-elf/init-mixed.out
PASS: static init array mixed
for ifunc.exp I'm not exactly sure what I'm looking for, but all
the tests seem to pass.
I'm _sorely_ tempted to give up attempting to run testsuites on
lfs (yes, I still remember the erratic problems people had in LFS-4
which led to "pure lfs" in which toolchain testsuites were run, but
I'm getting hacked off by this heap of foetid dingos' kidneys).
The logs (binutils-2.23.2.log.check and ld.log) are now at
http://higgs.linuxfromscratch.org/~ken/binutils-failures/
and changed to m644 so that people can read them.
Undoubtedly the fault is still in what _I'm_ doing, but I'm
distinctly unimpressed by tests which report that they fail, but
show as pass in the detailed log.
Now, if you will excuse me, I'll go and shout some language which
would get me banned from the lists if I posted it.
ĸen
--
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Wed, Jan 29, 2014 at 04:53:21AM +0200, Markku Pesonen wrote: > Ken Moffat wrote: > > I think I'll make a fresh attempt, maybe tomorrow, but in the mean > > time any suggestions are welcome. Although the build was scripted, > > the ld tests still fail if I run 'make check' by hand in > > binutils-build/ld. > > The binutils testsuite creates detailed logs in binutils/binutils.log, > ld/ld.log, and gas/testsuite/gas.log in the binutils-build directory. > I have found them to be very useful in figuring out unexpected test > failures. > Thanks! I've just blown the first attempt away, but I'll have a look at these in the second attempt. Also, an addition to my previous comment on instrumenting the exp file (if anyone cares) - send "ld is $ld\n"; will be much nicer. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Wed, Jan 29, 2014 at 12:40:15AM +, Ken Moffat wrote: > > I discovered that I had an error in the functions I use while > building, libc.a was being renamed to libc.a - but even with that was being renamed to libc.a.hidden > renamed, and libz.a being made available, for me the tests still > fail. > Just correcting that line for clarification, both libc.a and libz.a are available. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Tue, Jan 28, 2014 at 09:48:38PM +0100, Frans de Boer wrote:
> On 01/28/2014 09:09 PM, Frans de Boer wrote:
> > On 01/28/2014 08:37 PM, Ken Moffat wrote:
> >> On Tue, Jan 28, 2014 at 07:27:58PM +0200, Markku Pesonen wrote:
> >>>
> >>> I got those errors when I had removed the static version of libz
> >>> (/usr/lib/libz.a). Static version of glibc is also needed.
> >>>
> >>Thanks for that pointer.
> >>
> >> ĸen
> >>
> > Hm, there should be a libz.a somewhere, but none is build. I will look
> > into the matter and will report back my findings.
>
> Sorry, I had a leftover from a previous experiment where I removed the
> static files after install. So, the absence of libz.a is hereby
> explained. I will check other scripts for the BSS phase on that fact too.
>
> That does not explain the static allocation errors by it self, but will
> start fresh again with a BSS build and monitor what is happening.
>
> Regards, Frans.
>
I hope your attempt goes better than mine!
I discovered that I had an error in the functions I use while
building, libc.a was being renamed to libc.a - but even with that
renamed, and libz.a being made available, for me the tests still
fail.
Looking at the last test:
binutils-2.23.2/ld/testsuite/ld-ifunc/ifunc.exp
The tests seem to be run from the check-DEJAGNU target
and that uses LIBS=$(LIBS) which is -lz -ldl so that explains the
need for libz.a : the static tests pass -static to the linker.
This particular test is
if ![default_ld_link $ld "tmpdir/static_prog" "-static -Ltmpdir
tmpdir/static_prog.o -lifunc"] {
fail "Could not link a static executable"
set fails [expr $fails + 1]
}
and for me, now, the problem seems to be $ld.
If I try to run the command in binutils/build/ld using _any_ ld
(either the existing version in /tools/bin. or the newly built
ld-new which is what actually gets used) it fails like this:
ld -o tmpdir/static_prog -static -Ltmpdir tmpdir/static_prog.o -lifunc
ld: warning: cannot find entry symbol _start; defaulting to
00400140
tmpdir/static_prog.o: In function `main':
prog.c:(.text.startup+0x28): undefined reference to `printf'
prog.c:(.text.startup+0x41): undefined reference to `puts'
prog.c:(.text.startup+0x4d): undefined reference to `puts'
prog.c:(.text.startup+0x62): undefined reference to `puts'
prog.c:(.text.startup+0x71): undefined reference to `puts'
I tried adding other libs, but only managed to progress to blowing
up against undefined unwind symbols and __gcc_personality_v0 which
may be a g++ thing. Adding libstdc++ and libsupc++ didn't help.
There was a suggestion elsewhere to link in libgcc_s to fix a
__gcc_personality_v0 problem, but that is a _shared_ lib and the
test forces -static.
BUT if I run it using gcc :
gcc -o tmpdir/static_prog -static -Ltmpdir tmpdir/static_prog.o -lifunc
it succeeds and I can then do
./tmpdir/static_prog
ifunc working correctly
I found that binutils-build/ld/ld-new was being used by instrumenting
binutils-2.23.2/ld/testsuite/lib/ld-lib.exp
by adding a line
send "ld is $ld"
in the default_ld_link proc. Oh well, I've learned how to print a
variable in an expect script :-(
And it seems to me that when I run the testsuite it will only work
if $ld is expanded to gcc. And yet it appears to work for some other
people.
I think I'll make a fresh attempt, maybe tomorrow, but in the mean
time any suggestions are welcome. Although the build was scripted,
the ld tests still fail if I run 'make check' by hand in
binutils-build/ld. For those who want to know about my environment:
root in chroot /building/binutils-build/ld# printenv
TERM=xterm-color
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin
JOBS=4
PWD=/building/binutils-build/ld
REALDEV=
PS1=\u in chroot \w\$
SHLVL=1
HOME=/root
_=/tools/bin/printenv
OLDPWD=/building/binutils-build
root in chroot /building/binutils-build/ld#
Oh, and type-pa ld shows /tools/bin/ld
(yes, still building in /mnt/lfs/building - /sources is still an nfs
mount from another machine :)
$REALDEV could be /dev/sdX, it gets used in real builds to help me
work out values for fstab and for the rootfs backups, but I've bound
/scratch/lfs to /mnt/lfs for this debugging build.
$JOBS gets passed to make -j during (most) compiles (but never to
installs).
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Tue, Jan 28, 2014 at 07:27:58PM +0200, Markku Pesonen wrote: > Frans de Boer wrote: > > FAIL: static preinit array > > FAIL: static init array > > FAIL: static fini array > > FAIL: static init array mixed > > FAIL: Could not link a static executable > > > > There are five failures and I can't find the cause of it. > > I rebuilded everything from scratch - more then once, but still > > encounter these messages. I tried this on i686 and x86_64 machines. > > > > Anybody an idea what might be the cause and if it is a show stopper. > > I got those errors when I had removed the static version of libz > (/usr/lib/libz.a). Static version of glibc is also needed. > Thanks for that pointer. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Tue, Jan 28, 2014 at 05:30:16PM +0100, Frans de Boer wrote: > The next messages are produced every single time I encounter this chapter: > > Running /sources/binutils-2.24/ld/testsuite/ld-elf/binutils.exp ... > Running /sources/binutils-2.24/ld/testsuite/ld-elf/comm-data.exp ... > Running /sources/binutils-2.24/ld/testsuite/ld-elf/compress.exp ... > Running /sources/binutils-2.24/ld/testsuite/ld-elf/dwarf.exp ... > Running /sources/binutils-2.24/ld/testsuite/ld-elf/eh-group.exp ... > Running /sources/binutils-2.24/ld/testsuite/ld-elf/elf.exp ... > FAIL: static preinit array > FAIL: static init array > FAIL: static fini array > FAIL: static init array mixed > Running /sources/binutils-2.24/ld/testsuite/ld-elf/exclude.exp ... [...] > Running /sources/binutils-2.24/ld/testsuite/ld-ifunc/ifunc.exp ... > FAIL: Could not link a static executable [...] > - > > There are five failures and I can't find the cause of it. > I rebuilded everything from scratch - more then once, but still > encounter these messages. I tried this on i686 and x86_64 machines. > > Anybody an idea what might be the cause and if it is a show stopper. > > Regards, Frans. I see that all the time, at least on x86_64 (I don't remember if I saw it when I built and tested i686 in August). So, definitely NOT a show stopper. In my own builds, I do everything I can to avoid static libraries. I have a _few_ from the toolchain, particularly libc.a, but not all of them, and not static libs from other packages. Pedantically, I do still have the libs, but I rename them to libwhatever.a.static so that I can make them available if I need to. The last time I looked at my own failures in static linking during these tests, I failed to diagnose the problem : I have a variable to preserve all static libs if I'm doing a "build like the book" run, and I thought that would solve the problem, but it didn't. By the time I looked at the results, I was way past binutils and didn't have the build and source directories any more. I was not sufficiently interested to prioritise debugging what I assumed was a problem with my own scripts. If you have not advanced beyond the tests, and still have all the build directory, I guess you could look at the test results and see if anything jumps out. If not, I suppose I can do a fresh build sometime in the next week or two. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Wed, Jan 22, 2014 at 10:11:29PM +, akhiezer wrote: > > > (( p.s. Although - and excuse the/any noise - OTTOMH am not sure why sudo > need be part of the picture if the 'su - lfs' is done in '4.3. Adding the > LFS User'. Also noticed earlier that the 'problematic' ranlib in your > /tools/bin was owned by root:root ; which didn't seem right for that stage > of build. BUT, am still not at a suitable environment for checking those > out: hence again, apols for the/any noise. > )) Well spotted - I had missed that ownership. Owning by root:root is probably, in itself, not a problem. But it appears to indicate that "make install" is being run as root. If that is the case, any errors can trash the host system. I don't, for the moment, understand *how* root came to be involved. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Wed, Jan 22, 2014 at 11:40:44AM +0100, Pierre M.R. wrote: > Enrique Larraia wrote: > > libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a > > ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found > The error message comes from bash. It looks like 'make install' reset > the shell PATH. I would suspect some security magics like selinux. > > Pierre > If so, more likely AppArmor - but ubuntu has shipped with that for several years. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Wed, Jan 22, 2014 at 12:23:26AM +, Ken Moffat wrote:
> On Tue, Jan 21, 2014 at 09:53:03PM +, Enrique Larraia wrote:
>
> Your error was
> > libtool: install: chmod 644 /tools/lib/libsupc++.a
> > libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a
> > ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not
> > found
>
I got sufficiently interested by this to try building LFS-7.4 on my
i686 7.4 system, using copy-and-paste. Fortunately (although
perhaps discouragingly for Enrique) this isn't very far into the
build.
> That appears to be using a libtool script. I don't recall if it is
> within the gcc-build directory, or the gcc-4.8.1 source - or even in
> a subdirectory. But I guess it is in the top level of gcc-build (if
> I'm wrong you'll need to search for it), and perhaps created from a
> file in the gcc source by using sed on variables.
>
OK, so I overlooked that we are now only trying to build and
install in libstdc++. The libtool script is gcc-build/libtool.
> What is the first line of this libtool script ? (I'm guessing it
> will be something like #!/bin/sh or #!/bin/bash ?
Mine starts #! /bin/sh so the /bin/sh symlink to /bin/bash is
indeed important. Let's try rechecking, in case something in
ubuntu-land is making the symlink disappear (unlikely, but when the
obvious fails, never discount things).
I get
lfs:/mnt/lfs/sources/gcc-build$ file /bin/sh
/bin/sh: symbolic link to `bash'
lfs:/mnt/lfs/sources/gcc-build$ /bin/sh --version
GNU bash, version 4.2.45(1)-release (i686-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
You are almost certainly using a different version of bash, please
can you compare your results for those two commands ?
At this point, I'm expecting that the /bin/sh -> bash symlink is
NOT effective - but that is guesswork, and I don't know why it would
happen.
If your /bin/sh is any version of bash-4.2, please try what I've
written below.
>
> Can you paste the lines around line 1132 where it is invoking this
> command ? I'm not sure if the ranlib (i686-lfs-linux-gnu-ranlib) is
> hard-coded in the libtool script [ i.e. something got processed by
> the shell to create this libtool script ], or if it is using
> variables.
>
In fact, that is a chunk within a function which looks like this:
# func_show_eval cmd [fail_exp]
# Unless opt_silent is true, then output CMD. Then, if opt_dryrun
# is
# not true, evaluate CMD. If the evaluation of CMD fails, and
# FAIL_EXP
# is given, then evaluate it.
func_show_eval ()
{
my_cmd="$1"
my_fail_exp="${2-:}"
${opt_silent-false} || {
func_quote_for_expand "$my_cmd"
eval "func_echo $func_quote_for_expand_result"
}
if ${opt_dry_run-false}; then :; else
eval "$my_cmd"
^ this is line 1132
my_status=$?
if test "$my_status" -eq 0; then :; else
eval "(exit $my_status); $my_fail_exp"
fi
fi
}
So we can see that either the function is being misparsed (perhaps
the local variables give a problem), or else the command is simply
not being found.
In the previous case (x86_64) I think we established that the
ranlib WAS on the PATH, but let's check in your case that things are
correct. Here are my commands and results -
lfs:/mnt/lfs/sources/gcc-build$ echo $PATH
/tools/bin:/bin:/usr/bin
lfs:/mnt/lfs/sources/gcc-build$ type -pa i686-lfs-linux-gnu-ranlib
/tools/bin/i686-lfs-linux-gnu-ranlib
lfs:/mnt/lfs/sources/gcc-build$ ldd $(type -pa
i686-lfs-linux-gnu-ranlib)
linux-gate.so.1 (0xe000)
libz.so.1 => /lib/libz.so.1 (0xb7701000)
libc.so.6 => /lib/libc.so.6 (0xb754c000)
/lib/ld-linux.so.2 (0xb772d000)
And if your results really do match all of mine, I think I need a
very stiff drink ;-)
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Tue, Jan 21, 2014 at 09:53:03PM +, Enrique Larraia wrote: > Hi all, > > I'm experiencing the same issue as Louis Rine in this thread: > > https://www.mail-archive.com/lfs-support@linuxfromscratch.org/msg21373.html > > I'm unsure whether or not reply to the cited thread, or create one on my > own. I apologize if this causes a duplication of the same topic :( > I think we are out of ideas on that thread, so either way will suit :-( > I got the following otuput error after make install of package > libstdc++-4.8.1: > > make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/include' > Making install in libsupc++ > make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' > make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' > test -z "/tools/lib" || /bin/mkdir -p "/tools/lib" > /bin/sh ../libtool --mode=install /usr/bin/install -c libsupc++.la > '/tools/lib' > libtool: install: /usr/bin/install -c .libs/libsupc++.lai > /tools/lib/libsupc++.la > libtool: install: /usr/bin/install -c .libs/libsupc++.a > /tools/lib/libsupc++.a > libtool: install: chmod 644 /tools/lib/libsupc++.a > libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a > ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found From memory, Louis was using x86_64 so the problem appears to be related to ubuntu-derived hosts, but on both architectures. What do 'ldd' and 'ls -l' report for /tools/bin/i686-lfs-linux-gnu-ranlib ? I'm expecting sensible results (all libraries present, and file is executable), but something unexpected is happening somewhere. > make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127 > make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' > make[1]: *** [install-am] Error 2 > make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' > make: *** [install-recursive] Error 1 > > > I've checked and i686-lfs-linux-gnu-gcc-ranlib IS under /tools/bin. I'm > building with host Ubuntu 12.04, I've checked the host requirements and are > all OK (i think), in particular: > - /bin/sh points to bash not dash > - /usr/bin/yacc -> /etc/alternatives/yacc -> /usr/bin/bison.yacc > with bison.yacc being the following simple script: >#! /bin/sh > exec '/usr/bin/bison' -y "$@" > > .bashrc file of lfs user has $LFS variable well defined, /tools directory > is a symlink to $LFS/tools and $PATH has first /tools/bin. > I think we were hoping that if Louis started again with /bin/sh pointing to /bin/bash, it would fix it. That seemed a plausible hope, because the initial configure in the top level directory will use its shell and it converts variables which may then be used by configure scripts in other directories. Dash is known to be less powerful than bash and has often broken with constructs which work fine in bash. Oh well, something else must be involved. > In case you find it useful, I'm including the errors in the config.log > after configure Libstdc++-4.8.1, located in $LFS/sources/gcc-build. Not > sure what they mean or if they are related to the issue (yes, I untar'ed > gcc package again to build libstdc++): > Just to confirm : you removed the original gcc-4.8.1 and gcc-build directories before doing that ? > lfs@tornasol:/mnt/lfs/sources/gcc-build$ cat config.log | grep -i error > i686-lfs-linux-gnu-gcc: error: unrecognized command line option '-V' > i686-lfs-linux-gnu-gcc: fatal error: no input files > i686-lfs-linux-gnu-gcc: error: unrecognized command line option '-qversion' > i686-lfs-linux-gnu-gcc: fatal error: no input files > i686-lfs-linux-gnu-g++: error: unrecognized command line option '-V' > i686-lfs-linux-gnu-g++: fatal error: no input files > i686-lfs-linux-gnu-g++: error: unrecognized command line option '-qversion' > i686-lfs-linux-gnu-g++: fatal error: no input files > conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory > conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory > collect2: error: ld returned 1 exit status > | /* Override any GCC internal prototype to avoid an error. > collect2: error: ld returned 1 exit status All these sorts of messages seem absolutely normal. Configure scripts are run by /bin/sh and most of them mainly do two things: (i.) generate program fragments and try to compile them - this determines if headers / libraries exist, or if certain things exist in certain functions: that is what you see above, and is all part of adapting the build to different systems (not just linux) or different architectures (ii.) they use pkg-config to find if a package exists, and how to compile against it. And then, at the end of configure, they use the settings to alter how Makefiles will be created. > glibcxx_cv_system_error14=yes > glibcxx_cv_system_error15=yes These sort of variables might be used in the creation of the various Makefiles > ERROR_CONSTANTS_SRCDIR='config/os/generic' > WERROR='' > #define HAVE_STRERROR_L 1 > #define HAVE_STRERROR_
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Sat, Jan 18, 2014 at 01:28:58PM +, akhiezer wrote: > > Date: Fri, 17 Jan 2014 22:17:42 -0600 > > From: Louis Rine > > To: LFS Support List > > Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 > > > . > . > > > > Anyway, as for those sanity checks: > > > > $ ls -laF /tools/bin/x86_64-lfs-linux-gnu-ranlib > > -rwxr-xr-x 2 root root 5204187 Jan 17 18:29 > > /tools/bin/x86_64-lfs-linux-gnu-ranlib* > > > > > OK. Size looks very large, even re cross- stuff; not near a machine to check > just now. > Just a side-note that this size isn't totally out of order, I got 4.6M on x86_64-lfs-linux-gnu- on a gcc-4.8.1 host with CFLAGS unset and the file not stripped. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Thu, Jan 16, 2014 at 05:47:42PM -0600, Louis Rine wrote: > If this is the correct use of ldd... > > :~$ ldd /tools/bin/x86_64-lfs-linux-gnu-ranlib > linux-vdso.so.1 => (0x7fffa837b000) > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ff874f03000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ff874b3a000) > /lib64/ld-linux-x86-64.so.2 (0x7ff87511a000) > > Not sure how to tell if that output is correct... > Looks ok : "no such file" can mean broken linkage, but not in this case. > I'm using netrunner 13.06 which is based on ubuntu 12 I think? > > host system requirements check scripts gives the following > > :~$ ~/code/lfs/version-check.sh > bash, version 4.2.45(1)-release > /bin/sh -> /bin/dash Fix that - dash causes problems in all sorts of places. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Thu, Jan 16, 2014 at 04:23:51PM -0600, Louis Rine wrote: > Hello all. :) > > I'v gone through the book a couple times in the past on i686, but this is > my first time around with x86_64. All seemed to go well until I ran into > this little gem while installing libstdc++: > > <...lots of compilation output...> > Making install in libsupc++ > make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' > make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' > test -z "/tools/lib/../lib64" || /bin/mkdir -p "/tools/lib/../lib64" > /bin/bash ../libtool --mode=install /usr/bin/install -c libsupc++.la > '/tools/lib/../lib64' > libtool: install: /usr/bin/install -c .libs/libsupc++.lai > /tools/lib/../lib64/libsupc++.la > libtool: install: /usr/bin/install -c .libs/libsupc++.a > /tools/lib/../lib64/libsupc++.a > libtool: install: chmod 644 /tools/lib/../lib64/libsupc++.a > libtool: install: x86_64-lfs-linux-gnu-ranlib > /tools/lib/../lib64/libsupc++.a > *../libtool: line 1132: x86_64-lfs-linux-gnu-ranlib: command not found* > make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127 > make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' > make[1]: *** [install-am] Error 2 > make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' > make: *** [install-recursive] Error 1 > > I checked in /tools/bin, and indeed x86_64-lfs-linux-gnu-ranlib IS there, > along with the other stuff that should be there. The lfs user environment > seems to be all set up correctly, including $PATH which is > /tools/bin:/bin:/usr/bin. > Perhaps /tools/bin/x86_64-lfs-linux-gnu-ranlib is broken. What does 'ldd' say about it ? What host system are you using, and did you check all the "host system requirements" ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Proposed Changes to LFS Book
On Wed, Jan 15, 2014 at 04:51:23PM +, Ken Moffat wrote: > On Tue, Jan 14, 2014 at 03:50:47PM -0500, alex lupu wrote: > > I would like to submit for your consideration the following changes > > to the Section "III. 6.7. Linux-3.12.6 API Headers" of the > > "Linux From Scratch - Version SVN-20140102" book. > > > > 1. After the paragraph > > > > " ..: This is done by > > way of sanitizing various C header files that are shipped in the Linux > > kernel source tarball.", > > > > I would insert: > > > > Note: > > For the meaning of the action "sanitizing" (in this context), run command > >sh scripts/headers_install.sh | sed s/echo// > > and in the output read the section between "Prepares " and " keywords." > > (output, lines 3-6). > > > > I don't find that helpful. At all. > Please note that I'm not intending to shut you off here - _I_ know what is meant by sanitizing the headers (or, I think I do), but the book doesn't go into any detail. Maybe we ought to change the chapter 5 reference to 'sanitizing' (5.6) - that is where we first mention it. At the moment we say "This is done by way of sanitizing various C header files that are shipped in the Linux kernel source tarball." perhaps change to "... source tarball (to make them fit for use by userspace applications)". But I've been doing this stuff for years, back to the days of linux-libc-headers and clfs's own attempt. Not sure if my wording would add anything useful for new readers, or if it would just sow confusion. And anyway, I'm too busy to do any development at the moment. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Proposed Changes to LFS Book
On Tue, Jan 14, 2014 at 03:50:47PM -0500, alex lupu wrote: > Dear Development LFS Book Administrators: > For development, you ought to post to lfs-dev, but you'll need to subscribe before you do that. The devs (primarily Bruce and Matt) might read this here, I'm not sure. > I would like to submit for your consideration the following changes > to the Section "III. 6.7. Linux-3.12.6 API Headers" of the > "Linux From Scratch - Version SVN-20140102" book. > > 1. After the paragraph > > " ..: This is done by > way of sanitizing various C header files that are shipped in the Linux > kernel source tarball.", > > I would insert: > > Note: > For the meaning of the action "sanitizing" (in this context), run command >sh scripts/headers_install.sh | sed s/echo// > and in the output read the section between "Prepares " and " keywords." > (output, lines 3-6). > I don't find that helpful. At all. > 2. After section > > "They are placed in an intermediate local ", > > I would insert: > > "subdirectory (named by us, 'dest', in the command below)" > If the user does not understand that we are creating a directory called 'dest' then LFS is probably too hard for them. In everything, a balance is needed between explaining and teaching your grandmother to suck eggs. > 3. After > > "copied to the needed location", > > I would change to > > "copied to the intended user-space standard location, '/usr/include/...' " > Again, that should be obvious from the command. > 4. I would change the command > > cp -rv dest/include/* /usr/include > to > cp -prv dest/include/* /usr/include > > That would synchronize the file times in the '/usr/inlude/' tree to the > times > of the files created in the kernel directory on running the command > 'make headers_install', and not assign them an arbitrary time when I get > around to > run the copy after taking out the garbage and then getting a well deserved > rest > before being finally able to complete the procedure :) > So, you think that the time(s) when the files were initially created in dest/ are more important than the times when they were finally installed to /usr ? Why ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Section 5.5.1 GCC-4.8.1 'make'
On Sun, Jan 12, 2014 at 04:00:04PM -0500, William Darryl Jackson wrote: > Hello again, > > In the GCC first pass section 5.5.1 page 38 - I received the > following compile error: > > checking for i686-lfs-linux-gnu-gcc... > /mnt/lfs/sources/gcc-build/./gcc/xgcc > -B/mnt/lfs/sources/gcc-build/./gcc/ -B/tools/i686-lfs-linux-gnu/bin/ > -B/tools/i686-lfs-linux-gnu/lib/ -isystem > /tools/i686-lfs-linux-gnu/include -isystem > /tools/i686-lfs-linux-gnu/sys-include > checking for suffix of object files... configure: error: in > `/mnt/lfs/sources/gcc-build/i686-lfs-linux-gnu/libgcc': > configure: error: cannot compute suffix of object files: cannot compile > See `config.log' for more details. ^^ Open config.log in 'less' or 'view', search for the error message - /cannot\ compute\ suffix\ of Then look at the lines above that - there will be some sort of compile or link error message. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5.7 glibc-2.1{7,8}
On Sat, Jan 11, 2014 at 10:29:41PM +0100, Frans de Boer wrote: > > > Your right of course, that is the only exception. I always use a build > directory within the source tree. I has always worked before...until I > tried now using a build directory outside the source tree! Behold, it is > now working. Never had this experience before, but will follow the > direction to have a build directory OUTSIDE the source tree!! > > Just curious, since it had always worked before, why is it required to > have a build dir outside the source tree? Is there a dependency of some > sort? > > Regards, Frans. The book has "always" [1] used separate build directories for binutils, gcc, glibc. I imagine that you "got lucky" when a build directory in the source tree worked. Perhaps, in the days when LFS was only i?86, we were unnecessarily cautious in following what upstream recommended. But doing it that way has always worked. 1. Since at least late 2005, when gcc-4 came out. I think we did that even when I first got here (for LFS-3) but I don't now have my scripts before late 2005, and I can't connect to the lfs-museum at the moment. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] folder permissions
On Sat, Jan 11, 2014 at 03:14:38PM -0500, William Darryl Jackson wrote: > On 01/11/2014 02:51 PM, Chris Staub wrote: > > On 01/11/14 14:47, William Darryl Jackson wrote: > >> On 01/11/2014 02:33 PM, Chris Staub wrote: > > >>> Your output says there is something mounted on /media/lfs, yet you keep > >>> saying you are assigning LFS=/mnt/lfs. > >> I was trying to follow the instructions precisely. I agree this seems to > >> be the cause of the problem. This is an external drive that auto mounts > >> to the (user) media folder, and (root) dev folder. The only reason it > >> says media/lfs is because I added a label in gparted. Debian is using > >> uuid identifiers - which is causing me problems. Would it help if I > >> replaced LFS=/mnt/lfs with something else? Also, I have 2 partitions on > >> that external drive. They both mount showing 500GB, when the drive is > >> only 500GB. > >> > >> Thanks. > >> Using automounting for where you intend to build LFS is probably a bad idea. Actually, in my personal view automounting is always a bad idea : I don't expect the system to try to second-guess what I want to do ;) You need to be root at certain places in the LFS build, so you might as well be root to mount /mnt/lfs. Just remember to become user LFS when the book does. We used to have certain things which _required_ /mnt/lfs, now I believe you can mount the build anywhere and have a reasonable chance of success if you make the consequential changes. But if it breaks, you get to keep both pieces. So, /mnt/lfs is what we recommend. > > Sorry, but if you really need to ask this, LFS is just too advanced for > > you. I suggest going here - > > http://www.linuxfromscratch.org/lfs/view/7.4/prologue/prerequisites.html > > - for starters, and learning about how to actually use Linux, especially > > on the command line, before attempting something like LFS. > That was a bit harsh. I have been using command line for 3 years. That > is long enough for me to attempt to learn more about Linux, which is > what I thought LFS is all about. I have learned enough now to not bother > the list with silly questions. > I _will_ reiterate that you seem to have a fundamental problem with how you are mounting the external drive : each partition should be smaller than the total size of the drive, and when both are mounted you ought to be able to see different partition numbers, and sizes, in the output from 'mount' and 'df'. Debugging this problem for yourself will help you when it comes to other problems with your new LFS system. LFS *is* about learning linux - but mostly in the sense of how the various packages fit together to produce a usable minimalist system. By paying attention to the details of how each package is built, you will perhaps learn a little about how to use sed and patch. But other common tools will only get brief mentions. I think awk probably gets used in checking the host requirements. Some people have apparently built LFS "to learn linux"- for me, that would have been unnecessarily difficult. Read the links Chris pointed to, read the book _before_ you try to follow it (to get an overview of what is to be done), and then if you think you are ready, please check the host requirements. I will also add that I recommend that people build and install a kernel before trying LFS (in situations where that is possible) - i.e. use an upstream kernel, come up with a .config which boots *without* an initrd [ build in the root filesystem and whatever you need for your disk drives ], test, strip things out and/or add other things until the kernel both boots and does everything you need it to do. For this, edit /boot/grub.cfg as root [ review what the book says for kernel configs ] AND add your own identifier in the EXTRAVERSION so that a later rebuild to get a better config will not overwrite the modules from the current attempt. Of course, some people leave the fun of finding a useful kernel config until they have completed LFS. Personally, I find it a lot easier to debug any problems on my own builds (yes, I still get boot problems) - mostly from upgrades to the BLFS packages which I build before I boot, e.g. for nfs, but I can still remember that I had issues when I updated my (very) old server system to LFS-6.8 because of config changes I had forgotten about over the years - if the kernel .config is "known good" : people get all sorts of one-off problems when building LFS for the first time, e.g. by botching one of the packages [ /me scowls at ncurses and libz ]. And if you do get more problems when you are building LFS, please mention where you are in the book when you ask for advice. Have fun, building and booting LFS isn't about ticking boxes on a ToDo list. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Static versus Shared libraries
On Mon, Dec 30, 2013 at 11:29:34PM +0100, Frans de Boer wrote: > Dear reader, > > While building things again, I now start to wonder why LFS let almost > every package installs a static library? Where are the static libraries > used? > They can sometimes be used if you mis-install one of the packages :-) More so on 32-bit x86 - x86_64 is more likely to fail to link static libs into shared executables because it requires -fPIC. Obviously, using something to suppress the static libs in your own package management will highlight any places where this happens! I append ".hidden" to all non-toolchain /usr/lib/lib*.a files at the end of my package installs. More likely, _some_ of the toolchain libs _might_ be required to run configure scripts. I've never found enough time to test this. I did hide a few "unlikely to be needed" static toolchain libs, but others such as libc.a seem likely to be generally used, at least in configure scripts. Or, as Bruce's reply probably pointed to (I didn't read his link) - for development. > After all, the down side of static libraries is that once linked into a > module/program, any upgrade is not incorporated. Potentially leaving > modules/programs vulnerable to manipulation. > In general, please be aware that "--disable-static" does not always work. More importantly, some libs are not in fixed versions, so the static version is theoretically required (e.g. PAM needs a static lib from flex - I got a dirty workaround from our late colleague Andy to convert any .a to .so, but that might not be a good idea when things can change because they have not been versioned). Also, in BLFS tcl and tk require their static stub libs, and firefox / xulrunner require libcrmf.a which in my systems comes from standalone nss. I now remember there is at least one static lib in kde. And probably others in packages I don't care about. > It is listed that only a very few use some static libraries and others > are not mentioned. I know, disk space is not an issue nowadays, but > still it needs to be maintained and dependencies are not listed anyhow. > > Can someone shed some light on this issue? > > Regards, Frans. > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/lfs/faq.html > Unsubscribe: See the above information page I think many LFS/BLFS builders don't care about these sort of problems. It was a tedious buisness to disable static libs in BLFS. Fortunately, those of us who care can fix the parts we care about on our own systems (so yes, I could test if my remaining static toolchain libs are really needed, but it hasn't yet proved important enough to me : if I need to rebuild the toolchain, I upgrade LFS). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.4 Patching Perl
On Wed, Dec 25, 2013 at 10:44:38AM -0500, Bob Elgie wrote: > My apologies if I'm blindly overlooking something obvious. > > Among the patches needed to build 7.4 is a Perl libc patch. I can't see > where this patch is applied; it is not mentioned in chapter 6.39. > > The only place I find instructions to apply it is in the French version of > the svn build. > > Should the patch be applied at all, and if so, where would that happen if > not in 6.39? > > Thanks. > > Bob Elgie You are looking at the wrong chapter! We use it in chapter 5. Please read the patch, including the description. We use it so that perl will work when we enter chroot using /tools/libc.so and /tools/bin/gcc. It is specific to how we build LFS in chroot, the new system doesn need this workaround. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 7.4 / i686-pc-linux-gnu / drm_kms_helper: panic occurred
On Sun, Dec 15, 2013 at 10:57:00PM -0600, Bruce Dubbs wrote: > Ron Hartikka wrote: > > Hi Group, > > > > I took a picture and used OCR. > > Is it enough to give you an idea of what is wrong? > > I seemed to have no issues through Chapter 8. > > I also installed everything in 9.3 except gptfdisk and parted. > > > > Any guidance appreciated, > > Ron > > > > The error message was somewhere above this. This is part of a call trace, the error comes first, then register dumps. But catching it is hard - possibly PageUp would work, possibly not. > > > > 63.156739] C] ? SyS_nknod+6x28/8x38 > > 63.156736] E] nount_root+8xf3/6xfb > > 63.156736] C] ? SyS.unlink+0x18/9x26 > > 63.1567361 Kcl9c817a>l ? initrd_ 1 oad +8x43/8x47 > > 63.159736] [] prepare_nanespace*6xllf/6xl59 > > 63.159736] [] ? SyS_access +8x29/8x39 > > 63.1597361 [] kernel_init_freeable+0xlb7/0xlc4 > > 63.1597391t] ? do_early_paran+0x78/0x78 > > 63.1567361 Kcl6e?fdb>] kerne1_init+exb/8x148 > > 63.1567361 [1 ret_fron_kernel_thread+0xlb/0x28 > > 63.1567361 [] ? rest_ init+8x68/8x68 > > *63.1567361 drm_kms_helper: panic occurred, switching back to text console* > > 63.266161] -1 cut here 1- > > The most common reason for kernel panics during boot is that one or more > drivers are not built into the kernel. Typically the missing drivers > are ext, pci, or sata. Make sure they are =y and not =m. > I will guess that the problem is somewhere in KMS (kernel modesetting). What graphics card do you have ? Please also attach the video part of your kernel config : the lines from CONFIG_AGP through to CONFIG_SOUND (not the rest of the sound settings - CONFIG_SOUND should be the first line after whatever is your last entry in the video section. There ought to be a command-line option to disable kms (to help with debugging), but I guess its exact form will depend on which hardware this is. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring 3.10.10 for quad-core processor
On Thu, Dec 05, 2013 at 08:01:50PM +1300, Simon Geard wrote: > On Wed, 2013-12-04 at 20:33 -0600, Dan McGhee wrote: > > > Ken, are K10 and A10 the same? > > Nope. K10 refers to a generation of AMD processors from about 3 years > ago (including the Phenom II in my current desktop box). A10 is a > specific model of their current A-series processors. It's possible > they're similar enough that K10 optimisations and stuff will work, but > they might not be too... > > Simon. > In the context of what I wrote earlier (K10 and later for acpi cpufreq, and MK8 working on K10) I *think* it should be fine. The other day my A4 locked up (left it running but idle, waiting for a scheduled backup to run, then came back later to find that there was no video output and it didn't respond to Magic SysRQ). When I rebooted there was nothing in the logs and it hadn't got as far as running the backup. Undebuggable, but that is the nature of many sporadic kernel problems. So, no promises. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring 3.10.10 for quad-core processor
On Wed, Dec 04, 2013 at 02:46:47PM -0600, William Harrington wrote: > > On Dec 4, 2013, at 1:49 PM, Dan McGhee wrote: > > > AMD-10-5745M > > Have you used the powernow-k8 driver and have SMP enabled? > > http://cateee.net/lkddb/web-lkddb/X86_POWERNOW_K8.html > > Sincerely, > > WIlliam Harrington Powernow is for cpufreq (a good thing to use, IMHO, but not mentioned in LFS) and not used anymore for K10 and newer CPUs (the support is now in acpi-cpufreq). From memory, the initial K10 was the athlon64xII. My git-foo isn't good enough to identify which release that happened in, but the indications are that it was well before 3.10. SMP is the key. If Dan is building only for that machine (and doesn't intend to use the system to boot any replacement machine when the time comes) then optimizing for the specific processor family, i.e. AMD x86_64 (Opteron/Athlon/Hammer/K8 : this is CONFIG_MK8 but works on K10 ;-) might gain a little, as might Multi-Core Scheduler support. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.4
On Fri, Nov 29, 2013 at 11:35:19AM -0600, Bruce Dubbs wrote: > Baho Utot wrote: > > Is it possible to build LFS-7.4 on x86_64 without the /lib64 symlink? > > > > I have tried to do so but libstd++ in the chapter 5 tool chain dies. > > > > I would like to build for x86_64 and have the same filesystem layout > > that i686 has ie without the lib64 directories > > I really don't know but I can make some guesses. uname --machine gives > x86_64. I wouldn't be suprised if some packages that assume a multilib > system use that value to insist on /lib64 or /usr/lib64. > >-- Bruce Cross-LFS has always done that for pure64. It's a _long_ while since I last built clfs x86_64-64 and many things have changed, but the main difference is that clfs still uses a specfile - their build is now quite different from how LFS has evolved. If you do something like that, then yes, a few _blfs_ packages will probably get confused by the absence of /lib64. OTOH, you would get a nice clean system - but the build for x86_64 will be somewhat different from what is currently in LFS. I've a feeling that someone, perhaps our late colleague Andy, used to build 64-bit LFS without the symlink - but I've no idea of the details about how to do it (and that was before libstdc++ and g++ became required for building gcc, so the details would have to change for gcc-4.8). This message will self-destruct in 5 seconds. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ethernet Card Not Found
On Mon, Nov 25, 2013 at 07:44:16PM -0500, Alan Feuerbacher wrote: > > Apparently things in the linux world have changed recently with respect > to naming devices generally, so that old conventions like "eth0" have > been replaced by conventions that are said to make more sense. I suppose > "enp3s0" makes sense to some people, but "eth0" makes more sense to a > non-expert like me. > If you don't want to run Lennart-from-scratch, this is what I use to get back to a sane name - # fix the ecpXsY ethernet naming echo "# dummy, so that network is once again on eth0" >/etc/udev/rules.d/80-net-name-slot.rules Strictly, just creating an empty file with that name will solve the problem - but empty files are fragile and their meaning is likely to be forgotten! This fixes the major abomination since udev was merged into systemd - that undesirable change is now also in eudev and Bruce's udev-from-systemd. I leave it to the people drinking Lennart's kool-aid to explain why names such as enp3s0 are saner than eth0! ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ethernet Card Not Found
On Sun, Nov 24, 2013 at 09:33:54AM -0600, Bruce Dubbs wrote: > Alan Feuerbacher wrote: > > On 11/24/2013 12:19 AM, Bruce Dubbs wrote: > >> Alan Feuerbacher wrote: > >>> Can anyone clue me in? > >> > >> It sounds like you don't have the right ethernet driver built. We > >> recommend building it into the kernel. > > > > Ok, then I must have missed something when building the system. What do > > I look for in the LFS book to build the right ethernet driver? > > Bring up a working system and run lsmod. We have no way to tell what > hardware you have, but we do refer to several references on configuring > a kernel in Section 8.3. > I think Alan needs the r8169, this is what I use : CONFIG_NET_VENDOR_REALTEK=y and CONFIG_R8169=m (actually 'y' would be better, i.e. faster to come up) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Error: invalid file name When Booting For the First Time
On Sat, Nov 23, 2013 at 02:32:47PM -0500, Alan Feuerbacher wrote: > > In grub.cfg, why is the "root" in the line "set root=(hd1,1)" different > from the "root" in the line "linux /vmlinuz-3.12-lfs-SVN-20131119 > root=/dev/sdb3 ro"? In other terms I have: > > /dev/sdb1 -> /boot > /dev/sdb3 -> / > > I'm really fuzzy about this stuff. > They are totally different things. Grub purports to be a universal bootloader, and there is no consistent way of naming disk devices across different systems, so it uses its own names. For the linux kernel bootargs, root= expresses which partition to load for '/', using the linux kernel's naming system. > At any rate, I recompiled the kernel and reinstalled the grub stuff. I'm > still getting an error: > > error: file '/vmlinuz-3.12-lfs-SVN-20131119' not found. > > I invoked the grub command line to see what I could see: > > ls => (hd0) ... (hd1) (hd1,msdos2) (hd1,msdos1) (hd2) > > So grub apparently sees my disk /dev/sdb as (hd1). Next I tried: > > ls (hd1) => > Device hd1: No known filesystem detected - Total size 3907029168 sectors > > I also tried this with (hd0) and (hd2). Same response: no filesystem > detected. > > So for whatever reason, grub is not recognizing the disks. Having tried > the same thing with the two other disks, /dev/sda and /dev/sdc, which > grub lists above as (hd0) and (hd2), I'm at a loss. All three of these > disks are in operation, since when I fire up Fedora19 on /dev/sda, I can > write to and read from all of the disks. > > Any ideas? > > Alan How about ls (hd1,1) ? hd0 and hd1 are the whole disk, what you need to look at is a partition. I've also got a much-less-important comment on your kernel names as a reply to your earlier post: You had four variants of 3.12 lfs kernels. All of them had the same size in bytes, one was from nearly two days before the rest, of the others two had the same time and the other was a second later. To me, that looks unusual : Mostly, a fresh build with different options will produce a kernel with a slightly different size. It's not impossible that minor changes might produce same-size binaries, but obviously with different md5sums. But when I see three kernels with essentially the same time I start to worry - I don't think even the fastest machines can produce an updated kernel so quickly. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.3 Screen Flickering problem
On Fri, Nov 22, 2013 at 02:54:34PM -0600, Douglas R. Reno wrote: > Ken, > > The screen turns on and off repeatedly... I can see some text when it is > on. That is how I can tell it booted successfully because I can see the > login prompt for a split second. I also have logs in /var/log. > Good. I've never come across one like that, but from what you say below I guess that more than one framebuffer driver is becoming active and they are fighting. > Looking at the Kernel Options that you suggested (I keep a backup of my > .config on a USB drive), I do believe that I enabled the frame buffer > drivers... I will disable those when I get to the machine tonight. > > And yes, I mean the penguin (it is technically a waste of screen space, but > I think it looks cool) > > Douglas Reno I don't agree it's a waste of space because it only lasts for a little while and then everything scrolls up over it. Perhaps a waste of kernel memory, but amusing - how else would be have seen the Linux for Workgroups penguin in 3.11 ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Radeon Extra Firmware [WAS: Boot Failure with wlan0 firmware]
On Fri, Nov 22, 2013 at 09:38:59AM -0600, Dan McGhee wrote: > I'm asking this question because I really want to re-build my kernel > only once. My LFS kernel is looking for ARUBA_pfp.bin and > TAHITI_uvd.bin. In '/linux-firmware/radeon I have the same three ARUBA > files that you have indicated. So, obviously, I'll put them in > /lib/firmware and indicate them in the "extra_firmware" line. When it > comes to TAHITI though, I have the -uvd.bin, but also _ce.bin, _mc.bin, > _me.bin, _pfp.bin, _rlc.bin and _smc.bin. Do you know if I need all > those TAHITI files, or should I just put them in "to be safe" and not > have to reconfigure my kernel again, and again, and again? I'm very far from an expert on firmware, but on my modern machines with reasonably-stripped-down configs it doesn't take _too_ long to rebuild a kernel. For trying to identify what is needed on a (desktop) radeon, I usually use the gentoo wiki: https://wiki.gentoo.org/wiki/Radeon Just above the 'Driver' section [ gentoo-specific ] is a table with columns for Family, Chipset name, Product name, Firmware - I see that page has been updated since I last needed to look at it: the Sea Islands and Volcanic Islands families are new to me, so I assume that whatever it specifies is current. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.3 Screen Flickering problem
On Fri, Nov 22, 2013 at 09:17:16AM -0600, Douglas R. Reno wrote: > Hello, > > After completing a successful build of LFS, I restart to get into the > system for the first time and my screen turns black and then comes back on > for about 1 second. > > I have a NVidia Vanta LT card in my PC. I am using the Nouveau drivers for > the framebuffer, as I plan to install X. I have Nouveau configured as well > in the kernel. > > I can tell that the system booted successfully, Excuse me for being a pedant, but *how* do you tell that the system booted successfully ? If you have been back to chroot and managed to read logs, then yes, it booted and there might be a message somewhere in the log (search for 'nouveau' or 'framebuffer'). If you haven't got logs, then here is my impression of what is happening: Grub passes control to your new kernel - screen goes black, initial messages appear using probably an 80x25 vga console, then it tries to switch to the framebuffer console and goes black. Are the framebuffer and KMS options built in to the kernel, or as modules ? If you leave it for 60 seconds, does it give you any error message and then procede ? If you leave it for 180+ seconds (I suggest trying something a little longer, e.g. 5 minutes, just to be sure) does it reboot ? The first would probably be related to either failing to load a module, or failing to load firmware and the message ought to provide an indication of what is needed. The reboot after 3+ minutes would indicate it oopsed and tried to kill init. > but I have already tried > various options in kernel configuration (such as Generic VESA). I would > also like to keep my bootlogo, but I am willing to remove it if necessary. > If you mean the penguin(s), it/they come with the framebuffer and KMS requires a framebuffer. For a recent kernel using KMS, you should enable CONFIG_FRAMEBUFFER_CONSOLE and the appropriate DRM entry, but NONE of the Frame buffer hardware_drivers [ CONFIG_FB_CIRRUS...SIMPLE ] should not be set. > The system appears to have issues detecting the card because of the > resolution (it stays at about 640x480). I have booted several LiveCDs > (Ubuntu and System Rescue CD) successfully without this problem. > > Host: System Rescue CD (added bison to image) > NOTE: this system is i686 > Compaq Presario 5230us if that helps. > > Thank you, > > Douglas Reno ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] /dev/fb0 not being created on boot
On Fri, Nov 22, 2013 at 07:05:14PM +, Richard Melville wrote: > Ken, I'm using vesafb on a web server with no Xorg, and I just use the > console. I realise that my kernel was quite old but as I like to check > every configuration option (often because of new hardware) it takes a long > time to configure a new kernel and becomes incredibly boring towards the > end :-( Therefore, I usually limit my upgrades to about one per year, or > when I can be bothered. OK, but in that case I suggest that you go for "early stable" kernels (.1, .2, etc). You said you had been using 3.7-rc8 - that probably turned out to be totally good for your uses, but sometimes even .0 releases still have issues in a few places. Also, the config you use in a late -rc will normally not provide any extra questions for released / stable kernels in the same series if you use 'make oldconfig'. > > Bruce, my framebuffer config was much like yours but with one exception: I > had CONFIG_X86_SYSFB=y. This was stopping vesafb loading and stopping > /dev/fb0 being created. I've removed that option, reconfigured, and now it > all works as expected. Interesting. That option works ok on intel (I'm running with it at the moment), I'll try to remember that for the future - my server also runs with CONFIG_FB_VESA and vga=792 (it's a radeon RS780, when I got it I had no experience with modern ATI hardware and totally failed to get the radeon framebuffer to work - 80x25 is too restrictive for me!) - for the moment I'm running 3.10 (LTS) there. > > Regarding vga=792, that still works for me. If I substitute video=1024x768 > the command is ignored an I get a large, ugly font. I'm currently using > grub-2.0, so I can't understand what the problem is likely to be. Any > ideas? > > Richard Stick with vga=792 since it still works ? Any idea how large the font is, or how many pixels in the screen size when you boot with video=1024x768 ? When the box boots, you get the font from its bios. But when the LFS bootscripts start to run it ought to switch to your specified font (provided the setup supports it, e.g. my own 12x22 is only supported on framebuffers and I've not tried it with Vesa, my screen there is physically 1024x768 so I use an 8x16 font on that). So, basically work out what sort of console font *size* will suit you, then try "setfont" in a spare tty and see if any of the available fonts look ok _and_ provide the character coverage you require. My own LatGrkCyr are intended for white/pale text on a black background and I'm told that at least one of them looks awful with dark text on a pale background : there is a balance between getting adequate coverage, shapes which do not offend our own particular sensibilities, and being able to distinguish the various accents and diacritical markings - for some uses, noting that a glyph is e.g. "letter a with accent" may be good enough, but others may wish to be able to see at a glance what sort of accent is present, particularly in unfamiliar languages. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On Sun, Nov 17, 2013 at 05:10:57PM -0500, Alan Feuerbacher wrote: > On 11/16/2013 6:10 PM, Dan McGhee wrote: > > The kernel. It dies with a message like "... kernel panic ..." > > > Must you do a "hard" reset to start over or can you use > > ALT-CTRL-DEL? > > I have to recycle the power. > With your later comment about today's setback, this suggestion is irrelevant unless/until you can get back to this state. But if you manage to recover to there, please see if any indications of what is wrong get to the screen. If anything useful is there (i.e. not scrolled off), google it just in case someone has found a fix. If not, my first suggestion is to try newer kernels. This sounds very like the sort of thing that was discussed in the various lkml threads about EFI/UEFI I alluded to when replying to Dan in the past month (a change which fixes some machines breaks others). I suggest that you start by trying 3.12.0. No idea if anything there will fix it, but it is current. I normally don't recommend people try early -rc kernels, and 3.13-rc1 wasn't even released when I last checked. If you haven't had any success when 3.13-rc1 is released then certainly try it : but expect unrelated breakage in all sorts of weird and wonderful corner cases. So, if 3.12.0 doesn't work I would then try 3.10.0 in case a later "fix" broke something, and after that perhaps 3.8.0, 3.6.0, 3.4.0 (assuming your glibc "--enable-kernel=" isn't as aggressive as mine and will let your init run old kernels). IFF you can find something old which boots, you then get to work out what broke it. ĸen, glad to be a luddite using the bios and an MBR - at least until you guys have sorted out what needs to be done. -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On Sun, Nov 17, 2013 at 05:02:09PM -0600, Dan McGhee wrote: > > I don't know how, or even > if, the distros have modified GRUB in their packages. > I remember reading something that said fedora's grub is very different from upstream. Try using cgit to see what fedora are doing [ use a graphical browser ]. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found - SOLVED
On Sun, Nov 17, 2013 at 05:35:32PM +, Ken Moffat wrote: > > That commit is in util-linux-2.24, which works for me. I'm not sure > if the problem also applied to 2.23.1 (I don't have any systems > using that), but 2.23 was OK. > > ĸen, currently upgrading all my 7.4-and-newer systems. After further testing, all 6 of my x86_64 systems (4 machines) showed the problem, but my sole i686 (and also my ppc-32) did not. The commit message from Dave Reisner at Arch says "When unmounting some mountpoints as an unprivileged user (via the 'user' option in fstab), the umount fails." I'm now guessing that "some" might mean "x86_64". ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found - SOLVED
On Fri, Oct 25, 2013 at 12:21:02AM +0100, Ken Moffat wrote: > On Thu, Oct 24, 2013 at 05:59:52PM -0500, Bruce Dubbs wrote: > > Ken Moffat wrote: > > > I first noticed this on my desktop which is running LFS-svn with > > > make-4.0, and where I've got more than enough other things still to > > > look at. But on my server running 7.4 I've just done: > > > > > > mount /scratch > > > [ /me does something there ] > > > umount /scratch > > > > > > which returns - > > > umount: /scratch: mountpoint not found > > > > > > and /scratch is still mounted. Any ideas about what is going on, > > > please ? > > > > No, but you can always 'umount /dev/sd??' > > > >-- Bruce > > > Well, root can, so thanks for that (all too often, I'm too close to > the problem and can't see the wood for the trees). - /scratch is > where I use the spare space from modern disks : it doesn't get > backed up [ what a waste of space that would be! ] and either ken or > lfs can use it - or indeed /root when updating the system. > > One day, I suppose I'll find out what else needs to be changed so > that users can umount it again. Ah, the wonders of being on the bleeding edge and looking for guidance before anyone else has had the problem :) Arch also suffered this and one of their devs fixed it: http://marc.info/?l=util-linux-ng&m=137945227914961&w=2 That commit is in util-linux-2.24, which works for me. I'm not sure if the problem also applied to 2.23.1 (I don't have any systems using that), but 2.23 was OK. ĸen, currently upgrading all my 7.4-and-newer systems. -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Shadow
On Sat, Nov 16, 2013 at 07:57:36PM -0500, Alan Feuerbacher wrote: > On 11/16/2013 7:43 PM, Nathanial Jones wrote: > > > I would love it if someone could post a link to a mirror or send me the > > package directly. > > Check your mail. > > Alan > More generally, http://anduin.linuxfromscratch.org/sources/LFS/lfs-packages/ ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On Sat, Nov 16, 2013 at 02:04:31PM -0500, Alan Feuerbacher wrote: > Hi, > > After getting the stock LFS system installed, with an MBR type boot > installation, I'm experimenting with installing to a UEFI type boot > location on a brand new hard drive. I've been reading a lot of online > documentation, and have tried a first-cut installation, but am not > having success in installing. While I can install the entire set of LFS > programs, and a lot of BLFS programs, when I try to boot up, Linux fires > up but quickly generates a fatal error. > > Is there any possibility of advice from the LFS staff? http://www.mail-archive.com/lfs-support@linuxfromscratch.org/ See the posts from Dan McGhee - most recently on 13th November, but starting on 28th October. Four threads, titles mentioning GRUB or EFI. At the moment they are all on the first page at that link, at least in firefox. Our best advice / guesses is in those threads. Dan hasn't cracked it yet, but your hardware might be different. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Fri, Nov 15, 2013 at 01:20:06PM +, Vasco Almeida wrote: > OK, I did as instructed in your recommendations above, and tried to > be as extra careful as ignorance allows. So I am attaching the four > logs collected during the 5.4.1 step, for your kind inspection. But > when I invoked "make install", I got a raft of > > "This is not dpkg install-info anymore, but GNU install-info > See the man page for ginstall-info for command line arguments > This is not dpkg install-info anymore, but GNU install-info > See the man page for ginstall-info for command line arguments > This is not dpkg install-info anymore, but GNU install-info > See the man page for ginstall-info for command line arguments > This is not dpkg install-info anymore, but GNU install-info > See the man page for ginstall-info for command line arguments > This is not dpkg install-info anymore, but GNU install-info > See the man page for ginstall-info for command line arguments" > > which are perhaps not that surprising. They are certainly surprising to _me_, and I don't see them in any of the gzipped logs you attached. Now that we've pointed out the 'Error' that you could not see, please do not attach gzipped logs unless it is essential - a plain text log is readable in many sane mail clients (well, in mutt anyway :) but a .gz has to be extracted before it can be read. Did you type (only, exactly) the commands in the book, and in fresh source and build directories ? Please try again, with fresh source and build directories, and capturing stderr (the 2>&1 stuff) at the places it happens. Those error messages are plain weird for an LFS build. ken (rather than ?en), but ĸen for everyone else - the fonts in console-tools (used by debian distros) are somewhat deficient. -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] [blfs-support] akamai / osuosl / mailing-list archives (pt. 94)
On Thu, Nov 14, 2013 at 11:53:22AM +, akhiezer wrote: > Hi, > > Could a similar thing (to the Akamai note below) be swung for LFS/BLFS? > > And likewise, as noted before, for master-mirroring at e.g. osuosl.org? > > Could be some ways to, inter alia, get the mailing-list archives available > again. > If you follow the website links for lfs-support you will get to http://linuxfromscratch.org/pipermail/lfs-support/ and the links there point to mail-archive.com Not totally convenient, but a lot better than nothing. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] New dovecot page: '--with-...' specs.
On Thu, Nov 14, 2013 at 11:40:42AM +, akhiezer wrote: > > Hi, > > > On the new dovecot page ( > http://www.linuxfromscratch.org/blfs/view/svn/server/dovecot.html), the > section > 'Command Explanations' lists the five options '--with-ldap' et seq: yet none > of > them actually appear in the commands. I've noticed a similar thing in several > places in blfs74 book. > > > Apols if have missed an earlier discussion on that, but: is this an error in > rendering; or is it kindof that those '--with-ldap' &c options are really > meant > as a sort-of subsection concerning other main parameters that the user might > want to consider? But in any case, them appearing as-is just looks like it's > an > error (e.g. "has a chunk of text been lopped off the 'configure ...' > commmand?"), > and one repeated elsewhere in the book. > They are tagged as in the xml, instead of , and different browsers may render them differently. In firefox, the command --disable-static shows in italic monospace, although the directory class overrides that to what I suppose is bold monospace for the moduledir. The options are rendered in normal weight monospace. Yeah, I would prefer italic for options but I'm not touching that stuff (the xml itself) with the proverbial barge-pole. > > In a related vein, given that four of the above-noted five options are stated > to be re auth, could I also recommend noting that (at least) the following > auth > methods are enabled by default: > > --with-shadow Build with shadow password support (auto) > --with-pam Build with PAM support (auto) > --with-bsdauth Build with BSD authentication support (auto) > --with-vpopmail Build with vpopmail support (auto) > > I think it's worth stating that explicitly so that folks can see at-a-glance > that dovecot does handle those ( - don't hide its light under a bushel). One > of > the central considerations, of course, in choosing a pop/imap server is in > what > authentication methods can it handle, and how it would in this respect > integrate > with other parts of infrastructure. Sure, folks considering using it > seriously, > would do their due diligence anyhow and not just make a decision based on a > single 3rd-party page (in this case, the blfs page): but still, it doesn't > hurt > to state it up-front by noting the default methods additional to said list. > If something is optional and automatically detected, we don't usually add an explanation of a switch to enable it. Unless an editor thought it was worth mentioning. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Thu, Nov 14, 2013 at 10:37:57AM +, Vasco Almeida wrote: > 1. On my Ubuntu I should install at least/bison, gawk, g++, m4/ > and/makeinfo/ (via apt-get install/packa//ge-name/, assuming these are > indeed the names). Yes. For gawk, you might also need to change the 'awk' symlink to point to gawk instead of mawk. > 2. Possibly, I should also install/build-essential/. Definitely install this, I think it might pull in some of the others listed above. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Wed, Nov 13, 2013 at 09:59:18PM +, Vasco Almeida wrote: > Please find attached "mymakelog" file. Thank you again for your support. > > Vasco I see the following - if (/mnt/lfs/sources/binutils-2.23.2/missing makeinfo --split-size=500 --split-size=500 --version) >/dev/null 2>&1; then \ for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9] bfd.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ else :; fi && \ if /mnt/lfs/sources/binutils-2.23.2/missing makeinfo --split-size=500 --split-size=500 -I ../../../binutils-2.23.2/bfd/doc \ -o bfd.info `test -f 'bfd.texinfo' || echo '../../../binutils-2.23.2/bfd/doc/'`bfd.texinfo; \ then \ rc=0; \ else \ rc=$?; \ $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[3]: *** [bfd.info] Error 1 make[3]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd/doc' Making info in po and it eventually falls through to - make[3]: Nothing to be done for `info'. make[3]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd/po' make[3]: Entering directory `/mnt/lfs/sources/binutils-build/bfd' make[3]: Nothing to be done for `info-am'. make[3]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd' make[2]: *** [info-recursive] Error 1 make[2]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd' make[1]: *** [all-bfd] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/binutils-build' make: *** [all] Error 2 This looks as if makeinfo in now *required*. Try installing texinfo on the host. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Wed, Nov 13, 2013 at 10:52:02AM +, Vasco Almeida wrote: > Thank you for your suggestions, Ken. > > I did check the minimum Host System Requirements when I started off (I > am indeed trying to build LFS-7.4 on Ubuntu 12.04), but rechecked them > and nothing seems amiss. > > As for capturing the output, I went about it in two steps: > /mnt/lfs/sources/binutils-build$ ../binutils-2.23.2/configure > --prefix=/tools --with-sysroot=$LFS --with-lib-path=/tools/lib > --target=$LFS_TGT --disable-nls --disable-werror > myconflog 2>&1 and, > after checking there were no errors in myconflog, followed it with > make > mymakelog 2>&1. The errors in mymakelog were exactly as reported > in my initial post and in my reply to William Harrington. I can send you > the log files if you deem it necessary and appropriate. > > Thank you for your support. Best regards. > Vasco > Well, I'm pleased that you didn't fall into the trap I accidentally set by putting '2>&1' after the pipe to tee. Also, configure won't report an error if it gets as far as creating the Makefiles - but the results of the various tests which configure runs might be useful iff we can find out what is reported for the error during 'make'. First we need to identify that message. How big is 'mymakelog' ? If it is under 50K, please attach it. If it is bigger, please compress it with gzip and attach the .gz version. My own log [ configure, make, install ] was 259k, but gzipped to 22k so you should be able to attach one or the other without hitting the list's limits. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Wed, Nov 13, 2013 at 09:41:33AM +0100, Pierre Labastie wrote: > Le 13/11/2013 02:53, Ken Moffat a écrit : > > On Tue, Nov 12, 2013 at 07:57:30PM -0500, Baho Utot wrote: > >> If you are using bash 4.0 or greater > >> > >> ../path/to/binutils-source/./configure ... | tee myconflog 2>&1 > >> > >> becomes > >> > >> ../path/to/binutils-source/./configure ... |& tee myconflog > >> > > I would change 'becomes' to 'can be changed to' - there is no > > *requirement* to change a following '2>&1' to a preceding '&'. > > > > > but 2>&1 should be before the `|' anyway : it does not work the same as `>'. > > If you type the command as above, it sends the "tee" errors to stdout, > not the "configure" errors... > > Regards > Pierre > Arghh! Right you are. What was I thinking ? Brown paper bag, please. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Tue, Nov 12, 2013 at 07:57:30PM -0500, Baho Utot wrote: > > If you are using bash 4.0 or greater > > ../path/to/binutils-source/./configure ... | tee myconflog 2>&1 > > becomes > > ../path/to/binutils-source/./configure ... |& tee myconflog > I would change 'becomes' to 'can be changed to' - there is no *requirement* to change a following '2>&1' to a preceding '&'. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Tue, Nov 12, 2013 at 11:31:56PM +, Vasco Almeida wrote:
> "
>
> Where do I go from here?
>
>
Find the part of the output with the actual 'Error' message (it might
say 'error'). It looks as if the real error was before that warning
about makeinfo. I haven't seen the post where 'make -k' was
recommended (I expect it is taking a slow route to reach me), but in
general you do NOT want to do that in LFS, except when running test
suites.
Since you have barely started, please also check the Host System
Requirements in section Vii of the Preface.
Actually, check the Host System Requirements _first_, then (if
your host meets _all_ of them : newer versions *probably* work for
binutils and gcc), repeat your attempt to compile this, after
removing the existing binutils-2.32.2 (I'm assuming you are trying
to build LFS-7.4) and binutils-build directories.
But this time, capture the output in a log, for example
../path/to/binutils-source/./configure ... | tee myconflog 2>&1
and then
make | tee mybuildlog 2>&1
so that the error messages on stderr ('2') get mixed in. Then look
at the build log in 'view|vim' or 'less' and search for Error [
'/Error' ].
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On Sat, Nov 09, 2013 at 02:13:02PM -0600, Dan McGhee wrote: > For one thing it resolved my paranoia about where grub would write. > I would describe that as "sensible caution", not paranoia. I've irretrievably bricked one machine, and I don't wish that on anyone. In my case (the notorious AmigaOne - I overheated mine one time too many, but it took me a long while to realise what had been happening) and I had learned enough about the hardware to make me give up, and it wasn't _that_ expensive, unlike apple products. > Yes, the different distro sites seem to be rather silent on this stuff. > And you found something that I was hesitant to mention. This stuff does > depend a lot on vendors. Many have written their own Boot Managers and > I've found many comments and articles on how "buggy and unreliable" many > are. As of a year ago, HP was one of those that had lots of > complaints. That may be something else I need to research. rEFInd and > gummiboot, look out I may be headed your way. > Ah, I didn't realise it was the hardware vendors. Thanks for clarifying. > As I've said, I'd like to accomplish two things: 1) get LFS-7.4 to boot > in a UEFI environment, and 2) do it in a way that will be useful to LFS. > > Thank you very much, Ken, for your efforts. > > Dan > Thank you. I hope it turns out well, and look forward to reading more. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On Sat, Nov 09, 2013 at 10:42:14AM -0600, Dan McGhee wrote: > I wanted to respond directly to you, Ken, because your original was so > detailed and obviously took a long time. Thanks for that. > > I'm keeping your suggestions for the "if all else fails" part of my > work. In what I have observed, the Boot Manager is trying to "hand off" > to a boot loader. I get a really, really quick screen that has two > very, very short lines--that's all I can distinguish--before it moves > almost instantaneously to the Ubuntu grub screen. That's why I think > it's not a kernel problemyet. > Understood. I've no idea what happens on efi. So I looked for something detailed and useful about grub efi booting on intel _mac_. Ubuntu's best effort seems to be the *old* page at https://help.ubuntu.com/community/UEFIBooting (the newer page it links to says the old one might be better for macs). That points to a major source of the kernel problems (a mix of EFI 1.x and UEFI 2.x). Arch goes into some detail at https://wiki.archlinux.org/index.php/GRUB#UEFI_systems_2 but I get the impression they do things very differently from ubuntu. There is a page at http://www.rodsbooks.com/efi-bootloaders/grub2.html which talks in general terms - possibly targetted at windows users, I'm not sure if it will tell you anything you haven't already discovered. The gentoo links that google found all seemed to be untested. A mageia link noted that EFI is very flexible so every vendor (I think the writer means every distro) does things differently. (Reminds me of VSAM - "a flexible and powerful tool", really easy for the unwary to screw things up). All I can suggest is that you try editing ubuntu's grub.cfg [ perhaps using 40_custom rules in the longer term, but as a first step I would just make it writable and edit it ] so that you can add an LFS entry to the ubuntu grub menu. That might allow you to prove that the LFS kernel is usable, or alternatively to prove that the required parms aren't what was expected. For that, you would need to copy the LFS kernel to wherever ubuntu has installed its kernels. That's only a step on the way, and ignores many of the things you want to eventually do, but it would break the problem down into slightly smaller parts. > Although your steps may be quite painful, they may be necessary. Is > that called "regression testing?" I've done a little of that myself > recently and regressed to the oral expulsive stage of my personality > development in which my hp-envy almost became hp-sattelite when I wanted > to make the hp-efi into hp-ufo. Technically, regression testing is when it used to work and you want to see if it still does. You haven't got a known-good setup for LFS at the moment, so it's development. > > And to refer to Bruce's analysis of what you wrote I wonder if things > are "horrid" because they become "simply complicated;" e.g. kernel > configuration from scratch. > It's more that they don't have *any* system available to them, except what is statically built in, and minimal space. That tends to mean odd build dependencies (lilo), awkward user interfaces for loading the new setup (lilo, yaboot is somewhat similar, and uimage which used 'dd' when I had to use that). And that is before the weirdnesses of certain firmware (blessing with hfs|hfs+ on macs). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On Sat, Nov 09, 2013 at 02:35:35AM +, Ken Moffat wrote: > [ snip EFI / grub.cfg details, I'm going to query your reasoning ] > I see Bruce has replied while I was composing this. Definitely try his suggestions first (he understands those horrid gpt partitions and the even more horrid [1] grub ;-) Only come back to my painful suggestions if you have to. ĸen 1. ALL bootloaders are horrid, it's in their nature. -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On Fri, Nov 08, 2013 at 06:17:44PM -0600, Dan McGhee wrote: > I have everything in place to boot LFS in EFI-mode. The problem is that > something is failing and the messages go by so fast that I can't see > what it is. Just like I have it set up, the laptop boots to Ubuntu if > the LFS boot failed. My problem is that I'm stymied in my troubleshooting. > > I've reasoned that the problem is probably in my grub.cfg. > [ snip EFI / grub.cfg details, I'm going to query your reasoning ] One initial question: you are getting kernel messages when LFS fails to boot ? If so, in a conventional bios boot the showstopper is usually something like "trying to kill init" and that usually happens because rootfs= is wrong, or the device drivers and filesystem are missing. You have root=/dev/sda6, so I will be very surprised if you have fallen into that hole. Hmm, does it change to booting ubuntu _immediately_ if the LFS boot fails ? If so, I can understand why you can't see the messages, but I've no idea how to address that. My reason for questioning if this is a grub.cfg issue is that I've been reading the kernel mailing list (lkml) since before I ever found BLFS or LFS. Some days I skim most of the posts, but in the last month or two I've seen a lot of posts between kernel developers about (U)EFI. My impression is that the situation is still very fragile [to be fair, most of the threads were primarily about signing the kernel for secure boot], and I recall reading that many commits which fixed things for some people broke things for others. In particular, I had the impression that many apple machines seemed to disagree with fixes that worked on "regular" Windows EFI x86 and (perhaps) on arm. So, I think it might be a problem either with the kernel config, or with the kernel version. Since you can't boot, that isn't a very helpful observation. Can you do anything to pause it after it fails to boot LFS ? On all the machines I've ever built for (x86 with bios, and various ppc) the automatic reboot happened about 3 minutes after the boot failed, which gave me time to note some of the visible messages. Hmm, if this is a laptop then I suppose the screen might not have enough rows to see anything useful. Perhaps the same if you got an oops and the kernel state was dumped. I *guess* a way to approach this might be to take the .config from ubuntu (/boot/config-3.x.y-z-something), work out what needs to be built-in instead of modules [ lsmod on ubuntu - if it loaded, you probably need it, at least until you can boot ], and then take a similar kernel version and try that. What I mean is, IFF you are running e.g. 3.2.0-34-generic on ubuntu, then first try 3.2.0, but also try 3.2.latest. If either boots, it's a start. If both boot, go with 3.2.latest. If neither boots, I've probably wasted your time. If only 3.2.0 boots, perhaps try "broad brush" bisection between 3.2.0 and 3.2.latest [ I don't know what the latest 3.2 SUBLEVEL is, my oldest running kernel is now 3.10.something, and anyway you might not be running 3.2 in ubuntu ]. ** after you can boot, first try 3.10.latest with that .config as the input to make oldconfig please, in case that works - if so, the job is done ** e.g. if latest is .100, for "broad brush" bisection try .50, then either .25 or .75 according to whether or not that boots. Depending on available time, you might get to the latest version of _that_ kernel which boots. That would indicate that one of the commits in the next SUBLEVEL broke it. Hmm, ubuntu are doing long-term maintenance of some kernels, of which I think one is 3.8 and I'm not sure about the other - I think they are adding their versions at the fourth level [ EXTRAVERSION ]. Whatever, the first step is to try to get a kernel which boots. If you can achieve that, the next step is to move through the newer still-maintained versions. I think the following are still maintained officially - 3.2, 3.4, 3.10. If it is an "errant hardware" problem I will have to suggest that you might need to try ALL the various SUBLEVELs of whichever of those series are newer than what ubuntu runs. Hopefully .0 will work, but it is possible that a later SUBLEVEL fixes an error, only for a still-later one to break it again. Actually, once you have a .config that lets you boot LFS, I guess the most efficient thing to do would be to try 3.10.latest with that config, in case it works. [ I've added the '**' sentence above ]. I'm sorry this sounds painful (it probably will be), but EFI is not yet something that most linux users are using. For the BIOS, it took years to sort out some of the weirdnesses. And I'm sorry, my suggestion to try 3.10.latest once you have a working older .config will short-circuit a lot of what I've written (if it works). I'm sure you can find an appropriate path through the twisty maze of kernel versions, all almost alike ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://lin
Re: [lfs-support] 8.3 - Kernel Build
On Wed, Nov 06, 2013 at 01:47:42PM +, Ken Moffat wrote: > I have a very vague recollection that one or two packages (probably > not in BLFS) used to pick up kernel details by looking at > /usr/src/linux , if it existed, in the very distant past. ISTR they > actually wanted to know the capabilities of the _running_ kernel. > To clarify: consider the situation where you suspect you have a kernel bug. Say you are now on 3.12.0 and had previously used 3.11.5. As a first step, boot 3.11.5 [ assuming you kept it around, of course ] to see if things are different. Any application looking at /usr/src/linux has no guarantees that the source (or indeed the .config there) matches what is running. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 8.3 - Kernel Build
On Wed, Nov 06, 2013 at 01:22:23PM +, Richard wrote: > Hello again, > > I am surprised and confused by the warnings and instructions in Section 8.3 - > can someone please elaborate on the points below? > > I have previously rebuild the kernel several times on a variety of distros > and although instructions differ there has always been one unshakable thing > in common: the kernel sources always always always live below /usr/src/linux. > I have just checked my host system (a recent clean install of slackware - > running 3.2.29-smp) and it too has a symlink from /usr/src/linux to the > current source tree. So the obvious questions arise: > > - Where should the kernel source be kept? Presumably below /sources with all > the rest? Keep it anywhere you like! Or don't keep it extracted [ I believe that certain iptables-related things want kernel source, but that is extremely unusual and certainly iptables itself doesn't need the kernel source for normal builds ]. Apart from during the build of LFS, where root is the only user, there is no need to build the kernel as root. For years, my kernel source lived in /home/ken. I only moved it out of there to avoid the waste of backing it up : as long as you can recreate the .config, an extracted kernel tree isn't needed. > - What are these dire consequences which are alluded to in the warning box at > the end of 8.3.1? > - Is this a LFS-specific problem or are other distro making a mistake? As > just stated there seems to be such a symlink on slackware and I had a brief > flirtation with gentoo which I am sure also store kernel source below > /usr/src/linux? > I have a very vague recollection that one or two packages (probably not in BLFS) used to pick up kernel details by looking at /usr/src/linux , if it existed, in the very distant past. ISTR they actually wanted to know the capabilities of the _running_ kernel. But yes, we consider that everyone making an unnecessary /usr/src/linux symlink is mistaken, just as we consider that updating the kernel headers when updating the kernel is wrong. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 6.7.1 header file search verification failure
On Wed, Nov 06, 2013 at 05:30:58AM -0600, Douglas R. Reno wrote:
> I am building GCC 4.7.1 (book says to use 4.7.2). My book version is 7.3,
> so I am not using the latest version of the book. I have built several
> systems with 4.7.1 instead of 4.7.1.
>
You seem to be confused about *where* you are in the book, and I
suspect you are looking at multiple versions of it. Your heading is
'Chapter 6.7.1 header file search verification failure' but in all
of the books since (at least) 7.2 the section is 6.10. 7.3 is at :
http://www.linuxfromscratch.org/lfs/view/7.3/chapter06/adjusting.html
> My output of "grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'" is:
>
> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/lib")
> SEARCH_DIR("/lib");
>
And on that page I've linked to, it says:
| 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");
Which appears to match your results.
For 7.4, the '/tools' match disappears. Perhaps you are trying to
build something that is between 7.2 and 7.3, but comparing it to the
7.4 or current svn book ? Or maybe you are building 7.3 except for
sticking with an older gcc-4.7 release. That seems weird, but I'm
sure you will think many things _I_ do are weird.
I can't imagine why you would want to build such an old version -
for me, stable 7.4 is verging on 'old' (I'm from the "LFS is near
the bleeding edge" school) - but "your system, your rules" and the
*matching* instructions should still work. But please be _clear_
about which version you are using, and what variations you have
made, when you post here. At the moment, people will probably
assume you are building 7.4 if you say nothing.
I was going to moan about you top-posting, but I see you are using
gmail so I guess you don't have any real choice if you are using its
web interface - sucks, doesn't it.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Some BLFS Packages Before Making LFS-7.4 Bootable
On Thu, Oct 31, 2013 at 06:07:03PM -0500, Dan McGhee wrote: > > I also have my sources in /usr/src and that is a separate partition so I > > can use it from any build. I recommend the following as separate > > partitions: /boot, /home, and /usr/src. /opt is also a possibility. > > > > -- Bruce > > > I have a script that gets me to chroot and it mounts those each time I > go in. > > I forgot about wget, thanks for reminding me. > > A separate partition for /usr/src? Never occurred to me, but it's a good > idea. > Actually, you can build any package *anywhere*. For something like the kernel, keeping the source directories around if I haven't built that version before ( or if there have been major changes such as when I was upgrading only from a very old system that needed the old compatability sysfs options for less ancient kernels) is a good idea. If the kernel boots, I can get the config from /proc/config.gz - it's the ones that don't boot which are the problem ;) My scripts *used* to build (as root) in /usr/src because that was conventional and traditionally intended for root to build in, and kernels and anything else built manually as a regular user were in ~/. Nowadays I use a dedicated partition which doesn't get backed up, and which has _writable_ directories belonging to me and someone called lfs, and another directory that root uses in my scripts. So, you certainly want space to build things, and it needs to be writable by whoever does the building, but it doesn't matter where you put it. BTW, I mention "not backed up" because '/' '/boot' and '/home' get backed up regularly by fcron invoking an rsync-over-nfs script. That uses a *lot* of space on the server (typically 2.5 times the size of the data : the copy is then rsynced to a retention area using hardlinks for GDG-style backups) and my server disks aren't huge - main system now on a 1TB disk including the area the backups are first written to, and a pair of 1TB RAID-1 disks for inter-alia the backups themselves and also a lot of photos and media. There are probably an infinite number of sensible partitioning strategies, but knowing how you will recover if things go wrong (e.g. a dieing disk) should be a consideration. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Some BLFS Packages Before Making LFS-7.4 Bootable
On Thu, Oct 31, 2013 at 02:28:27PM -0500, Dan McGhee wrote: > So that I can "hit the deck running" after I get my new system to boot, > I want to add a few packages, and their associated boot scripts, from > BLFS. These are dhcpd, wpa-supplicant, libxml, libn, open-ssl and > d-bus. I seem to remember reading somewhere, and I thought it was in > the LFS book, that it was OK to do what I'm thinking of. I don't see > anything that will hinder my plan, but I thought I'd ask here where many > people know a lot more about this than I do. > > Anything to be careful of? > > Thanks, > Dan > There used to be some packages that gave problems if building in chroot. But I don't remember what they were. In the last couple of years I've done some complete builds in chroot while I sorted out changes to my build scripts, so I don't think you'll have any problems. You might want to add a text browser so that you can read the BLFS book. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
On Thu, Oct 31, 2013 at 03:26:35PM +, Richard wrote: > > > > From: Ken Moffat > ... > >Are you using the 7.4 book or svn ? If you are using gcc-4.8.2 > >then I have no data to offer. > ... > > I am (I hope!) using the plain, normal, generic, unadulterated LFS 7.4 - > which means that I just compiled gcc 4.8.1. > > I will proceed under the assumption that all is well. > > Thanks, R. I thought you were using that - clearly, the tests cannot have changed in the past x weeks because the tarball (and its md5sum) has not changed. ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
On Thu, Oct 31, 2013 at 01:28:09PM +, Richard wrote: > Hello again, > > I have finally completed the leviathan task of my first gcc compilation and > test. > > I am encouraged to have only one unexpected failure outside libmudflap. > > This leaves me with two questions. > > 1. How bad is that error? I have inferred that it is probably infrequent - > but it does no harm to check... > (FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_HugeMallocTest > Ident((char*)malloc(size))[-1] = 0 output pattern test, should match is > located 1 bytes to the left of 2726297600-byte) > I've never seen that one, I assume it is probably platform-specific My rule of thumb is that a large number of unexpected failures mean something is wrong [ I had that once, in the early days of udev ]. Beyond that, I don't have a high regard for testsuites - what really matters is whether the package will work in normal situations. Getting a new failure is interesting, but might be random. > 2. Far more worryingly - have I somehow mishandled the tests? I am drawn to > startling disparity in the test totals. Here is my gcc summary, based on > source tarballs downloaded in the past week or so: > > === gcc Summary === > > # of expected passes92870 > # of expected failures259 > # of unsupported tests1096 > > and here is the corresponding section from > http://www.linuxfromscratch.org/lfs/build-logs/stable/core2duo/test-logs/080-gcc > (which I believe ran in August): > === gcc Summary === > > # of expected passes93302 > # of expected failures261 > # of unsupported tests1368 > > Am I correct in thinking that I am missing 706 tests? Has the test suite > really shrunk by 700 tests in the past 8 weeks? Are you using the 7.4 book or svn ? If you are using gcc-4.8.2 then I have no data to offer. > > Again, many thanks, R. I've only built 32-bit x86 once for LFS-7.4 (on a recent AMD machine, I think it's an A4). My results were more like yours than Bruce's : === gcc Summary === # of expected passes92903 # of expected failures 259 # of unsupported tests 1084 What appears to be changing is the number of unexpected failures. My build had some variations from the -rc1 book (a patch in automake which I think got into the release, and eudev instead of udev from systems), but those are later than the gcc test results. I also limit the compatability code in glibc [ --enable-kernel=3.9.0 to suite my rescue CD ] but I'm guessing the config of the running kernel might be what has most influence on which tests are unsupported. Everything else we've built at this stage should match. Mostly, I only look at the errors reported by this sort of testsuite. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, Oct 28, 2013 at 04:25:02PM +, Richard wrote:
>
> I think I neglected to shut down the networking on the host system - so the
> posix tests did not fail. I did not realise that network isolation was a
> requirement. I do not have that machine with me here at work - so I will
> check later.
>
That is interesting. And very puzzling. For me, I don't shut down
networking on the host (why would anyone do that ?), but I think that
test has always failed for me since it was introduced - it's fairly
recent.
Similarly, I get an ignored Error for posix/annexc.out and I think
that one has been like that ever since we've been running the tests
('pure LFS' - first release like that was 5.0 if my memory is
correct), but I didn't see that one either in your grep.
> >
> > > I am also assuming that glibc is one of the packages that can safely be
> > > installed to a fake root - then tarballed 'slackware style'? (i.e: I am
> > > intending that my next step would be make DESTDIR=dest install), rather
> > > then installing directly.
> > >
> >
> > For the first time, we recommend doing things by-the-book so that
> > you understand how it all fits together. If you wish to try doing
> > things differently, please be aware that you *might* encounter
> > problems that other people don't.
>
> I'll probably get shouted at for this - but here goes...
>
> ... forgive my stupidity. I was trying to stick to doing things by the book.
> The method of installing to a fake destination directory is explained in
> sections
> 6.3.2.3 and 6.3.2.6; so I thought that using DESTDIR *was* doing things 'by
> the book'.
>
When we say "by the book" we usually mean by following the commands
on the page for that step (and ONLY those commands - you have
already shown a willingness to come up with your own version of the
grep command :-) There are a number of different approaches to
package management, all of them have drawbacks.
In my own case I "suppress" many of the static libraries, but that
restricts what I can do [ no statically-linked packages, some tests
in binutils fail, also I can't build sysvinit, tk, firefox [ with
system libs ], some of kde, or Linux-PAM without making a static lib
available (various different static libs). So, although there are
some packages where I use --disable-static, in other cases I take
other measures (e.g. in flex) so that I can make a lib available when
needed.
So, I'm not trying to condemn you for doing things differently.
I'm trying to point out what we mean by "follow the book". Anything
which is different from the book runs the risk of putting you on a
less well-trodden patch. It may be "fun" (in the sense of the word
used by operators and programmers) and very educational, but if
things break you get to keep both pieces.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, Oct 28, 2013 at 01:07:32PM +, Richard wrote: > Hello experts, > > I am attempting my first LFS build; which will (hopefully) be 7.4, built on a > host system of slackware-14. > > All went well up until chapter 6. I am unsure as to whether or not the errors > in the glibc fall into the acceptable variety or not. > > glibc appeared to build well enough. Having tried the test suites (with > TIMEOUTFACTOR=16 - this is a humble machine), the make - k check ends with: > > AWK='gawk' scripts/check-local-headers.sh \ > "/usr/include" "/source/glibc-build/" > > /source/glibc-build/check-local-headers.out > /usr/bin/perl scripts/begin-end-check.pl argp/argp.h assert/assert.h > catgets/nl_types.h crypt/crypt.h ctype/ctype.h debug/execinfo.h > dirent/dirent.h dlfcn/dlfcn.h elf/elf.h elf/link.h gmon/sys/gmon.h > gmon/sys/gmon_out.h gmon/sys/profil.h grp/grp.h gshadow/gshadow.h > iconv/iconv.h iconv/gconv.h inet/netinet/in.h inet/netinet/igmp.h > inet/netinet/ip6.h inet/netinet/ether.h inet/netinet/icmp6.h inet/arpa/inet.h > inet/arpa/telnet.h inet/arpa/tftp.h inet/arpa/ftp.h inet/protocols/routed.h > inet/protocols/timed.h inet/protocols/rwhod.h inet/protocols/talkd.h > inet/aliases.h inet/ifaddrs.h inet/netinet/ip6.h inet/netinet/icmp6.h > intl/libintl.h io/sys/stat.h io/sys/statfs.h io/sys/vfs.h io/sys/statvfs.h > io/fcntl.h io/sys/fcntl.h io/poll.h io/sys/poll.h io/utime.h io/ftw.h > io/fts.h io/sys/sendfile.h libio/stdio.h libio/libio.h locale/locale.h > locale/langinfo.h locale/xlocale.h login/utmp.h login/lastlog.h login/pty.h > malloc/malloc.h malloc/obstack.h malloc/mcheck.h > math/math.h math/complex.h math/fenv.h math/tgmath.h misc/sys/uio.h > nis/rpcsvc/yp_prot.h nis/rpcsvc/nis_callback.h nis/rpcsvc/yp.h > nis/rpcsvc/ypupd.h nis/rpcsvc/nislib.h nis/rpcsvc/nis_tags.h > nis/rpcsvc/ypclnt.h nis/rpcsvc/nis.h nptl_db/thread_db.h > nptl/sysdeps/pthread/pthread.h nptl/semaphore.h nss/nss.h posix/sys/utsname.h > posix/sys/times.h posix/sys/wait.h posix/sys/types.h posix/unistd.h > posix/glob.h posix/regex.h posix/wordexp.h posix/fnmatch.h posix/getopt.h > posix/tar.h posix/sys/unistd.h posix/sched.h posix/re_comp.h posix/wait.h > posix/cpio.h posix/spawn.h pwd/pwd.h resolv/resolv.h resolv/netdb.h > resolv/arpa/nameser_compat.h resolv/arpa/nameser.h resource/sys/resource.h > resource/sys/vlimit.h resource/sys/vtimes.h resource/ulimit.h rt/aio.h > rt/mqueue.h setjmp/setjmp.h shadow/shadow.h signal/signal.h > signal/sys/signal.h socket/sys/socket.h socket/sys/un.h stdio-common/printf.h > stdio-common/stdio_ext.h stdlib/stdlib.h stdlib/alloca.h > stdlib/monetary.h stdlib/fmtmsg.h stdlib/ucontext.h > sysdeps/generic/inttypes.h sysdeps/generic/stdint.h stdlib/errno.h > stdlib/sys/errno.h string/string.h string/strings.h string/memory.h > string/endian.h string/argz.h string/envz.h string/byteswap.h > sunrpc/rpc/pmap_clnt.h sunrpc/rpc/xdr.h sunrpc/rpc/rpc_des.h > sunrpc/rpc/auth_des.h sunrpc/rpc/pmap_rmt.h sunrpc/rpc/rpc.h > sunrpc/rpc/auth.h sunrpc/rpc/key_prot.h sunrpc/rpc/netdb.h > sunrpc/rpc/rpc_msg.h sunrpc/rpc/auth_unix.h sunrpc/rpc/pmap_prot.h > sunrpc/rpc/svc.h sunrpc/rpc/clnt.h sunrpc/rpc/des_crypt.h sunrpc/rpc/types.h > sunrpc/rpc/svc_auth.h sunrpc/rpcsvc/bootparam.h sysvipc/sys/ipc.h > sysvipc/sys/msg.h sysvipc/sys/sem.h sysvipc/sys/shm.h termios/termios.h > termios/sys/termios.h termios/sys/ttychars.h time/time.h time/sys/time.h > time/sys/timeb.h wcsmbs/wchar.h wctype/wctype.h > > /source/glibc-build/begin-end-check.out > make[1]: Target `check' not remade because of errors. > make[1]: Leaving directory `/source/glibc-2.18' > > When I look for just the errors, using 'grep -i error glibc-check-log' I find: > If you had used the command in the book (grep Error) instead of your own version you would have got a much shorter output. > make[2]: *** [/source/glibc-build/rt/tst-cputimer1.out] Error 1 > make[1]: *** [rt/tests] Error 2 > make[2]: [/source/glibc-build/conform/run-conformtest.out] Error 1 (ignored) > make: *** [check] Error 2 > > I have inferred from the book that 'cputimer1' and 'run-conformtest' might be > 'acceptable' failures, but I was surprised that the test suite ended mid-way. > Why do you think it ended mid-way ? Your output from the make check command seems to end normally (I was going to cut it from the reply, but I've left it for the moment) - my log ended similarly. Ah, you don't seem to have results from the posix/ tests. For me they are run (and fail as noted) before run-conformtest.out. If you look at glibc-check-log (try using less or vim from the host system), does tst-getaddrinfo4 get mentioned ? In my log the .c file gets compiled to .o with a command which references the .o and .o.dt before creating the .o, then gets linked to tst-getaddrinfo4 (by gcc), and then gets invoked in the next line to create tst-getaddrinfo4.out. Do you have any of that in your log ? > Have I done something stupid? Are these acce
Re: [lfs-support] compile error with libstdc++
On Sun, Oct 27, 2013 at 01:01:17AM +0200, Hans P. wrote: > Hello, > > I'm try to compile the libstdc++. I'm read carefully the section "5.8.1. > Installation of Target Libstdc++", but when i try to "make install" I > get an error: > "../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found" > > and after that, some line further the program stop. > > Can someone help me? > Just to be clear - did you remove the gcc-4.8.1/ directory after pass 1 of gcc ? You need fresh source and build directories each time. I'm mentioning that because I don't remember seeing this problem before. If you re-used the previous source, please use fresh source and try again. > Thanks a lot > > best regards > rado > > > I execute the following command: > ../gcc-4.8.1/libstdc++-v3/configure --host=i686-lfs-linux-gnu > --prefix=/tools --disable-multilib --disable-shared --disable-nls > --disable-libstdcxx-threads --disable-libstdcxx-pch > --with-gxx-include-dir=/tools/i686-lfs-linux-gnu/include/c++/4.8.1 > > Result: > ... > make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/include' > Making install in libsupc++ > make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' > make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' > test -z "/tools/lib" || /bin/mkdir -p "/tools/lib" > /bin/sh ../libtool --mode=install /usr/bin/install -c libsupc++.la > '/tools/lib' > libtool: install: /usr/bin/install -c .libs/libsupc++.lai > /tools/lib/libsupc++.la > libtool: install: /usr/bin/install -c .libs/libsupc++.a > /tools/lib/libsupc++.a > libtool: install: chmod 644 /tools/lib/libsupc++.a > libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a > ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found i686-lfs-linux-gnu-ranlib should have been installed by binutils pass 1. You presumably have *some* of the binutils programs, otherwise gcc pass 1 could not have built for $LFS_TGT. My i686 log shows the following programs were installed. Please check if they are present on your build: /tools/bin/i686-lfs-linux-gnu-addr2line /tools/bin/i686-lfs-linux-gnu-ar /tools/bin/i686-lfs-linux-gnu-as /tools/bin/i686-lfs-linux-gnu-c++filt /tools/bin/i686-lfs-linux-gnu-elfedit /tools/bin/i686-lfs-linux-gnu-gprof /tools/bin/i686-lfs-linux-gnu-ld /tools/bin/i686-lfs-linux-gnu-ld.bfd /tools/bin/i686-lfs-linux-gnu-nm /tools/bin/i686-lfs-linux-gnu-objcopy /tools/bin/i686-lfs-linux-gnu-objdump /tools/bin/i686-lfs-linux-gnu-ranlib /tools/bin/i686-lfs-linux-gnu-readelf /tools/bin/i686-lfs-linux-gnu-size /tools/bin/i686-lfs-linux-gnu-strings /tools/bin/i686-lfs-linux-gnu-strip and also some of them were in /tools/i686-lfs-linux-gnu/bin/ : /tools/i686-lfs-linux-gnu/bin/ar /tools/i686-lfs-linux-gnu/bin/as /tools/i686-lfs-linux-gnu/bin/ld /tools/i686-lfs-linux-gnu/bin/ld.bfd /tools/i686-lfs-linux-gnu/bin/nm /tools/i686-lfs-linux-gnu/bin/objcopy /tools/i686-lfs-linux-gnu/bin/objdump /tools/i686-lfs-linux-gnu/bin/ranlib /tools/i686-lfs-linux-gnu/bin/strip [ ISTR these are hardlinked to the first set ]. Are all these files present ? If not, which are missing ? Another thing to consider - did you interrupt the build and exit it, then later come back ? Perhaps the environment for user lfs didn't get restored ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found
On Fri, Oct 25, 2013 at 08:28:40AM +0100, Michael E. Maher wrote: > On Fri, 2013-10-25 at 00:58 +0100, Ken Moffat wrote: > > On Fri, Oct 25, 2013 at 12:25:11AM +0100, Michael E. Maher wrote: > > > > > > Hey Ken, > > > > > > Does `/etc/mtab' look good? > > > > > > > > > Thanks, > > > Michael > > > > > > > Root has now umounted /dev/sdXY, so it is no longer mounted. What > > should I look for if I mount it again and then try to umount it ? > > > > ĸen > > First make sure it's a symlink to `/proc/self/mounts' Yes for both (the server running 7.4 where I noticed this, and the current desktop machine where I originally saw it). > and check that it > contains a entry like: > > /dev/sdXY /scratch ext4 rw,noquota 0 0 > I've just attempted to umount on the desktop (took me a while to get to a point where nothing was actively using /scratch :) - ken@ac4tv ~ $cat /etc/mtab | grep /scratch /dev/sda14 /scratch ext4 rw,relatime,data=ordered 0 0 ken@ac4tv ~ $umount /scratch/ umount: /scratch: mountpoint not found But root was able to 'umount /scratch' after that. The line in /etc/fstab is: /dev/sda14 /scratch auto noauto,user,rw,exec,suid,dev 0 0 The options are because I sometimes do test chroot builds there. Those settings were working fine until recently. > I might be way off base, but I'm guessing maybe this is within a > `chroot'? > No, regular systems. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found
On Fri, Oct 25, 2013 at 12:25:11AM +0100, Michael E. Maher wrote: > > Hey Ken, > > Does `/etc/mtab' look good? > > > Thanks, > Michael > Root has now umounted /dev/sdXY, so it is no longer mounted. What should I look for if I mount it again and then try to umount it ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found
On Thu, Oct 24, 2013 at 05:59:52PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > I first noticed this on my desktop which is running LFS-svn with > > make-4.0, and where I've got more than enough other things still to > > look at. But on my server running 7.4 I've just done: > > > > mount /scratch > > [ /me does something there ] > > umount /scratch > > > > which returns - > > umount: /scratch: mountpoint not found > > > > and /scratch is still mounted. Any ideas about what is going on, > > please ? > > No, but you can always 'umount /dev/sd??' > >-- Bruce > Well, root can, so thanks for that (all too often, I'm too close to the problem and can't see the wood for the trees). - /scratch is where I use the spare space from modern disks : it doesn't get backed up [ what a waste of space that would be! ] and either ken or lfs can use it - or indeed /root when updating the system. One day, I suppose I'll find out what else needs to be changed so that users can umount it again. Meanwhile, only about another 30 packages to test (mostly DESTDIR) on *this* build with make-4.0. I'd better get back to preparing my scripts for the *next* build - all the remaining rubbish^Wthings I don't normally build. ;-) Thanks. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] umount: mountpoint not found
I first noticed this on my desktop which is running LFS-svn with make-4.0, and where I've got more than enough other things still to look at. But on my server running 7.4 I've just done: mount /scratch [ /me does something there ] umount /scratch which returns - umount: /scratch: mountpoint not found and /scratch is still mounted. Any ideas about what is going on, please ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Wed, Oct 23, 2013 at 09:00:36PM -0400, Viola Zoltán wrote: > Dear Ken, I need the new distro from you suggestion ONLY, JUST for the > building of LFS, no for other works/jobs! No problem, if it not have > wifi-possibility or others. I saved the full LFS and BLFS books to my > new-used partition, I will work from its. And I was downloaded all needed > packages, of course. I will install the new host distro, and build LFS. If > I would like work/play any other, then reboot to my Sabayon. Therefore, I > no need full-featured desktop environment. Just a lightweight WM with a > browser to read the LFS book, mc (not musthaved, but I like it) and nothing > else, just I should can build my LFS. I need the host distro just > temporarily, ad interim. Which distro you do use nowadays for build you LFS > system? To answer that last question - LFS. I have used debian-ppc and then ubuntu for my non x86 boxes, but the last x86 distro I used was probably mandrake-7.2. Is sabayon the gentoo-based hardened distro you were using ? Or did you actually install gentoo ? > > Or, it is would be much easyer to my, that if you have a full temporary > system as written in the LFS book, - finished to the 5.35 chapter - then > you pack it to a tar.bz2 file, and send me its download link. I download > it, unpack it to my partition, change ownership, and begin at this chapter > I continue the building of my own LFS system, with chroot and others. This > is a little bit would be alike to the Gentoo, from stage3, I think. > > Zoli Four reasons why I can't do that : 1. I don't have such a tarball. 2. Size - I don't have anywhere to upload large files. 3. Licensing - you would need my buildscripts, and I would also have to offer to supply you with the source tarballs for a reasonable time, at least for the GPL'd packages. 4. I'm normally building on x86_64. You are building i686. At this point, perhaps I should mention that we really dislike top posting. You mentioned that you didn't like ubuntu : if you have a fairly-recent ubuntu CD, that should be good enough : install it and then boot ubuntu, install a minimal desktop instead of the bloated 'buntu desktop (I prefer icewm, but xfce is nearly as useful), your mc, and then whatever it needs for LFS - build-essentials, and replacing the dash symlink is my guess. Check the host system requirements in the book. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Wed, Oct 23, 2013 at 07:14:15PM -0400, Viola Zoltán wrote: > Dear Ken, I am sure that this is no memory problem. I have absolutely full > totally new memory chipset in my laptop, and all programs work very good, > both in my Sabayon (because I use not Gentoo, but Sabayon) and my old > Ubuntu 11.10 distro in an other partition. > > Okay, I try the LFS with any other host distro. Make a suggestion to me, > please, which distro would be good for this procedure? No LiveCD please, I > have an empty almost 100 GB partitio for the host system. Please propose a > distro which has MC... I CAN use the commandline without MC, good, but WITH > mc it is much easyer and faster. I am not profi in the Linux, but no > beginner. Maybe "power user". I can write not too difficult bash scripts, > can programming in C/C++ (and a little bit in assembly...), my preferred > window manager is the DWM, but I am newbie in the LFS, because I not > understand good how the "configure", the "make", "autoconf", "automake" > and the linker work, not know they's syntax, etc. I am in the Linux > autodidact, self-educated, I was never learned it in any school or training > course. Actually/as a matter of fact, I was begin the LFS even just exactly > because I would like to know FULLY, how a Linux system work, and because I > very not like the bloatware distros (named *buntu, etc) with lot of (for > me) superfluous programs. I like, agree, approve the > suckless.orgphilosophy. I like the commandline and the > commandline-based programs (and > ncurses). But sorry, I not have a good "mentor"... Thus, what host distro > do you suggest for me, which work good (tested) sure to this LFS? > > Zoli > I've no idea which distro would suit you. But whatever you use, 100GB is excessively large for a system. Many people will put the user's files in /home on a separate partition. Some people will put other data files (e.g. audio-video) on a separate partition. You can always reinstall a distro if it gets trashed, but you are the only one who can preserve and back-up your own data. Debian and debian-derived distros (ubuntu, mint) may be missing a few things (e.g. they might have mawk instead of gawk, and /bin/sh might be symlinked to dash - both these things can be fixed). Distros like Arch and fedora might be too bleeding edge (i.e. newer than what we have tested), but I will be surprised if they cause many problems (I'm assuming that systemd doesn't cause a problem in building LFS - I've never used it, and have no plans to). MC is not something I like, so I've no idea which distros use it. The one benefit to a distro is that it should set up your hardware properly. Nowadays many things just work, but older or very new hardware can have problems. Wifi can be a problem, and occasionally graphics are also a problem. Suspend/hibernate also. If you can find a distro which suits you, you can use it to examine desktops and different desktop applications. I assume that debian has the widest range of these. Once you have a usable (for you) desktop, you will (I hope) find that using a graphical browser such as firefox is the easiest way to search for solutions to problems, and you will also be able to try putting multiple terms on the same desktop (if your screen is big enough) - I guess that kde, gnome, and unity (ubuntu) are probably not very good for multiple terms on the same desktop. Seriously, a desktop configured the way you like it, with multiple terms, is the most productive way to write scripts or code IMHO. I'd better not forget to mention Slackware. You might do best to spend a few weeks playing around with different distros - for normal use, I guess that 10GB is plenty for a system, but you may have trouble getting multiple distros to play nicely with each other - particularly when setting up grub, but also the user and group IDs. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Wed, Oct 23, 2013 at 05:49:27PM -0400, Viola Zoltán wrote: > @akhiezer: > > I tryed: > > CFLAGS="-O2 -g" make > > but no changed: > My final suggestion is : try a different host distro. The recent google matches for this were almost all for people updating packages on gentoo, which is why I suspect gentoo's hardening. There was one similar error for someone doing something on fedora, but at the moment I regard that as an outlier (it had no responses and apparently remains unresolved). One of the gentoo threads suggested that these errors could come from memory problems (test with memtest86), but I suspect there must also be something in the hardening which has an influence, because you are not getting a segfault. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Tue, Oct 22, 2013 at 07:41:24PM -0400, Viola Zoltán wrote: > Excuse me, I am very newbie and very idiotic... I tryed it: > > CFLAGS="-fno-exceptions -fno-rtti"; make > > CFLAGS="--fno-exceptions --fno-rtti"; make > > but nothing changed, the compile not succeeded, same error message... > I intended you to try REMOVING those CFLAGS by setting CFLAGS to just -O2 -g, but ONLY if they were already set in your LFS user's CFLAGS. I know you posted some variables in your original post, but perhaps your lfs user has mangaged to acquire some other settings from the host distro ? I don't understand the details of gentoo, but running 'printenv' as the lfs user should enable you to check that if you are in any doubt. Or 'printenv | less' if htings have been picked up. Also, if you do change anything like that you need to use freshly untarred source and a fresh (empty) build directory, and specify them when you run configure. But I think the most likely problem is that your gentoo system has been hardened, and I have no idea how to deal with that. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Tue, Oct 22, 2013 at 11:12:09PM +0100, Ken Moffat wrote: > > Someone in another gentoo response suggested reducing the CFLAGS to > something sane - if you are following LFS exactly, then the default > CFLAGS from the package should be used. I -fno-exceptions -fno-rtti > are from the package. But if you did set those, try without them. > That second sentence should start I assume -fno-exceptions ... ^^ ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Tue, Oct 22, 2013 at 05:31:19PM -0400, Viola Zoltán wrote: > Hi, excuse me for the bad English... I try LFS from Sabayon host system, > with this GCC version: > > lfs@Csiszilla /Mount/Simplicity/sources/gcc-build $ gcc --version > gcc (Gentoo Hardened 4.7.2-r1 p1.5, pie-0.5.5) 4.7.2 > > The "binutils" succeeded. The GCC not. It wrote me this error message: > > build/genautomata ../../gcc-4.8.1/gcc/config/i386/i386.md \ > insn-conditions.md > tmp-automata.c > /bin/sh: line 1: 24043 Bus error build/genautomata > ../../gcc-4.8.1/gcc/config/i386/i386.md insn-conditions.md > tmp-automata.c > make[3]: *** [s-automata] Error 135 > Apparently, a bus error differs from a segfault - valid memory is being accessed in an invalid way. The example google found was for unaligned accesses on architectures where those are illegal. i686 is generally very permissive, so I can't imagine what sort of access would cause this. Google did find similar examples on gentoo lists (users trying to emerge gcc and getting a Bus error). Apparently, the pie setting was involved. I've no idea how you would reduce the hardening on a gentoo system. Someone in another gentoo response suggested reducing the CFLAGS to something sane - if you are following LFS exactly, then the default CFLAGS from the package should be used. I -fno-exceptions -fno-rtti are from the package. But if you did set those, try without them. > My significant variables: > > lfs@Csiszilla /Mount/Simplicity/sources/gcc-build $ echo $LFS > /Mount/Simplicity Might work nowadays, but we always recommend /mnt/lfs. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ncurses Libraries in Perl Library Tree
On Tue, Oct 15, 2013 at 12:16:48PM -0500, Dan McGhee wrote:
> In trying to add Vim at the end of Ch. 5, I discoverd that four ncurses
> libraries weren't where they were supposed to be. Instead of /tools/lib
> I found libncurses{,w}.so.5{,.9} (actually two of these are soft links)
> in /tools/lib/perl15/5.18.1/x86_64-linux-gnu/. This just doesn't seem
> right. I think I can remember typing "x86_64-linux-gnu" when building
> Ch. 5, but I can't remember in what section. The only instructions in
> either ncurses or perl that could have caused any "typing issues"--and I
> usually copy and paste to eliminate those--are in the perl build. "cp
> -Rv lib/* /tools/lib/perl5/5.18.1.
>
On my 7.4 builds, in chapter 6 perl installs some files into
/usr/lib/perl5/5.18.1/x86_64-linux-gnu/. It doesn't do that in
chapter 5.
Similarly, in chapter 5 the book doesn't install the wide versions
of ncurses.
No idea how you could have got ncurses libs installed into the perl
directory tree. I guess you aren't scripting chapter 5, but if your
lfs user's bash history is available it might show something.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
On Sat, Oct 12, 2013 at 04:59:04PM -0500, Dan McGhee wrote:
> On 10/12/2013 03:01 PM, Ken Moffat wrote:
> >>
> > Maybe the syntax highlighting in that version of gedit is missing
> > or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
> > /etc/vimrc). I use a black background, with ':colorscheme elflord'
> > I didn't see anything unusual when I pasted that line into a script.
> >
> > Not that vim's highlighting is perfect, it occasionally gets
> > confused but usually only when I scroll a long way through a long
> > script.
> That was one of my first thoughts and so I loaded up a script that I
> knew worked and looked at it. It was fine. BTW it was the build script
> you helped me with a few years ago. You taught me how to extract the
> package name from a tar archive not knowing what the final extender
> was--gz, tz, bz, bz2. If you're interested, I've got that down to one
> line now instead of four since tar -xf works for all the stuff that I've
> tested.
Yeah - I think I've still got that in my functions. As you say, it
hasn't been needed for a few years. The problem is knowing when the
last system with an old version of tar has gone. I know, I'll claim
I'm retaining it in case I ever have to build from a debian system
.
>
> My thought was, "If there's something wrong in that line, the cd...
> line, then if I edit it, I might get all the pretty colors back in the
> rest of the script. The offensive character I found when I removed it
> is the " following $(pwd). When I remove the " gedit indicates that the
> syntax is OK. The problem, and it's not really a problem, is that this
> exact line is the first in every function call of the script for _make),
> _check) and _install). I understand the command because it puts you in
> the right directory to run ./configure, make and install.
>
> When I first saw this line, I thought that the purpose of all the " was
> to keep the shell from expanding things execpt a few special
> characters. As a matter of fact, after I did some more editing just
> know, I discovered that it's the combination of () and "" with $pwd that
> causes the problem. Either set of characters *used alone* works. In
> combination everything after ...d)" including the " is pink in gedit. I
> know that last was a highly technical statement of the analysis. :)
>
> I wonder if the first " escapes the first ( and the last " is seen as an
> unresolved quote. Well, at least I found the problem, even though the
> syntax sin escapes me--no pun intended, but when I read it, it's not a
> bad one.
>
> The script has been recently edited. I don't know how recently tested.
> Hopefully, we can get the situation corrected.
>
Parentheses can be a pain. In metaflac all tag values are input in
double-quoted strings, but I've never managed to get parentheses in
a tag - I did once manage \( which wasn't at all what I wanted, but
every other attempt got an error report from bash.
Similarly, a parenthesised subshell which is commented by # in a
here document (e.g. the command to get the libxul sdk in firefox's
mozconfig in the BLFS book) *is* evaluated by bash - took me a long
while to work out where the message :
Package libxul was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxul.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libxul' found
was coming from when I built firefox without xulrunner :)
But it's all about learning.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
>
> I suppose that the most practical thing for me to do is "jump into" Ch.
> 6 and build with the script in the hint as it exists now. I could
> "pause" at the end of this command to see what was happening. However,
> in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
> in. First of all, I want to understand everything the script is doing
> and when I looked at it in my text editor (gedit in Ubuntu) I saw a
> problem. With that editor the only valid thing in pick is what's
> between two quotes in an command. Anything else in pink has
> something wrong in front of it--a syntax error. In gedit everything in
> the script after <"$(pwd)"> is pink. There's something wrong, and I'd
> like to find it before I start.
>
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
It's also, of course, possible that there is an apparent error
_before_ this which makes the highlighter confused.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Errata for LFS 7.4
On Tue, Oct 08, 2013 at 07:42:49PM -0500, William Harrington wrote: > > On Oct 8, 2013, at 7:02 PM, Steve Crosby wrote: > > > Changelog lists host system requirements changes for kernel to 2.6.34, > > http://www.linuxfromscratch.org/lfs/view/stable/chapter01/changelog.html > > Indeed, > > Not sure why > > Sincerely, > > William Harrington The initial discussion was on lfs-dev on 6th July, starting at http://www.mailarchive.com/lfs-...@linuxfromscratch.org/msg18826.html if I've manually copied the link correctly (I'm on my netbook, need to use a tty to be able to _read_ my mail, don't have gpm). The value of --enable-kernel= was set to 2.6.34 in r10302. It got downgraded to 2.6.32 in r10327 in August, and obviously the log was overlooked. I don't recall why it got downgraded, and I couldn't find the reason in my mailboxes (which is not to say that it wasn't discussed). Personally I don't have anything running such an old kernel at the moment - everything is now on 3.10-rc or newer :) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting in Chapter 5
On Mon, Oct 07, 2013 at 11:59:00PM +0100, Ken Moffat wrote: > > The usual way to look at what gets installed is to run 'make > DESTDIR=/path/to/somewhere install [ optional args ]' - once you get > into DESTDIR installs for looking at what is installed you will find > some packages use other variables (often INSTALLROOT or something > like that) - if shadow is such a package,then running *as a user* > will fail. So try it as a user, to a directory which that user can > write to. > OK, so you can't try a DESTDIR install as a normal user because you are root and 'su' doesn't exist. Build outside the new system as user lfs and do a DESTDIR, e.g. to /home/lfs/somewhere or /tmp/somewhere. The same for su from old coreutils (my notes show that I had to build all of coreutils to get su linked - there might be a shorter series of commands - but NOT which old version of coreutils last contained 'su'. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting in Chapter 5
On Mon, Oct 07, 2013 at 05:09:52PM -0500, Dan McGhee wrote:
> I use the more_control hint in my builds. I need before I start
> working in Ch. 6. It's used to go back and forth between 'root' and a
> 'package_user.' When coreutils still supplied , the procedure was
> just to copy it to /tools/bin after installing coreutils to the build
> chain. Su itself was not installed because user 'lfs' is the installer
> and coreutils wanted to install it suid root. In the 'package users'
> system, there is no need for it to be suid root, but it's needed before
> the installation of shadow in Ch. 6.
>
> One option is to install 'shadow' at the beginning of Ch. 6, but that
> leads to some hiccups down the road. They're not insurmountable, but
> they can be frustrating. I'm want to install only from shadow
> before I get to Ch. 6. My problem is that I know only enough about
> and to make me dangerous, and I get bogged down
> reading the documentation.
>
> Knowing that there are some packages in LFS that will either make one
> target or install one target or copy the desired binary from the source
> directory, I looked in the configure and makefile and just couldn't see
> a way to do what I wanted. After I compiled it, I found all the
> programs shadow installs in a directory called src. In it are sets of
> files in the form . Of course, in my situation I am
> interested in only su, su.c and su.o. At this point can I just copy su
> to /tools/bin? Do I need the other two files? If so, where do they go?
>
I'm extremely reluctant to encourage people to use that hint (over
the years, the lists have seen many problems and often the users
have neglected to mention they are using it until after a lot of
investigation). But I see people are still using versions of it, so
here goes -
You don't need to install the .c file, it's the source code.
Similarly, the .o is object code from the compile - it then has to
be linked before you can execute ('run') it.
Probably, src/su will not need any further libs. But when you get
to desktop packages they often rely on their own libraries. To be
sure, run 'ldd' on src/su and confirm that it only uses system
libraries (if it uses others, they will probably be marked as 'not
found' if shadow isn't installed - I'm assuming you are already in
chroot, so system libs will be in /tools apart from the vdso).
> Alternatively, I have a question about how to use . The
> following is part of the output from <./install-sh --help>:
>
> > Usage: ./install-sh [OPTION]... [-T] SRCFILE DSTFILE
> >or: ./install-sh [OPTION]... SRCFILES... DIRECTORY
> >or: ./install-sh [OPTION]... -t DIRECTORY SRCFILES...
> >or: ./install-sh [OPTION]... -d DIRECTORIES...
> >
> > In the 1st form, copy SRCFILE to DSTFILE.
> > In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
> > In the 4th, create DIRECTORIES.
>
> The way I see this is that I'll get what I want if I run su /tools/bin>
> Is this correct? Of course, I'm back to the copy mode if I can't
> install this as user lfs. I do not want it suid.
>
Without looking at the Makefile(s), I'm reluctant to assume that
'make install' will do the same thing as ./install-sh. Perhaps it
does.
The usual way to look at what gets installed is to run 'make
DESTDIR=/path/to/somewhere install [ optional args ]' - once you get
into DESTDIR installs for looking at what is installed you will find
some packages use other variables (often INSTALLROOT or something
like that) - if shadow is such a package,then running *as a user*
will fail. So try it as a user, to a directory which that user can
write to.
If/when it is installed there, use ldd to confirm that it doesn't
need any not-present libraries.
But two more comments:
First, why not use --prefix=/tools when you configure it ?
Second, ISTR that su is a problem. My notes show that I tested the
code from
http://wiki.linuxfromscratch.org/hints/browser/trunk/PREVIOUS_FORMAT/more_control_and_pkg_man.txt?rev=904
last September (Bryan pointed to it last year, and I was
experimenting with building as a user to do DESTDIR LFS installs (so
I could log the files without accidentally doing a real install if
the package didn't respect DESTDIR - e.g. glibc uses INSTALLROOT or
similar). That didn't work for me (segfaulted when run as a user).
I perhaps tried su from the last version of coreutils - I'm not
sure. In the end, for BLFS I went through sudo (PITA, no added
security IMHO) and then found a (slow, voluminous) way of logging
all the files at the start of a package and after it completed, and
from that noting what got installed and what was updated -
My method still gives me erroneous 'updated' files if the first
attempt to install fails (usually from fubars in my scripts, e.g.
hard-coded filenames/versions - static libs, usually - getting
renamed or deleted) - but then anyone who writes scripts needs to
expect failures, and to learn *how* their own scripts fail : I'
Re: [lfs-support] GCC specs file contains reference to /lib/ld-linux.so on a 64 bits machine
On Fri, Oct 04, 2013 at 11:15:30PM +0200, Afshin wrote: > Hi LFS Team > > I've read in the LFS book v7.4 at the section “6.10. Adjusting the > Toolchain” that is a good idea to visually inspect the GCC specs file > and that's what I did. I've noticed that there are 2 references > to /lib/ld-linux.so even if I'm using a 64 bits machine. So I replaced > them by /lib64/ld-linux-x86-64.so.2. Am I wrong or there is really a > mistake somewhere or maybe I made something wrong during the > construction of the temporary system? > /lib64/ld-linux-x86-64.so.2 is correct. ISTR that the book has a note that the filename may vary, but I'm not going to look up the details - I've already misled one person this week :) > Generally do you have any feedback on the building of LFS on a 64 bits > machine? Before upgrading to the 7.4 I was using LFS 6.4 on a 32 bits > machine and had no such a problem. > I've been using 64-bit on LFS since before it was officially supported. In the early days, a few BLFS packages such as jpegsrc.v6b (sic) got confused and required their config files (e.g. config.guess) to be updated. Other occasional packages such as popt insisted on using /usr/lib64 instead of /usr/lib. Everything was solveable. The current LFS method of symlinking /lib64 to /lib isn't as pure or clean, but it works ok. > I read somewhere that using ldconfig is not recommended but I was > obliged to use it to go ahead as I was stuck for 2 days on the > compilation of the package file (problem to find the shared library > libz). > What do you mean by "the package file" ? Anyway, that sounds as if you made a mistake in installing libz : libz.so.1.2.8 should end up in /lib, with a symlink from /lib/libz.so.1 and another from /usr/lib/libz.so. This is a difference between 32-bit i686 and 64-bit : the static libz.a cannot be used in a shared 64-bit library, so the link fails if a shared libz isn't found. In 32-bit the link with libz.a will succeed, which might not be what you want. > I use Debian 7 (wheezy) installed in a Vmware fusion VM which is in turn > installed on an Apple iMac. Maybe glibc/gcc are too recent on my > machine to build the temporary system... > > Best Regards > Afshin > LOL. A debian release "too recent". After picking myself up from the floor, I suggest that building in a vm, and indeed using that hardware [ broken UEFI implementations have been noted on the kernel list, and each new version seems to bring problems with HID devices not being recognized by the kernel, until someone adds the fix ] are more likely to cause problems. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.17. GCC-4.8.1 - Linker search paths
On Mon, Sep 30, 2013 at 11:52:07PM -0500, Bruce Dubbs wrote: > > It can match if there is more than one SEARCH entry on the line. See below. > You are right, of course. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.17. GCC-4.8.1 - Linker search paths
On Tue, Oct 01, 2013 at 04:41:28PM +1300, Craig Magee wrote:
> On 1 October 2013 16:09, Ken Moffat wrote:
>
> > On Tue, Oct 01, 2013 at 03:27:22PM +1300, Craig Magee wrote:
> > > However, grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' returns only:
> > > SEARCH_DIR("/usr/lib")
> > > SEARCH_DIR("/lib");
> > >
> > > while the book tells me to expect:
> > > SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64")
> > > SEARCH_DIR("/usr/local/lib64")
> > > SEARCH_DIR("/lib64")
> > > SEARCH_DIR("/usr/lib64")
> > > SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib")
> > > SEARCH_DIR("/usr/local/lib")
> > > SEARCH_DIR("/lib")
> > > SEARCH_DIR("/usr/lib");
> > >
> > > Any advice on where I went wrong would be greatly appreciated.
> > >
> > > Thanks.
> >
> > Does the book tell you to expect that ? My local copy of 7.4 says
> > that your results are correct. I think you might have been looking
> > at a different version of the book, or a different page, along the
> > way. In particular, that grep for '.*/usr/lib' cannot possibly match
> > '/usr/x86_64-unknown-linux-gnu/lib'.
> >
>
> Ah, I didn't think to take the time decoding the regular expression as they
> confuse the heck out of me. I copypasta'd it.
>
> http://www.linuxfromscratch.org/lfs/view/stable/chapter06/gcc.html
> It definitely states the block of text I quoted.
>
> Would the expected output listed for i686 systems also be incorrect?
> SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/local/lib")
> SEARCH_DIR("/lib")
> SEARCH_DIR("/usr/lib");
Ah, I was looking at 6.10 (Adjusting the toolchain), not 6.17.
Interesting. In my logs I keep the actual output from dummy.log
and that does have all of those. But I don't see how that (same)
regexp can possibly return the first two results that we show.
OTOH, I'm hours past my bedtime, maybe I'm missing something
obvious. I'll defer to Matt or Bruce if they comment in the next
few hours. At the moment it looks like such an obvious fubar that I
would expect _someone_ to have noticed it, so I guess I'm probably
out on my own again and leading you astray ;-)
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] 6.17. GCC-4.8.1 - Linker search paths
On Tue, Oct 01, 2013 at 03:27:22PM +1300, Craig Magee wrote:
> High folks,
>
> I'm building 7.4 Stable in 64-bit.
> GCC compiled, checked, and installed. The dummy file compiles. Tests show
> search paths for correct places for header files.
>
> However, grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' returns only:
> SEARCH_DIR("/usr/lib")
> SEARCH_DIR("/lib");
>
> while the book tells me to expect:
> SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64")
> SEARCH_DIR("/usr/local/lib64")
> SEARCH_DIR("/lib64")
> SEARCH_DIR("/usr/lib64")
> SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib")
> SEARCH_DIR("/usr/local/lib")
> SEARCH_DIR("/lib")
> SEARCH_DIR("/usr/lib");
>
> Any advice on where I went wrong would be greatly appreciated.
>
> Thanks.
Does the book tell you to expect that ? My local copy of 7.4 says
that your results are correct. I think you might have been looking
at a different version of the book, or a different page, along the
way. In particular, that grep for '.*/usr/lib' cannot possibly match
'/usr/x86_64-unknown-linux-gnu/lib'.
I'm looking at 6.10 - are you looking at a different page ?
ĸen, still up, and apparently making off-topic progress using an
*old* bootloader version on ppc with LFS-7.4 :-)
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Boot Issues
On Thu, Sep 26, 2013 at 05:43:51PM -0400, Casey Daniels wrote: > Thanks for the info, > but followed the instructions and as usual I get the grub rescue > prompt which is a total different issue and question. > > But I tried what I have been trying to get the normal boot menu up > > set prefix(hd0,??) > insmod normal > normal > > now its saying no such partition. > I ls at the rescue prompt and it shows the (HD0) but it gives no > partitions to go along with it. > Please don't top post, we hate it. You said this was variously a thumb drive and an SD card (you had a different issue with the real disk). You also said that you created an MSDOS partition table, but did you also create partitions, or are you trying to use the whole of /dev/sdX as a single filesystem ? If you do have partitions, then grub _might_ work with insmod ext2 set root='(hd0,msdosN)' where N is the partition number containing /boot - and presumably if /boot isn't a separate partition you would need to point to /boot/vmlinuz-whichever instead of just vmlinuz (dunno, I always have a separate /boot partition on my x86 machines). That _might_ be enough to solve the grub side of the problem, but you will still need to do something to let the kernel find the filesystem whichever "disk" it appears as (typically, use an initramfs, I believe). Just in case this isn't clear, the stick or external drive might be /dev/sdb or /dev/sdc at the moment, but it could shouw up as /dev/sda even if there is a "real" disk currently there, it all depends on which appears first and the order is unreliable across different kernels / different configs. So the intramfs has to contain enough of a system to then be able to mount the stick or external drive, e.g. by UUID (generally, the kernel doesn't understand UUIDs although the situation on GPT drives is, I think, slightly different). But I don't have experience in booting from removable drives/sticks. I suggest that you change your plans: 1. Get it to boot on the spinning-rust /dev/sda. That will allow you to prove that the completed system is usable. If you can't get this to work, please report the error(s) in detail, along with your partitioning. You WILL also need a rescue CD in case things become broken. 2. Study the various posts which google finds about booting to a removable disk / memory stick. There are a number of different (and probably incompatible) solutions. In particular, look at the 'About initramfs' page in BLFS : http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html although that doesn't specifically talk about booting from external usb drives. http://www.linuxquestions.org/questions/linux-from-scratch-13/booting-lfs-from-usb-stick-897465/ might have something useful in it (for the grub suggestions). There have been many threads here over the years, but the mail archives aren't available so I can no longer point you to them. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] chroot into the temporary ...?
On Wed, Sep 25, 2013 at 08:41:37AM +0800, 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', Why do you think that 'sudo' is the command to run here ? Do we build sudo in chapter 5 (/tools) ? > 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. Apart from using sudo instead of su, why doesn't /bin/bash exist in /mnt/lfs ? If you are following the book, we create the /mnt/lfs/bin/bash symlink in section 6.6 - and we enter chroot *after* that, not in section 6.1. I'm sure that reading the book is *hard* for people who don't have English as a native language, but you seem to be making false assumptions about what the book says. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Man Pages and Man-DB
On Sun, Sep 22, 2013 at 09:38:04PM -0400, Casey Daniels wrote: > I think I know the answer, but searched a bit and couldn't find a direct > answer, but would there be any situation someone can think of where not > installing Man-Pages (6.8) and Man-DB (6.56) could cause problems? > > Looked through the dependices for the Base LFS system and didn't see any > issues, but I'm guessing there is some package somewhere that I'll ended > up wanting to install that requires it. The system I'm making really > doesn't have any need for Man Pages since its a server that no one > really should be logged directly on it. > > Thank You > AFAICS things should be fine without them. For a server, the usual reason to have them is probably to help with debugging the setup. Many packages install a few man pages of their own, but that doesn't mean you have to read them. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
