Re: [lfs-dev] Thoughts about LFS and systemd
On 03/25/14 11:22, Bruce Dubbs wrote: I've been looking at systemd and had a thought that perhaps both could be put into a single LFS build. Looking at the installed package contents in the books, I see the following name collisions: systemd sysvinit eudev udevd udevadm udevadm halt halt init init poweroff poweroff reboot reboot runlevel runlevel shutdown shutdown telinit telinit I don't know if udevd is missing from the systemd page or is really not installed when doing a systemd build, but I suspect it has just been omitted from the page. In any case, this cursory look indicates to me that both could be installed with custom names and a script written to swap the names and reboot to the desired system. I also suspect a sysV initialization could use the systemd version of udev and eudev would not be necessary. I have not looked at boot scripts or possibly different build options in other programs, but wanted to throw out the idea for comments. -- Bruce First, let me say that I personally love that idea. I feel that LFS was kind of loosing sight of the primary goal by not introducing systemd. However, are you suggesting that LFS have optional instructions? That's not bad in itself, just that it has never been acceptable before. I especially like providing both methods (again, primary goal of LFS). Ag has already raised the same point about optional instructions before I completed this message. Also, I'm not sure about scripting the swap. By all means, provide the instructions to switch, but leave the scripting to the user IMO. What about BLFS? Install both sysvinit and unit files from the single install target from the bootscripts tarball? I'm unfamiliar with the sysvinit compatibility in systemd, never had a need for it. --DJ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN-20120916
On 09/26/2012 09:36 PM, Bruce Dubbs wrote: It looks like we need to pass --docdir=/usr/share/doc/flex-2.5.37 Also need to remove the mkdir command that goes along with this...stops jhalfs today. -- DJ -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] lfs-book r10001 e2fsprogs build error
On 09/27/2012 10:45 AM, Bruce Dubbs wrote: xinglp wrote: chapter06/flex also has a error. with option --docdir=/usr/share/doc/flex-2.5.37 and mkdir -pv /usr/share/doc/flex-2.5.37 (File exists) That shouldn't happen with the -p option. It does fail without it. -- Bruce Whoops. Didn't see this thread, but, adding -p was my solution too, only to have it fail when creating the symlink (libfl.a). Make 'ls -svf' ? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Grammar
On 07/16/2012 02:57 PM, Ken Moffat wrote: On Mon, Jul 16, 2012 at 09:54:40PM +0300, Ivan Kabaivanov wrote: actually if we're gonna be sticklers for grammar and puctuation rules, it's gotta be: Installed programs: accelerometer, ata_id, cdrom_id, collect, mtd_probe, scsi_id, v4l_id, udevadm, and udevd (notice the comma between 'udevadm' and 'and') IvanK. I disagree - as with many elements of English grammar and punctuation, there are different schools of thought. http://en.wikipedia.org/wiki/Serial_comma ĸen Huh, I've never heard the term Serial or Harvard, only Oxford. Ultimately, I see it only as a matter of personal style, except when it actually does make the sentence ambiguous. Like mentioned in this thread, I had thought it was required in UK English and optional in US English (I probably picked that idea up from that very thread some time in the past as that is one of my favorite writing resources). See the 4th question: http://owl.english.purdue.edu/purdueowlnews/565 There is no mention of it here, but it is used in all examples: http://owl.english.purdue.edu/owl/resource/607/02/ Though I've gone back and forth over the years, I find that use of the extra comma is less likely to cause ambiguity than lack of use. It still needs to be considered for context, but when no ambiguity exists either way, I choose to include it (well...at least at this time I do). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] perl chapter 5 fails
On 06/01/2012 10:16 PM, Bruce Dubbs wrote:
Matt,
Trying a fresh build, perl 5.16.0 fails to configure.
As user lfs:
$ sh Configure -des -Dprefix=/tools
Directories to use for library searches?
[/lib/../lib64 /usr/lib/../lib64 /lib /usr/lib /tools/lib]
...
What libraries to use?
[-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat]
...
Checking your choice of C compiler and flags for coherency...
I've tried to compile and run the following simple program:
#includestdio.h
int main() { printf(Ok\n); return(0); }
I used the command:
cc -o try -O2 -fno-strict-aliasing -pipe -fstack-protector
-fstack-protector try.c -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
-lgdbm_compat
./try
and I got the following output:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
cannot find -lgdbm
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
cannot find -ldb
collect2: error: ld returned 1 exit status
===
On my system, I have
/usr/lib/libdb.so
/usr/lib/libgdbm.so
/usr/lib/libgdbm_compat.so
But we really don't want to use any of those because they won't be
available in chroot. It is curious Configure finds them at first and
then the link command doesn't as the lfs user.
==
If I run Configure manually and leave off -lgdbm -ldb -lgdbm_compat, it
builds OK.
==
Finally, I found if I edit Configure (chmod 775 first), and add the line:
libswanted=''
to line 3577, then it works!
chmod 0744 Configure
sed -i -e '/Restore computed paths/i libswanted=' Configure
sh Configure -des -Dprefix=/tools
make CLDFLAGS='-lm'
and continue seems to work.
-- Bruce
P.S. This took WAY too long to figure out.
While I am having other issues with perl ATM, maybe it would be better
to use the new compiler to determine the library search path instead of
the brute force method above (or the one in hints/linux.sh).
hints/linux.sh temporarily redefines gcc to /usr/bin/gcc (if it exists)
which is what is used to determine the library search path. sed
's@\$gcc@gcc' -i hints/linux.sh may be sufficient, not sure if $gcc is
used elsewhere. While I'm working on my other issues, Gentoo u32 host
and NPTL linking error (which may also be related), I'm going to undo
this change locally and omit the gcc override and see if I get any
further. On a side note, it may have been sufficient to make libswanted=m.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] perl chapter 5 fails
On 06/04/2012 02:38 PM, DJ Lucas wrote: While I am having other issues with perl ATM, maybe it would be better to use the new compiler to determine the library search path instead of the brute force method above (or the one in hints/linux.sh). hints/linux.sh temporarily redefines gcc to /usr/bin/gcc (if it exists) which is what is used to determine the library search path. sed 's@\$gcc@gcc' -i hints/linux.sh may be sufficient, not sure if $gcc is used elsewhere. While I'm working on my other issues, Gentoo u32 host and NPTL linking error (which may also be related), I'm going to undo this change locally and omit the gcc override and see if I get any further. On a side note, it may have been sufficient to make libswanted=m That worked for both the separate NPTL linking problems and the host libs. Bruce, would it be possible for you to try with the original instructions on your affected host and use this new perl-libc patch? I didn't check if the sed would have been enough, just figured we'd probably want to redefine it globally if used elsewhere anyway. http://www.linuxfromscratch.org/~dj/perl-5.16.0-libc-2.patch -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] perl chapter 5 fails
On 06/04/2012 03:33 PM, Bruce Dubbs wrote: chmod 0644 hints/linux.sh sed -i -e 's|/usr/bin/gcc|/tools/bin/gcc|' hints/linux.sh sh Configure -des -Dprefix=/tools make seems to work. We still need a chmod instruction and the sed is slightly different. We do lose the need to specify CLDFLAGS. It still searches for -lgdbm -ldb -lgdbm_compat, but the test compile doesn't fail. Yes, that should work fine and is far better than extending the patch. Is this worth changing? Absolutely, we don't want to mix incompatible target and host libs (my build failure and reason for looking into this in the first place). Any host that doesn't use NPTL, (separate NPTL if that is still possible), or too old of NPTL/GLibC is broken. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] perl chapter 5 fails
On 06/04/2012 03:53 PM, Bruce Dubbs wrote: DJ Lucas wrote: On 06/04/2012 02:38 PM, DJ Lucas wrote: That worked for both the separate NPTL linking problems and the host libs. Bruce, would it be possible for you to try with the original instructions on your affected host and use this new perl-libc patch? I didn't check if the sed would have been enough, just figured we'd probably want to redefine it globally if used elsewhere anyway. http://www.linuxfromscratch.org/~dj/perl-5.16.0-libc-2.patch I wasn't aware that patch would update read-only files! Yes, that works for. Go ahead and commit the patch and I'll fix up the book. Me neither...I failed to notice that! In that case, patch is in the repo. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 06/04/2012 02:35 PM, Jeremy Huntwork wrote: (perl is another one I'd love to see removed, but I'm not going to seriously recommend that one :) ) Just curiosity, what are the necessary steps? I was pretty sure that something obscure in either gcc or glibc builds required it, but I am all too aware of how well fuzzy memories have served me recently! :-) -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [LFS Trac] #3098: udev/systemd 183 is out
On 06/03/2012 02:03 PM, Bruce Dubbs wrote: Bryan, I tried the patch you submitted to linux-hotplug yesterday: systemd-make-systemd-optional.patch It doesn't apply cleanly to either systemd-183 or -184. It applies with offsets to git master...which hopefully soon will be -185. git://anongit.freedesktop.org/systemd/systemd -- DJ -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
a simple package upgrade, but that still means manual (or maybe only partially automated) builds for omitting optional deps in the build process up to the point that I need. Please prime flame throwers now! Does a recommended dependency change meaning once again? :-) I've never used pacman, so I can't speak for the complexity of it, but from my fuzzy memory, it did fit fairly well with our purposes (optional deps were supported). On the surface, I'm game. A few more questions though. What separates LFS from say Arch, Gentoo, T2... at that point? No mile long USE flags or complex switching scripts I presume, but I know little about the other two. I've included some of their work in BLFS in the past, but that is about it. My hope is that build order is still a manual process where the user determines build order herself. Dependency checking is done only at build time and that optional deps remain optional. If there will be automation, how do we determine what optional deps to pull in? What benefits can we expect for users who have already done the leg work to use other packaging methods? For instance, with what is put into the book, could a logical parser be made to genarate a spec file? How about dpkg? While I admit that the .d/ directory reduces this concern immensely, what happens to configuration files that must be modified by additional installations? Do we keep diffs indefinitely, or do we create a comment marker for each package's additions, modify the package to support some sort of include directive? I can see scripting getting somewhat difficult here, not impossible, but difficult. If it is to be done, it should be designed with all goals in mind from the start. I have long suggested that LFS and BLFS move to installations from DESTDIR (or equivalent) as this does about 60% of building your src rpm without defining a particular package manager. The other 40% is just transposing what is in the book to spec, and could be automated, but even this has had lackluster support in the past despite the obvious educational benefits. Sorry I didn't use the bullet points...out of time for today. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] problem of bootscript setclock
On 05/13/2012 01:16 PM, Bruce Dubbs wrote: DJ Lucas wrote: On 05/13/2012 11:33 AM, Bryan Kadzban wrote: xinglp wrote: Now, It is the job of udev to start /etc/init.d/setclock . When I use initd-tools to install somethings else, it was installed for depended. Is there a way in these newfangled headers to say that setclock is really an alias for udev? That's what's happening in the scripts, anyway... And I THINK , ntpd and checkfs should not depend on $time. Not sure on ntpd (although I wouldn't be surprised if it was because ntpd refuses to do anything if the clock is far-enough off from what it's getting from the upstream servers). But checkfs does depend on the time. It checks whether the current time is before or after the last-full-fsck-time plus the days-between-mounts value stored in the ext3 (and probably 4, and perhaps 2) superblock. If it's after, then it forces a full fsck run. (It also checks whether the mount count stored in the superblock is more or less than the number-of-mounts-between-full-fsck-runs value in the superblock, and forces a full fsck if it's more. Of course, that doesn't depend on knowing the current time.) tune2fs -t will change the number of days between checks, and tune2fs -c will change the number of mounts. tune2fs -Ttimestamp will set the last-checked time (can be done live), and tune2fs -Cinteger will set the current mount count (can also be done live). All that said, if there's no way in this extra-abstraction setup to express an alias, then we should change the other scripts to depend on udev instead of setclock. After a quick review of the scripts, here is my take: a quick fix would be to add $time to the provides of the udev script headers. That's probably not exactly the right thing to do. The setclock script should probably be renamed hwclock and provide hwclock (at shutdown). Scripts that need a close time source (hwclock) should depend on udev for startup. The RTC will always be available to the hwclock program on x86 or x86_64 even if /dev is not mounted (the same is not true of other archs though). I believe there is a way to set the system time by way of kernel config now too so that the udev rule could go...been a while since I looked at it. $time should probably be provided by the ntpd script, and then a $time dependency should never appear in any script that is installed into the rcS.d/, rc1.d/, or rc2.d/ directories. For LFS, we can't rely on ntpd because we can't assume a network connection. -- Bruce Correct, no scripts in the base LFS should have a hard dependency on $time for startup. You could still use should-* if desired, but no examples immediately come to mind where that would be appropriate (and that's not even necessary if the kernel is configured to set the system time). Scripts that need to have semi-accurate time (obtained from the RTC) should depend only on udev for start-up. A provides of hwclock for shutdown would be made available, though the only use of hwclock I can see is as a Required-Stop for the ntpd script. Few things should have a hard dep for $time, in fact, MIT Krb5 is the only one I can think of ATM for BLFS (and Heimdal if it goes back in). BTW, OT but just curiosity, why was MIT chosen to be kept over Heimdal? I would have thought Heimdal to clearly be the more capable of the two, though the extra functionality provided by Heimdal should be handled by PAM anyway, so no *real* loss. Heimdal will be the default krb5 provider for Samba 4 in the future (and included in the distribution, though you can still use a system instance of either if desired). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 04/22/2012 12:19 PM, Jeremy Huntwork wrote: On 4/22/12 11:33 AM, LFS Trac wrote: #3066: Chapter 5 ncurses fails with (old?) gpm on host -+-- Reporter: dj@… | Owner: lfs-book@… Type: task | Status: new Priority: normal | Milestone: 7.2 Component: Book | Version: SVN Severity: normal |Keywords: -+-- Host system is again Gentoo Live DVD 2011. I had to add --without-gpm to the configure flags to get around it. (I tried updating the ticket in trac, but that required me resetting my password and now the site puts me in an infinite redirect loop... trac is being wonky) Anyway, unless ncurses is doing something non-standard to detect gpm, I don't think this should be happening. The point of the chapter 5 toolchain is to remove /usr or anything like it from the search paths. DJ can you dig in the logs to find out what ncurses is doing to detect gpm? In the meantime, I've downloaded the gentoo live dvd and am going to play a bit. JH As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is not a symlink, but rather a linker script that points to another linker script that points to an invalid destination (ie: no 64bit libgpm). I was going to close as invalid, but then I wondered if we want our chapter 5 ncurses linked to something that does not exist in the chroot environment? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 04/22/2012 03:06 PM, Bruce Dubbs wrote: Jeremy Huntwork wrote: So to be clear, Pierre is correct in that there is a serious flaw in the current LFS SVN. In fact, until this gets resolved LFS SVN should be considered completely broken. Having a chapter 5 toolchain that searches /usr/include kills the purpose of building a separate temporary toolchain at all. s/serious// I agree that we need to fix this, but I think the actual problem is more potential than serious. It's unlikely that any headers incorrectly included will make the generated system work incorrectly without being highlighted like the gpm issue. I think we can get this fixed in the next couple of days. -- Bruce Well, I wasn't going to stick with it as I actually intended to use this one for a couple of months. I just restarted the build on the affected host with Pierre's proposed change. Should be able to give a thumbs up in about 45 minutes or so. I know it only affects SVN as I completed a 7.1 build not even a month ago using the same host. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] --without-ppl and --without-cloog
On 04/22/2012 04:35 PM, Jeremy Huntwork wrote: So, I'm seeing that you have the aforementioned switches in both pass 1 and pass 2 gcc and I'm trying to understand exactly why. In pass1 it simply speeds up the build, the explanation is incorrect. They shouldn't be needed by pass2. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 04/22/2012 03:25 PM, DJ Lucas wrote: Should be able to give a thumbs up in about 45 minutes or so. Yeah, good. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] --without-ppl and --without-cloog
On 04/22/2012 05:05 PM, Jeremy Huntwork wrote: On 4/22/12 5:59 PM, DJ Lucas wrote: On 04/22/2012 04:35 PM, Jeremy Huntwork wrote: So, I'm seeing that you have the aforementioned switches in both pass 1 and pass 2 gcc and I'm trying to understand exactly why. In pass1 it simply speeds up the build How does it speed up the build? JH I'm not entirely positive, it's been a few years, but there was no need to compile unnecessary additions that eat up time. Granted, it is a very small savings in the grand scheme. That was the goal of those switches and several others at the time that GCC started requiring mpc, mpfr, and gpc (and when it was decided to exclude Cloog and PPL). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Summary of changes in JH toolchain proposal
On 04/22/2012 10:36 PM, Bruce Dubbs wrote: I've been studying Jeremy's changes and want to summarize them here. Snip complete summary Asking for a technical review? :-) Both methods achieve the goal! Now for a quick, non-technical overview of the effect on the book. You have reduced the amount of lines in command blocks in the book by 23, added 15 lines, and removed a page, so complexity of the typed commands is reduced slightly (that could be taken as a negative, but the removed page is explained again in chapter 6 and really doesn't compare with the next point). We gain the added educational value of explaining how and why a sysroot build works for us--something that can be, and is used outside of LFS. One really common stumbling block is removed (first toolchain adjustment). Finally, two commands that are regarded as hacks by some are removed (-B, and this is subjective). Assuming the result has proven sane by comparison testing (and I'm pretty sure that has already been done), the only possible downside that I see is the lost explanation of -B, which I don't recall having seen outside of LFS, but I really haven't looked either. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Coreutils uname patch for all arches
On 03/27/2012 03:55 PM, Matt Burgess wrote: On Mon, 2012-03-26 at 19:07 -0500, DJ Lucas wrote: Noticed that 8.16 patch has not been committed, want to suggest an updated one that gets all arches. Been using this for a while, taken directly from Gentoo, about 2/3 of the way through a gnome desktop with no ill affects. http://www.linuxfromscratch.org/~dj/coreutils-8.14-uname-2.patch I've got a sense of deja vu here, DJ! Did we not discuss this recently? I can't seem to find anything in the archives or Trac history though. Yeah, I had sent it to you off list several months back and said I'd make a suggestion after it had been tested well enough. I'd much rather just drop the patch completely, to be honest. It is simply cosmetic, you can get that information from /proc/cpuinfo anyway, and the patch is never going to be accepted upstream in its current form. True. I hadn't even thought of it like that. Was simply trying to get rid of the case in the book. Drop is better for the book. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Coreutils uname patch for all arches
Noticed that 8.16 patch has not been committed, want to suggest an updated one that gets all arches. Been using this for a while, taken directly from Gentoo, about 2/3 of the way through a gnome desktop with no ill affects. http://www.linuxfromscratch.org/~dj/coreutils-8.14-uname-2.patch This is from two different machines: Old patch (not on x86_64) dj [ coreutils ]$ uname -a Linux name64 2.6.36.2 #1 SMP PREEMPT Wed May 11 21:01:44 CDT 2011 x86_64 x86_64 x86_64 GNU/Linux New patch: dj [ /sources ]$ uname -a Linux name65 3.2.9 #1 SMP PREEMPT Sun Mar 18 09:34:15 GMT 2012 x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux Something simple, but better IMO. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Coreutils uname patch for all arches
On 03/26/2012 07:07 PM, DJ Lucas wrote: no ill affects. s/affects/effects :-) -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gettext configure error
On 11/27/2011 04:05 AM, Matthew Burgess wrote: On Sat, 26 Nov 2011 22:19:59 -0600, DJ Lucasd...@linuxfromscratch.org wrote: On 11/26/2011 10:02 PM, DJ Lucas wrote: On 11/26/2011 09:27 PM, DJ Lucas wrote: Latest gettext configure can hang in chapter 5 on checking where .elc files should go... if emacs is installed on the host. Should probably add --without-emacs and probably --without-git to the chapter 5 gettext configure flags. Though I did not have any trouble with git, it will not be available in the chroot environment, but is picked up by default. -- DJ Lucas Scratch that...bad troubleshooting, forgot to put the symlink back. Something is broken in gettext-tools/configure. Looking into it now. This is related to having /usr/bin/emacs - zile symlink on x86_64 (does not affect 32bit builds). Bug has aparently been there for a very long time. Workaround is 'EMACS=no ./configure ...' Not sure how gentoo handles this internally. Suitable for the book, or just blacklist x86_64 Gentoo as a suitable host? I've been using the Gentoo Live DVD for x86 builds for a while now (and I used to use System Rescue CD, which I've seen mentioned a few times), but this was first build on x86_64. Anybody have GNU Zile on some other x86_64 host that can double check this? Thanks for the report, DJ. I can't double-check myself as I build on x86 still. However, your analysis looks fine, and the simple workaround of setting EMACS=no is certainly suitable for the book (far more suitable than blacklisting an entire distribution). I'll add it to the book during the next round of updates. Thanks, Whoops..forgotten. I expected a fresh LFS system and instead was greeted with a 233 minutes of build time for chapter 5 gettext using the Gentoo Live DVD as a host distribution. The 'EMACS=no ./configure ...' workaround still solves this. The '--without-emacs' switch does _not_ as the configure check is done out of order (fixed upstream at http://lists.gnu.org/archive/html/bug-gettext/2011-11/msg00016.html ). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] lfs bootscripts and multiple instances
On 02/03/2012 01:55 AM, Dean Takemori wrote:
I'm trying to setup multiple instances of rsyslog (one for kernel
messages) using lfs-bootscripts-20120116 and running into some
problems.
I'm using rsyslogd 5.8.6, which is designed with multiple instance
support. I've set up one configuration file (/etc/rsysklog.conf)
for the kernel logger and one for the system logger (/etc/rsyslog.conf)
rsyslogd's
-i flag specifies the pid file used and
-f specifies the configuration file.
root:~# source /lib/lsb/init-functions
root:~# start_daemon -p /run/rsyslogd.pid /sbin/rsyslogd -i
/run/rsyslogd.pid -f /etc/rsyslog.conf
root:~# echo $?
0
Now let's check:
root:~# ps xa | grep rsyslogd
8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd/pid -f
/etc/rsyslog.conf
8131 tty1 s+ 0:00 grep rsyslog
root:~# stausproc -p /run/rsyslogd.pid /rsbin/rsyslogd
rsyslogd is running with Process ID(s) 8045
root:# cat /run/rsyslogd.pid
8045
So far so good.
But now let's try running the second instance.
root:~# start_daemon -p /run/rsysklogd.pid /sbin/rsyslogd -i
/run/rsysklogd.pid -f /etc/rsysklog.conf
root:~# echo $?
0
and now check:
root:~# ps xa | grep rsyslogd
8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd.pid -f
/etc/rsyslog.conf
8133 tty1 s+ 0:00 grep rsyslog
What?
Note that rsyslog behaves as expected:
root:~# sbin/rsyslogd -i /run/rsysklogd.pid -f /etc/rsysklog.conf
root:~# echo $?
0
root:~# ps xa | grep rsyslogd
8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd.pid -f
/etc/rsyslog.conf
8149 ?Sl 0:00 /sbin/rsyslogd -i /run/rsysklogd.pid -f
/etc/rsysklog.conf
8155 tty1 s+ 0:00 grep rsyslog
root:~# cat /run/rsyslogd.pid
8045
root:~# cat /run/rsysklogd.pid
8149
So far, I think I've tracked the problem down to statusproc() not correctly
using the pidfile it's given.
Namely: this is correct
root:~# statusproc -p /run/rsyslogd.pid /sbin/rsyslogd
rsyslogd is running with Process ID(s) 8045
root:~# cat /run/rsyslogd.pid
8045
But this is not
root:~# statusproc -p /run/rsysklogd.pid /sbin/rsyslogd
rsyslogd is running with Process ID(s) 8045
root:~# cat /run/rsysklogd.pid
8149
BTW: statusproc() defined in /lib/lsb/init-functions has an exit 1 just
after
it prints its Usage statement; shouldn't this be a return 1 instead?
BTW2: statusproc()'s Usage statement says :
echo Usage: [-p pidfile] statusproc {program}
Shouldn't this be this?
echo Usage: statusproc [-p pidfile] {program}
Yes, statusproc() looks broken. Might it be better to use pidofproc()
directly where possible? Not sure that statusproc() should be needed any
longer. I haven't had the time to dig too deep into the wrapper
functions since the rewrite. I'll have a look at them later today, but
hopefully Bruce can chime in here today as well. Not sure about the exit
vs return.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] bootscripts-20111017 statusproc() broken?
On 01/22/2012 10:43 AM, Bruce Dubbs wrote:
Dean Takemori wrote:
lfs/lib/services/init-functions defines statusproc() with this snippit
to process arguments:
while true; do
case ${1} in
-p)
pidfile=${2}
shift 2
;;
esac
done
Isn't this broken?
What's broken? Can you give an example of how it breaks?
-- Bruce
I think this might carry over from the original so the problem dates
back to me or possibly even Nathan and Alex. I didn't look. At any rate,
the problem is that there is no error checking. I don't believe that
statusproc() is intended to check multiple processes from multiple
executables (multiple processes from one executable yes). For the -p
case, you should verify that $2 is a valid file, and that $3 is
executable or undefined, and add a * case, that $1 is executable and $2
= -p shift 1;. If any of the above are false, a return value of 2
should fit the LSB spec with optional error message Error: invalid or
excessive argument(s). A case could be made that $3 in the -p case or
$1 in the * case not being executable should return a value of 5, but
I'm not sure that value should apply here. I didn't look to see if the
executable is evaluated later in the function, but the function should
most definitely have argument handling for excessive arguments in the
while loop.
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [blfs-dev] Iced Tea
Sorry for top posting, phone is giving me a fit. That is another that its traditionally mine, but would appreciate another look as far as style. Some caveats, IcedTea 7 cannot be built with 6 ATM, it'll have to be bootstrapped from a GCJ Java environment. Latest 6 should be fine if you intend to do the update. I'll upload a newer patch for the cacerts. If not interested, I will do it when I can. -- DJ Bruce Dubbs bruce.du...@gmail.com wrote: Has anyone done Iced Tea with LFS 7? Personally, I try to stay away from Java, but some packages need it so I was going to install it. There do seem to be some updates from what we have in the book. -- Bruce -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] libtirpc better explanations/implementation
On 12/03/2011 09:39 AM, DJ Lucas wrote: This question still stands. I was not able to find anything readily available. -- DJ Lucas What a disaster! Even RedHat hasn't got this far yet. There is more we need to do to GLibc than install the headers. I'm suggesting that we follow suit, as the rest of the distros have, and re-export the symbols in LFS and continue to install the headers until a *complete* replacement is available. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/glibc/2.14.1/0070_all_glibc-2.14-rpc-export.patch Also, OpenSSL will likely be a requirement soon for TI-RPC's crypto libs. As far as BLFS is concerned, we can make the assumption that the eratta was followed with the above changes made (glibc re-installed for people who have already built LFS-7.0), or just stick with what is there now and delete the static libs for TI-RPC, but that does mean that NIS is completely dead (and the shared TI-RPC is still potentially broken). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gettext configure error
On 11/27/2011 04:05 AM, Matthew Burgess wrote: Thanks for the report, DJ. I can't double-check myself as I build on x86 still. However, your analysis looks fine, and the simple workaround of setting EMACS=no is certainly suitable for the book (far more suitable than blacklisting an entire distribution). I'll add it to the book during the next round of updates. Thanks, Matt. The --without-emacs switch is still required. The fix I sent upstream (applied already) puts the checks for the LISP directory into a conditional based on the value of the EMACS variable, which is now run after configure checks for Emacs, not based on the EMACS environment variable. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] man-pages download link
The man-pages download link in the book is incorrect, the correct one is: http://man7.org/linux/download/man-pages/man-pages-3.35.tar.gz -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] gettext configure error
Latest gettext configure can hang in chapter 5 on checking where .elc files should go... if emacs is installed on the host. Should probably add --without-emacs and probably --without-git to the chapter 5 gettext configure flags. Though I did not have any trouble with git, it will not be available in the chroot environment, but is picked up by default. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gettext configure error
On 11/26/2011 09:27 PM, DJ Lucas wrote: Latest gettext configure can hang in chapter 5 on checking where .elc files should go... if emacs is installed on the host. Should probably add --without-emacs and probably --without-git to the chapter 5 gettext configure flags. Though I did not have any trouble with git, it will not be available in the chroot environment, but is picked up by default. -- DJ Lucas Scratch that...bad troubleshooting, forgot to put the symlink back. Something is broken in gettext-tools/configure. Looking into it now. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-7.0 coreutils-8.14 libexec
On 11/12/2011 04:20 PM, Bruce Dubbs wrote: Installed library: libstdbuf.so Installed directory: /usr/lib/coreutils I made a change to that in the description in -dev. Thanks for pointing that out. Unless I've misunderstood the above comment, you should set libexecdir back to /usr/lib/coreutils as this has been standard practice in LFS and BLFS for as far back as I can remember (/usr/lib/packagename). There are several examples in BLFS for sure, and in both books IIRC. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
bootscript fixes
Mostly for Bruce, but sent to list for everyone's review:
Attached are some fixes for the bootscripts. These are mostly cosmetic,
but there are some minor functional changes due in part to reverting to
multi-part writes to the screen, some clean-up/simplification of syntax,
for instance, == instead of = in comparison tests, use -a and -o
instead of ] [ or ] || [ resp., removed the second interactive
prompt, made available boot message prefixes and color ${INFO} for
mountvirtfs, made certain that control charcters are not written to the
boot log in case color codes are used in screen messages, and reduced
duplication of items in rc.site and init-functions (rc.site is required
for init-functions/rc). Please review, and discuss if necessary, before
commit.
Thanks.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
diff -Naurp lfs-bootscripts-20111017-orig/lfs/init.d/checkfs lfs-bootscripts-20111017/lfs/init.d/checkfs
--- lfs-bootscripts-20111017-orig/lfs/init.d/checkfs 2011-09-19 03:31:46.0 +
+++ lfs-bootscripts-20111017/lfs/init.d/checkfs 2011-11-05 19:52:36.0 +
@@ -79,7 +79,7 @@ case ${1} in
log_info_msg Checking file systems...
# Note: -a option used to be -p; but this fails e.g. on fsck.minix
- fsck ${options} -a -A -C -T
+ fsck ${options} -a -A -C -T /dev/null
error_value=${?}
if [ ${error_value} = 0 ]; then
diff -Naurp lfs-bootscripts-20111017-orig/lfs/init.d/cleanfs lfs-bootscripts-20111017/lfs/init.d/cleanfs
--- lfs-bootscripts-20111017-orig/lfs/init.d/cleanfs 2011-09-19 03:31:46.0 +
+++ lfs-bootscripts-20111017/lfs/init.d/cleanfs 2011-11-05 19:52:41.0 +
@@ -90,7 +90,7 @@ case ${1} in
log_info_msg Cleaning file systems:
if [ ${SKIPTMPCLEAN} = ]; then
- log_info_msg2 \n /tmp
+ log_info_msg2 /tmp
cd /tmp
find . -xdev -mindepth 1 ! -name lost+found -delete || failed=1
fi
diff -Naurp lfs-bootscripts-20111017-orig/lfs/init.d/consolelog lfs-bootscripts-20111017/lfs/init.d/consolelog
--- lfs-bootscripts-20111017-orig/lfs/init.d/consolelog 2011-09-19 03:31:46.0 +
+++ lfs-bootscripts-20111017/lfs/init.d/consolelog 1970-01-01 00:00:00.0 +
@@ -1,78 +0,0 @@
-#!/bin/sh
-
-# Begin consolelog
-#
-# Description : Set the kernel log level for the console
-#
-# Authors : Dan Nicholson - dnichol...@linuxfromscratch.org
-# Gerard Beekmans - ger...@linuxfromscratch.org
-# DJ Lucas - d...@linuxfromscratch.org
-# Update : Bruce Dubbs - bdu...@linuxfromscratch.org
-#
-# Version : LFS 7.0
-#
-# Notes : /proc must be mounted before this can run
-#
-
-
-### BEGIN INIT INFO
-# Provides:consolelog
-# Required-Start:
-# Should-Start:
-# Required-Stop:
-# Should-Stop:
-# Default-Start: S
-# Default-Stop:
-# Short-Description: Sets the console log level.
-# Description: Sets the console log level.
-# X-LFS-Provided-By: LFS
-### END INIT INFO
-
-. /lib/lsb/init-functions
-
-# set the default loglevel if needed
-LOGLEVEL=${LOGLEVEL:-7}
-
-[ -r /etc/sysconfig/console ] . /etc/sysconfig/console
-
-case ${1} in
- start)
- case $LOGLEVEL in
- [1-8])
- log_info_msg Setting the console log level to ${LOGLEVEL}...
- dmesg -n $LOGLEVEL
- evaluate_retval
- exit 0
- ;;
-
- *)
- log_failure_msg Console log level '${LOGLEVEL}' is invalid
- exit 1
- ;;
-
- esac
- ;;
-
- status)
- # Read the current value if possible
- if [ -r /proc/sys/kernel/printk ]; then
- read level line /proc/sys/kernel/printk
- else
- log_failure_msg Can't read the current console log level
- exit 1
- fi
-
- # Print the value
- if [ -n $level ]; then
- log_info_msg The current console log level is ${level}\n
- exit 0
- fi
- ;;
-
- *)
- echo Usage: ${0} {start|status}
- exit 1
- ;;
-esac
-
-# End consolelog
diff -Naurp lfs-bootscripts-20111017-orig/lfs/init.d/mountvirtfs lfs-bootscripts-20111017/lfs/init.d/mountvirtfs
--- lfs-bootscripts-20111017-orig/lfs/init.d/mountvirtfs 2011-09-19 03:31:46.0 +
+++ lfs-bootscripts-20111017/lfs/init.d/mountvirtfs 2011-11-05 19:53:19.0 +
@@ -36,15 +36,15 @@ case ${1} in
mount -n /run || failed=1
mkdir -p /run/{var,lock,shm}
- log_info_msg Mounting virtual file systems: /run
+ log_info_msg Mounting virtual file systems: ${INFO}/run
if ! mountpoint /proc /dev/null; then
- log_info_msg2 /proc
+ log_info_msg2 ${INFO}/proc
mount -n /proc || failed=1
fi
if ! mountpoint /sys /dev
Re: bootscript fixes
On 11/05/2011 04:15 PM, Bruce Dubbs wrote:
DJ Lucas wrote:
Mostly for Bruce, but sent to list for everyone's review:
Attached are some fixes for the bootscripts. These are mostly cosmetic,
but there are some minor functional changes due in part to reverting to
multi-part writes to the screen, some clean-up/simplification of syntax,
for instance, == instead of = in comparison tests, use -a and -o
instead of ] [ or ] || [ resp., removed the second interactive
prompt, made available boot message prefixes and color ${INFO} for
mountvirtfs, made certain that control charcters are not written to the
boot log in case color codes are used in screen messages, and reduced
duplication of items in rc.site and init-functions (rc.site is required
for init-functions/rc). Please review, and discuss if necessary, before
commit.
I appreciate the fixes. I'll review the diff in more detail, but note
that I used = instead of == for string comparisons explicitly because
the bash man page says:
string1 == string2
True if the strings are equal. = may be used in place of == for
strict POSIX compliance.
I was trying to make the scripts Bourne/Posix compatible.
-- Bruce
Although I hadn't actually noticed that init-functions used /bin/sh for
the interpreter prior to your mention POSIX above, I fortunately only
made the comparison and logical and/or changes in the rc script which
uses /bin/bash for the schebang (it looks as if this is the only script
to do this as well). The goal was consistency. You are correct, a single
= character must be used for comparison tests in init-functions for
POSIX compliance. I'll drop in a couple of random scripts using dash or
ash as the interpreter tonight or tomorrow to make sure, but I believe
all is well. It could be argued, however, that we should drop to /bin/sh
for the interpreter used in the rc script and do the reverse. If agreed,
just respond here and ignore the earlier patch (I'm pretty sure we
should probably use sh syntax and avoid mixing the two for consistency).
I'll reverse those specific changes and get a corrected one tested
tomorrow or later tonight along with the proposed cosmetic changes. I'm
going to build ash and symlink to /bin/sh now to get a thorough test
done. I'll get to dash later in the week.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: bootscript fixes
On 11/05/2011 06:04 PM, Bruce Dubbs wrote:
Bruce Dubbs wrote:
DJ Lucas wrote:
Mostly for Bruce, but sent to list for everyone's review:
I had left the definitions
NORMAL=\\033[0;39m # Standard console grey
SUCCESS=\\033[1;32m# Success is green
WARNING=\\033[1;33m# Warnings are yellow
FAILURE=\\033[1;31m# Failures are red
INFO=\\033[1;36m # Information is light cyan
BRACKET=\\033[1;34m# Brackets are blue
in init-functions to handle the case when a user may have deleted them
from rc.site.
Same for the DISTRO vars in init.d/rc
Ahh..okay, they should be left then as ones in rc.site take precedence.
-
I'm not sure we want to set LOGLEVEL every time we change run level.
Perhaps that should be wrapped in
if [ ${runlevel} == S ]; then dmesg -n ${LOGLEVEL:-7}; fi
Yes, there is no longer any need for the consolelog script as we do not
change logging level in any of the scripts. It is not necessary to have
/proc or /sys mounted to set the kernel log level when using dmesg. Note
that this could also be set any number of other ways (including via
sysctl). If you want a really clean look, it is important to set this as
early as possible. With LOGLEVEL set to 4 in early rc, All boot messages
show on screen, nothing out of place, including the welcome message for
interactive prompt.
-
The purpose of log_info_msg2 was to be able to put something in the middle:
log_info_msg Start of message...
...
log_info_msg2 Something else
(exit $RET)
evalutate_retval
So it would come out as:
Start of message...Something else [ OK ]
Adding ${BMPREFIX} to log_info_msg2 would change that behavior. See the
modules script.
Opps that wasn't supposed to be left in there, added it by mistake when
I added the removal of non-printable characters. I still have one issue
with logging, a couple of OK messages out of place, but I'll post a fix
back when I find the issue (was there before I started mucking around
with them).
Thanks for the review...changing local copy with the above now. I'll be
able to trudge through the rest of them tonight, but I'm pretty sure all
is well. Everything changed above was simply for aesthetic purposes --
colon for lists instead of trailing dots (mountvirtfs and cleanfs), or
lines without output (ifup), boot message prefixes, double welcome
message... I'm still gonna revisit the added ifdown functionality and
service functions, even if only for downstream users, but they look real
good. Sorry I'm only now getting to review them. I also have a few
scripts laying around for BLFS that are not in the contrib/lsb directory
that should be suitable for the current scripts, I'll get to those when
I get to building them.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS on github (RFC)
On 09/24/2011 12:22 PM, Kevin Lyda wrote: snip all of the actual important stuff Anyway, thanks if you read this far and hope the info here was useful. LFS has been an excellent tool for me at work. You guys have done a fantastic job. If this is not desired I'm happy to remove it. If it's useful that's also great. Kevin, wow! Thanks for the detailed writeup, it is much appreciated. I vaguely remember a few minor hiccups with the move from CVS to Subversion which our admins at the time worked diligently to fix. This isn't much different from then, and now it seems there are more/better tools to assist with the migration if needs be. That said, Git is probably a little overkill for LFS, but who knows what people will want going forward. At least there is a way to bridge the gap for those who are more comfortable with git. I myself have been using git with repo for managing android development. I'm tracking well over 300 projects right now...no way I'd be able to do that manually with svn. And if it's offensive/unwanted, please accept my apologies in advance. Having copies anywhere and everywhere is kind of the point of distributed version control. Taking it a step further, you have all of the history of that repo, even dating back to CVS, on at least two other boxes now. I cannot possibly fathom how that could be a bad thing. I will probably go through the steps myself just for the learning aspect of it, but yeah, keep it up. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev_retry
Bryan Kadzban br...@kadzban.is-a-geek.net wrote: Nathan Coulson wrote: Another thought (one I have not actually tested, forgive me if It's not possible) is trigger only block devices in the first pass, then try devices/subsystems on the 2nd pass? DJ Lucas wrote: Can we not simply re-trigger all known affected subsystems with a subsystem match? Ooo, interesting. I believe either of these should work fine. (It would also be possible to make udev_retry blindly retry *all* events, but that will make it take slightly longer to finish the settle call, as well. :-) ) Now, if that would work well enough, then just add a configuration file for the udev_retry bootscript so that it can be extended in BLFS for say ALSA, and then parse the list. Yeah. It would also work to make the pre-checkfs/pre-mountfs udevadm trigger call have a list of subsystems to trigger, of course, if we triggered just the block subsystem by default (as Nathan suggested). for SUBSYSTEM in `grep -v '^#' /etc/udev_retry.conf` Or sysconfig, or wherever similar scripts are put in Bruce's new setup. But yeah. you could even write a message for each one if you wanted to have more verbose output in the event of a failure, or a stepping like we do in mountvirtfs. I like the mountvirtfs / modules scripts' approaches, with a config file containing a list of things to process. At that point it's only a question of whether we want to use this method to decide what devices are necessary for checkfs/mountfs, or we want to use this method to decide what devices might need to be retried. I think that finding the devices necessary for checkfs/mountfs might be a bit more fragile, actually; we would have to ensure that none of the udev rules for the storage devices require anything else. (They should not, since those might be the first events triggered, but who knows what might happen in the future, if upstream lives in a world where every system runs an initramfs that mounts these FSes for them.) Although, hmm. Either way here, there's a possible problem, with symlinks for disk devices. If the USB ID file isn't present, then it's possible that the /etc/fstab entry for /usr refers to a symlink that relies on this file. Of course, in that case you're just as screwed even if you have an initramfs that does this mounting (since the initramfs doesn't have the file either), so it's probably not worth defending against. Unfortunately, I think inevitably we'll have to add it, but we aren't there quite yet. I'm pretty sure upstream will eventually force it upon us. If a small /usr is in the initrd, it'll work. Does the /lib/udev/devices get a recursive copy? If so, then can't a minimal symlink tree be created to account for a particular device...and if not, then in rootfs before real / is mounted. --DJ Lucas -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev_retry
On 09/15/2011 02:38 PM, Bruce Dubbs wrote: References are threads starting at: http://www.linuxfromscratch.org/pipermail/lfs-dev/2011-August/064960.html http://linuxfromscratch.org/pipermail/lfs-dev/2011-September/065130.html We are in a Catch-22 situation with udev_retry. Here's a rundown: We need to start udev (S10udev) before mounting filesystems (S40mountfs) so that the device entries are available in order to mount partitions. udev will create some devices and may run some programs before all file systems are mounted (setclock) that need directories that are potentially not mounted (/usr, /var). The same issues come up for BLFS in alsa. Currently we are addressing these types of problems with the command: /sbin/udevadm trigger --type=failed --action=add in udev_retry. The problem is that '--type=failed' has been deprecated upstream and we need to plan for that. We also get a nasty warning message on every boot about the deprecation. In the infrequent case of a changed network card, we also need to be able to copy udev generated files from the tmpfs /run directory to /etc after / is remounted r/w, but that can be moved to the mountfs script from the udev_retry script. There are options about what to do right now: 1. Leave in the warning message and optionally write something about it in the book. 2. Add 2/dev/null to the udevadm command above. 3. Modify the source to remove the warning (delete 1 line). Go with 3 for the time being, or see below snip 4. Reinsert the deleted retry code into udev with a patch. Or recreate the functionality outside of udev. What is the consequence of manually triggering an add event that has already happened? From here, it looks like the device nodes are simply recreated (and rules processed appropriately). Look: root@name64 [ /etc/udev/rules.d ]# echo echo 'YES' /etc/test.txt /etc/init.d/setclock root@name64 [ /etc/udev/rules.d ]# rm /etc/test.txt rm: cannot remove `/etc/test.txt': No such file or directory root@name64 [ /etc/udev/rules.d ]# ls -l /dev/rtc* lrwxrwxrwx 1 root root 4 Sep 15 19:22 /dev/rtc - rtc0 crw-r--r-- 1 root root 254, 0 Sep 15 19:22 /dev/rtc0 root@name64 [ /etc/udev/rules.d ]# udevadm trigger --subsystem-match=rtc --action=add root@name64 [ /etc/udev/rules.d ]# cat /etc/test.txt YES root@name64 [ /etc/udev/rules.d ]# ls -l /dev/rtc* lrwxrwxrwx 1 root root 4 Sep 15 19:24 /dev/rtc - rtc0 crw-r--r-- 1 root root 254, 0 Sep 15 19:24 /dev/rtc0 root@name64 [ /etc/udev/rules.d ]# As you might have guessed, I did that a few times before...hence only 2 minute difference. Can we not simply re-trigger all known affected subsystems with a subsystem match? I don't really see the possibility of failure here, but I certainly am not the udev aficionado, so I could easily be missing something. Now, if that would work well enough, then just add a configuration file for the udev_retry bootscript so that it can be extended in BLFS for say ALSA, and then parse the list. In the udev_retry script, a for loop like so: ( failed=0 for SUBSYSTEM in `grep -v '^#' /etc/udev_retry.conf` do udevadmin trigger --subsystem-match=$SUBSYSTEM --action=add || failed=1 done exit $failed ) Or function and return, or test on the variable or whatever works well in the context of that particular boot script...you could even write a message for each one if you wanted to have more verbose output in the event of a failure, or a stepping like we do in mountvirtfs. I'd like to see some more discussion about this. -- Bruce What ya'll think? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: /etc/bash_completion.d/ is not configured
On 09/11/2011 12:42 AM, DJ Lucas wrote: I haven't found where the Debian one is developed yet. https://alioth.debian.org/projects/bash-completion/ -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: /etc/bash_completion.d/ is not configured
On 09/11/2011 12:04 PM, Bruce Dubbs wrote: DJ Lucas wrote: On 09/10/2011 11:49 PM, DJ Lucas wrote: Grub and GLib both install bash completion scripts. Need to add something to the default /etc/profile in the book to take advantage of them. Additionally, the one for grub is broken currently looking for a have() function, which for distros is usually defined in /etc/bash_completion. I see where this is installed, but I don't see where it is used. And it gets worse: The gdbus one requires _get_cword() from a Debian package called bash-completion-lib. Grub requires 2 more from the same package: filelist(), _get_longopt(), and _filelist() is dependent on _expand(). There was a Google code project (http://code.google.com/p/bash-completion-lib/) that doesn't cover _split_longopt() (following). Last release was in Feb of 2009, but I haven't found where the Debian one is developed yet. What functionality fails if these are missing? Bash tab completion for the gsettings and gdbus commands, and several grub-* commands. For instance, if I type 'grub-set-default tab', I get a listing of the available targets in my grub.cfg: root@name64 [ /sources/bash-completion-1.3 ]# grub-set-default Linux, with Linux 2.6.32.15 Linux, with Linux 2.6.32.15 (recovery mode) Linux, with Linux 2.6.36-lfs-SVN-20101118 Linux, with Linux 2.6.36-lfs-SVN-20101118 (recovery mode) Linux, with Linux 2.6.36.2-x86_64 Linux, with Linux 2.6.36.2-x86_64 (recovery mode) Linux, with Linux 2.6.36.2-x86_64 Kernel 32bit userspace Linux, with Linux 2.6.36.2-x86_64 Multi-lib Linux, with Linux 2.6.36.2-x86_64 Multi-lib (recovery mode) Linux, with Linux 2.6.36.2-x86_64-old Linux, with Linux 3.0.2-x86_64 Linux, with Linux 3.0.2-x86_64 (recovery mode) Linux, with Linux 3.0.4-x86_64 Linux, with Linux 3.0.4-x86_64 (recovery mode) WindowsXP Professional (Chainloaer) root@name64 [ /sources/bash-completion-1.3 ]# grub-set-default Overall, I think this is stupid. These are library functions. Why are they in /etc instead of /lib. DJ, I know you are just describing things. -- Bruce They are bash functions that are intended to make bash command completion easier. LFS is fine without. I'll do something in the wiki or in the BLFS profile page later on. It just bugs me that these were 'standardized' to the Debian way. Do these functions exist outside of Debian? Anybody got a RH or Cent box handy? As far as placement, the logic is that they are part of a configuration file, and technically they are I guess. Gray area? Anyway, all OT for this list now I guess. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: /etc/bash_completion.d/ is not configured
On 09/11/2011 12:24 PM, Andrew Benton wrote: On Sat, 10 Sep 2011 23:49:36 -0500 DJ Lucasd...@linuxfromscratch.org wrote: Grub and GLib both install bash completion scripts. Need to add something to the default /etc/profile in the book to take advantage of them. rm -rf /etc/bash_completion.d # works for me. Am I missing something? Andy Absolutely nothing! However, I think that I'd like to see them left in place for those who actually would like to use them. :-) -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
/etc/bash_completion.d/ is not configured
Grub and GLib both install bash completion scripts. Need to add
something to the default /etc/profile in the book to take advantage of them.
Additionally, the one for grub is broken currently looking for a have()
function, which for distros is usually defined in /etc/bash_completion.
So, I'd suggest to add a /etc/bash_completion file with the following
commands:
cat /etc/bash_completion EOF
#!/bin/bash
# Begin /etc/bash_completion
have()
{
unset -v have
PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin type $1 /dev/null
have=yes
}
# Pull in additional completion scripts
for script in /etc/bash_completion.d/* ; do
if [ -r ${script} ] ; then
. ${script}
fi
done
unset script
# End /etc/bash_completion
EOF
chmod 644 /etc/bash_completion
And then source the /etc/bash_completion file from the default /etc/profile.
Also, what of /etc/profile.d/ for LFS? Best continued to be left for
BLFS? I would consider it nice to have in a default installation, but
there is nothing that uses it until the 4th package into BLFS for me.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: unknown HZ value message still appears in procps utils
On 09/04/2011 11:48 PM, Bruce Dubbs wrote: DJ Lucas wrote: On 06/07/2011 05:16 AM, LANOUX Bertrand wrote: Hi all, I have noticed the unknown HZ value message still appears at boot time and under some unpredictable circumstances when running the ps command, even after applying the procps-3.2.8-fix_HZ_errors-1.patch (I currently use a SMP, 2.6.38.4 tickless kernel). So after looking inside the procps code and patch, I deduced the linux_version_code variable was not correctly valued. After starting to make my own patch, I came across a similar issue when looking over the net (seen on http://www.linuxquestions.org/questions/slackware-14/slackware-13-37-rc-unknown-hz-value-after-procps-upgrade-871679/). It seems the constructor functions don't run as the package expect on recent libgcc. After applying it, the message definitively disappeared. The patch is attached (another solution is to prioritize the constructor functions). It works well since quite a while for me now, so may it be taken into account for those who have encountered the same inconvenience. Have a look ? Thanks for reading, Bertrand. Upstream patch committed as procps-3.2.8-fix_HZ_errors-2.patch. Still needs to be updated in the book. DJ, It's unclear to me if the -2 patch should be done in addition to the -1 patch or if it should just replace the -1 patch. -- Bruce It is a replacement. The Debian changes were not taken upstream, and didn't work correctly for tickless kernels. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Add IPv6 localhost entry to /etc/hosts file
While it's not really prevalent just yet, big ISPs are supposed to begin to doing test roll-outs of IPv6 by the end of the year (if they haven't already). Probably good to add an entry for the loopback at very least. It's just ::1 localhost immediately under the existing 127.0.0.1 entry. I'm not really sure what to do about actual IPv6 entries as your prefix will likely change when your router is rebooted unless ISPs start handing out static /64s (the last 64 bits are stable as they are assembled from the MAC address with FFFE inserted in the middle). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Diffutils default editor set to ed by default
On 09/05/2011 11:58 AM, Bruce Dubbs wrote: I have never seen the use of an editor in diffutils, but I learn new stuff all the time. The only place DEFAULT_EDITOR_PROGRAM is in the code is sdiff. After some looking, I found Section 2.5.1 in the diffutils info page about 'ed' scripts. `diff' can produce commands that direct the `ed' text editor to change the first file into the second file. Long ago, this was the only output mode that was suitable for editing one file into another automatically; today, with `patch', it is almost obsolete. Use the `--ed' (`-e') option to select this output format. It looks like diffutils uses 'ed' to produce old style scripts. I have no idea if changing 'ed' to 'vi' will break this obsolete functionality or not, but it might. If the change is made, then it needs to be tested and the info page updated. I don't think it's worth the effort. I had no idea what it did...just seen it in passing, figured I'd throw it up here for somebody who used that functionality seeing as we no longer install ed. If you choose ed from the % prompt, it does indeed open the actual diffs with context (not the output file) in vi as expected, but the eb, el, er, e1, e2... commands all do the same thing, 'vi $tmpfile' sdiff -o file.diff file1.txt file2.txt %ed I can't see many people using that functionality, but it is configured incorrectly by default. :-/ Setting the EDITOR environment variable allows you to change it, but you'll never get the intended functionality out of any random editor value. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Add IPv6 localhost entry to /etc/hosts file
On 09/05/2011 12:12 PM, Bruce Dubbs wrote: Does IPv6 run in conjunction with IPv4. I think it does. I don't really understand all the issues with implementing IPv4. I think that we should hold off for now (after LFS-7.0) until we get a good handle on how it will be used. AFAIK, most internal networks will still use IPv4/NAT, but the single DHCP from the ISP or static IPs may well be IPv6. Nah, it'll probably be dual stack for a few years at least. As Zachary mentioned above, the local assigned address will be a non-issue, much as it is today for IPv4 dynamic addresses. We only need to concern ourselves with the loopback entry (::1). OT: IPv6 is much different in the way that auto-configuration/default route takes place. Your ISP will likely assign you a /48 or /64, and the router will advertise a /64 on the inside inerface(s) if the internal interface is assigned values. Everything else happens automatically with no additional tools with the exception of DNS. The last 64 bits are based on the MAC address. For instance, I'm currently using a 6to4 tunnel with tunnelbroker.net (my ISP was too slow to take up testing and I got impatient). My assigned address is 2001:470:c5bf::/48 on the tunnel adapter. IPs are automatically assigned to my other 4 interfaces on the router (my other 4 internal networks) based on my selection of a /64 (for which I assigned :1 to my internal network for a /64. My (obfuscated) MAC address on eth0 is 00:xx:8c:44:xx:xx, and my IP address (assembled from the network and MAC addresses) is 2001:470:c5bf:1:2xx:8cff:fe44:/64. Anyone feel free to poke around a bit at the subnet if you are capable BTW. I could use a sanity check on my routing rules (ICMPv6 is allowed to forward on 1 and 2). Routing rules are no different than in IPv4. The only current use of DHCPv6 is to assign DNS servers, and maybe for control freaks who want sequential addresses internally for some reason. The only problem I had implementing IPv6 was that I couldn't be lazy and rely on DST-NAT and MASQ. I had to assemble actual routing rules for my internal networks (there are about 35 in the IPv6 chain to cover my needlessly complex network vs about 15 when using nat and masq for the IPv4 segments to provide services to both the outside and internal networks). When it was all said and done, I feel like I learned a bit (on a new platform - MikroTik RouterOS), and had to re-learn an awful lot as well, but IMO, sink or swim is the best possible learning method. :-) -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Bootscripts rewrite
, log
only when the following is true:
if [ ${PREVLEVEL} == N || ${PREVLEVEL} == S ]; then...
or optionally (as was done previously):
if [ ${RUNLEVEL} != 6 || ${RUNLEVEL} != 0 ]; then...
Also, a little OT, but while doing major surgery anyway, didn't anybody care
for the single line configuration format for the network that Bruce
suggested?
Maybe comma-space delimited would be better than colon delimited as
originally
suggested:
# Begin eth0.conf
#IFACE, SERVICE, PARAMS
eth0, ipv4-static, 192.168.1.1, 24, 192.168.1.254, 192.168.1.255
eth0, ipv6-static, 2001:270:cb5f:5::, 64, MAC
eth0, ipv4-static-route, 192.168.2.192, 26, 192.168.1.2, 1
# End eth0.conf
Of course, these could also be separated into 3 files named
1stNIC.ipv4.conf,
ipv6.eth0.conf, and route-to-192.168.2.192\/26.conf if desired.
I think that about covers it for now. After we dig in a little further,
we'll
see if there is anything else. To be honest, after looking at that list and
seeing all the presumed breakage, I'd really like an explanation as to
how you
came to the conclusion that a rewrite was in order as opposed to
'fixing' the
scripts that were already written. I understand that education was the
focus,
but I had thought the judicious use of comments in the extended
functionality
of the LSB scripts would have provided much more educational value.
Again, not
as simple, but certainly no high bar for entry either.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Diffutils default editor set to ed by default
On 09/05/2011 11:58 AM, Bruce Dubbs wrote: DJ Lucas wrote: Taken from cross-lfs: sed -i 's@\(^#define DEFAULT_EDITOR_PROGRAM \).*@\1vi@' lib/config.h Any reason not to do this in LFS? I have never seen the use of an editor in diffutils, but I learn new stuff all the time. The only place DEFAULT_EDITOR_PROGRAM is in the code is sdiff. After some looking, I found Section 2.5.1 in the diffutils info page about 'ed' scripts. `diff' can produce commands that direct the `ed' text editor to change the first file into the second file. Long ago, this was the only output mode that was suitable for editing one file into another automatically; today, with `patch', it is almost obsolete. Use the `--ed' (`-e') option to select this output format. It looks like diffutils uses 'ed' to produce old style scripts. I have no idea if changing 'ed' to 'vi' will break this obsolete functionality or not, but it might. If the change is made, then it needs to be tested and the info page updated. I don't think it's worth the effort. -- Bruce vimdiff gives similar functionality...though I'd likely never use it. Actually, on second thought, that could be pretty useful! I may wind up adding that to my regular toolset yet. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts rewrite
On 09/05/2011 07:48 PM, Bruce Dubbs wrote:
DJ Lucas wrote:
LSB defined functions belong in /lib/lsb/init_functions so that
compliant
bootscripts work as expected. Do not include the LSB definitions directly in
the distro's functions file. Either source them in the distribution's
functions or move the distribution's functions to the end of
/lib/lsb/init_functions and source only the one file (preferred method as
discussed previously in the LSB thread).
I've got the network service scripts in /lib/boot. I don't have a
problem with renaming /lib/boot to /lib/lsb/ and functions to
init_functions, but I'm not sure about having two new directories in
/lib. I lean toward moving the LFS functions to the end of the a single
init_functions file.
Okay...later question requires review of the spec to see if we can add
other items there, but again, lsb is not descriptive for networking
services. The spec requires /lib/lsb (and later /usr/lib/lsb), and the
discussion earlier wanted the service scripts separated. Need input form
all to see if this is acceptable.
There is no reason to redefine 35+ values every time a new script is
run. Once per runlevel change in rc is sufficient. One conditional
around the source line in each script, on a known constant should be
good, and will be more efficient, and nominally faster than sourcing
2 or 3 files for every script that is run.
I don't really follow this. Do you mean sourcing the functions within
the rc file? If so, environment variables have to be exported to be
available in child scripts. Additionally the scripts need to have the
variables available if not run from the rc file.
If I misunderstand you, please elaborate.
No, you didn't misunderstand. The variables have to be exported. That's
why there used to be a testcase around the source of distro functions in
/lib/lsb/init_functions. It was taken out with some of the more recent
changes (merger of $distro-functions and /lib/lsb/init_functions) and I
had forgotten to put it back. The getty does not pass the variables to
the login shell when rc passes control. Take a look at the LSB scripts
and default/rc{,.site} for the items that remain. It's probably a minor
point anyway, but something that was lost in multiple rewrites. Also,
stty sane can go now...it breaks input when run in x terminals in some
cases with our now proper input configurations, it was ^J and ^Z IIRC in
UTF-8 locales, been a few years since I ripped that out. Also, any idea
why the screen is cleared on tty1? I looked but didn't see anything.
Get rid of boot_mesg all together. This was left over from a mixed
results attempt at international messages and long display output
(and line wrapping). As James mentioned the other day, it has long
since been abandoned by all of us involved with adding it. Both the
echo binary and the bash built-in support the -e flag. We can choose
/bin/bash for the schebang in the scripts, or just use /bin/echo. The
built-in is faster, but we can guarantee that /bin/echo has the
needed functionality if the /bin/sh symlink is changed. Personally, I
prefer the /bin/bash schebang, but really no technical argument
either way.
I prefer /bin/bash too, but left everything as /bin/sh (and used
non-bash constructs). I think there may be a problem if a non-LFS
script uses /bin/sh and the functions use /bin/bash.
I agree that we can guarantee echo -e works and let the shell decide to
use a builtin or /bin/echo.
Get rid of echo_*() and friends and just use print_*_msg() in these
cases. Handle boot logging in the print_*_msg() functions as per the LSB
spec (framework is already there if the LSB functions are copied directly).
Where did /lib/boot come from?
Alzheimer's. I got my SS card on Saturday. Is that a :) or a :(
LOL
/lib/services was discussed and approved for
the network services by 5 participants (yourself included) back in May with
only one objection on naming which was later retracted. boot is also a
poor choice for the name if the network services are stored here as they
will be used after boot.
I'm not real happy with /lib/services AND /lib/lsb, especially if
lib/lsb has only one file. How about /lib/services and a symlink from
/lib/lsb to /lib/services?
Again, spec review is required. That is a tomorrow thing. Need input
from others here as well because of the separation that was a goal in
the previous discussion.
Same thing for /etc/sysconfig. Consensus was
reached among participants to use /etc/default to help clean up the /etc
directory a tiny bit, and /etc/network for network configuration scripts.
I'd like to revisit that. The way I've done the network scripts, there
are no subdirectories to /etc/sysconfig and all the scripts are in the
form of ifconfig*. On a simple system, there is only ifconfig.eth0, but
things like ifconfig.eth0.ip2 are honored. sysconfig stands for system
configuration and I think more descriptive than
Re: unknown HZ value message still appears in procps utils
On 06/07/2011 05:16 AM, LANOUX Bertrand wrote: Hi all, I have noticed the unknown HZ value message still appears at boot time and under some unpredictable circumstances when running the ps command, even after applying the procps-3.2.8-fix_HZ_errors-1.patch (I currently use a SMP, 2.6.38.4 tickless kernel). So after looking inside the procps code and patch, I deduced the linux_version_code variable was not correctly valued. After starting to make my own patch, I came across a similar issue when looking over the net (seen on http://www.linuxquestions.org/questions/slackware-14/slackware-13-37-rc-unknown-hz-value-after-procps-upgrade-871679/). It seems the constructor functions don't run as the package expect on recent libgcc. After applying it, the message definitively disappeared. The patch is attached (another solution is to prioritize the constructor functions). It works well since quite a while for me now, so may it be taken into account for those who have encountered the same inconvenience. Have a look ? Thanks for reading, Bertrand. Upstream patch committed as procps-3.2.8-fix_HZ_errors-2.patch. Still needs to be updated in the book. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Diffutils default editor set to ed by default
Taken from cross-lfs: sed -i 's@\(^#define DEFAULT_EDITOR_PROGRAM \).*@\1vi@' lib/config.h Any reason not to do this in LFS? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc is causing segfaults in SDL (and according to redhat's bugzilla, other programs as well)
On 09/01/2011 11:21 PM, Bruce Dubbs wrote: Nathan Coulson wrote: Glibc-2.28.8 Pretty sure that the glib version and the glibc version were mixed up. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Apply MPFR upstream patch releases
According to the home page, we should be applying the upstream patches found here: http://www.mpfr.org/mpfr-3.0.1/allpatches See bugs section at: http://www.mpfr.org/mpfr-3.0.1/ -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Rewrite bootscripts and Chaper 7
On 09/01/2011 11:54 PM, Jeremy Huntwork wrote: On Sep 1, 2011, at 9:03 PM, Bruce Dubbsbruce.du...@gmail.com wrote: What I did is basically the same as the LSB scripts, but updated for /run and to streamline the file locations. The only outstanding issues are network related in some relatively rare cases (e.g. multiple IPs attached to a single interface or not brought up at boot). That's great, but it still doesn't answer why. I just don't get what the objection is to the LSB scripts. JH I believe complexity was the main objection. I've not yet had the time to test Bruce's rewrite. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Rebuilding glibc results in an infinite loop
On 08/31/2011 11:05 AM, Bruce Dubbs wrote: William Tracy wrote: Hello, First, I would like to congratulate the LFS team on the 7.0 rc. Good job, people. :-) I'm working through a build right now. I screwed up on the original build of glibc, but did not notice until running the test listed in section 5.8 of the book. I went back, wiped my glibc build directory, and tried to rebuild from scratch. When I issued 'make', the build entered an infinite loop. It took me a day and a half to realize this._ After much digging around, I found a source online that suggested that this would happen if the glibc headers were already present under $PREFIX/include. I moved /tools/include to /tools/include-old, copied the kernel headers back to /tools/include, and now the build seems to be proceeding normally. Obviously, this was caused by a mistake on my part, but it seems like an easy enough mistake to make, and the result is not intuitive to debug. So, can I suggest adding a bullet point to the book addressing this potential trap? This seems odd. I haven't tried rebuilding using Chapter 5 procedures, but I've certainly rebuilt from a standard LFS system without problems. Moving /tools/include would also move the kernel headers so you would need to back up and reinstall at least those. In cases like these, especially for those only a few steps into Chapter 5, we usually say that you should wipe everything and just start over. Can you give us a pointer to the online source you are referring to? Yes please. I am experiencing this exact issue now on a 32bit cross build of glibc. I just had a system board failure and apparently the CMOS battery is dead or near dead. Any possibility that the system time was the issue William? make[4]: Warning: File `/tools/include/linux/limits.h' has modification time 28327 s in the future I didn't bother tracking it down further. I've corrected the system time. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Partial update of bootscripts
On 07/14/2011 09:13 PM, Bruce Dubbs wrote:
Group networking scripts and explain how the are configured.
Also, I'm thinking of moving the current 'network' config file to
init_params since it is only defines one environment variable. If we
leave it as a separate file, it should be renamed to 'hostname'.
I also want to put the configuration of sysklogd in init_params. That
requires a minor change to the init.d/sysklogd script that I haven't
made yet.
I deleted the contrib section because I think it has mostly been
incorporated into the new scripts. For LSB, we need to add init-tools
to BLFS.
And add in /lib/lsb/initd_functions (either by symlink if it is extended
to account for all of the functions, or by separate file) and LSB headers.
Feedback is welcome.
-- Bruce
I didn't get a chance to install yet, but did a quick walk through, and
barring any simple errors, they look good, nice and clean too. More time
tomorrow hopefully. Suggestions: need to add LSB headers to all of the
scripts -- even though they are not LSB scripts (and LSB does not
require them to be), we still need to be able to track the dependencies
in order to use the LSB tools {install,remove}_initd if you still want
to go after LSB as a possible goal to be completed in BLFS. Boot logging
would be a major request by me as it's been requested several times in
the past. Every distro provides this now and it might be expected by
some users (especially nice to have on headless systems). Also, since
if{up,down} will be system tools, they need to have help text added at
very least on error...but wait to see what happens when/if the single
config is done.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Partial update of bootscripts
On 07/12/2011 04:14 PM, Andrew Benton wrote: I agree, I'd like to see a hint, but not enough to actually do the work myself... I'd look into it, but I just don't think either are quite ready for prime time, besides I like the idea of runlevels too much to give them up just yet. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Question about the 'K' and 'S' in script names in /etc/rc.d/rc{0, 6}.d
Moved to LFS-Dev.
On 07/17/2011 07:57 PM, Bruce Dubbs wrote:
DJ Lucas wrote:
On 07/17/2011 02:51 PM, Bruce Dubbs wrote:
DJ Lucas wrote:
Actually, this check needs to be removed. It causes issues for the alsa
script and also setclock (if used to set hwclock when network goes down
in RL2).
Wouldn't this be just as easy as creating symlinks S50setclock in rc0
and rc6 in the LFS Makefile? In the same way, creating S35alsa symlinks
in the BLFS Makefile would save the asla settings.
No. Drop to RL1 with alsa volumes restored via udev for an example of
why that block should be removed. It doesn't matter for 0 and 6 because
the check is skipped. It's been a while, but IIRC, the same thing for a
K??setclock link in RL2.
I don't understand. What we have now is:
snip code
In rc1.d I have K30sshd, K80network, K90sysklogd, S25random. The same
in rc2.d. setclock is executed in rcsysinit.
If alsa utils is installed, you should have K links in RLs 0,1,2,6 and
no start links as the volume restore is handled by udev.
If I add S50setclock and S40alsa to rc{0,6}.d, the '-f ${prev_start}'
fails and the continue is never executed. The command is run with the
stop parameter in both cases and does the right thing, AFAICT.
Oh, actually, setclock should not be run in rcsysinit any longer. that's
for udev to handle now as well. That is where the issue comes into play.
The alsa script should write the volumes to disk when switching from
runlevel 3 to runlevel 2 (no net == no usr == no alsactl) or especially
RL1 as the rootfs might be RO, and it certainly wasn't started by a
script in RL3, but by udev (please ignore the FHS /usr argument as we
are still bound by it for now). You should see the same issue (not
started in previous runlevel) if you were to put Kxxsetclock in rc2.d or
rc1.d and telinit 2 or 1.
This is proper IMO when using NTP, but not really useful in practice.
Agree, except if the hw clock is too far off, ntp is unhappy.
That is the point, to set hwclock when dropping network so that it'll be
that much closer when you jump back into 3/4/5probably really
doesn't matter unless you are in RL2 overnight and system timer is way
outta whack (in which case you have bigger problems).
Are you suggesting that we just remove the 'if' block above? I'd think
that might add some strange failures at shutdown, but shouldn't hurt
anything.
Yes, that is exactly what I was suggesting. Using S links in 0 and 6 for
alsa does nothing for RL1 and RL2. Besides, as mentioned earlier in the
thread, the S links in 0 and 6 _were_ intended to be reserved for very
specific system requirements. I'm not really sure if ALSA, or anything
outside of the base LFS for that matter, should get special treatment here.
With the LSB defined return values, it didn't matter because stopping an
already stopped service results in a return value of 0 (an OK message).
In the case of alsa, this doesn't even apply, you're not stopping a
service, only writing a file, there should never be a failure here
unless it is run late or you did something that makes /etc read only.
Also, I don't really see how we could get a bunch of warning/error
messages with current scripts (though I haven't really used the stock
scripts for more than a few minutes at a time since 2006). Everything
installed by the books is handled in all 7 runlevels or sysinit, with a
few exceptions, notably the two above (and only alsa is mentioned in
either of the books).
The prevlevl check has simply been outdated by modern tools (udev).
Going back to the LSB return values mentioned above, the warning
messages about items not running at shutdown are not really useful. I
mean, what can you do about it at that point? Same thing for the not
started in previous runlevel message...just exit 0 and paint a pretty
green message on the screen. If the pid file checks are rewritten, again
I'll refer to the LSB scripts pidofproc(), you can simply bypass the
execution and exit 0. This also fixes the issue with the apache script
killing children first.
Again, I don't particularly like it (yet), but I have a feeling that
we'll begin to see more and more of this in the future. Network cards
could conceivably be next in line (think of turning on your wireless
card on your laptop), so it makes some sense to rewrite ifup and ifdown
now, along with the network script (which could be also be replaced by
NM or something similar after LFS). As much can be reused in the future,
the better. Of course, I could be very wrong in my prediction, but I
figure rather than introduce a couple of corner cases, you should
probably go ahead and nip what we can in the bud now while you are
familiar with the work that needs to be done.
Free time is still not what it should be for me right now, but I'll jump
in an make some comments on your changes (if needed/wanted) as soon as I
have time to install and test.
-- DJ Lucas
--
This message
Re: Bootscript reorganization
On 07/07/2011 02:53 PM, Bruce Dubbs wrote: The file I have in mind is /etc/sysconfig/network. I think we can use variables like eth0_onboot=yes eth0_ip=1.2.3.4 etc Alternatively we could use something like: #TYPE:IP:PREFIX:MASK:GATEWAY:BOOT eth0=static:192.168.1.1:24:192.168.1.255:192.168.1.1:onboot If you really want to go to a single config file, why not take a peak at how Ubuntu does their networking scripts then? I don't know how they work internally, but parsing logic seems obvious enough on the surface. The single config file, /etc/network/interfaces, is used there and looks fairly nice and is certainly self explanatory: = # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 = Seem easy enough to parse that...grep for ^auto and pass field 2 to ifup. Bryan's example works here too, just append the following to the file: = # Turn on Wake-On-LAN for eth0 iface eth0 ? WOL = The ifup script greps for all lines containing ^iface $1 (which also has the type and service fields), record the line numbers found, get type and service from those line numbers (f3 and f4 resp.), next line, next line, next line until a ^#, empty line, or EOF is found. Pass the following lines to the service script on a single line and let the service script handle the arguments in a shifting while loop. Same process for ifdown except to take the highest numbered line first. We probably don't even need the type field. Doesn't get to look any nicer than that for single config file and our existing modular method for extending the available services can be reused (although they'll require some modifications). We can even tear down the interfaces properly based on a running cache constructed the same way (as was suggested a few weeks ago in the LSB thread). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscript reorganization
On 07/19/2011 12:29 AM, DJ Lucas wrote: The ifup script greps for all lines containing ^iface $1 (which also has the type and service fields), record the line numbers found, get type and service from those line numbers (f3 and f4 resp.), next line, next line, next line until a ^#, empty line, or EOF is found. Pass the following lines to the service script on a single line and let the service script handle the arguments in a shifting while loop. Actually, we could do all of that on the next line after an iface line. I still don't see the need for type yet...also didn't look at your new scripts yet Bruce, just throwing out ideas in an older part of the thread that had stuck with me. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Question about the 'K' and 'S' in script names in /etc/rc.d/rc{0, 6}.d
On 07/19/2011 12:20 AM, Bruce Dubbs wrote:
DJ Lucas wrote:
If alsa utils is installed, you should have K links in RLs 0,1,2,6 and
no start links as the volume restore is handled by udev.
No, we don't have anything at RL2. At least not now. The BLFS Makefile
has:
ln -sf ../init.d/alsa ${EXTDIR}/rc.d/rc0.d/K35alsa
ln -sf ../init.d/alsa ${EXTDIR}/rc.d/rc1.d/K35alsa
ln -sf ../init.d/alsa ${EXTDIR}/rc.d/rc6.d/K35alsa
Oh, that is broken then in stock scripts. I've have it in mine for a
long time. FHS issue, one that really shouldn't exist today. I think
the udev rule is in the same state though.
Yes, writing to /etc for configuration is wrong. It should write to
/var/cache/alsa or similar or more likely /home/.config/alsa/state, not
/etc. I agree that dropping to RL1 should do this, but not RL2. It's a
design problem in alsa.
Actually, I haven't done a manual change of run level is several years.
I like to start in RL3 and stay there until shutdown. It's easy to
type startx and the boot is a lot faster. For those who are command
line impaired, I guess a change from RL5 to RL3 is sometimes needed, but
C-A-D for reboot and shutdown for halt is all I ever use.
I can't remember the last time I used RL1 or RL2 for any reason.
Traitor! That's the perfect argument for upstart (systemd too?). ;-)
Again, I don't particularly like it (yet), but I have a feeling that
we'll begin to see more and more of this in the future. Network cards
could conceivably be next in line (think of turning on your wireless
card on your laptop), so it makes some sense to rewrite ifup and ifdown
now, along with the network script (which could be also be replaced by
NM or something similar after LFS).
I already rewrote ifup/ifdown and added a way to write multiple
(optional) scripts for a single interface. There will need some new
services written for BLFS and wireless can be complicated and a bit tricky.
I really need to look...shooting for tomorrow if I get home early
enough. I'm out for the night.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Bootscript reorganization
On 07/07/2011 12:33 PM, Jeremy Huntwork wrote:
This is requesting feedback on many of the exact things we discussed in a
recent thread, although some of the conclusions were different.
I can't pull up the exact thread at the moment since I'm on the road, but DJ
should be able to point the way.
Thanks,
JH
Sorry for the lack of attention, I too have been very busy lately. I'm
available for a short time now.
On Jul 7, 2011, at 12:31 PM, Bruce Dubbsbruce.du...@gmail.com wrote:
I've been looking at the bootscripts and want to do some fairly major
reorganization. I'm putting this out as a basis of discussion.
1. Remove /etc/sysconfig/rc
Presently this does
rc_base=/etc/rc.d
rc_functions=${rc_base}/init.d/functions
network_devices=/etc/sysconfig/network-devices
The indirection this provides does not appear to be needed to me. Each
boot script now does:
. /etc/sysconfig/rc
. ${rc_functions}
I don't see a need for this. Each script can have this replaced with
the simpler
. /etc/rc.d/functions
2. Remove /etc/sysconfig/network-devices
Move the scripts ifdown, iftest, and ifup to /sbin.
Up until here, you are consistent with the recent changes in LSB
bootscripts. Are you intending to scratch those completely? Even if LFS
does not use the scripts we've worked on for the past few years, the
rewritten ifup/ifdown could probably be reused effectively as they were
written specifically for being placed into /sbin, but see below...
Integrate
ipv4-static* into the if* commands.
3. Place all configuration parameters for the network into
/etc/sysconfig/network.
This would include the HOSTNAME as well as any information in
/etc/sysconfig/network-devices/ifconfig.*/*
These I'm a little curious about. I really like the modular approach of
one directory per interface, so I'll be a hard sell, but an example that
accounts for BLFS additions would certainly be desirable.
---
I think these changes will make the LFS bootscripts more understandable
and easier to administer. There will be a lot of changes as basically
every bootscript will have to be touched. Sections 7.11 and 7.13.2 of
the book will also have to be reworked.
We can use the opportunity to review and update the /etc/rc.d/rc and
/etc/rc.d/functions scripts.
Yes, there is a lot of unused/outdated stuff in there now and much room
for improvement. A complete restart would be good. I'd also like you to
consider using the rc script additions from the LSB bootscripts and some
of the logic from the initd_functions if you decide to avoid the LSB
scripts as a whole.
I am requesting feedback.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: svn bootscript regression
On 06/07/2011 06:20 PM, Archaic wrote: Network interface configuration used to be either a file or a directory named ifconfig.interface. With the latest lsb-compliant bootscripts, it seems that the bootscript won't accept a file and neither will ifup unless using -c. Is this intentional? It was done intentionally. I was not aware that anyone had ever used a file named ifconfig.interface and this was not documented anywhere. I removed it because it simply because it was one more test case in ifup and ifdown. I could certainly put it back. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: unknown HZ value message still appears in procps utils
On 06/07/2011 05:42 AM, Gilles Espinasse wrote: the upstream code does not use the changes in http://www.linuxfromscratch.org/patches/lfs/development/procps-3.2.8-fix_HZ_errors-1.patch only the __attribute__((constructor)) fix http://procps.cvs.sourceforge.net/viewvc/procps/procps/proc/ Actually, LFS should probably take into consideration the the Debian/Fedora/openSUSE fork once a stable release is made. http://gitorious.org/procps Many, many more fixes in there...was some talk of procp-ng. There were a couple of interesting items in there last time I looked, but I do not recall specifics. Not really sure why gitorious was chosen over alioth for project home either...curious. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscript regression
On 06/07/2011 11:33 PM, Bruce Dubbs wrote: You are right. That's the way I remember it too. I never liked it though. A single file that is edited would be better for LFS. The system is designed so a distribution package manager can just drop in files. That's easier for a distro, but harder for a person to understand. It was much easier for BLFS too! BTW, aren't we a distro yet? ;-) I'll add the functionality back in this weekend. I'm also not going to get the other changes in until tomorrow night as my new directory server has been a little bit more of a PITA than anticipated. I was having a bit of difficulty in getting my custom attributes to play nicely, but it is all resolved now, or at least I hope it is. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc-2.14 issues
On 06/06/2011 03:07 PM, Matthew Burgess wrote: I'd prefer for us not to use HJL's binutils Then don't. That patch doesn't look all that invasive..no need to add tests for local build fix, just the 3 corrected files (bottom of the list). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 05/30/2011 08:19 PM, Bruce Dubbs wrote: Dan Nicholson wrote: On Mon, May 30, 2011 at 12:55 PM, Bruce Dubbsbruce.du...@gmail.com wrote: DJ Lucas wrote: On 05/30/2011 12:34 PM, Bruce Dubbs wrote: In the latest svn, the bootscripts are lfs-bootscripts-20110424. I get an error: Â make[1]: /usr/lib/lsb/install_initd: Command not found This was identified a week ago by xinglp, but I don't see a fix. Â Â -- Bruce Either need to roll back the inadvertent commit to the bootscripts tarball job or move forward with the patch I sent in. Let me know if I should do this. I'd appreciate it if you could do a revert. Done. Â I took a look at the patch and it installs initd-tools as yet another package. Â I looked at the source to initd-tools and I don't understand why we need a C program to do that. Â It could be done in a shell script. That would require some effort to create, but would be much easier to maintain. Perhaps I can try writing the script after the middle of next month. Â We have a big deadline coming up. Â After that, Â I think I've earned about a year of comp time. Try writing as a shell script, Bruce. DJ did before and found that my C version was much, much faster. Parsing the dependencies and building a tree in an interpreted language with no data structures is a nightmare. In C it's a linked list of structs. Just my opinion, though. I'll take a look and perhaps I'll come to the same conclusions. I'm not sure speed is the issue though. Oh yes it is! At least in shell with a couple of calls to sed and grep anyhow. :-) I wish I had seen this prior to my other message. Please allow me to save you some time as I speak from experience. Of course, you are certainly welcome to try, but as Dan mentioned above, it was an absolute nightmare in bash, unless I just way over thought it. You are limited to a group of arrays and a rat's nest of complex loops. Dividing into smaller functions and making it more linear might help a little with readability, but I still fear that you'll be dealing with insane loops. Also, in the event of a reciprocal dependency (which is actually an error in the script being installed), the potential for infinite loops exists without error checking on every iteration (which means more calls to grep further slowing things down). As for other _interpreted_ languages, I didn't really get far enough with perl to evaluate it, plus I don't actually know it well enough to write a utility that I'd want distributed (it was a learning exercise). Perl certainly provides a more advanced/polished tool set with which to work and seems somewhat of an obvious step WRT LFS (if you really want to use an interpreted language that we already have access to), while Python is the current flavor per Debian (and at least was for other distributions back in 2007/2008) and did seem to work well at that time. Here is the current set of tools that Debian uses: http://ftp.debian.org/pool/main/l/lsb/lsb_3.2-27.tar.gz I just figured that was immediately out with LFS as it added yet another group of dependencies for which a base package will have to be rebuilt in BLFS (that's two added packages unless the install_initd and remove_initd scripts are included in the bootscripts package). Plus with the exceptionally slow move to Python 3 lingering...it just doesn't seem like a good fit for LFS, at least IMO. With the above said, however, I'm still partial to Dan's tools as I've used them for so long and they seem to work well for our purposes. Another set of eyes on that code would certainly be welcome too I'm sure, and perhaps they can be extended in time to include an lsb-config utility (of course, that could easily be written in shell too, I imagine that wouldn't take more than half an hour). Well anyway, there is some food for thought. I hope it helps. See my other message as well if you do decide to proceed with a new tool as there are at least a couple of corner cases that don't immediately spring to mind when doing the outline. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 05/31/2011 10:21 AM, Bruce Dubbs wrote: Thanks for the input. Personally, I like php for scripting, but that isn't appropriate for LFS. Perhaps we are overthinking here. The trouble I had was using install_initd in the lfs-bootscripts Makefile. If we just get that fixed and put Dan's initd-tools in BLFS, it would work out. After all, we don't make LFS completely LSB compatible (e.g. no package manager), so postponing initd-tools seems reasonable. Yeah, I had thought about PHP, and I know you are good at that. I suppose waiting until BLFS would work, then it could be up the user to select which tool set is best for them. I don't exactly like that idea personally, but it should provide a working compromise. Gimme a day to figure out how to handle the Makefile and we'll see if it is a plausible solution or not--install_initd should be used if available (think upgrades) with a fallback to a predefined order if not, for new installs. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 05/30/2011 12:34 PM, Bruce Dubbs wrote: In the latest svn, the bootscripts are lfs-bootscripts-20110424. I get an error: make[1]: /usr/lib/lsb/install_initd: Command not found This was identified a week ago by xinglp, but I don't see a fix. -- Bruce Either need to roll back the inadvertent commit to the bootscripts tarball job or move forward with the patch I sent in. Let me know if I should do this. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 05/30/2011 02:55 PM, Bruce Dubbs wrote:
I'd appreciate it if you could do a revert. I took a look at the
patch and it installs initd-tools as yet another
package. I looked at the source to initd-tools and I don't understand
why we need a C program to do that. It could
be done in a shell script. That would require someeffort to create,
but would be much easier to maintain.
I'll jump in and fix that for now real quick then, I'll also add the
subsystem call to udev script, but IDK about scripting
{install,remove}_initd. Initd-tools is one extra package, it's tiny, it
works, and being only in C, the maintenance burden is likely to be very
small.
Perhaps I can try writing the script after the middle of next month.
We have a big deadline coming up.
After that, I think I've earned about a year of comp time.
I'll wish you luck then. ;-) Been there, done that. It was really slow
in just bash (and a couple hundred sed and grep calls), but was a neat
learning exercise none the less. For fun, I then wound up using make to
handle dependencies and the script was almost fast enough to be usable
(somebody had suggested using make as a replacement for init in some
passing conversation and I thought it a neat idea). :-) Then I decided
to use it as an excuse to learn perl. Dan came up with initd-tools
before I really even got started on it in perl (which I still do not
know well BTW). I thought C would be perfect (no additional dependencies
for LFS), so I scrapped all three previous attempts.
At any rate, here are a couple of caveats that I vaguely remember
causing me to start from scratch or make major changes to the way I was
doing things a few times:
1. Scriptname != Facility. Admittedly, this seems obvious now.
2. Do not fall into the trap of looking at /etc/rc.d/init.d and
expecting all scripts to be activated. The easiest method I came up with
for a list of activated scripts was to run through all of the rc?.d
directories to assemble a list of link targets. From that list, I then
read all of the headers into multiple arrays and worked only from the
index with the new script as the last in the array so that disk i/o was
limited to the beginning and end of the script.
3. Don't forget about start links in 0 and 6 which will be dependent on
both *-stop and *-start of the current runlevel, but not scripts
supplied in runlevel S (formerly sysinit).
4. All other runlevels will have to account for items started in
runlevel S.
5. The Default-St{art,op} does not have to define in which runlevels any
existing activated scripts are started, but both Dan and I, while
working independently, chose to do so as the spec does not limit the
program in that way, and the note at the bottom of
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html
does not seem to indicate that will change. LFS does not provide any
existing automation, and in practice this is really the most direct way
of managing runlevel 4 if needed, and provides similar functionality to
insserv or chkconfig in Suse or RedHat without any added complexityor
additional tools(in fact, in all test cases that I could come up with,
it greatly simplifies the job to always reorder as opposed to trying to
fit a script in between others).
HTH
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/21/2011 12:32 PM, Jeremy Huntwork wrote: On 5/21/11 12:52 PM, DJ Lucas wrote: Oh, I didn't realize that it had continued beyond the new network script and ifup/ifdown scripts, or rather I read it as just example, not an actual suggestion. Give me a few minutes to run through the thread again. I didn't actually see the new scripts. I took a cursory look at what was in subversion and it looked the same as before... Maybe I missed something? JH Well, so much for a few minutes. As far as what has changed at this point, ifup and ifdown were completely rewritten for use in /sbin (help text added, -d option for a configuration directory, -c option for a configuration file (used by the updated network script), -f option to do a flush and down of interface in ifdown, and long -- options are accepted for each). I have come to the conclusion that it'll have to be made modular for BLFS purposes, and each of the network service scripts adjusted to account for the added functionality. Basically, at the end of the network script, cycle through all network interfaces in /sys/class/net/*, and run each interface name through the available scripts in /lib/network-devices to see if the associated service is running for the interface, and kill it if so. The default ipv4-static and ipv4-static-route scripts will be excluded as when the interface link is set down, the kernel will take care of any actual ipv4 or ipv6 addresses and routes in the kernel routing table. Also, any issue with reverting back to /etc/rc.d/* on your end? This appears to work with shipped package bootscripts if a /etc/init.d - /etc/rc.d/init.d symlink is created. If so, it will be a simple Makefile value change (make ETCDIR=/etc install) as I'll take care of fixing the path in /etc/default/rc in the Makefile and in process-scripts.sh for the book. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/21/2011 12:20 PM, Bryan Kadzban wrote: DJ Lucas wrote: There are a couple of packages, non-obvious packages at that, that install their own bootscripts and they work in the current proposal without modifications using the lsb functions. I must not install them, then. Alternately, I do install them, but don't care to use their bootscripts (I think that might apply to one; fcron, bind, dhcpcd v5, or something like that, maybe). :-) I suspect that we'll see more in the future, however, I have not actually confirmed that they do not work within the old layout (sysinit/S change is required). Changing sysinit to S is fine. I don't generally use the rc*.d directory names, just init.d. Bryan pointed out that the old layout lent itself better to tab completion, the savings is only one keystroke, but you actually have to type more _characters_ in the new layout as opposed to pressing tab repeatedly. I don't yet know how much work is involved in reversing that decision, but it should at least be discussed. If other packages are a concern, then I think an /etc/init.d symlink might work as well. There's already too much in /etc that starts with in or ini, so adding one more entry there doesn't seem too bad. I dislike littering /usr/sbin with symlinks, for the record. I actually dislike it even more since it's in /usr, given that these are links to bootscripts, but moving it to /sbin is also pretty bad (since now it's a much larger chunk of a small directory). It's also one more set of links that needs to be kept up to date (though that's probably rare). The service script might work, but it's a complete re-training for me, and I'm a bit of a curmudgeon. That's probably not a reason to avoid doing it, though. :-P Yes, tested, /etc/init.d symlink works as expected with at least fuse (one I had handy). I went ahead and defaulted to /etc/rc.d in the Makefile and made the value of ETCDIR change /etc/default/rc appropriately, and added a symlink if ETCDIR is not /etc. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
Okay. There will still be one change to the network script *after* I get BLFS bootscripts into place. Attached (revised) patch makes all necessary changes as of 20110523-0515 UTC. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. LSB-1.patch.xz Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
believe that is the remainder of the concerns. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/21/2011 07:10 AM, Jeremy Huntwork wrote:
On 5/21/11 2:48 AM, DJ Lucas wrote:
I do plan to add a service script later that would alleviate the issue
completely, as was suggested by Jeremy a few months ago, but I'm a
little stuck as far as how to handle multi-level, conditional tab
completions in bash, so it is on hold for a sec. Plus, I haven't seen
how Jeremy and Archaic handle that in LightCube OS yet. My simple
solution turned out to be not as simple as I had thought. That may even
turn out to be a C program included with initd-tools or somewhere
later...IDK as it hasn't been discussed yet. Jeremy, Archaic, any
ideas/suggestions on that?
We've kept it simple, but possibly we have not met all the reqs:
http://dev.lightcube.us/sources/lsb-bootscripts/service
And then that's just installed to /usr/sbin:
http://dev.lightcube.us/projects/lightcubeos/repository/entry/lightcube_os/trunk/packages/lsb-bootscripts/lsb-bootscripts.spec
Ok, cool. Thank you for the links. That was the direction I had headed.
I got stuck with the bash completion though. Every time I try to use a
second conditional for tab completion, those options of second functions
in the event of -W, show in the first list. What I would like to do is
use the value of $prev (in the example below) to set another variable
that greps for Usage:, sed out that and the brackets, and use IFS of
| to display the options for the selected script. The example below is
good enough to get a list of available scripts by typing servitabtab
#!/bin/bash
# Begin /etc/profile.d/service-completion.sh
#
# service scriptname {start|stop|restart|reload|force-reload|status}
#
__service()
{
local cur prev opts
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
prev=${COMP_WORDS[COMP_CWORD-1]}
opts=$(ls /etc/init.d | sed 's@/etc/init.d/@@')
COMPREPLY=( $(compgen -W ${opts} -- ${cur}) )
}
complete -F __service service
# End /etc/profile.d/service-completion.sh
While that is kind of cool IMO, I really do want it to spit out the
script options as well. Prior to a few days ago, I had never explored
the complete command.
2nd, Jeremy's concern was the contents of rc.site. I agreed with all
suggestions, including combining lfs-fucntions with init-functions, save
one. I've made all the agreed changes locally. Most of everything in
rc.site has been moved into rc, with the exception of clock params,
hostname, conditional boot off/on and prompt time, boot logging off/on,
and the command that is run when a boot script ends in an unexpected
error ('read Enter' in our case). The last one I had just added and was
on the fence about, but after consideration, I've decided that to be
something that should be user configurable. Perhaps a function is best,
as I had suggested originally instead of putting a command in a variable
in a user configuration file. Make it configurable there by a simple
yes/no for PAUSE_ON_ERROR or some such.
Sounds great. I can live with that.
Ok. I'll skip the easy way out. :-)
Theads got long quick, and a little OT at times, but I do believe that
is the remainder of the concerns.
Are we treating the handling of network down logic as a separate issue?
I think there was still some discussion out on that one.
Oh, I didn't realize that it had continued beyond the new network script
and ifup/ifdown scripts, or rather I read it as just example, not an
actual suggestion. Give me a few minutes to run through the thread again.
JH
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/21/2011 11:17 AM, Robert Xu wrote: On Sat, May 21, 2011 at 08:10, Jeremy Huntwork jhuntw...@lightcubesolutions.com wrote: On 5/21/11 2:48 AM, DJ Lucas wrote: I do plan to add a service script later that would alleviate the issue completely, as was suggested by Jeremy a few months ago, but I'm a little stuck as far as how to handle multi-level, conditional tab completions in bash, so it is on hold for a sec. Plus, I haven't seen how Jeremy and Archaic handle that in LightCube OS yet. My simple solution turned out to be not as simple as I had thought. That may even turn out to be a C program included with initd-tools or somewhere later...IDK as it hasn't been discussed yet. Jeremy, Archaic, any ideas/suggestions on that? We've kept it simple, but possibly we have not met all the reqs: http://dev.lightcube.us/sources/lsb-bootscripts/service And then that's just installed to /usr/sbin: http://dev.lightcube.us/projects/lightcubeos/repository/entry/lightcube_os/trunk/packages/lsb-bootscripts/lsb-bootscripts.spec Have you guys thought of using insserv? It's what SuSE has been using for years and what Debian Squeeze and on is using. No, I haven't looked at it. I think it is a bit more than what we were looking for initially, but that could certainly be an option. For right now, I'd like to use the simple method as it will certainly come to completion on the stated goal a little quicker. What we have now (in this thread) works well enough. Or, you could just symlink all the initscripts to a rc location in /usr/sbin/rcscriptnamehere like /usr/sbin/rcnetwork for tab completion. I don't think the tab completion would be any better in that you'd have to add an additional complete command every time a script is added to the system as opposed to it being dynamic (see my response to Jeremy). There is a simple solution, others use it in a case statement for a different purpose, I just haven't been able to understand it just yet as the documentation is lacking IMO. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
Bruce Dubbs bruce.du...@gmail.com wrote: Matthew Burgess wrote: Firstly, thanks for taking the time to do this, it looks pretty good to me. I haven't had time to review yet. Secondly, what follows are probably bike-shed topics, but I'll throw my 2p in along with everyone elses anyway :) : make-aux-files.sh: Why renaming things to lsb-bootscripts? If we're migrating (which I think we should), shouldn't we just move the lsb scripts out of contrib and then continue to refer to the package as the lfs-bootscripts? Package name is still lfs-bootscripts, only directory name changed in svn. Reason is to avoid losing svn history (for both sets). At go time, we can 'svn mv' in whatever way is appropriate without losing history. I was thinking the same thing. Also, would this change, along with the /run, etc changes, be enough to roll the LFS version to 7.0? Maybe, up to you all. I've still got the DESTDIR changes POC coming along as well. Surprizingly, a lot changed to account for the /lib64 - /lib hack so it doesn't present nearly as well as it used to. -- DJ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
Matthew Burgess matt...@linuxfromscratch.org wrote: On Wed, 18 May 2011 12:16:22 -0500, DJ Lucas d...@linuxfromscratch.org wrote: Alright, with last commit to lsb-bootscripts, I think we are ready to go. Bruce, Matt, you guys get a chance to review the patch? Hi DJ, apologies for the delay, but I've now managed to review your patch. Firstly, thanks for taking the time to do this, it looks pretty good to me. Secondly, what follows are probably bike-shed topics, but I'll throw my 2p in along with everyone elses anyway :) : make-aux-files.sh: Why renaming things to lsb-bootscripts? If we're migrating (which I think we should), shouldn't we just move the lsb scripts out of contrib and then continue to refer to the package as the lfs-bootscripts? No change, just file layout in SVN. chapter07/console.xml: 1) Where did the consolelog script/configuration go? echo kernel.printk=4 /etc/sysctl.conf chapter07/network.xml: I quite like Red Hat's layout, but probably just because I've become accustomed to it through my day job. On that distro, network device config lives in /etc/sysconfig/network-scripts, and those files namely ifcfg-ifname and route-ifname. I certainly don't see the need for subdirectories under whichever directory is chosen to house the network configuration files, but maybe I'm being blinkered by my only needing static wired interfaces to be configured. Might have to configure multiple services on one interface, for instance ip and ipx, or maybe one interface does not provide default gw, but a static route is still needed for a dual homed machine. Why are network scripts put under /lib/network-services? Again, possibly blinkered by my exposure to Red Hat, but keeping the service scripts in the same directory as the interface config files makes sense to me. Executables don't belong in /etc, this one was covered in Jeremy's thread. --DJ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/18/2011 08:57 PM, Jeremy Huntwork wrote: On 5/18/11 9:26 PM, DJ Lucas wrote: Results of a bad sed? I hadn't noticed that, only fixing the misspelling in the dependencies. Prior to that commit it was kernel when it was mountkernfs. Fixing. Thanks. Ha ha, the ones in the parentheses got me, it looked intentional. I actually googled for 'linux virtel' thinking maybe there was some new terminology I missed somewhere. :) JH I hit dictionary.com before I realized what happened. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Using the LSB Bootscripts
On 05/17/2011 11:34 PM, Bryan Kadzban wrote:
Few nits related to the shell. In the network script:
# Process individual configuration files
for file in `ls ${dir}`; do
Ew. :-) How about:
for file in ${dir}/* ; do
ONBOOT=`grep ONBOOT ${file} | sed ...
...
I had used it that way for debugging to create a list. There was a
reason that it was left that way, but I can't for the life of me recall
what it was, and it obviously wasn't important.
(since it always does a ${dir}/${file} as written)
In the ifup/ifdown scripts:
else
grep ${INTERFACE} /proc/net/dev 21 /dev/null
if [ ${?} != 0 ]; then
Why not a (simpler):
if grep ${INTERFACE} /proc/net/dev 21 /dev/null ; then
instead? (This is done in several places: anywhere the script is
testing the value of $? can potentially be simplified.)
Simply preference, it looks more explicit to my eyes if someone wants to
review the script and learn from it. I went ahead and changed all four
examples to inline tests.
echo ERROR: ${INTERFACE} is not a valid network interface.
echo
exit2
That should be exit 2, right? :-)
Fixed.
fi
fi
Thanks for the review.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: udevadm --settle
On 05/16/2011 12:59 AM, Bryan Kadzban wrote: DJ Lucas wrote: stuff about settle being broken I see some traffic on linux-hotplug about this as well, so it looks like it's not LFS-specific, at least. (Arch and Debian have both had bugs reported about this.) The messages from Kay so far seem encouraging, as well. ...Oh, and I see the message from you there, too. OK, never mind. :-) It's looking like it'll get sorted out soon. I committed a patch to patches/udev/udev-168-settle-1.patch, should be added to the book. Also, while on the subject, in the udev README file they mention this change: dj [ lsb-bootscripts ]$ diff -au etc/init.d/udev /etc/init.d/udev --- etc/init.d/udev2011-05-14 22:17:45.0 -0500 +++ /etc/init.d/udev2011-05-18 12:08:33.0 -0500 @@ -73,7 +73,8 @@ # Now traverse /sys in order to coldplug devices that have # already been discovered -/sbin/udevadm trigger --action=add +/sbin/udevadm trigger --action=add --type=subsystems +/sbin/udevadm trigger --action=add --type=devices # Now wait for udevd to process the uevents we triggered /sbin/udevadm settle Seems logical, any reason not to? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/14/2011 11:12 PM, DJ Lucas wrote: Attached patch is pretty invasive, 33 KB uncompressed. :-) I wasn't sure whether to leave inittab in the book where it is currently, but I am thinking from a packaging POV that it should remain as is and be removed from the bootscripts tarball now. It was required in the tarball previously because of the path changes. -- DJ Lucas Alright, with last commit to lsb-bootscripts, I think we are ready to go. Bruce, Matt, you guys get a chance to review the patch? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/18/2011 01:58 PM, Jeremy Huntwork wrote: On 5/18/11 1:16 PM, DJ Lucas wrote: Alright, with last commit to lsb-bootscripts, I think we are ready to go. Bruce, Matt, you guys get a chance to review the patch? I've been looking over the scripts, they look good, nice job! There are a couple of things that I think I'd still prefer to see changed, if possible. The /etc/default/rc.site file still contains some things that I think don't quite belong in what is intended as an end-user configuration file (note, I'm thinking even beyond what we often think of as an _LFS_ end-user and more like a typical non-LFS end user) The first line is an RC_BASE definition. I can't possibly think why anyone would ever change this - if you change it to something besides /etc, everything breaks. You'd really have to modify a number of things in order for this to work, and if you're going to do that, you're more than an end user. /etc/default/rc seems more appropriate. Agree...and easily done. RC_FUNCTIONS=.../lfs-functions - I think I forgot to mention that we killed this completely in our modifications and just dumped it all to the end of /lib/lsb/init-functions. I don't really see a need to keep it separate. That is a bit of history trying to make the scripts compatible with the existing scripts until I got some into BLFS contrib that matched. It wasn't allowed at one point...or at least I thought it wasn't. After a quick review, I see nothing that prevents combination of the two. Last paragraph here (before the note at end of page): http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html and Second para of the first note allow combining them: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html NETWORK_DEVICES=/etc/network - Again, likely to ever be changed by an end user? The FAILURE_ACTION line and everything after: I see these all as installation configurations, not end user. It's either distro settings, colors for the display on the lines, prefixes for the types of notices, settings for interactive startup, if you're using it, exporting those variables and a function to print a message. Agree, with one possible exception: FAILURE_ACTION. A user might actually want to make the boot process pause in the event of a failure for troubleshooting purposes. I'm on the fence...can go either way. Anyone have an opposing argument? The only thing I personally think should stay in /etc/default/rc.site is the following, everything else should move to /etc/default/rc: # Bootlogging (requires a tempfs mount) BOOTLOG_ENAB=yes Can get rid of note about tempfs mount too...is unconditional now. # Hostname HOSTNAME=lfs # System time variables UTC=1 CLOCKPARAMS= JH -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/18/2011 05:50 PM, Jeremy Huntwork wrote: On 5/18/11 1:16 PM, DJ Lucas wrote: On 05/14/2011 11:12 PM, DJ Lucas wrote: Attached patch is pretty invasive, 33 KB uncompressed. :-) I wasn't sure whether to leave inittab in the book where it is currently, but I am thinking from a packaging POV that it should remain as is and be removed from the bootscripts tarball now. It was required in the tarball previously because of the path changes. -- DJ Lucas Alright, with last commit to lsb-bootscripts, I think we are ready to go. Bruce, Matt, you guys get a chance to review the patch? What's virtel? (In etc/init.d/mountvirtfs) JH Results of a bad sed? I hadn't noticed that, only fixing the misspelling in the dependencies. Prior to that commit it was kernel when it was mountkernfs. Fixing. Thanks. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/18/2011 05:50 PM, Jeremy Huntwork wrote: On 5/18/11 1:16 PM, DJ Lucas wrote: On 05/14/2011 11:12 PM, DJ Lucas wrote: Attached patch is pretty invasive, 33 KB uncompressed. :-) I wasn't sure whether to leave inittab in the book where it is currently, but I am thinking from a packaging POV that it should remain as is and be removed from the bootscripts tarball now. It was required in the tarball previously because of the path changes. -- DJ Lucas Alright, with last commit to lsb-bootscripts, I think we are ready to go. Bruce, Matt, you guys get a chance to review the patch? What's virtel? (In etc/init.d/mountvirtfs) JH Also used to say kernel-based changed to virtual. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Using the LSB Bootscripts
On 05/17/2011 08:54 AM, Jeremy Huntwork wrote:
On 5/16/11 1:49 AM, Bryan Kadzban wrote:
I'm not sure what the goal *should* be. :-) Does it make sense to try
to clean up completely in this kind of setup? Maybe or maybe not.
I do think it's least *surprising* to only undo the effects of the start
script, though. For whatever that's worth.
I do think we're getting a little overcomplicated here. Let's try to
simplify expectations. Here's what I expect (and I *think* this is
reasonable - you tell me :-) )
When I run the equivalent of /etc/init.d/network stop:
All devices configured to start ONBOOT are shut down, any addresses
assigned to them are removed (this of course means that if there is a
running dhcp service in the background, it won't add any addresses to
the device until I restart the network service).
When I run the equivalent of /etc/init.d/network start:
Any devices configured to start ONBOOT are brought up according to the
settings in their associated config file.
This behavior implies that I should be able to modify network devices on
the fly. If the service is restarted, the devices will only be activated
with configuration explicitly stated in the config files.
JH
With ifup and ifdown public, they needed to have predictable behavior
with invalid options, and provide a help text. Having been edited a
thousand times, those scripts had become kind of ugly to look at. At
very least, they are more linear, but IMO they are much cleaner and easy
to follow now.
Scripts attached for review.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
#!/bin/sh
# Begin /etc/init.d/network
### BEGIN INIT INFO
# Provides:$network
# Required-Start: $local_fs swap localnet
# Should-Start:$syslog
# Required-Stop: $local_fs swap localnet
# Should-Stop: $syslog
# Default-Start: 3 4 5
# Default-Stop:0 1 2 6
# Short-Description: Starts and configures network interfaces.
# Description: Starts and configures network interfaces.
# X-LFS-Provided-By: LFS
### END INIT INFO
. /lib/lsb/init-functions
case ${1} in
start)
# Start all network interfaces
for dir in ${NETWORK_DEVICES}/ifconfig.*
do
interface=${dir##*/ifconfig.}
# skip if $dir is * (because nothing was found)
if [ ${interface} = * ]; then
continue
fi
# Process individual configuration files
for file in `ls ${dir}`; do
ONBOOT=`grep ONBOOT ${dir}/${file} | sed 's@^ONBOOT=@@'`
case ${ONBOOT} in
Y* | y* | 0)
/sbin/ifup -c ${dir}/${file} ${interface}
;;
esac
done
done
;;
stop)
# Reverse list
DIRS=
for dir in /run/network/ifconfig.*
do
DIRS=${dir} ${DIRS}
done
# Stop all network interfaces
for dir in ${DIRS}; do
interface=${dir##*/ifconfig.}
# skip if $dir is * (because nothing was found)
if [ ${interface} = * ]; then
continue
fi
# Process individual configuration files
for file in `ls ${dir}`; do
# No checking necessary if it is in /run/network
/sbin/ifdown -c ${dir}/${file} ${interface}
done
link_status=`/sbin/ip link show ${interface} | \
grep -o state DOWN`
if [ ${link_status} != state DOWN ]; then
message=Shutting down the ${interface} interface...
/sbin/ip addr flush ${interface}
/sbin/ip link set ${interface} down
evaluate_retval standard
fi
done
;;
restart)
${0} stop
sleep 1
${0} start
;;
*)
echo Usage: ${0} {start|stop|restart}
exit 1
;;
esac
# End /etc/init.d/network
#!/bin/sh
# Begin /sbin/ifdown
#
# Description : Interface Down
#
# Authors : DJ Lucas - d...@linuxfromscratch.org
#
# Version : 00.02
#
. /lib/lsb/init-functions
function get_args()
{
if test -z ${1} ; then
showhelp
exit 1
fi
while test -n ${1} ; do
case ${1} in
-c | --configfile)
check_arg $1 $2
CONFIGFILE=${2}
shift 2
;;
-f | --force)
FORCE=1
shift 1
;;
eth* | iw* | wlan*)
INTERFACE=${1}
shift 1
;;
-h | --help)
showhelp
Re: Summary: Using the LSB Bootscripts
On 05/17/2011 08:54 AM, Jeremy Huntwork wrote: I do think we're getting a little overcomplicated here. Let's try to simplify expectations. Here's what I expect (and I *think* this is reasonable - you tell me :-) ) When I run the equivalent of /etc/init.d/network stop: All devices configured to start ONBOOT are shut down, Also anything configured by hotplug or any other method that uses /sbin/ifup with a configuration file as the config file will be in the state directory. When networking is stopped, there is no need to check the value of ONBOOT. Conditions on the value of ONBOOT could actually be harmful when stopping networking. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udevadm --settle
On 05/16/2011 12:59 AM, Bryan Kadzban wrote: DJ Lucas wrote: stuff about settle being broken I see some traffic on linux-hotplug about this as well, so it looks like it's not LFS-specific, at least. (Arch and Debian have both had bugs reported about this.) The messages from Kay so far seem encouraging, as well. ...Oh, and I see the message from you there, too. OK, never mind. :-) It's looking like it'll get sorted out soon. Tracked it down real quick to this commit: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=ff2c503df091e6e4e9ab48cdb6df6ec8b7b525d0 -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Using the LSB Bootscripts
On 05/16/2011 12:49 AM, Bryan Kadzban wrote: Zachary Kotlarek wrote: On May 15, 2011, at 12:31 PM, Bryan Kadzban wrote: I'm trying to figure out why it'd be necessary to do this. We already have the previous configuration of every interface stuffed away in /run, and we use that when deciding which service scripts to call when bringing down networking. Doesn't that kill the pppd / pppoe / dhclient / dhcpcd / whatever daemons already? And doesn't that remove the IPs that were configured already, for static? I thought the goal was to predictably handle scenarios where the running config didn't match the cached version, or where there was no cached version. While I don't want to speak for the people actually doing the work here, it seems to me like this might be getting a bit complicated for the wins here. I don't think it's very likely that there is no cached version (since we store it away at boot time when the scripts set up the interfaces). I also *think* the only way the cached config might not match the running config is if root mucked with the running config manually. And in that case, I don't think it's smart to override that decision. (Consider, for instance, a setup that requires two IPs on a single NIC, both on a single subnet -- say one for management and another for real traffic, with filtering upstream to prevent management packets from the public Internet. The management IP might be set up outside the scripts for some reason (especially at machine setup time, but potentially in other cases as well, for configuration management and redundancy reasons), in which case flushing all IPs at interface-down would be actively harmful.) Though I suppose this isn't terribly likely either. Hmm. If the goal is only to directly cancel the configuration as-cached, and not to care if that cache is no longer accurate or no longer exists, then I agree, there's no need to do any of this special handling as the normal service scripts should be sufficient. I'm not sure what the goal *should* be. :-) Does it make sense to try to clean up completely in this kind of setup? Maybe or maybe not. I do think it's least *surprising* to only undo the effects of the start script, though. For whatever that's worth. It is worth a lot, and I'm kind of in the same camp. However, there was a request, and I'd like for this to be the same solution for all _if_possible_. The thing is, what do admins typically do when using other distros? I know how I make changes in LFS, and that involves a temporary config file, stop networking, copy new config, start networking, which seems pretty obvious to me having been using LFS for so long. When I use a distro, I usually use some distro supplied tool to make configuration changes, but I only maintain maybe 10 distro Linux servers at this point, and couldn't tell you the last time I had to make networking changes. This may not be the case for somebody who has been using say RedHat on 50+ servers for the past 10 years and knows the format of the configuration files like the back of her hand. For instance, take a temporary configuration change, admin might simply run 'ifdown eth0' (or 'service network stop') expecting all the configuration changes to go out the window right then (I don't honestly know if that is the case in other distros, I know that it works as is for ). I don't think that is unacceptable, it's just finding a working solution that is agreeable by everyone. An argument can equally be made for root changes to be undone by root (as above, and I am actually in that group). As far as I'm concerned, what is there now works well enough for my purposes, and probably greater than 99.99% of all users, but I don't mind spending the extra time to explore the possibility of additional functionality to cover the other less than .01%, but I do need to step back for a second and take into account all arguments for/against. If I do come up with what I think to be a working solution, it certainly won't go in without review because I don't use the other services very often (at all right now, everything is static now). I need to see if it would reek havoc on other corner cases such as the one mentioned above. It may be that we can't meet everyone's expectations (which is why I haven't simply added 'ip addr flush $1' to the end of the ifdown script yet). That is another thing too, now that ifup and ifdown are no longer in a controlled environment and available to admins without mucking around in the network-devices tree, some error checking needs to be done in the scripts for proper arguments and maybe a help text. As it is now, if you run ifdown on an interface that has no config file, you get a warning and an ugly error message from bash. That will probably be another small change that doesn't have any affect the existing automated setup. -- DJ Lucas -- This message has been scanned for viruses
Re: Summary: Using the LSB Bootscripts
Bruce Dubbs bruce.du...@gmail.com wrote: Zachary Kotlarek wrote: On May 16, 2011, at 12:49 AM, Bryan Kadzban wrote: I also *think* the only way the cached config might not match the running config is if root mucked with the running config manually. Or when /run is not writable at the time the network scripts execute. The only way that could happen would be if rcsysinit.d/S00mountvertfs failed to execute which means that the whole system would fail. You wouldn't have /proc or /sys either. Actually, that is handled by rc directly now. -- DJ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Using the LSB Bootscripts
On 05/15/2011 12:11 AM, Zachary Kotlarek wrote: Could we just do this in ifdown: if [ -x /lib/network-services/dhcp ]; then /lib/network-services/dhcp $interface down fi and assume that whatever DHCP client is installed (if any) provides a script appropriate to handle the interface shutdown? Zach Actually, yeah, that is a great idea! We had planned to merge the dhcp scripts anyway to simplify Gnome-System-Tools interface management in BLFS. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Using the LSB Bootscripts
On 05/15/2011 01:39 AM, Nathan Coulson wrote: On Sat, May 14, 2011 at 9:36 PM, DJ Lucas d...@linuxfromscratch.org mailto:d...@linuxfromscratch.org wrote: On 05/14/2011 04:37 PM, DJ Lucas wrote: Everything is covered per this conversation in SVN with the exception of accounting for missing /run in LightCube OS, but I think it was decided that it would be added. Also no ip flush (I forgot, but will get it in a day or two) on down interface, and dhcp calls not accounted for. I'll need to setup both DHCP clients to test functionality for this, which is why I didn't just do it tonight. The problem I want to avoid is if we do a flush, but the client daemon is still running, come expiration, the client daemon might try to reconfigure the device...even if it means adding dhcp logic in the lfs scripts (or replacing them in BLFS). Also, is anyone still using RP for PPPoE, alos simple ppp, that is willing to test? I unfortunately no longer have a ?DSL circuit to test with so I'll need some help from somebody who does. I would think if the link is set down the client daemons for the dhcp clients would exit, but would ppp attempt to reconnect? I'm also thinking that the added functionality for ifdown can be done in a modular way in /lib/network-services so that it can be divvied up for each who needs it. -- DJ Lucas dhclient, and dhcpcd checks, does get ugly if we test for specific programs. I always liked avoiding package specific work. (and there are other dhcp clients out there. My openwrt has dnsmaq for example) Yeah, could use a bit of help here actually. I'm thinking about providing default service config values in the service script itself (to be over ridden by the config file), and a guard at the top of the service script for IFCONFIG, and just walking the /lib/network-service tree from ifdown. This seems easiest, and more importantly, most efficient in that for each service, a generic stop target can can be called for an interface (as opposed to down), and the service script has the logic, not the ifdown script. This makes it extensible for whatever you want to throw at it. For instance, in the case of both dhcp cleints, you check for the appropriate lease file, or just exit 0. Have to explicitly exclude ipv4-static and ipv4-static-route, reason being we'll flush all IPs on the interface, so ipv4-static is not needed, and when the link is dropped, the kernel will drop the static routes as well. Do you see anything wrong with that logic? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/14/2011 02:47 PM, Bruce Dubbs wrote: DJ, You need to change the version/release date in general.ent and lfs-bootscripts-version in packages.ent to actually publish the bootscript changes. Do you wnat me to do it? -- Bruce No, I'm still working on them. Besides, they are in contrib and are no longer compatible with the instructions in the book. I have just about completed the necessary changes. I made a mistake when I reread the original thread and put the interface configuration files in /etc/network-devices instead of /etc/network. The big changes are coming in a few moments, after I go back and fix the placement of the network config files. There is really no need for a change in the book until we are ready to switch (which requires some other changes to the book anyway). I also plan to move them out of the bootscripts folder before they go into the book and move the old to bootscripts-old afterward. I'll post a patch for the necessary book, udev-config, and rendering changes to the list at that time. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Summary: Using the LSB Bootscripts
Everything is covered per this conversation in SVN with the exception of
accounting for missing /run in LightCube OS, but I think it was decided
that it would be added. Also no ip flush (I forgot, but will get it in a
day or two) on down interface, and dhcp calls not accounted for. Quite a
few changes are required for the book to work with them now including:
* rendering of scripts in the book, path and name changes
* tarball creation with book render job
* inittab is installed by the bootscripts package (this could be changed
if desired)
* initd-tools page needs to be added
* the path for the setclock script in 55-lfs.rules needs to be changed
* the network interface configuration file should be placed in
/etc/network/ifconfig.int/
* setting clock parameters for the setclock script is done in /etc/rc.site
* setting the hostname is now done in /etc/rc.site
* add mention of turning off bootlogging and interactive prompt
For LightCube OS (or anyone else that would like to customize the
scripts for their release), hopefully all that is needed is a similar
patch to the one below, in addition to the one adding additional
services and scripts (which will need to be rediffed for the new file
layout),
diff -Naur lsb-bootscripts-20110514/etc/default/rc.site
lsb-bootscripts-20110514-LCOS/etc/default/rc.site
--- lsb-bootscripts-20110514/etc/default/rc.site2011-05-14
16:00:31.0 -0500
+++ lsb-bootscripts-20110514-LCOS/etc/default/rc.site2011-05-14
16:30:27.0 -0500
@@ -9,7 +9,7 @@
BOOTLOG_ENAB=yes
# Hostname
-HOSTNAME=lfs
+HOSTNAME=lightcube
# System time variables
UTC=1
@@ -17,12 +17,12 @@
# Manual input is not appropriate on remote systems. Define what
happens when
# an error is encountered that interupts the boot/shutdown proceess
-FAILURE_ACTION=read ENTER
+FAILURE_ACTION='echo '
# Distro Information
-DISTRO=Linux From Scratch # The distro name
-DISTRO_CONTACT=lfs-dev@linuxfromscratch.org # Bug report address
-DISTRO_MINI=lfs # Short name used in filenames for distro config
+DISTRO=LightCube OS
+DISTRO_CONTACT=http://dev.lightcube.us/projects/lightcubeos/issues;
+DISTRO_MINI=lightcube
# Define custom colors used in messages printed to the screen
BRACKET=\\033[1;34m # Blue
@@ -45,9 +45,9 @@
export PREFIX_SUCCESS PREFIX_WARNING PREFIX_FAILURE
# Interactive startup
-iprompt=yes # Wether to display the interactive boot promp
+iprompt=no # Wether to display the interactive boot promp
itime=2 # The ammount of time (in seconds) to display the prompt
-dlen=29 # The total length of the distro welcome string
+dlen=23 # The total length of the distro welcome string
ilen=38 # The total length of the interactive message
welcome_message=Welcome to ${INFO}${DISTRO}${NORMAL}
i_message=Press '${FAILURE}I${NORMAL}' to enter interactive startup
diff -Naur lsb-bootscripts-20110514/Makefile
lsb-bootscripts-20110514-LCOS/Makefile
--- lsb-bootscripts-20110514/Makefile2011-05-14 16:00:31.0 -0500
+++ lsb-bootscripts-20110514-LCOS/Makefile2011-05-14
16:26:42.0 -0500
@@ -25,7 +25,7 @@
install: create-dirs
install -m ${MODE} etc/init.d/checkfs ${EXTDIR}/init.d/
install -m ${MODE} etc/init.d/cleanfs ${EXTDIR}/init.d/
-install -m ${CONFMODE} etc/init.d/lfs-functions ${EXTDIR}/init.d/
+install -m ${CONFMODE} etc/init.d/lfs-functions
${EXTDIR}/init.d/lightcube-functions
install -m ${MODE} etc/init.d/halt ${EXTDIR}/init.d/
install -m ${MODE} etc/init.d/console ${EXTDIR}/init.d/
install -m ${MODE} etc/init.d/localnet ${EXTDIR}/init.d/
Think that covers it all. Time for some testing.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/14/2011 04:09 PM, Bruce Dubbs wrote: DJ Lucas wrote: On 05/14/2011 02:47 PM, Bruce Dubbs wrote: DJ, You need to change the version/release date in general.ent and lfs-bootscripts-version in packages.ent to actually publish the bootscript changes. Do you wnat me to do it? -- Bruce No, I'm still working on them. Besides, they are in contrib and are no longer compatible with the instructions in the book. I have just about completed the necessary changes. I made a mistake when I reread the original thread and put the interface configuration files in /etc/network-devices instead of /etc/network. The big changes are coming in a few moments, after I go back and fix the placement of the network config files. There is really no need for a change in the book until we are ready to switch (which requires some other changes to the book anyway). I also plan to move them out of the bootscripts folder before they go into the book and move the old to bootscripts-old afterward. I'll post a patch for the necessary book, udev-config, and rendering changes to the list at that time. OK, sounds good. -- Bruce Attached patch is pretty invasive, 33 KB uncompressed. :-) I wasn't sure whether to leave inittab in the book where it is currently, but I am thinking from a packaging POV that it should remain as is and be removed from the bootscripts tarball now. It was required in the tarball previously because of the path changes. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. LSB.diff.xz Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Using the LSB Bootscripts
On 05/14/2011 04:37 PM, DJ Lucas wrote: Everything is covered per this conversation in SVN with the exception of accounting for missing /run in LightCube OS, but I think it was decided that it would be added. Also no ip flush (I forgot, but will get it in a day or two) on down interface, and dhcp calls not accounted for. I'll need to setup both DHCP clients to test functionality for this, which is why I didn't just do it tonight. The problem I want to avoid is if we do a flush, but the client daemon is still running, come expiration, the client daemon might try to reconfigure the device...even if it means adding dhcp logic in the lfs scripts (or replacing them in BLFS). Also, is anyone still using RP for PPPoE, alos simple ppp, that is willing to test? I unfortunately no longer have a ?DSL circuit to test with so I'll need some help from somebody who does. I would think if the link is set down the client daemons for the dhcp clients would exit, but would ppp attempt to reconnect? I'm also thinking that the added functionality for ifdown can be done in a modular way in /lib/network-services so that it can be divvied up for each who needs it. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udevadm --settle
On 05/11/2011 11:14 PM, Bryan Kadzban wrote: DJ Lucas wrote: After updating from udev-165 to udev-168, I ran into a timing issue with settle using tmpfs for /dev. My swap partition failed to mount because the device node was not present. No other changes than those made to the bootscripts and FS layout to account for /run. Ah. /run. Does settle not work with the new location of the udev database? I rebooted a few more times to see that the problem was consistent. One other variable is that I'm using new bootscripts (which _should_ provide a very minimal speed increase), but order is the same as stock LFS. Is it easy to swap them out for the standard scripts? Easy enough to do for troubleshooting purposesdelete rc.d symlink, install regular bootscripts, correct setclock path in 55-lfs.rules, modify inittab path to rc, but it'll have to wait till the weekend. What happens if you boot with init=/bin/bash, then manually run scripts one at a time, until you get to udev, then both (a) run it, and (b) list out /dev/sd*, in the same shell command? What happens if you do (a) and (b), then (c) rerun udevadm settle, then list again? (All in the same command again.) Where is your swap? /dev/sda3...which gives a much better explanation as to why it works with devtmpfs. I did not buy the faster bit. (I'm thinking the kernel isn't sending the event to udev in time after the trigger. There's no way settle can wait for an event that udevd doesn't know about yet.) I think you hit the nail on the head there. Have to get logging going to same files on a tmpfs to be sure. We are likely talking about a very small timing issue. I think, at least in my case, a couple hundredth seconds sleep would suffice after trigger...wonder what would be worst case scenario on say i586. A tenth second? If the event is in queue, I suspect settle will work as expected. Alternately, the man page isn't real clear about --seq-end, will settle sit there and spin until that event number is reached or timeout is reached, or will it check the empty queue and continue? If the former, set the value to around 200 and give a really low timeout, say 1 second. Following a hint I found on a Debian mailing list claiming that devtmpfs was faster, I enabled devtmpfs, commented out the /dev mount in the udev script, and sure enough, the problem resolved itself. Even if you use a symlink to the swap partition? (Say, something in /dev/disk/by-uuid.) I'd be extremely surprised. The kernel will put raw sd* device nodes into devtmpfs for you, but using anything more stable in userspace will still have problems if udevadm settle is broken somehow. As above, that's why the devtmpfs works. 1. The obvious one (at least to me) is to force the use of devtmpfs as upstream has intended, and remove the /dev mount from the udev script. Still breaks if you want to use stable names, I believe. 2. Add a sleep to the end of the udev script (how long?). Not that I like this, but this is what the livecd did. It added a rootdelay=xx, to stuff an extra sleep xx in the initramfs. Can do a really low value, .1? 3. Changing bootscript order to put checkfs before swap should give enough time for udev to get the coldplug events handled and written to the tempfs. Except then one of the targets for checkfs will be missing. :-) Yep. Bad idea. 4. It is a local issue and my troubleshooting skills are not up to par. ;-) Incorrect path for setclock script in 55-lfs.rules - not related and works fine BTW. 5. (I really really hate this one...) Bite the bullet and set up a fully dynamic set of bootscripts, interfacing with udev directly. (Because black magic, a la upstart or systemd, is *obviously* the right way to go. Sigh.) So mounting a given filesystem will only happen after the proper device node shows up (and will depend on udev, which will depend on kernel FSes), and then anything that requires that FS will depend on the mounting script. It's a *LOT* of work though, for what I thought was very little gain. However, if upstream has broken settle, we may not have much of a choice... :-( No, settle is supposed to work for normal sysv setups. Something must have been broken in new trigger. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udevadm --settle
On 05/11/2011 11:25 PM, Bruce Dubbs wrote: DJ Lucas wrote: After updating from udev-165 to udev-168, I ran into a timing issue with settle using tmpfs for /dev. My swap partition failed to mount because the device node was not present. No other changes than those made to the bootscripts and FS layout to account for /run. I rebooted a few more times to see that the problem was consistent. One other variable is that I'm using new bootscripts (which _should_ provide a very minimal speed increase), but order is the same as stock LFS. Following a hint I found on a Debian mailing list claiming that devtmpfs was faster, I enabled devtmpfs, commented out the /dev mount in the udev script, and sure enough, the problem resolved itself. Now, that said, I'm probably a bit of a minority with so many partitions on my disks and this surely has some weight, however,the results are consistantly reproducable on my system. Why settle is not doing what it is intended to do is beyond me. We are only discussing a very small amount of time, a few ms at best here, so I see a couple of options: 1. The obvious one (at least to me) is to force the use of devtmpfs as upstream has intended, and remove the /dev mount from the udev script. I don't use either. I prefer a persistent /tmp, but that's just me. If I download a file, say a pdf, from the browser, it saves it to /tmp even though it goes directly to the pdf reader. I'd rather it takes up disk than ram and I prefer it to stay in /tmp until I specifically delete it. Yes, I modified cleanfs. I don't think we are referring to the same thing. DEVTMPFS provides a minimal /dev (a tmpfs mount) immediately after the kernel mounts the rootfs. Aparently it is a little more populated than I had thought as /dev/sd* devices exist there which is why it worked for me...and probably would for most users (except those really well versed in udev tricks using device by id or labels and such). I prefer simplicity a good part of the time, but there are many exceptions. Fortunately, device naming is not one of those exceptions. - Device Drivers - Generic Device Drivers () path to uevent helper [*] Maintain a devtmpfs filesystem to mount at /dev [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs CONFIG_UEVENT_HELPER_PATH= CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y 2. Add a sleep to the end of the udev script (how long?). Two seconds has been reported as working. 3. Changing bootscript order to put checkfs before swap should give enough time for udev to get the coldplug events handled and written to the tempfs. That seems like a reasonable approach, but it may not be enough depending on the size and number of the partitions and if they are clean or not. 4. It is a local issue and my troubleshooting skills are not up to par. ;-) I doubt it. udev is a bit troublesome. I suppose there could be a custom udev rule to automatically mount the swap partition when, say /dev/sda3, becomes available. That's probably not really satisfactory though. This is what upstream wants. See below... Another thought would be to do something like: while ! -b /dev/sda3; do sleep 1; done swapon -a settle has an option for just that, but I don't think it is the right fix. Seems to me that something must have been broken in trigger, else, given the reliable reproduction of my current problem and the reliability of the work around, I would have seen the same issue well before now. The problem seems to be inherent with dynamic devices. If you try to do something before the driver tells udev it's there, the operation will fail. It's a race condition. I don't see a solid solution that will work in every case. -- Bruce Sure there is...a fully event driven init as Bryan described earlier. I just don't find that to be transparent enough for my taste, nor udev quite mature enough just yet (as evidenced by this very issue), though it is getting there slowly but surely. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
udevadm --settle
After updating from udev-165 to udev-168, I ran into a timing issue with settle using tmpfs for /dev. My swap partition failed to mount because the device node was not present. No other changes than those made to the bootscripts and FS layout to account for /run. I rebooted a few more times to see that the problem was consistent. One other variable is that I'm using new bootscripts (which _should_ provide a very minimal speed increase), but order is the same as stock LFS. Following a hint I found on a Debian mailing list claiming that devtmpfs was faster, I enabled devtmpfs, commented out the /dev mount in the udev script, and sure enough, the problem resolved itself. Now, that said, I'm probably a bit of a minority with so many partitions on my disks and this surely has some weight, however,the results are consistantly reproducable on my system. Why settle is not doing what it is intended to do is beyond me. We are only discussing a very small amount of time, a few ms at best here, so I see a couple of options: 1. The obvious one (at least to me) is to force the use of devtmpfs as upstream has intended, and remove the /dev mount from the udev script. 2. Add a sleep to the end of the udev script (how long?). 3. Changing bootscript order to put checkfs before swap should give enough time for udev to get the coldplug events handled and written to the tempfs. 4. It is a local issue and my troubleshooting skills are not up to par. ;-) I'm fairly sure that I've proven #1, and disproven #4. Haven't tested 2 or 3 yetworking on that now. More later. -- DJ Additional note: Setclock failed to run the first time, but ran fine for the replay. This also did not happen for 165. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using the LSB Bootscripts
On 05/09/2011 10:33 PM, Bryan Kadzban wrote: DJ Lucas wrote: You know what? I think we are over thinking this. How about a state file? Upon successful initialization of an interface, copy the config file to a subdir of /run/network. The ifdown script sources the running copy if it exists and removes it on successful stop of the interface, or ip down interface if it does not exist and exits 0. Ooo, I like that idea. :-) Now, to get time to hack it together... :-( I'm just about done with the DESTDIR POC (still need to add instructions to account for lib64 - lib since I did this on multilib first) but that can use some time to mature a bit anyway, so should have time on Wed if one of y'all don't get there first. The current task list is as follows (for which I believe we have consensus from those who have chimed in so far): * Most important, pull as much as possible of the items below from LightCube OS's files to ease merging and keep the diffs to a minimum so that they are easily shared across distributions. * Move ifup and ifdown scripts to /sbin. * Move network service scripts to /lib/services (there was one minor objection here, should that be /lib/network-services or /lib/network? I don't really have any preference here, /lib/services is fine by me). * Move network configuration files to /etc/network. * Move network (hostname value) and clock config into /etc/default/rc.site (default to UTC?) * Use /etc/default for rc configuration files (remaining items in /etc/sysconfig currently). And here is a summary of remaining items that have not come to consensus or haven't been brought up previously in this thread: * Add initd-tools to book - This is required for the new scripts. Jeremy what is the status on this in LightCube OS? I remember a few months ago about you possibly taking over maintenance of them, adding a service binary/script and such? At last check, Dan did not have them in an RCS, which is not an issue for now, just curious about the future of the tools. The tarball and homepage are available in Dan's home directory on freedesktop.org if we need for the book. Dan? * Add configurable function to handle script errors in place of 'read Enter'. Of course, the option exists to kill that completely, but it puts the error in plain sight for desktop users. * ifup - copy configuration file from /etc/network/$int/$file to /run/network/$int/$file upon successful initialization of the interface. * ifdown - source configuration files from /run/network/$int/*. * ifdown - if interface configuration files do not exist, ip addr flush $int, ip link set $int down, exit 0. * The three items above are the best I think we can do with it and should cover 99% of all cases, the known exceptions being starting the dhcp client or ppp client manually, and possibly manual configuration of wireless interfaces (I've never configured wireless in LFS - also what about VPN tools started manually?). I believe Bryan is already on board with these changes, Bruce, Jeremy, Zach? * svn mv BOOK/bootscripts/contrib/lsb-v3 BOOK/LSB-Bootscripts. * merge necessary changelog entries and readme from original bootscripts with LSB-Bootscripts. * Add a copy of the MIT license file to bootscripts. * Add needed changes to book rendering for new bootscripts (I have this done locally). * I just noticed, need to fix setclock UTC logic to use case as in all others for 0|y*|Y*|t*|T*,1|n*|N*|f*|F*,* exit 2 (invalid argument). * Remove selective boot - personally I'd rather keep that in place simply because it was requested so many times in the past, but possibly disable the functionality by default? * Do something with the tmpfs used for the boot log...in fact, we could probably setup the /run mount point directly in the rc script and remove it from mountvirtfs. Hope I didn't miss anything, but I've got to go. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using the LSB Bootscripts
On 05/10/2011 07:25 AM, DJ Lucas wrote: I'm just about done with the DESTDIR POC (still need to add instructions to account for lib64 - lib since I did this on multilib first) but that can use some time to mature a bit anyway, so should have time on Wed if one of y'all don't get there first. The current task list is as follows (for which I believe we have consensus from those who have chimed in so far): * Use /etc/default for rc configuration files (remaining Oops...that should be in the bottom list. Sorry Bryan. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
