Rebuilding glibc results in an infinite loop
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? William Tracy afishion...@gmail.com Cell phone: (805) 704-0917 Internet phone: (707) 206-6441 -- 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
This is the post that finally pointed me in the right direction: http://www.linuxfromscratch.org/pipermail/lfs-support/2010-December/040001.html Even if I hadn't been able to pinpoint the problem to /tools/include, it was nice to confirm that the issue was indeed something I had messed up earlier (as opposed to, say, my system clock being on the fritz) but was something outside of the package build directory (which is why starting that package over again didn't help). William Tracy afishion...@gmail.com Cell phone: (805) 704-0917 Internet phone: (707) 206-6441 On Wed, Aug 31, 2011 at 9: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? > > -- Bruce > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS' future server plans
This may not advance this particular discussion very much, but: What I would love to see, and what I'm actually surprised that nobody in the FOSS community has built yet, is a discussion board system with a separated back-end that can be attached to multiple front-ends. The same install could have a web-based front-end and an email front-end, and both would be first-class citizens. (Bonus points if the different front-ends can share account information, so you can post the email interface from home, and the web interface on a public computer somewhere, and the system will understand that both messages come from the same account.) >From there, you could extend the system with an arbitrary number of front-ends: A client that pushes new thread notifications to Twitter? Sure. A bot that pushes new post information to IRC? Sure. A client that automatically generates a new post with every push to revision control? Sure. Multiple web front-ends, because someone wants an app written in PHP, and someone else wants an app built with Ruby on Rails? Sure. I already have enough projects on my plate, but if anyone out there wants to build this, I might be able to pitch in. :-) William Tracy afishion...@gmail.com Cell phone: (805) 704-0917 Internet phone: (707) 206-6441 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS' future server plans
On Mon, Sep 12, 2011 at 3:27 PM, Matthew Burgess < matt...@linuxfromscratch.org> wrote: > That said, if other folks want to explore other options that fit their > needs better, > Okay, I'll actually throw in my two cents this time: Web-based forums seem to be really popular with people who have trouble with the whole concept of managing mailing list subscriptions, or who are just too impatient for subscribing and then unsubscribing from lists, and those people aren't exactly the target audience of LFS. Having formatting and smilies that won't get messed up across different email clients seems to be another attraction, but this crowd seems to consider that to actually be a negative. The only real advantage for LFS that I can think of would be the ability to participate without publicly sharing your email address. I would suggest that the class of people who want to do that would probably be better served by IRC, anyway. Besides, LFS users really should know how to create a throw-away email account if it comes down to that. FWIW, in the FOSS projects I've seen that provide both a mailing list and a web forum, the forum tends to get used by the "non-technical" users, and the mailing list gets used by the developers and the occasional power user. I think that speaks volumes about which is more appropriate for a project with the words "from scratch" in its name. :-) William Tracy afishion...@gmail.com Cell phone: (805) 704-0917 Internet phone: (707) 206-6441 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Direction
On Sat, Jan 14, 2012 at 9:49 AM, Gerard Beekmans < ger...@linuxfromscratch.org> wrote: > One of the downsides with putting those things in BLFS is that people > then find out about them too late. If you want to setup a system with > initramfs and LVM configurations, that needs to be done early on in the > LFS book. If you find out after the fact you end up having to re-do the > LFS installation again. > > A compromise solution would be to still do a write-up about the various > options in the LFS book. Explain what it's all about, the pros and cons > but if it's decided to be out of LFS' scope then refer to the > appropriate sections elsewhere. This keeps the work flow intact: make a > sound and informed decision on how to partition your system early on. > My 2 cents, FWIW: Cover initramfs in BLFS, and include an explicit reference to that section early in the LFS chapter on the kernel. I would love to see initramfs covered by Linux From Scratch (it would be *really* handy for LFS-based liveCD/flashdrive systems) but I really don't see it belonging in a "normal" LFS system. William Tracy afishion...@gmail.com Cell phone: (805) 704-0917 Internet phone: (707) 206-6441 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS-8.0
On Mon, Jan 30, 2012 at 4:15 PM, Baho Utot wrote: > Lookup the bumblebee fiasco on google, > The bumble devs had a line rm -rf /usr /lib in a install script > so you installed the app and your /usr was gone. > Are you seriously saying this is a reason to split things between /bin and /usr/bin? The typo could have just as easily been 'rm -rf / usr/lib/'. How would splitting stuff between /bin and /usr/bin help you then? (In fact, since most implementations of rm seem to traverse directories in alphabetical order, the files under /bin would be the first ones to get deleted before you could hit ctrl+C.) There are lots of good arguments both for and against the split, but this really isn't one of them. (My actual opinion? If I were starting from scratch, putting everything under /usr seems more logical than sprinkling binaries all over the directory tree. At the same time, the existing system works and I don't see any compelling reason to change it.) William Tracy afishion...@gmail.com Cell phone: (805) 704-0917 Internet phone: (707) 206-6441 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Plans for LFS-7.1
If the plans to include initramfs go forward, would those be targeted for 8.0? William Tracy afishion...@gmail.com Cell phone: (805) 704-0917 Internet phone: (707) 206-6441 On Sun, Feb 5, 2012 at 11:16 AM, Bruce Dubbs wrote: > We are starting to plan for LFS-7.1. We are anticipating an -rc1 > release in about two weeks and lfs-7.1 around the first of March. > > Right now there are only two relatively routine package updates in the > ticket queue: the kernel and automake. > > > http://wiki.linuxfromscratch.org/lfs/query?status=assigned&status=new&status=reopened&group=milestone&max=300&col=id&col=summary&col=status&col=owner&col=type&col=priority&order=priority > > We are also expecting a release version of util-linux-2.21 at any time. > > If you have anything else you think we need to address, please let us > know. Packages, text, boot scripts, and web site are all reasonable > areas for changes. > > -- Bruce > > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS 7.3 ISO discussion
Aw, man, I built a "shrink LFS" script at one point but I think I don't have it any more. The big thing to know is that deleting files will not decrease the size of a Qemu image file. To get rid of the cruft created by building an LFS system, you might have to create a new Qemu disk image and "cp -r" the files over. If that's not enough, here's some quick ideas, from memory: Find and delete the static library files. Trim down the documentation under /usr/share/doc. Delete terminfo/termcap files that you don't need. Consider removing unnecessary packages (autotools comes to mind) and rebuilding others with -Os. If you actually get serious about deleting unnecessary files, Gnome has a tool called "baobab" (or "Disk Usage Analyzer" under the menu) that makes pretty graphs that show you which parts of a directory tree are chewing up the most space. William Tracy afishion...@gmail.com (408) 685-4819 On Wed, Mar 20, 2013 at 9:58 PM, Bruce Dubbs wrote: > Bruce Dubbs wrote: > >> I'm not sure about specific drivers, but I did get it working. I did >> 'make defconfig' and that seems to have done it. I've looked at the >> difference between configs for the one that sets up hda and the one that >> uses sda, but nothing jumps out at me. > >> I'm going to play around with it and try to minimize .config. That's >> the nice thing about qemu. You can reboot quickly without changing >> other things. I'll post anything I find out. > > I'm getting there. I've got a fairly well minimized kernel that works. > > -rw-r--r-- 1 root root 4.5M Mar 19 21:21 vmlinuz-3.8.3-lfs-SVN-20130316 > -rw-r--r-- 1 root root 5.1M Mar 21 00:46 vmlinuz-test > -rw-r--r-- 1 root root 3.1M Mar 21 02:22 vmlinuz-test2 > > What's really encouraging is the boot time in qemu. > > The kernel finishes at 1.383953 seconds and the boot scripts take 2 > seconds. The network up line from the kernel is the last dmesg entry at > 5.072569 seconds. > > The configuration is really minimal. I eliminated ipv6, netfilter, as > many drivers as I thought were unneeded, multiprocessor support, raid, > etc. I even reduced the number of loop devices. If I could only reduce > the number of ttys, /dev would be quite compact. Searching the net, it > seems that would require a change to a header in the kernel. > > I was thinking about distributing a qemu .img file, but that doesn't > seem realistic. The file is now 5.6G (1.5G compressed, but it took > almost an hour to do the compression). Adding things like Xorg would > just make it bigger. > >-- Bruce > > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS will need bc.
On Mon, Apr 1, 2013 at 5:50 PM, Rob Landley wrote: > Just a random note, but I've been building LFS systems using busybox as > the base system for years now. (I spent several years making that work. > :) At risk of taking this even further off-topic ... Have any of the LFS developers looked at musl? http://www.musl-libc.org/intro.html This is a completely new libc implementation (it doesn't borrow any glibc code like uClibc does) for Linux aimed at having a very small footprint. It completely supports BusyBox. The project's "How to Use" page actually specifically mentions LFS, but fails to go farther into detail on using LFS. Sabotage is a musl-based distro described as being "based on LFS", though it appears to feature a full-blown package management system now: https://github.com/rofl0r/sabotage It's also apparently possible to use glibc's C++ library alongside it. (Emphasis on "possible".) I'll shut up now and let you guys get back on-topic. :-) ~ William Tracy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
