From diy-linux-dev@diy-linux.org Fri Aug 3 06:53:29 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 3 Aug 2007 16:53:29 +1000 Subject: latest grep-2.5.3 Message-ID: <20070803065329.GA18235@eyo32.local> Hi Guys, Just a headsup re latest release of grep-2.5.3 failing some tests. The failing tests are new tests relative to 2.5.1a and the failures appear to be expected by the upstream devs judging from this post in the archives: http://lists.gnu.org/archive/html/bug-grep/2006-03/msg00004.html See below for the failures. Regards Greg PASS: file.sh Testing: ../src/grep Word -o -i input: "WordA/wordB/WORDC/" output: "" expect: "Word/word/WORD/" FAIL Testing: ../src/grep WORD -o -i input: "WordA/wordB/WORDC/" output: "" expect: "Word/word/WORD/" FAIL Testing: ../src/grep Word --color=always -i input: "WordA/wordb/WORDC/" output: "WordA/wordb/WORDC/" expect: "WordA/wordb/WORDC/" FAIL Testing: ../src/grep WORD --color=always -i input: "WordA/wordb/WORDC/" output: "WordA/wordb/WORDC/" expect: "WordA/wordb/WORDC/" FAIL FAIL: foad1.sh SKIP: fmbtest.sh Test #11: { ../src/grep -F -n -b -m 5 -C 1 yes; echo "?$?"; sed 's!^!X!'; } output: "2-10-[B02 no ]/3:20:[C03 yes]/4:30:[D04 yes]/5:40:[E05 yes]/6-50-[F06 no ]/7-60-[G07 no ]/8:70:[H08 yes]/9:80:[I09 yes]/10-90-[J10 no ]/?0/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/" expect: "2-10-[B02 no ]/3:20:[C03 yes]/4:30:[D04 yes]/5:40:[E05 yes]/6-50-[F06 no ]/7-60-[G07 no ]/8:70:[H08 yes]/9:80:[I09 yes]/?0/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/" FAIL Test #27: { ../src/grep -F -n -b -m 2 -v -C 1 yes; echo "?$?"; sed 's!^!X!'; } output: "1:0:[A01 no ]/2:10:[B02 no ]/3-20-[C03 yes]/?0/X[C03 yes]/X[D04 yes]/X[E05 yes]/X[F06 no ]/X[G07 no ]/X[H08 yes]/X[I09 yes]/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/" expect: "1:0:[A01 no ]/2:10:[B02 no ]/?0/X[C03 yes]/X[D04 yes]/X[E05 yes]/X[F06 no ]/X[G07 no ]/X[H08 yes]/X[I09 yes]/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/" FAIL Test #28: { ../src/grep -F -n -b -m 2 -v -C 1 -o yes; echo "?$?"; sed 's!^!X!'; } output: "3-25-yes/?0/X[C03 yes]/X[D04 yes]/X[E05 yes]/X[F06 no ]/X[G07 no ]/X[H08 yes]/X[I09 yes]/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/" expect: "?0/X[C03 yes]/X[D04 yes]/X[E05 yes]/X[F06 no ]/X[G07 no ]/X[H08 yes]/X[I09 yes]/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/" FAIL FAIL: yesno.sh ================================= 2 of 13 tests failed (1 tests were not run) Please report to bug-grep@gnu.org ================================= From diy-linux-dev@diy-linux.org Sat Aug 4 15:20:37 2007 From: diy-linux-dev@diy-linux.org (Alberto =?iso-8859-1?q?Trevi=F1o?=) Date: Sat, 4 Aug 2007 09:20:37 -0600 Subject: Status on Glibc 2.6.1 and friends Message-ID: <200708040920.37802.alberto@trevino.org> I saw that Greg posted changes upgrading to Glibc 2.6.1, GCC 4.2.1 and=20 Binutils 2.17.50.0.18. Now that the first revisions of these packages our= =20 out, I would like to know if it is safe to proceed and use them or if it is= =20 still rocky trying to build an entire system with them and I should stick=20 with Glibc 2.5, GCC 4.1, etc. Any tips will be appreciated. =2D-=20 Alberto Trevi=F1o alberto@trevino.org From diy-linux-dev@diy-linux.org Sun Aug 5 05:38:54 2007 From: diy-linux-dev@diy-linux.org (Jeremy Huntwork) Date: Sun, 05 Aug 2007 01:38:54 -0400 Subject: gcc pass 1 Message-ID: <46B5626E.5070902@linuxfromscratch.org> Hello Greg, After looking through your reference build and reading some of the linked threads, I have a question for you. You use --disable-shared on GCC Pass 1. I've read through the thread you pointed to when explaining the purpose of the libgcc_eh.a symlink. You provide a great deal of rationale there showing that making use of --disable-shared doesn't hinder your build and you can in fact still achieve a fully functional Glibc for the temporary tools. I understand how you are able to work around its limitations. What I would like to know more about is why --disable-shared is a good thing. You said, "I pass `--disable-shared' to GCC Pass 1 because it's simply the sanest thing to do when bootstrapping a new toolchain. Cross compilation techniques do same. IMHO it results in a more robust build method (less chance of things going wrong)." What sorts of things going wrong are you here trying to avoid? Is the goal simply to keep from pulling in unwanted symbols from the host for GCC's internal libs? Or is there more to it? Thanks, -- JH From diy-linux-dev@diy-linux.org Mon Aug 6 05:41:05 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 6 Aug 2007 15:41:05 +1000 Subject: Status on Glibc 2.6.1 and friends In-Reply-To: <200708040920.37802.alberto@trevino.org> References: <200708040920.37802.alberto@trevino.org> Message-ID: <20070806054105.GA16511@eyo32.local> On Sat, Aug 04, 2007 at 09:20:37AM -0600, Alberto Trevi=F1o wrote: > I saw that Greg posted changes upgrading to Glibc 2.6.1, GCC 4.2.1 and=20 > Binutils 2.17.50.0.18. Now that the first revisions of these packages = our=20 > out, I would like to know if it is safe to proceed and use them or if i= t is=20 > still rocky trying to build an entire system with them and I should sti= ck=20 > with Glibc 2.5, GCC 4.1, etc. It all seems fine here (at least on x86). But you'd be better off testing for yourself and reporting any problems. Regards Greg From diy-linux-dev@diy-linux.org Mon Aug 6 05:56:47 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 6 Aug 2007 15:56:47 +1000 Subject: gcc pass 1 In-Reply-To: <46B5626E.5070902@linuxfromscratch.org> References: <46B5626E.5070902@linuxfromscratch.org> Message-ID: <20070806055647.GA16540@eyo32.local> On Sun, Aug 05, 2007 at 01:38:54AM -0400, Jeremy Huntwork wrote: > What I would like to know more about is why --disable-shared is a good > thing. You said, "I pass `--disable-shared' to GCC Pass 1 because it's > simply the sanest thing to do when bootstrapping a new toolchain. Cross > compilation techniques do same. IMHO it results in a more robust build > method (less chance of things going wrong)." > > What sorts of things going wrong are you here trying to avoid? It's really just the KISS principle. Building with `--disable-shared' results in a simpler compiler. Simpler means less problems at this critical stage of the build method, and it also means we can bootstrap from a wider range of hosts. I don't have any specifics for you, just anecdotal evidence after years of looking at this stuff ie: instictively I know it's the right thing to do. BTW, this relevant link was in the same thread you referred to: http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055262.html Regards Greg From diy-linux-dev@diy-linux.org Mon Aug 6 21:48:00 2007 From: diy-linux-dev@diy-linux.org (Jeremy Huntwork) Date: Mon, 06 Aug 2007 17:48:00 -0400 Subject: gcc pass 1 In-Reply-To: <20070806055647.GA16540@eyo32.local> References: <46B5626E.5070902@linuxfromscratch.org> <20070806055647.GA16540@eyo32.local> Message-ID: <46B79710.8050507@linuxfromscratch.org> Greg Schafer wrote: > It's really just the KISS principle. Building with `--disable-shared' > results in a simpler compiler. Simpler means less problems at this critical > stage of the build method, and it also means we can bootstrap from a wider > range of hosts. I don't have any specifics for you, just anecdotal evidence > after years of looking at this stuff ie: instictively I know it's the right > thing to do. BTW, this relevant link was in the same thread you referred to: > > http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055262.html Thanks for the explanation. There's a lot of things that have 'clicked' over the last few weeks, I appreciate the help. It's a shame that no one ever properly replied to Alex's request. I vaguely remember it, but I was probably more preoccupied with other things at the time; and I'm sure I didn't understand the toolchain issues then half as well as I do now. There's still lots to learn... Perhaps after 6.3 is released, I'll ping that thread again on the list. As an aside, you might be interested to know that I'm trying your build method on my Sun Netra. It's an ultrasparc IIi (sparc64). So far it's moving along nicely, the only things I've had to adapt is adding '-mcpu=ultrasparc -mtune=ultrasparc' anywhere you set CFLAGS or related variables. Still too early to tell exactly what the outcome will be, and the 450Mhz processor crawls, but I'll keep you informed of the progress, if you're interested. -- JH From diy-linux-dev@diy-linux.org Mon Aug 6 23:41:20 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 7 Aug 2007 09:41:20 +1000 Subject: PPC build on "current" In-Reply-To: <9cf823c60707231451k79c22ecbt3d3d6662e6732dbb@mail.gmail.com> References: <9cf823c60707231451k79c22ecbt3d3d6662e6732dbb@mail.gmail.com> Message-ID: <20070806234120.GA32024@eyo32.local> On Mon, Jul 23, 2007 at 05:51:27PM -0400, Jon Grosshart wrote: > Hey all. Just a quick 411 on the PPC side using 4.2.1/2.5/2.17/2.6.22.1... > Hardly worth mentioning and takes about 5 seconds to realize a solution > but.... > > I'm appending -fgnu89-inline to glibc and coreutils else I get thousands of > C99 warnings. Jon, this was covered back here: http://www.diy-linux.org/pipermail/diy-linux-dev/2007-May/001029.html Essentially, it was decided that GCC-4.2 was best matched Glibc-2.6 ie: the combo you're using is not recommended according to the table here: http://www.diy-linux.org/reference-build/introduction.html#latest Regards Greg PS - I've cranked up the mac mini again and am attempting to get all the ppc builds verified, including the GCC42/GLIBC26 combo. One oddity - all builds are showing 1 failure in the e2fsprogs testsuite that I don't see on x86. From diy-linux-dev@diy-linux.org Mon Aug 6 23:55:13 2007 From: diy-linux-dev@diy-linux.org (Alf mel) Date: Mon, 6 Aug 2007 17:55:13 -0600 Subject: Status on Glibc 2.6.1 and friends In-Reply-To: <20070806054105.GA16511@eyo32.local> References: <200708040920.37802.alberto@trevino.org> <20070806054105.GA16511@eyo32.local> Message-ID: <200708061755.13670.alf@mypals.org> On Sunday 05 August 2007 11:41:05 pm Greg Schafer wrote: > It all seems fine here (at least on x86). But you'd be better off testing > for yourself and reporting any problems. I remember Glibc 2.6 had a bug that had to be immediately patched. I'll try it and see how it goes. -- @ - Alf From diy-linux-dev@diy-linux.org Tue Aug 7 00:23:03 2007 From: diy-linux-dev@diy-linux.org (Jon Grosshart) Date: Mon, 6 Aug 2007 20:23:03 -0400 Subject: PPC build on "current" In-Reply-To: <20070806234120.GA32024@eyo32.local> References: <9cf823c60707231451k79c22ecbt3d3d6662e6732dbb@mail.gmail.com> <20070806234120.GA32024@eyo32.local> Message-ID: <9cf823c60708061723g4b9b822g3aa51d2ff29b37ea@mail.gmail.com> ------=_Part_73984_26268374.1186446183960 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/6/07, Greg Schafer wrote: > > > > Jon, this was covered back here: > > http://www.diy-linux.org/pipermail/diy-linux-dev/2007-May/001029.html Sorry bout that. Must not be getting all the mail cause I don't recognize it... I'll have to start scanning the archives. With the exception of glibc and coreutils above mentioned, I'm approaching the end of my 300 package regiment and it went off without a hitch... Getting... Tired.... Of..... Com... piling......... ------=_Part_73984_26268374.1186446183960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 8/6/07, Greg Schafer <gschafer@zip.com.au> wrote:


