Re: Plans for LFS-6.3
El Lunes, 23 de Julio de 2007 20:49, Dan Nicholson escribió: That doesn't say too much. OK, looking at postix/test-vfork3.c, I think I see the issue. At that point it does 'unsetenv (PATH);' and then tries to execute echo. For this to work, we need to have echo in /bin, which we don't at that point. If /bin/echo - /tools/bin/echo is added to the Essential Symlinks, I bet it will pass. Can you give that a try? Yes, it passes, included using -j3 ;-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
gcc --print-search-dirs losing data in chroot
Something strange popped up after a recompile of one of my systems. I performed a chroot after building the toolchain and suddenly gcc could not find 'cc1', etc. After doing research, I found the command gcc --print-search-dirs. I then compared this with the /tools/bin/gcc in the chroot to the outside chroot /tools/bin/gcc, which are still the same exact files. Results differed, after comparing the two, I noticed /tools/lib/ from outside the chroot became /tools/ causing gcc to not be able to find anything as /lib vanished using its own built in search functions!? Any ideas? -- Kevin Day -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
On Mon, Jul 23, 2007 at 12:57:14PM -0700, Craig Jackson wrote:
I would love a simple installer that copies the contents of the livecd
to a safe OS partition, from which to build LFS or CLFS or whatever.
The most recent version does allow you to run the CD from a partition or
USB flash drive. Also, IIRC, there are hints available on 'installing'
the CD contents to a hard disk.
has errors, but Linux doesn't seem to mind so much. (If you think
this is immoral, think about all the people that suddenly like Linux
so much more after seeing its ability to do this) :)
Immoral? Nah, I think it's great. :)
No, thank you Jerermy and company. You truly have built the ultimate
boot cd as far as I'm concerned. :)
And many thanks to all who participated in this thread. It was most
appreciated. I think it helps to see that people are still making use of
the CD and that, for the most part, it's well-liked. I'll be looking
over the comments made to see where we might be able to use the
suggestions.
Admittedly, I was disappointed to see that only one {x,}LFS developer
commented. :/ Still, there was far more feedback than I expected. Thanks
again, everyone.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Plans for LFS-6.3
On 7/23/07, M.Canales.es [EMAIL PROTECTED] wrote: El Lunes, 23 de Julio de 2007 20:49, Dan Nicholson escribió: That doesn't say too much. OK, looking at postix/test-vfork3.c, I think I see the issue. At that point it does 'unsetenv (PATH);' and then tries to execute echo. For this to work, we need to have echo in /bin, which we don't at that point. If /bin/echo - /tools/bin/echo is added to the Essential Symlinks, I bet it will pass. Can you give that a try? Yes, it passes, included using -j3 ;-) OK. I'm adding echo and noting that nptl/tst-cancel1 is known to fail. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Mon, Jul 23, 2007 at 06:38:46PM +, Jeremy Huntwork wrote: Since the specs patch is already set up for pure64 and modifies the 64-bit linker to be in /tools/lib, I'm thinking to merge these small changes above to the pure64_specs patch and call it done. Any objections to that? The pure64 patch is usually thought to be needed in chapter 6 as well as pass 2 ;) ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Mon, Jul 23, 2007 at 10:34:45PM +0100, Ken Moffat wrote:
The pure64 patch is usually thought to be needed in chapter 6 as
well as pass 2 ;)
The problem I ran into is that the pure64 patch (at least the one I
found that's usable for gcc-4.1.1) won't apply once the specs patch has
been applied. I think both try to make dynamic linker changes to
linux{,64}.h. So I figured I'd roll up the needed changes from the
pure64 patch into the specs patch. That way we can just apply the specs
patch in gcc-pass2 and apply the pure64 patch in final gcc.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Mon, Jul 23, 2007 at 06:38:46PM +, Jeremy Huntwork wrote: MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 32 -MULTILIB_OSDIRNAMES = ../lib64 ../lib +MULTILIB_OSDIRNAMES = ../lib ../lib32 And, I suppose if I'm going to be adding this to the specs patch, it would be safer to have the dirnames be /tools/lib and /tools/lib32 -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote:
Thanks. This was just an oversight. I meant to include the contents of the
pure64 patch for gcc pass2, but overlooked it due to the similarly named
pure64_specs patch. Here's what the pure64 patch would give us (Approximately.
The following is a faux diff due to line wrapping issues on my news client):
gcc-4.1.2.orig/gcc/config/i386/t-linux64
gcc-4.1.2/gcc/config/i386/t-linux64
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32
-MULTILIB_OSDIRNAMES = ../lib64 ../lib
+MULTILIB_OSDIRNAMES = ../lib ../lib32
Since the specs patch is already set up for pure64 and modifies the 64-bit
linker to be in /tools/lib, I'm thinking to merge these small changes above to
the pure64_specs patch and call it done. Any objections to that?
Umm, you appear to have missed the point completely. Please re-read the
info I pointed to. MULTILIB_OSDIRNAMES needs to be *non-existent* to work
around the surprising (buggy?) GCC behavior I'm talking about.
Then again, I haven't tested x86_64 in a while so I might be talking out
of my arse. Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:
echo 'main(){}' | gcc -xc -o /dev/null -v -
Another point - To be honest, I don't see why any pure64 patch is needed
at all. That's what the symlinks are for. All the patch seems to do is
diverge the `x86_64 --disable-multilib' build further away from x86 than
is necessary.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: r8232 - in branches/x86_64/BOOK: . chapter05 chapter06
Author: jhuntwork Date: 2007-07-23 16:04:42 -0600 (Mon, 23 Jul 2007) New Revision: 8232 - Use --disable-multilib in final gcc and binutils Why binutils? It serves no purpose there. - Explicitly tell Glibc to use /lib and /usr/lib, instead of defaults of /lib64 and /usr/lib64 Again, why do it? The symlinks take care of this. It's just complicating the build unnecessarily IMHO. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote:
Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:
echo 'main(){}' | gcc -xc -o /dev/null -v -
Actually, that may not be enough. Would also need to see the output of:
gcc -print-search-dirs | sed 's/:/\n/g'
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: r8232 - in branches/x86_64/BOOK: . chapter05 chapter06
Greg Schafer wrote:
Author: jhuntwork
- Use --disable-multilib in final gcc and binutils
Why binutils? It serves no purpose there.
I did notice that it didn't make a difference with binutils, but I must
admit that this was a case of working from CLFS. I started by taking
notes of what they had and adapting for LFS. When I noticed that I
forgot this for final GCC in chapter 6 (the build crashed looking for
unnecessary stub headers), I just dumped in the command for binutils, as
well, assuming that CLFS knew what they are doing. Assumptions...
I can see by grepping that binutils seems totally unaware of this
switch. Will remove...
- Explicitly tell Glibc to use /lib and /usr/lib, instead
of defaults of /lib64 and /usr/lib64
Again, why do it? The symlinks take care of this. It's just complicating
the build unnecessarily IMHO.
This one I deliberated with for a bit. I finally opted for the switches
to Glibc for a couple of main reasons:
* Elsewhere, (in the gcc patches, for example) we are explicitly
forcing /lib to be the location of the 64-bit libraries. For the sake of
consistency in the system, it seemed better to have Glibc configured to
look there (and install there) by default.
* If Glibc is configured for /lib and /usr/lib, then if for some the
reason the symlinks disappear, the toolchain remains relatively intact.
If Glibc is left to its defaults, when the {/usr,}/lib64 links
disappear, the linker is broken immediately. It seems more robust to
have the symlinks there for compatibility only, than for them to be
absolutely depended upon. Of course, since I am still in the midst of
testing, I can't say definitively that the symlinks aren't absolutely
necessary either way.
Feel free to prove me wrong on the above. I am definitely learning as I
go and pointers from those already through this route are always welcome.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote:
Umm, you appear to have missed the point completely. Please re-read the
info I pointed to. MULTILIB_OSDIRNAMES needs to be *non-existent* to work
around the surprising (buggy?) GCC behavior I'm talking about.
I didn't miss the point, I understood all of what you wrote. I just
chose to test it differently.
Then again, I haven't tested x86_64 in a while so I might be talking out
of my arse. Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:
echo 'main(){}' | gcc -xc -o /dev/null -v -
I don't have an Ubuntu host to work from, but I will share the results
that I can. Have to fire off another build, so it might be a little bit.
Another point - To be honest, I don't see why any pure64 patch is needed
at all. That's what the symlinks are for. All the patch seems to do is
diverge the `x86_64 --disable-multilib' build further away from x86 than
is necessary.
Well, you may be right. But before I make any futher changes, I'd like
to get some feedback on this from others in the LFS community about it.
Greg, care to explain in more detail the {dis,}advantages of the
symlinks a bit more?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote:
Greg, care to explain in more detail the {dis,}advantages of the
symlinks a bit more?
Dude, it's fairly simple. The symlinks keep the `-disable-multilib' build
very much compatible with x86 ie: very little changes are required, and
this is a *MASSIVE* maintenance advantage. Also, as mentioned elsewhere in
this thread, LSB binaries (those with interpreter path
/lib64/ld-linux-x86-64.so.2) will work. I don't buy your argument about
symlinks being less robust.. neither does Ubuntu.. rescue CD's exist for a
reason you know :-)
I thought you were trying to adapt the current LFS/DIY *native* build
method to non-multilib x86_64 (similar to what I've done in the DIY
Refbuild). None of the CLFS gunk you're currently adding is needed. If
you're going to borrow bits of CLFS stuff then IMHO you may as well just
forget the whole thing and point folks to CLFS.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote these words on 07/23/07 20:44 CST: None of the CLFS gunk you're currently adding is needed. If you're going to borrow bits of CLFS stuff then IMHO you may as well just forget the whole thing and point folks to CLFS. I ditto these sentiments. Jeez, Jeremy, why invent the wheel? Besides, wouldn't your efforts be better spent getting LFS-6.3 out the door, instead of trying to incorporate into LFS (the hard way) what everyone has access to using already discovered methodology? Just my opinion. Don't answer the question, nor comment if there's nothing to be gained technically. We all appreciate your quest for knowledge. Just not at the expense of putting into LFS what is already out there, with your deviations. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 21:04:00 up 11 days, 14:11, 1 user, load average: 0.10, 0.04, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote: Dude, it's fairly simple. I'm not sure if you meant to sound condescending here; I'll give you the benefit of the doubt and assume you didn't. It does appear, however, that you missed the point of my request. I wasn't asking you to explain to me your method; I get it. I was asking you to present the options to the community in order to foster discussion. The symlinks keep the `-disable-multilib' build very much compatible with x86 ie: very little changes are required, and this is a *MASSIVE* maintenance advantage. Also, as mentioned elsewhere in this thread, LSB binaries (those with interpreter path /lib64/ld-linux-x86-64.so.2) will work. Thank you, this is what I was after. I don't buy your argument about symlinks being less robust.. neither does Ubuntu.. rescue CD's exist for a reason you know :-) I simply presented it as something to consider... I thought you were trying to adapt the current LFS/DIY *native* build method to non-multilib x86_64 (similar to what I've done in the DIY Refbuild). None of the CLFS gunk you're currently adding is needed. If you're going to borrow bits of CLFS stuff then IMHO you may as well just forget the whole thing and point folks to CLFS. Well the same could be said for adding material borrowed from DIY. 'Might as well just point the users to DIY-Linux'. The 'gunk' that you've mentioned is just one patch to GCC and two possible commands added to Glibc. And as was already mentioned, even that could be removed. It would just require that we alter the text that is shown from the gcc tests. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Randy McMurchy wrote: I ditto these sentiments. Jeez, Jeremy, why invent the wheel? Actually, I was trying to avoid that. The simple fact is that I rarely consult DIY. For reference, I looked at what I was already familiar with: CLFS. I didn't even remember that DIY had a native x86_64 build until after I already started my edits on my working copy. If there's a better method (one that is a closer fit to what we want to achieve in LFS) from DIY, great. Let's use it. Besides, wouldn't your efforts be better spent getting LFS-6.3 out the door, instead of trying to incorporate into LFS (the hard way) what everyone has access to using already discovered methodology? [snip] Just my opinion. Don't answer the question, nor comment if there's nothing to be gained technically. If there's nothing to be gained technically, why ask the question? knowledge. Just not at the expense of putting into LFS what is already out there, with your deviations. That's what bringing x86_64 into LFS would be - adding what has already been done with deviations appropriate for our BOOK/community. I'm not at all trying to make this about me, so it's not *my* deviations. The only reason I was the one to create the branch and start dropping in changes is because I was hoping to create a full 64-bit LiveCD. It would be very useful to me personally and at work, and we've had a few requests for such a CD on the livecd list. Am I free to use my time in that manner? BTW, how does this happen? How does it work out that I get attacked for my efforts? I created a branch *specifically* as an out of the way place where if I mess it up, no harm is done. I freely admit through all of my messages and commits that there may be errors to what is there. I ask for suggestions, and I try to show that I'm open to other methods and am willing to adjust. And yet people blast me for what I'm doing? What gives? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Randy McMurchy wrote: Besides, wouldn't your efforts be better spent getting LFS-6.3 out the door Jeremy is getting a head start on a potential LFS-7.0. I am about to cut a lfs-6.3-rc1. Right now there are two outstanding tickets. One, man-pages-2.63, it pretty trivial and I'll make that change in a few minutes. The other, iproute2-2.6.22-070710, is something we need to discuss. The problem is with the packaging. The package expands to the current directory. The issue is what to do. Here is what I see as the options: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page Both Dan and I have written to the iptables maintainer and have not heard any response. Opinions? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Bruce Dubbs wrote: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page I'd opt for either 1 or 2. If we did number 3, I'm sure many people would see the message after they've already unpacked it. What's included in the update? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote:
Greg Schafer wrote:
Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:
echo 'main(){}' | gcc -xc -o /dev/null -v -
Actually, that may not be enough. Would also need to see the output of:
gcc -print-search-dirs | sed 's/:/\n/g'
Here's the results from what is currently in the branch:
http://linuxfromscratch.org/~jhuntwork/test.log
http://linuxfromscratch.org/~jhuntwork/search_dirs.log
It does seem that there are still locations in /usr showing up in the
search dirs. They are later in the list, but still, it seems the
potential is there to pull in unwanted libs from the host.
Going to be adjusting the build again. It will end up being more DIY-like.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote these words on 07/23/07 13:51 CST: And yet people blast me for what I'm doing? What gives? You are too sensitive. I've not seen anyone blast you. I've only seen people be critical of the ideas you have. That is okay. This is a discussion forum where folks are expected to give their opinions on things. You take it personally, and you shouldn't. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 22:03:00 up 11 days, 15:10, 1 user, load average: 0.20, 0.05, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Randy McMurchy wrote: You are too sensitive. Yes, you're probably right. :/ -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Bruce Dubbs wrote these words on 07/23/07 22:06 CST: The other, iproute2-2.6.22-070710, is something we need to discuss. The problem is with the packaging. The package expands to the current directory. The issue is what to do. Here is what I see as the options: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page Both Dan and I have written to the iptables maintainer and have not heard any response. Not sure what the iptables maintainer has to do with an issue with the iproute package, but I'm guessing this a typographic error. However, if the current update in the iproute package sucks and doesn't perform to our expectations, then blow it off. What is in the book works. That means I vote for #1. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 22:24:00 up 11 days, 15:31, 1 user, load average: 0.15, 0.17, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: It does seem that there are still locations in /usr showing up in the search dirs. They are later in the list, but still, it seems the potential is there to pull in unwanted libs from the host. Actually, they show up on x86 too so they're not the problem. The specific problem I'm referring to was about GCC adding -L/lib/../lib64 entries when it shouldn't have... Aha, it's all starting to come back to me now.. the confusing thing was ../lib64 didn't show up in the -print-search-dirs output (which BTW, I think is fixed in GCC-4.2 or 4.3) and this made it hard to figure out the problem. Anyhoo, thanks for the logs but I don't think they're going to help.. oops. I'll try and come up with a simple testcase which will hopefully clarify it. Gimme a few days to get my x86_64 house in order.. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
most recent iproute2
Randy McMurchy wrote: Bruce Dubbs wrote these words on 07/23/07 22:06 CST: The other, iproute2-2.6.22-070710, is something we need to discuss. The problem is with the packaging. The package expands to the current directory. The issue is what to do. Here is what I see as the options: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page Both Dan and I have written to the iptables maintainer and have not heard any response. Not sure what the iptables maintainer has to do with an issue with the iproute package, but I'm guessing this a typographic error. However, if the current update in the iproute package sucks and doesn't perform to our expectations, then blow it off. What is in the book works. That means I vote for #1. s/iptables/iproute2/ :( The changelog's most recent entry is 2006-03-21, so it has not been kept up to date. A diff between the versions gives about 900 lines difference, but I haven't analyzed what was done. Changed files: iproute/Makefile iproute/include/SNAPSHOT.h iproute/include/iptables_common.h iproute/include/libiptc/ipt_kernel_headers.h iproute/include/linux/fib_rules.h iproute/include/linux/if.h iproute/include/linux/if_addr.h iproute/include/linux/if_link.h iproute/include/linux/netfilter/x_tables.h iproute/include/linux/netfilter/xt_tcpudp.h iproute/include/linux/netfilter_ipv4/ip_tables.h iproute/include/linux/netlink.h iproute/include/linux/socket.h iproute/include/linux/tc_act/tc_defact.h iproute/include/linux/xfrm.h iproute/ip/ipaddress.c iproute/ip/ipneigh.c iproute/ip/iprule.c iproute/ip/ipxfrm.c iproute/ip/routef iproute/ip/rtmon.c iproute/ip/xfrm.h iproute/ip/xfrm_policy.c iproute/ip/xfrm_state.c iproute/lib/libnetlink.c iproute/lib/ll_addr.c iproute/lib/ll_map.c iproute/lib/ll_types.c iproute/misc/ss.c iproute/tc/Makefile iproute/tc/m_ipt.c iproute/tc/q_netem.c iproute/tc/tc.c iproute/tc/tc_core.h iproute/tc/tc_filter.c iproute/tc/tc_util.c iproute/tc/tc_util.h -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
Craig Jackson wrote: Otherwise, I use console due to the extreme performance hit of X when run from the LiveCD. (Not sure why this is). This is known to happen on machines with insufficient amount of RAM due to VM bug in the kernel, because it doesn't like the fact that our dm-snapshot device is backed by a loop device on a sparse file on tmpfs (it fruitlessly loops and tries to free some memory by flushing dirty buffers, try echo 2 /proc/sys/vm/overcommit_memory and see an oops). Try adding swap to work around this. Or, if this guess is wrong (i.e., you have 512 MB of RAM or more), try booting the SVN version of the LiveCD as linux toram (if you have only 512 MB of RAM, you'll have to add swap, though). 4) What is the most annoying or useless bits of the CD? IPRoute. net-tools were added in the SVN version of the LiveCD. I can hack the init scripts a bit to get it to work, but its command line parameters are not very intuitive. This was my least favorite upgrade from 5.x. I do understand the need for the update. (IPv6 support). LFS doesn't support IPv6, so the move to iproute2 is unjustified from this viewpoint. I will take back this opinion as soon as LFS bootscripts start supporting IPv6. 5) What would you change/add/improve? I would love a simple installer that copies the contents of the livecd to a safe OS partition, from which to build LFS or CLFS or whatever. Sorry, the information how to do this was available before, and is still available via private e-mail. However, due to dummies asking stupid BLFS support questions on IRC without completing LFS, I provide this information only on the condition that you unsubscribe from the support lists and agree to be banned on IRC. The SVN CD includes a compromise: you can put the ISO as a file onto a partition and use this file for booting - but you can't save anything across a reboot (i.e., the same limitation as if you booted from a CD). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
