Re: Ready for LFS-6.2-pre2?
Bruce Dubbs wrote: All outstanding tickets and other issues that I know of have been made to the lfs-6.2 branch: svn co svn://linuxfromscratch.org/LFS/branches/6.2/BOOK If there are no other issues, I will release lfs-6.2-pre2 tomorrow (Saturday, July 22), probably early evening. Good! However, I have a little problem with the LiveCD. The problem is that no bugs for x86 were reported to livecd@linuxfromscratch.org since May 17, 2006. This means that the final 6.2 CD will be as buggy as -pre5. This also means that the FIXME about NVIDIA and hibernation in the README file will stay as-is. There were indeed some feature requests on IRC and ICQ, such as: * Please include sound support, speakup kernel patch and the "festival" speech synth engine, for blind people (will be dealt post-6.2) * The CD contains a lot of crap! (post-6.2, there will be two CDs, one like the current one or even more bloated, and one very minimalistic, even without non-US keyboard/language support). * Please include xine! (that appeared after I shared my plans via ICQ to include sound support for festival, and this WILL be dealt with after 6.2, in the full version of the CD only) * Please include synaptic touchpad driver (already fixed, will be on 6.2) but I prefer to see testing reports and fixes instead. This mail is the last call for such reports. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Success with CLFS-2.0 on ARM
Hello, the CLFS-2.0 book is almost good: it produces a system bootable in qemu with only minimal deviations, documented below. Screenshot is attached. One can repeat the steps in the book and below and reproduce the screenshot even without actually having an ARM board. Deviations: 1) When building Glibc, don't install locales. It's just impossibble now. 2) When building Shadow, don't run pwconv and grpconv, and don't set root password. 3) Use the attached kernel config (sorry, for old version of linux). Put boot/arm/zImage into /mnt/clfs/boot 4) After installing clfs bootscripts, remove /mnt/clfs/etc/rc.d/rcsysinit.d/S60setclock: ARM boards don't have RTC, and qemu just hangs if the setclock script is being run. The result is the complete ARM system under /mnt/clfs. How to test without a real ARM board: 1) Install X window system, SDL and nfs-utils. 2) Install gcc-3.4 and qemu from http://fabrice.bellard.free.fr/qemu/download.html (./configure --cc=gcc-3.4). Alternatively, if you don't want gcc-3.4, install the precompiled version of qemu from the same page. 3) Remount /mnt/clfs with the "noexec" option in order to avoid creating a root hole in the next step. 4) Export /mnt/clfs in /etc/exports as: /mnt/clfs 127.0.0.1(rw,no_root_squash,insecure,async) 5) Run qemu as: qemu-system-arm -kernel /mnt/clfs/boot/zImage -append "root=/dev/nfs nfsroot=10.0.2.2:/mnt/clfs,tcp,v3 ip=10.0.2.15:10.0.2.2:10.0.2.2:255.255.255.0:lfs:eth0:off" (the IP addresses are hard-coded in qemu, don't change them, they work). 6) Log in as root without password, run pwconv && grpconv && passwd root, generate your locale with localedef. 7) Try running other programs installed as a part of CLFS. Report bugs. -- Alexander E. Patrakov config.gz Description: application/gzip -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ntp nitpick
On Wednesday 12 July 2006 07:26, Nathan Coulson wrote: >... >>ntp-stable-4.2.0a-20060224.tar.gz.md5 >... why not using 4.2.2 ? Is there a technical showstopper? Thomas ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
I'm afraid this user error will become a FAQ
IRC log illustrating the problem is pasted below. (20:28:38) Tizer: Hi patrakov (20:28:46) patrakov: Hello Tizer (20:28:46) Tizer: networking woes... (20:28:50) ***Joe|afk wakes (20:28:51) Joe|afk: hi patrakov (20:28:54) Joe|afk теперь известен как Joe (20:28:57) patrakov: Hello Joe. (20:29:08) Tizer: Interface eth0 doesn't exist... why not? (20:29:23) patrakov: module not loaded (20:29:41) Tizer: it is configured in the kernel (20:30:07) patrakov: Tizer: which book? (20:30:16) Tizer: lfs-6.2 (20:30:32) patrakov: Did you create udev rule for your network card? (20:30:41) patrakov: If so, please paste it. (20:31:10) Tizer: ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID==":00:0d.0", NAME="sis900" (20:31:21) patrakov: then there will never be "eth0" (20:31:27) patrakov: there will be "sis900" (20:31:40) patrakov: and, are you sure about the ID? (20:32:40) patrakov: BTW, could you please suggest textual improvement to the book, so that it is 100% clear that the network interface gets renamed, and eth0 doesn't exist anymore? (20:33:18) Tizer: the examples had realtek and intel as the NAME (20:34:46) patrakov: you can use any name as long as you use it consistently. If that name is not "eth0", there will be no "eth0" at all. (20:35:14) Joe: patrakov, i'd exepct it after 1.0.0 is released (20:35:39) patrakov: Joe: expect what? (20:35:49) Joe: patrakov BTW, could you please suggest textual improvement to the book, so that it is 100% clear that the network interface gets renamed, and eth0 doesn't exist anymore? (20:36:44) ***Joe read that wrong the first time (20:37:04) patrakov: Joe: that was addressed to Tizer. My own opinion is that I can't improve the existing LFS text, because I wrote it, and I cannot be good at criticizing my own text (20:37:15) Tizer: so if I rename ifconfig.eth0 to ifconfig.sis900 (20:37:22) Joe: Tizer, yea (20:37:41) patrakov: What I am afraid of is that this becomes a FAQ :( (20:37:58) Joe: that wouldn't do any good (20:38:35) patrakov: that's why I think that the text has to be rewritten. (20:39:14) Tizer: ch 7.13.2 needs amending to the name used in the first section (20:39:45) Joe: i'll go read it as soon as i get back, probably in a half hour or so (20:39:51) Tizer: The following command creates a sample ipv4 file for the realtek device devised above (as an example). (20:40:01) Tizer: suggested change (20:41:03) patrakov: OK. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
GRUB disk geometry not listed in chapter 3 in LFS 6.2
The "Needed Patches" page does not list the GRUB Disk Geometry patch, as I found out when attempting to use jhalfs to build LFS 6.2. It needs to be added. Index: branches/6.2/BOOK/chapter03/patches.xml === --- branches/6.2/BOOK/chapter03/patches.xml (revision 7695) +++ branches/6.2/BOOK/chapter03/patches.xml (working copy) @@ -83,6 +83,14 @@ + GRUB Disk Geometry Patch - &grub-geometry-patch-size;: + +Download: +MD5 sum: &grub-geometry-patch-md5; + + + + Gawk Segfault Patch - &gawk-segfault-patch-size;: Download: -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Linux 2.6.16.27 UTF-8 patch does not exist
The book just updated to linux-2.6.16.27, but there is currently no UTF-8 patch for that kernel in the patches repo. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: bash patch in chapter 5
Forget it. I completely overlooked that the list_package functionality that is broken by the bash bug requires man, which is not available until after bash is rebuilt. So while applying the patch in chapter 5 would fix the swarm of error messages, it would not actually enable the functionality. Sorry for bothering you. MSB -- Bad comments reveal the bad programmer. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: I'm afraid this user error will become a FAQ
Alexander E. Patrakov wrote:
> (20:29:08) Tizer: Interface eth0 doesn't exist... why not?
Here's what we have today:
> These rules will always rename the network cards to "realtek" and
> "intel", independently of the original numbering provided by the
> kernel (i.e.: the original "eth0" and "eth1" interfaces will no
> longer exist, unless you put such "descriptive" names in the NAME
> key). Use the descriptive names from the Udev rules instead of "eth0"
> in the network interface configuration files below.
Perhaps we could say "naming" instead of "numbering" ("independently of
the original naming provided by the kernel")?
> (20:39:14) Tizer: ch 7.13.2 needs amending to the name used in the
> first section
Oh, that makes more sense.
Well, how about this then. Recent udev versions (I think udev-095) can
handle renaming to eth0/eth1/whatever, because if the name is currently
in use, it'll rename it to something else, and then wait until the real
target name is *not* in use. Older versions would fail if the kernel
assigned eth0 to one device and eth1 to another, then udev tried to swap
the names -- both renames would fail because the target device name
already existed. But recent udevs will use a temporary name, then
sleep, then try again, until they succeed.
This means we can tell the user to create a stable rule, but they can
choose which device is eth0, which is eth1, etc. So I'd suggest keeping
most of the text in 7.13.1, up until right after the "grep -H" that
finds the MAC addresses. Then, something like:
> For each network card (but not for the loopback interface), decide
> which eth* name to give it (eth0, eth1, etc.). Then create Udev
> rules similar to the following:
> cat > /etc/udev/rules.d/26-network.rules << "EOF"
> ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
> SYSFS{address}=="00:e0:4c:12:34:56", NAME="eth0"
> ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
> SYSFS{address}=="00:a0:c9:78:9a:bc", NAME="eth1"
> EOF
(With the appropriate lack of word-wrapping, of course.)
Then we should use the same names in the by-ID rules given below that,
and also fix the paragraph following. Something like:
> These rules will always name the network cards "eth0" and "eth1",
> independently of the (unpredictable) numbering provided by the
> kernel.
Sound good?
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: GRUB disk geometry not listed in chapter 3 in LFS 6.2
Chris Staub wrote: > The "Needed Patches" page does not list the GRUB Disk Geometry patch, as > I found out when attempting to use jhalfs to build LFS 6.2. It needs to > be added. > Indeed. Thanks. Fixed. Note: GRUB comes after Gawk (and Groff). I had to commit this twice myself to get it right. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: bash patch in chapter 5
Matthias B. wrote: > Forget it. I completely overlooked that the list_package functionality > that is broken by the bash bug requires man, which is not available until > after bash is rebuilt. So while applying the patch in chapter 5 would fix > the swarm of error messages, it would not actually enable the > functionality. Sorry for bothering you. Too late. I already made the fix. :) -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux 2.6.16.27 UTF-8 patch does not exist
Chris Staub wrote: > The book just updated to linux-2.6.16.27, but there is currently no > UTF-8 patch for that kernel in the patches repo. Thanks. Fixed in the patches repo as well as the 6.2 download area. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Stability and debugging
On July 22, 2006 03:56 pm, Declan Moriarty wrote: > These sort of results question the whole business of compiling from > scratch. I have gathered this much > > 1. Compiling new versions (particularly gcc-4.1x) the way LFS does it is > somewhere between a major PITA and impossible. I'm not sure what you mean by this. From what I can see gcc-4.1 a drop in replacement for the gcc-4.0 compiler already in lfs-svn, except with newer dependencies. > 2. I sense a lessening confidence in the quality of the toolchain among > the guys who should know here and that frankly undermines the whole > system. Again, I don't know what you mean by this. The gcc's keep getting better, more strict, and have better options. > 3. The predictability of results on the range lfs ideally wants to cover > ix86 32bit & 64 bit, amd & intel, and ideally ppc, sparc, etc. is > lessening with advances in complexity. Introducing valgrind will add > noticeably to times. 200 SBUs is enough to frighten anyone off. The valgrind tests are intended for gcc developers, not really for the majority of people. Someone who modifies gcc would fall under "gcc developer". > Others with deeper knowhow could no doubt add to this. > > Given the above, is there not a strong argument for this approach: > Alter the content of a release. Make it a book and the appropiate > tarball containing a prebuilt toolchain. > > The process would then be one of either > 1. Build your own toolchain with slightly different options if you were > going somewhere odd with your particular system or > 2. Use the tarball as the final toolchain, and build the system > Valgrind could then be compiled once, and then distributed. There would > be no need for a static build, the educational function of which is near > zero anyhow. Anyone who deviates one iota from the book in chapter 5 is > screwed, so the whole idea of compiling 'for choice of options' is gone. There are ways to modify chapter 5. NLS can be disabled. Elfutils could be used to replace Binutils. You can leave out ncurses and texinfo. And with hlfs you can chose to enable one security option and not another. robert pgpG81pUNccIS.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: lfs-2.6-pre1 test report
The first time i built ncurses-5.5 tic complained about some unresolved symbols. I built ncurses-5.5 again (this time on LFS-6.2-pre1), and tic doesn't complain anymore, maybe i did something that caused the problem, or maybe the problem is related to the host. I will try to recreate the problem with an LFS-6.1.1 host. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS 6.2-pre2 Released
The Linux From Scratch community is pleased to announce the second pre-release of LFS 6.2. This release provides several updated to the -pre1 release. It includes several minor textual changes and updates patches to vim and grub. It also includes an update to Linix-2.6.16.27. This being a test release, we would appreciate you taking the time to try it out and report any bugs you find in it to the LFS development team at [EMAIL PROTECTED] Bruce Dubbs LFS 6.2 Release Manager -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: I'm afraid this user error will become a FAQ
Bryan Kadzban wrote:
Alexander E. Patrakov wrote:
(20:29:08) Tizer: Interface eth0 doesn't exist... why not?
Here's what we have today:
These rules will always rename the network cards to "realtek" and
"intel", independently of the original numbering provided by the
kernel (i.e.: the original "eth0" and "eth1" interfaces will no
longer exist, unless you put such "descriptive" names in the NAME
key). Use the descriptive names from the Udev rules instead of "eth0"
in the network interface configuration files below.
Perhaps we could say "naming" instead of "numbering" ("independently of
the original naming provided by the kernel")?
(20:39:14) Tizer: ch 7.13.2 needs amending to the name used in the
first section
Oh, that makes more sense.
Well, how about this then. Recent udev versions (I think udev-095) can
handle renaming to eth0/eth1/whatever, because if the name is currently
in use, it'll rename it to something else, and then wait until the real
target name is *not* in use. Older versions would fail if the kernel
assigned eth0 to one device and eth1 to another, then udev tried to swap
the names -- both renames would fail because the target device name
already existed. But recent udevs will use a temporary name, then
sleep, then try again, until they succeed.
This means we can tell the user to create a stable rule, but they can
choose which device is eth0, which is eth1, etc. So I'd suggest keeping
most of the text in 7.13.1, up until right after the "grep -H" that
finds the MAC addresses. Then, something like:
For each network card (but not for the loopback interface), decide
which eth* name to give it (eth0, eth1, etc.). Then create Udev
rules similar to the following:
cat > /etc/udev/rules.d/26-network.rules << "EOF"
ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
SYSFS{address}=="00:e0:4c:12:34:56", NAME="eth0"
ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
SYSFS{address}=="00:a0:c9:78:9a:bc", NAME="eth1"
EOF
(With the appropriate lack of word-wrapping, of course.)
Then we should use the same names in the by-ID rules given below that,
and also fix the paragraph following. Something like:
These rules will always name the network cards "eth0" and "eth1",
independently of the (unpredictable) numbering provided by the
kernel.
Sound good?
Good, if we append this:
Instead of "eth0" and "eth1", you can use descriptive names of
your own choice, like "realtek" and "intel". If you do this, remember
to use your interface names everywhere, since the "eth0" and "eth1"
interfaces will not exist in this case.
One more issue is with Atheros wi-fi driver: it reportedly creates two
interfaces with identical MAC addresses, and our rules go crazy. Since I
don't have the corresponding hardware, I can't offer a working solution.
Exactly because of this pile of solved and unsolved nuisances that ruin
the whole idea of proper hardware autodetection, I think that LFS-6.3
should go without udev. For now, I think we should at least mention a
problem.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Adjusting toolchain
Hi. Sorry if this has been discused before. Rather than: SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs && gcc -dumpspecs > $SPECFILE && sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' $SPECFILE > tempspecfile && mv -vf tempspecfile $SPECFILE && unset SPECFILE I find it cleaner and easier to read: gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \ > `dirname $(gcc -print-libgcc-file-name)`/specs The result is exactly the same. robert pgpg43VGw3Gl7.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GRUB disk geometry not listed in chapter 3 in LFS 6.2
Bruce Dubbs wrote: Note: GRUB comes after Gawk (and Groff). I had to commit this twice myself to get it right. -- Bruce But in the build order, GRUB is built before either of those. It is listed first (among the Gs) because it is actually an acronym. Not really a big deal to me either way, I'm just looking for consistency. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: I'm afraid this user error will become a FAQ
Alexander E. Patrakov wrote: > One more issue is with Atheros wi-fi driver: it reportedly creates two > interfaces with identical MAC addresses, and our rules go crazy. Since I > don't have the corresponding hardware, I can't offer a working solution. I have the hardware, but I don't use it that often. What do I need to do to check the problem/solution. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adjusting toolchain
Robert Connolly wrote: > Hi. Sorry if this has been discused before. Rather than: > > SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs && > gcc -dumpspecs > $SPECFILE && > sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' $SPECFILE > tempspecfile > && > mv -vf tempspecfile $SPECFILE && > unset SPECFILE > > I find it cleaner and easier to read: > > gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \ > > `dirname $(gcc -print-libgcc-file-name)`/specs > > The result is exactly the same. I think you are right. I don't want to put this into 6.2 as the present instructions do work. It is a good suggestion for trunk. Can you create a ticket for this so we don't forget it? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GRUB disk geometry not listed in chapter 3 in LFS 6.2
Chris Staub wrote: > Bruce Dubbs wrote: >> Note: GRUB comes after Gawk (and Groff). I had to commit this twice >> myself to get it right. >> >> -- Bruce > > But in the build order, GRUB is built before either of those. It is > listed first (among the Gs) because it is actually an acronym. Not > really a big deal to me either way, I'm just looking for consistency. I know GRUB is a acronym and should be capitalized, but IMHO the sort order for these this should be case insensitive. Checking the book, we also have GCC as an acronym, but has an entry in the patches list in a case insensitive alpha order. I was just being consistent there. I don't think it should be changed for 6.2, but should we move GRUB down in chapter 6 to after groff for the trunk? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adjusting toolchain
On July 23, 2006 12:47 am, Bruce Dubbs wrote: > Can you create a ticket for this so we don't forget it? I'd like to, but my hlfs wiki login doesn't work for the lfs wiki, and I can't register at the lfs wiki because my login is already taken. I'd email jhuntwork except that he hasn't replied to my last email yet. Maybe someone else can help me fix this? robert pgpaZHqtkyOgW.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