Jon, this was covered back here:

http://www.diy-linux.org/pipermail/diy-linux-dev/2007-May/001029.html


Sorry bout that. Must not be getting all the mail cause I don't recognize it... I'll have to start scanning the archives.

With the exception of glibc and coreutils above mentioned, I'm approaching the end of my 300 package regiment and it went off without a hitch...  Getting... Tired.... Of..... Com... piling.........


------=_Part_73984_26268374.1186446183960-- From diy-linux-dev@diy-linux.org Tue Aug 7 02:01:27 2007 From: diy-linux-dev@diy-linux.org (Jeremy Huntwork) Date: Mon, 06 Aug 2007 22:01:27 -0400 Subject: redhat 6.2 breakage Message-ID: <46B7D277.5000501@linuxfromscratch.org> Greg, I fired up am emulator (Parallels Desktop) running redhat 6.2 to get some more experience using your reference build. I'm building HJL binutils-2.17.50.0.18, gcc-4.2.1 and glibc-2.6.1. When I got to binutils pass 1, the build failed with a 'your system is missing makeinfo' error. Of course, it also says I should only need it if I modified any doc files, which I didn't - I didn't even touch the source files. Digging further I found that I did in fact have the provided texinfo rpm installed (version 4.0.5) and makeinfo was present in /usr/bin. I'm not very familiar with makeinfo, but the error message seemed to imply that the failure could also suggest an incompatible 'make'. So, I decided to build a temporary makeinfo from texinfo-4.9 and copied the makeinfo binary to /temptools/bin. That fixed it - binutils built as it should have. Just letting you know in case you haven't tested the latest versions on a rh6.2 machine. Of course, take this all with a grain of salt, too as I'm not scripting this build. You may want to confirm this for yourself. -- JH From diy-linux-dev@diy-linux.org Tue Aug 7 02:15:39 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 7 Aug 2007 12:15:39 +1000 Subject: redhat 6.2 breakage In-Reply-To: <46B7D277.5000501@linuxfromscratch.org> References: <46B7D277.5000501@linuxfromscratch.org> Message-ID: <20070807021539.GA3328@eyo32.local> On Mon, Aug 06, 2007 at 10:01:27PM -0400, Jeremy Huntwork wrote: > I fired up am emulator (Parallels Desktop) running redhat 6.2 to get > some more experience using your reference build. I'm building HJL > binutils-2.17.50.0.18, gcc-4.2.1 and glibc-2.6.1. When I got to binutils > pass 1, the build failed with a 'your system is missing makeinfo' error. > Of course, it also says I should only need it if I modified any doc > files, which I didn't - I didn't even touch the source files. I thought I was the only one silly enough to test from RH62 :-) But seriously, yes I'm aware of this issue and it's even mentioned briefly in the refbuild prereq's section which is yet to be written properly. The other thing I have to do on RH62 when using headers_install is install a "pass 0" of tar because my scripts have an issue when unpacking the kernel tarball. Regards Greg From diy-linux-dev@diy-linux.org Tue Aug 7 02:30:32 2007 From: diy-linux-dev@diy-linux.org (Jeremy Huntwork) Date: Mon, 06 Aug 2007 22:30:32 -0400 Subject: redhat 6.2 breakage In-Reply-To: <20070807021539.GA3328@eyo32.local> References: <46B7D277.5000501@linuxfromscratch.org> <20070807021539.GA3328@eyo32.local> Message-ID: <46B7D948.6060907@linuxfromscratch.org> Greg Schafer wrote: > I thought I was the only one silly enough to test from RH62 :-) I wanted to experience the joy at least once for myself. And a good emulator makes it almost painless. > But > seriously, yes I'm aware of this issue and it's even mentioned briefly in > the refbuild prereq's section which is yet to be written properly. The other > thing I have to do on RH62 when using headers_install is install a "pass 0" > of tar because my scripts have an issue when unpacking the kernel tarball. Ah yes. I see the three words in the prereqs section now. :-) What's the issue you're having with tar? Your scripts look like they do the right thing. -- JH From diy-linux-dev@diy-linux.org Tue Aug 7 03:08:55 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 7 Aug 2007 13:08:55 +1000 Subject: redhat 6.2 breakage In-Reply-To: <46B7D948.6060907@linuxfromscratch.org> References: <46B7D277.5000501@linuxfromscratch.org> <20070807021539.GA3328@eyo32.local> <46B7D948.6060907@linuxfromscratch.org> Message-ID: <20070807030855.GA6815@eyo32.local> On Mon, Aug 06, 2007 at 10:30:32PM -0400, Jeremy Huntwork wrote: > What's the issue you're having with tar? Your scripts look like they do > the right thing. I rely on the output of `bunzip2 -dc tarball 2>&1 | tar tf - | head -n 1' and unfortunately the older tar (1.13.17) likes to whine about the funky pax header that Linus seems to produce his kernel tarballs with: /bin/tar: pax_global_header: Unknown file type 'g', extracted as normal file I couldn't be arsed fixing my scripts for such a corner case hence the soft option of installing tar-pass0. Regards Greg From diy-linux-dev@diy-linux.org Fri Aug 24 01:23:08 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 24 Aug 2007 11:23:08 +1000 Subject: Call for Assistance - udev Message-ID: <20070824012308.GA18387@eyo32.local> Hi Guys, Up until now I've been mostly avoiding udev. I just couldn't stomach it. The constant breakage, the constant need to upgrade udev when upgrading a kernel, the utter silliness of not installing a default config that "just works", etc, etc. For example, on some not-that-old distros, just installing a new self-built latest kernel completely renders the thing unbootable due to (I believe) outdated udev. It's insane! Anyhoo, it seems the latest release (udev-115) finally installs something that looks like a sane default config. From the announcement: "The etc/udev/rules.d/ directory now contains a default set of basic udev rules. This initial version is the result of a rules file merge of Fedora and openSUSE. For these both distros only a few specific rules are left in their own file, named after the distro. Rules which are optionally installed, because they are only valid for a specific architecture, or rules for subsystems which are not always used are in etc/udev/packages/" I just don't have time at the moment to test it out. It would be very helpful if some kind soul who is familiar with udev could figure out what needs to be done to make this latest udev work in the DIY Refbuild context ie: I'd like to finally add udev to the Refbuild. I'll probably stick with makedev for the actual build of the chroot phase, (I still find the LFS bind mount thing quite unpleasant) but install udev at the end and ideally do whatever is needed to make it work. Thanks for any help. Regards Greg From diy-linux-dev@diy-linux.org Fri Aug 24 03:48:25 2007 From: diy-linux-dev@diy-linux.org (Alexander E. Patrakov) Date: Fri, 24 Aug 2007 09:48:25 +0600 Subject: Call for Assistance - udev In-Reply-To: <20070824012308.GA18387@eyo32.local> References: <20070824012308.GA18387@eyo32.local> Message-ID: <46CE5509.3050407@ums.usu.ru> Greg Schafer wrote: > I just don't have time at the moment to test it out. It would be very > helpful if some kind soul who is familiar with udev could figure out what > needs to be done to make this latest udev work in the DIY Refbuild context > ie: I'd like to finally add udev to the Refbuild. I'll probably stick with > makedev for the actual build of the chroot phase, (I still find the LFS bind > mount thing quite unpleasant) but install udev at the end and ideally do > whatever is needed to make it work. Thanks for any help. > I would still like udev to be optional. There are configurations (e.g. Xen) that are not so far from the reference build to make them completely unsupported, but need special quirks WRT network interfaces. None of my servers in USU have udev. Also, udev and bootscripts are closely tied to each other (things like mounting /proc, /sys, /dev, triggering uevents, remounting root read-write, copying generated rules, retriggering failed uevents should happen in the right order). Thus, it would be just insane to add udev and not bootscripts (or at least some words about them). I will help if we decide what to do with the bootscripts and how to deal with non-SysV inits. As for the LFS bind-mount thingy, it is indeed overkill. It is enough to create the following devices, directories and symlinks for a full LiveCD build: null, console, zero, ptmx, tty, random, urandom, fd, stdin, stdout, stderr, pts, shm, core. Then the reader can decide at the end, whether he wants to use udev or static /dev. -- Alexander E. Patrakov From diy-linux-dev@diy-linux.org Fri Aug 24 13:33:10 2007 From: diy-linux-dev@diy-linux.org (Alf mel) Date: Fri, 24 Aug 2007 07:33:10 -0600 Subject: Call for Assistance - udev In-Reply-To: <20070824012308.GA18387@eyo32.local> References: <20070824012308.GA18387@eyo32.local> Message-ID: <200708240733.10414.alf@mypals.org> On Thursday 23 August 2007 07:23:08 pm Greg Schafer wrote: > Up until now I've been mostly avoiding udev. I just couldn't stomach it. > The constant breakage, the constant need to upgrade udev when upgrading a > kernel, the utter silliness of not installing a default config that "just > works", etc, etc. I agree with you. I have used udev and it has been a pain. I have used udev and the LFS rules (based on Debian, I believe) plus a couple of rules of my own to make it work. However, I've had to stick to udev 102 because 103 and beyond would not set the correct CD-ROM/DVD permissions and symlinks. Sometime back (around the 101, 102 era) I was going to suggest that udev was becoming stable enough. I went to 105, had those problems, and I was glad I didn't suggest it. > Anyhoo, it seems the latest release (udev-115) finally installs something > that looks like a sane default config. Finally! I always wondered why they didn't have a set of rules that they could make sure worked from one release to the other. That has always been have the problem. > I just don't have time at the moment to test it out. It would be very > helpful if some kind soul who is familiar with udev could figure out what > needs to be done to make this latest udev work in the DIY Refbuild > context ie: I'd like to finally add udev to the Refbuild. I'm converting all my rules and scripts to the latest 2.6.1/4.2.1/2.17.50 stuff. I'd be glad to tryout the new udev. Unfortunately, I have a very busy weekend ahead of me. It will probably be until early next week that I could try it out. I may not be the first to report but I could provide another view. -- @ - Alf From diy-linux-dev@diy-linux.org Fri Aug 24 13:48:52 2007 From: diy-linux-dev@diy-linux.org (Alf mel) Date: Fri, 24 Aug 2007 07:48:52 -0600 Subject: Call for Assistance - udev In-Reply-To: <46CE5509.3050407@ums.usu.ru> References: <20070824012308.GA18387@eyo32.local> <46CE5509.3050407@ums.usu.ru> Message-ID: <200708240748.52455.alf@mypals.org> On Thursday 23 August 2007 09:48:25 pm Alexander E. Patrakov wrote: > I would still like udev to be optional. I agree. > Also, udev and bootscripts are > closely tied to each other (things like mounting /proc, /sys, /dev, > triggering uevents, remounting root read-write, copying generated rules, > retriggering failed uevents should happen in the right order). Thus, it > would be just insane to add udev and not bootscripts (or at least some > words about them). I will help if we decide what to do with the > bootscripts and how to deal with non-SysV inits. Perhaps it would be useful to come up with a "boot sequence description" that would list what things should be done and in what order. It wouldn't be actual scripts; just something that would talk about what a good boot sequence should do. One advantage from udev is the ability to probe for hardware. If the kernel is built with modules and with automatic module loading support, udev can probe for the hardware, load necessary modules, populate /dev and configure the devices. Another thing to remember is that udev does not have to use any kind of ram disk to work. That means device nodes could be permanently written to disk once and left alone. For servers this would be particularly useful since they hardly change their hardware configuration. > It is enough to > create the following devices, directories and symlinks for a full LiveCD > build: null, console, zero, ptmx, tty, random, urandom, fd, stdin, > stdout, stderr, pts, shm, core. Then the reader can decide at the end, > whether he wants to use udev or static /dev. You can also use /proc/partitions to build the device nodes for your disks and partitions. That's what my bootscripts do before they mount partitions. Once partitions are mounted, I run udev and have it find the remaining hardware and do its thing. -- @ - Alf From diy-linux-dev@diy-linux.org Fri Aug 24 18:14:33 2007 From: diy-linux-dev@diy-linux.org (Alexander E. Patrakov) Date: Sat, 25 Aug 2007 00:14:33 +0600 Subject: Call for Assistance - udev In-Reply-To: <20070824012308.GA18387@eyo32.local> References: <20070824012308.GA18387@eyo32.local> Message-ID: <46CF2009.6030709@ums.usu.ru> Greg Schafer wrote: > Anyhoo, it seems the latest release (udev-115) finally installs something > that looks like a sane default config. Do you really think this is sane? 1) Strange symlinks that never existed before: KERNEL=="null", SYMLINK+="XOR" KERNEL=="ram0", SYMLINK+="ramdisk" KERNEL=="ram1", SYMLINK+="ram" KERNEL=="lp[0-9]*", GROUP="lp" SYMLINK+="par%n" 2) Mismatch between /dev/random and /dev/urandom permissions: KERNEL=="...|random", MODE="0666" KERNEL=="urandom", MODE="0644" 3) Syntax errors (missing comma, extra quote) KERNEL=="lp[0-9]*", GROUP="lp" SYMLINK+="par%n" KERNEL=="ht[0-9]*|nht[0-9]*", GROUP="disk"" 4) persistent CD symlinks and network interface names are provided only by distro-specific rules -- Alexander E. Patrakov From diy-linux-dev@diy-linux.org Fri Aug 24 18:17:30 2007 From: diy-linux-dev@diy-linux.org (Alexander E. Patrakov) Date: Sat, 25 Aug 2007 00:17:30 +0600 Subject: Call for Assistance - udev In-Reply-To: <46CF2009.6030709@ums.usu.ru> References: <20070824012308.GA18387@eyo32.local> <46CF2009.6030709@ums.usu.ru> Message-ID: <46CF20BA.4010305@ums.usu.ru> I wrote: > 4) persistent CD symlinks and network interface names are provided only > by distro-specific rules > Scratch that - I should not be awake at night. The other objections still apply. -- Alexander E. Patrakov From diy-linux-dev@diy-linux.org Fri Aug 24 18:28:21 2007 From: diy-linux-dev@diy-linux.org (Kay Sievers) Date: Fri, 24 Aug 2007 20:28:21 +0200 Subject: Call for Assistance - udev In-Reply-To: <46CF2009.6030709@ums.usu.ru> References: <20070824012308.GA18387@eyo32.local> <46CF2009.6030709@ums.usu.ru> Message-ID: <3ae72650708241128j777f3438ta054c77b7d1dd328@mail.gmail.com> On 8/24/07, Alexander E. Patrakov wrote: > Greg Schafer wrote: > > Anyhoo, it seems the latest release (udev-115) finally installs something > > that looks like a sane default config. > > Do you really think this is sane? > > 1) Strange symlinks that never existed before: > KERNEL=="null", SYMLINK+="XOR" Old ancient stuff. Mentioned in linux/Documentation/devices.txt > KERNEL=="ram0", SYMLINK+="ramdisk" Recommended in devices.txt. > KERNEL=="ram1", SYMLINK+="ram" Don't know. > KERNEL=="lp[0-9]*", GROUP="lp" SYMLINK+="par%n" Don't know. > 2) Mismatch between /dev/random and /dev/urandom permissions: > KERNEL=="...|random", MODE="0666" > KERNEL=="urandom", MODE="0644" You can write to random to add entropy to the pool. I guess, you can't write to urandom. > 3) Syntax errors (missing comma, extra quote) > KERNEL=="lp[0-9]*", GROUP="lp" SYMLINK+="par%n" > KERNEL=="ht[0-9]*|nht[0-9]*", GROUP="disk"" I'll fix that now. Will probably just work though. :) Kay From diy-linux-dev@diy-linux.org Sat Aug 25 04:36:19 2007 From: diy-linux-dev@diy-linux.org (Alexander E. Patrakov) Date: Sat, 25 Aug 2007 10:36:19 +0600 Subject: Call for Assistance - udev In-Reply-To: <3ae72650708241128j777f3438ta054c77b7d1dd328@mail.gmail.com> References: <20070824012308.GA18387@eyo32.local> <46CF2009.6030709@ums.usu.ru> <3ae72650708241128j777f3438ta054c77b7d1dd328@mail.gmail.com> Message-ID: <46CFB1C3.8020300@ums.usu.ru> Kay Sievers wrote: > On 8/24/07, Alexander E. Patrakov wrote: > >> 2) Mismatch between /dev/random and /dev/urandom permissions: >> KERNEL=="...|random", MODE="0666" >> KERNEL=="urandom", MODE="0644" >> > > You can write to random to add entropy to the pool. I guess, you can't > write to urandom. > The drivers/char/random.c file says: const struct file_operations random_fops = { .read = random_read, .write = random_write, .poll = random_poll, .ioctl = random_ioctl, }; const struct file_operations urandom_fops = { .read = urandom_read, .write = random_write, .ioctl = random_ioctl, }; So there is no valid reason for this mismatch. -- Alexander E. Patrakov From diy-linux-dev@diy-linux.org Tue Aug 28 01:27:51 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 28 Aug 2007 11:27:51 +1000 Subject: util-linux-ng-2.13 Message-ID: <20070828012751.GA5557@eyo32.local> Hi Guys, Ok, the new "ng" util-linux is finally released. We're going to have to think this one through a little. We currently build `mount' in the temptools phase so we can mount the virtual file systems inside the chroot. This new version insists upon linking against blkid (e2fsprogs) or volume_id (udev) so we may have to add either one of those (or just the libs thereof) to the temptools phase. Alternatively, it might be possible to hack around the requiremnt (we don't actually need much functionality from the temporary `mount'). If you have any ideas or experiences re this new package then please share them. Regards Greg From diy-linux-dev@diy-linux.org Tue Aug 28 06:06:40 2007 From: diy-linux-dev@diy-linux.org (Alexander E. Patrakov) Date: Tue, 28 Aug 2007 12:06:40 +0600 Subject: util-linux-ng-2.13 In-Reply-To: <20070828012751.GA5557@eyo32.local> References: <20070828012751.GA5557@eyo32.local> Message-ID: <46D3BB70.6050204@ums.usu.ru> Greg Schafer wrote: > Hi Guys, > > Ok, the new "ng" util-linux is finally released. We're going to have to > think this one through a little. We currently build `mount' in the temptools > phase so we can mount the virtual file systems inside the chroot. This new > version insists upon linking against blkid (e2fsprogs) or volume_id (udev) > so we may have to add either one of those (or just the libs thereof) to the > temptools phase. Alternatively, it might be possible to hack around the > requiremnt (we don't actually need much functionality from the temporary > `mount'). If you have any ideas or experiences re this new package then > please share them. Is it possible to mount the virtual filesystems from outside the chroot, thus completely bypassing the need for temporary "mount" program? -- Alexander E. Patrakov From diy-linux-dev@diy-linux.org Tue Aug 28 06:54:17 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 28 Aug 2007 16:54:17 +1000 Subject: util-linux-ng-2.13 In-Reply-To: <46D3BB70.6050204@ums.usu.ru> References: <20070828012751.GA5557@eyo32.local> <46D3BB70.6050204@ums.usu.ru> Message-ID: <20070828065417.GA22514@eyo32.local> On Tue, Aug 28, 2007 at 12:06:40PM +0600, Alexander E. Patrakov wrote: > Is it possible to mount the virtual filesystems from outside the chroot, > thus completely bypassing the need for temporary "mount" program? It most certainly is, and that's exactly what current LFS does. But I do recall some discussion from years ago where it was decided that using the host's mount binary was considered not kosher. Even tho' it has minor drawbacks, IMHO it's better to mount the virtual file systems from within the chroot. It just feels cleaner.. (and it's also easier on my build scripts :-) Regards Greg From diy-linux-dev@diy-linux.org Fri Aug 31 22:36:36 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sat, 1 Sep 2007 08:36:36 +1000 Subject: Status update Message-ID: <20070831223636.GA23443@eyo32.local> Hi Guys, Just a headsup that I will be adding latest binutils-2.18 to the Refbuild in place of the HJL release. It seems very solid so far, apart from a minor issue where an old or missing makeinfo breaks the build. If you were thinking of upgrading to latest and greatest, now is probably an excellent time as IMHO the toolchain planets have aligned nicely with glibc-2.6.1, gcc-4.2.1 and now binutils-2.18. I will soon make this the default Refbuild combo. Speaking of which, the Refbuild currently lists 5 toolchain combos as recommended. This is way too many. With the 3 current arches, that's 15 builds all up to test. Therefore I will be culling some very soon. The table will probably look like this very shortly: Glibc GCC Binutils Headers 2.3.6 3.4.6 2.16 LLH 2.5.1 4.1.2 2.17 HDRS_INST 2.6.1 4.2.1 2.18 HDRS_INST Essentially, it means dropping support for glibc-2.4 and gcc-4.0.x. I'd like to keep the venerable gcc-3.4.6/glibc-2.3.6 combo in place as it's extremely solid and quite likely represents when the planets last aligned. Let me know if you have any comments. Regards Greg