Re: lfslivecd
On Friday 25 March 2011 17:39:02 Mike McCarty wrote: > Neal Murphy wrote: > > On Tuesday 22 March 2011 17:10:52 Mike McCarty wrote: > >> Why do you say that? IME, most of the time is spent in the > >> compiler, not reading the CD-ROM. It takes a few seconds to > >> read the CD-ROM to get the compiler going, and then it runs. > >> Usually, most of it gets cached. > > > > Only if you have enough RAM. Taking a SWAG, 2GB ought to be enough to > > cache > > Even much less. If there is enough RAM to hold the compiler, it > takes a few seconds to load it up, and then it runs from memory. > I've built from LiveCD with 512MB of RAM, and most of the time > was waiting on the processor, not the disc. It's not just the compiler, but also the linker, the libraries, make, shell, utilities, etc. Now add in the object files being linked and the libraries being linked to and yer startin' to talk about real memory. Linux itself balloons from around 120MiB unpacked to 900GiB or so built. So I'll compromise and say it depends on what you are building. :) Another number to add that highlights Linux's caching. When building, my %wa (waiting for IO) rarely climbs above 0.3 and is most often 0.1 or less. Then when I rebuild, there's no waiting for input, and rarely waiting for output. N -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: lfslivecd
Neal Murphy wrote:
> On Tuesday 22 March 2011 17:10:52 Mike McCarty wrote:
>> Why do you say that? IME, most of the time is spent in the
>> compiler, not reading the CD-ROM. It takes a few seconds to
>> read the CD-ROM to get the compiler going, and then it runs.
>> Usually, most of it gets cached.
>
> Only if you have enough RAM. Taking a SWAG, 2GB ought to be enough to cache
Even much less. If there is enough RAM to hold the compiler, it
takes a few seconds to load it up, and then it runs from memory.
I've built from LiveCD with 512MB of RAM, and most of the time
was waiting on the processor, not the disc.
> the utilities (binutils, gcc, et al) and libs and leave working space for
> building the tool chain. To build LFS (the basic system), I imagine 6-7GB
> would be enough to cache the whole build. Once the tools and utilities are
That corresponds to my experience. The entire build took up 10GB on
disc, max, and not everything needs to be cached.
[...]
> When building my version of Smoothwall on my quad-core 8GB desktop system,
> I've found that about 6.5GB of stuff gets cached over the 90-120 minute
> build;
> LFS should be similar in size, maybe 1GB smaller. I also found that
> preloading
> a 7GB ramdisk only saves about 5 minutes real time building from scratch; it
> takes at least that long to load the ramdisk with the source tarballs,
> patches, &cet. Linux's file caching is *very* good when you have enough RAM.
Those are interesting figures. Thanks!
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: lfslivecd
On Tuesday 22 March 2011 17:10:52 Mike McCarty wrote: > Why do you say that? IME, most of the time is spent in the > compiler, not reading the CD-ROM. It takes a few seconds to > read the CD-ROM to get the compiler going, and then it runs. > Usually, most of it gets cached. Only if you have enough RAM. Taking a SWAG, 2GB ought to be enough to cache the utilities (binutils, gcc, et al) and libs and leave working space for building the tool chain. To build LFS (the basic system), I imagine 6-7GB would be enough to cache the whole build. Once the tools and utilities are cached, the CD should rarely be accessed when building the toolchain (Ch.5); it should almost never be accessed when building the final phase (Ch.6). When building my version of Smoothwall on my quad-core 8GB desktop system, I've found that about 6.5GB of stuff gets cached over the 90-120 minute build; LFS should be similar in size, maybe 1GB smaller. I also found that preloading a 7GB ramdisk only saves about 5 minutes real time building from scratch; it takes at least that long to load the ramdisk with the source tarballs, patches, &cet. Linux's file caching is *very* good when you have enough RAM. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: lfslivecd
Bruce Dubbs wrote:
> janu mam wrote:
>> i am using lfs livex86-r2160 as host for building lfs book 6.7,
>> in lfs6.7 book the following msg was there
>>
>> ""The LFS LiveCD might not work on newer hardware configurations,
>> failing to boot or failing to detect
>> some devices such as some SATA hard drives.""
>>
>> shall i use for lfslivecd as host or use any linux destro
>
> Really you can use any distro, but you may have to ensure the
> prerequisite packages are installed. The lfs live CD is already set up
> for you if it boots OK.
>
> Note that building off any live CD is relatively slow.
Why do you say that? IME, most of the time is spent in the
compiler, not reading the CD-ROM. It takes a few seconds to
read the CD-ROM to get the compiler going, and then it runs.
Usually, most of it gets cached.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: lfslivecd
janu mam wrote: > i am using lfs livex86-r2160 as host for building lfs book 6.7, > in lfs6.7 book the following msg was there > > ""The LFS LiveCD might not work on newer hardware configurations, > failing to boot or failing to detect > some devices such as some SATA hard drives."" > > shall i use for lfslivecd as host or use any linux destro Really you can use any distro, but you may have to ensure the prerequisite packages are installed. The lfs live CD is already set up for you if it boots OK. Note that building off any live CD is relatively slow. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
lfslivecd
i am using lfs livex86-r2160 as host for building lfs book 6.7, in lfs6.7 book the following msg was there ""The LFS LiveCD might not work on newer hardware configurations, failing to boot or failing to detect some devices such as some SATA hard drives."" shall i use for lfslivecd as host or use any linux destro -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: lfslivecd-x86_64-6.3-r2014 6.23. Perl-5.8.8 make fails
On Sun, Oct 21, 2007 at 12:10:07AM +0200, Danny Engelbarts wrote: > > I'm not sure why i got this error, searching it on google i only got 4 hits > which leades me to believe it's rather rare ... i must add that, allthough i > used gcc-4.1.2 for my toolchain, i decided to use 4.2.2 in step 6.12 hoping > that would save me the trouble of upgrading later. Might this have caused > perl to fail? > Well-known problem caused by the gcc change. But, by using a _different_ toolchain in the final system from what you used in the temporary system, you've abandoned any ideas of of toolchain purity. Changing the version of gcc isn't always trivial. If you are ready to play with new versions of packages, consider following the development book. But, x86_64 isn't supported yet (except by clfs). I would point you to the jh branch, which does cover x86_64, but you would need the tools to download and render it (and at the moment it doesn't cover bootloaders). Nobody here is building gcc-4.2.2 against the old binutils and glibc, so you may encounter new problems when you come to build whatever parts of blfs (or cblfs) you want. Testing builds with new versions of packages is good. But if you are going to do that, sometimes the resulting system will have showstopper problems so keep a known good system. And don't get fixated on "newer must be better" - sometimes it is, but not always. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: lfslivecd-x86_64-6.3-r2014 6.23. Perl-5.8.8 make fails
On Sunday 21 October 2007 00:47:18 Bauke Jan Douma wrote: > Danny Engelbarts wrote on 21-10-07 00:10: > > Hi, > > > > While building perl on my system with the x86_64-6.3-r2014 livecd i got > > the following error: > > > > make: *** No rule to make target `', needed by > > `miniperlmain.o'. Stop. > > > > I was able to resolve this error using the patch in this mail; > > > > http://www.nntp.perl.org/group/perl.perl5.porters/2006/11/msg117738.html > > > > I'm not sure why i got this error, searching it on google i only got 4 > > hits which leades me to believe it's rather rare ... i must add that, > > allthough i used gcc-4.1.2 for my toolchain, i decided to use 4.2.2 in > > step 6.12 hoping that would save me the trouble of upgrading later. Might > > this have caused perl to fail? > > Am I the only one, when reading posts like this, that thinks: > > "Basically, as soon as you knowingly deviate from the prescription, > you're not building LFS anymore, and shouldn't really be expecting > your subsequent problems to be dealt with on this list." You might be right, which is why i didn't come screaming to this list but went searching elsewhere first, had i not found the answer i'd probably restarted without 4.2.2. However i found a solution and posted it to this list (for the benefit of those experiencing the same problem). Then i ask a simple question wether or not installing the 4.2.2 compiler instead of the 4.1.2 could be cullprit. In my opinion it shouldn't matter which compiler i choose to install on the system because the one in the toolchain is used to compile perl. I did however get an error and i'm wondering wether i should revise this opinion ... i'm not asking or expecting anyone to deal with non-existing problems. Regards, Danny. > > bjd -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: lfslivecd-x86_64-6.3-r2014 6.23. Perl-5.8.8 make fails
Danny Engelbarts wrote on 21-10-07 00:10: > Hi, > > While building perl on my system with the x86_64-6.3-r2014 livecd i got the > following error: > > make: *** No rule to make target `', needed by > `miniperlmain.o'. > Stop. > > I was able to resolve this error using the patch in this mail; > > http://www.nntp.perl.org/group/perl.perl5.porters/2006/11/msg117738.html > > I'm not sure why i got this error, searching it on google i only got 4 hits > which leades me to believe it's rather rare ... i must add that, allthough i > used gcc-4.1.2 for my toolchain, i decided to use 4.2.2 in step 6.12 hoping > that would save me the trouble of upgrading later. Might this have caused > perl to fail? Am I the only one, when reading posts like this, that thinks: "Basically, as soon as you knowingly deviate from the prescription, you're not building LFS anymore, and shouldn't really be expecting your subsequent problems to be dealt with on this list." bjd -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
lfslivecd-x86_64-6.3-r2014 6.23. Perl-5.8.8 make fails
Hi, While building perl on my system with the x86_64-6.3-r2014 livecd i got the following error: make: *** No rule to make target `', needed by `miniperlmain.o'. Stop. I was able to resolve this error using the patch in this mail; http://www.nntp.perl.org/group/perl.perl5.porters/2006/11/msg117738.html I'm not sure why i got this error, searching it on google i only got 4 hits which leades me to believe it's rather rare ... i must add that, allthough i used gcc-4.1.2 for my toolchain, i decided to use 4.2.2 in step 6.12 hoping that would save me the trouble of upgrading later. Might this have caused perl to fail? Regards, Danny. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFSLiveCD root.ext2
On 4/11/07, Sherzod Rakh <[EMAIL PROTECTED]> wrote: > there is file in lfs live cd root.ext2. How can i build like root.ext2 file > my lfs system??? I didn't checked it out, so correct me if i'm wrong... The root.ext2 file is a filesystem in a file, to create such system you could use dd dd if=/dev/zero of=filesystem bs=1024 count=1048576 Above command would create a file that is 1 GB in size, this is the size of your partition. then you need to create a filesystem on it, with the mke2fs (or mkfs.ext2) command. (Or for ext3, mke3fs/mkfs.ext3) mke2fs filesystem The command will note you that filesystem isn't a block device, and this is correct. so continue with yes. then you can follow the LFS book, but only when mounting the partition you need to change the command. the book says: mount -v -t ext3 /dev/ $LFS you should do: mount -v -t ext2 /full/path/to/filesystem $LFS -o loop or for ext3: mount -v -t ext3 /full/path/to/filesystem $LFS -o loop But this only creates the filesystem(where you build LFS on), if you want to know how to boot from CD etc, you should look at the LFS Live CD remastering page. http://wiki.linuxfromscratch.org/livecd/browser/tags/6.2-5/doc/lfscd-remastering-howto.txt Tijnema -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFSLiveCD root.ext2
On 4/12/07, prdcomp <[EMAIL PROTECTED]> wrote: > > Recently, I did an experiment: I build lfs (using jhalfs) without > optmizations, and in a spare partition built it subsequently with (mainly) > the following flags: "-O2 -pipe -march=athlon-xp". Those are rather common > options, but the number of unexpected (and quite expected by now) libmudflap > failures raised from the traditional 6 to 320! That doesn't seem right. Those are perfectly normal flags, except maybe -march. In fact, gcc by default uses -O2. Are you pretty confident that you built everything the same way? I've never heard of mudflap totally falling over like that, but there are issues with it timing out some tests. Do the errors say that it's timing out? > Actually, I think the real question is: is it worth trying to optimize a LFS > (initial) system? For BLFS, I tend to believe it is. For LFS itself, not that > sure. Some things certainly benefit from optimization. Anything that's doing a lot of data processing or doing math intensive operations are going to benefit from using your processor's full capabilities. Think of a video encoding library. In LFS, the most useful, but also the most dangerous, thing to optimize is glibc. _Everything_ on your system uses glibc. If you can optimize your C routines, everything benefits. But if it breaks, then you're screwed. Most of the other stuff in LFS are pretty basic utilities. Ncurses and zlib jump out as libraries that a lot of other packages link to. Optimizing gcc and binutils only helps the build time behavior and not the runtime behavior. Just shooting from the hip here. I've never gone crazy optimizing or done any kind of benchmarking. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
LFSLiveCD root.ext2
there is file in lfs live cd root.ext2. How can i build like root.ext2 file my lfs system??? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
