New LFS build method and JHALFS
Hi, I have added the new variables to LFS/master.sh. This will only impact LFS and should not affect the building of earlier books. If there are any problems let me know. regards George -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fwd: Re: Document version not set with jhalfs-20081011
Bruce Dubbs wrote: > George Boudreau wrote: >> Matthew Burgess wrote: >>> Forwarding to lfs-dev...I'm currently unable to commit to SVN (my own >>> network setup here). I'd guess we either need to revert back to the '-' or >>> change it to '–' (note the additional ';'). >>> >>> George, how does 'xmllint' puke? It'd be nice if the LFS Book's validation >>> Makefile target could catch this. >>> >> xmllint prologue bookinfo.xml produces the following. >> >> Entity: line 1: parser error : Entity 'ndash' not defined >> >> 1999–2008 > > This looks like a problem with xmllint or it's invocation. Why doesn't it > know > about entities? This change was made in revision 4648 on 02/19/05. Why is > is > coming up now? > > I'd perver to keep the entity. After dusting off my xml. Predefined entities in xml "quot, amp, apos, lt, gt". The hyphen '-' or 'endash' is not a defined in XML but is defined for XHTML. You must either add in general.ent or just use a hypen in the copyright date span. Either way I am happy. George. > >-- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fwd: Re: Document version not set with jhalfs-20081011
Matthew Burgess wrote: > Forwarding to lfs-dev...I'm currently unable to commit to SVN (my own network > setup here). I'd guess we either need to revert back to the '-' or change it > to '–' (note the additional ';'). > > George, how does 'xmllint' puke? It'd be nice if the LFS Book's validation > Makefile target could catch this. > xmllint prologue bookinfo.xml produces the following. Entity: line 1: parser error : Entity 'ndash' not defined 1999–2008 ^ prologue/bookinfo.xml:22: parser error : Unregistered error message ©rightdate; ^ prologue/bookinfo.xml:27: parser error : Entity 'copy' not defined Copyright © ©rightdate;, Gerard Beekmans > Thanks, > > Matt. > > Original Message ---- > Subject: Re: Document version not set with jhalfs-20081011 > Date: Tue, 28 Oct 2008 09:13:14 -0400 > From: George Boudreau <[EMAIL PROTECTED]> > To: ALFS Discussion and Development List <[EMAIL PROTECTED]> > > DJ Lucas wrote: >> Just a heads up...I haven't investigated yet. >> >> procps-3.2.7-watch_unicode-1.patch: -- copied from /source-archive >> readline-5.2-fixes-5.patch: -- copied from /source-archive >> vim-7.2-fixes-3.patch: -- copied from /source-archive >> Document version <> >> >This is a problem in the document file 'general.ent' > > > > xmllint pukes on the &ndash. > >I do not have privs to modify the book. Anyone out there feel > adventurous? > >George >> -- DJ Lucas >> > > -- > http://linuxfromscratch.org/mailman/listinfo/alfs-discuss > 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: Changes in the LFS build procedure
DJ Lucas wrote: > Bruce Dubbs wrote: >> I have just made some relatively large changes in the LFS build procedure. >> > >> 2. The Makefile has been updated to automatically generate the bootscripts >> and >> udev-config tarballs. The entities that specify the tarball size and md5sum >> are >> automatically updated in the build, but those changes are not inserted into >> svn. >> Instead the entities have unique strings that are substituted with calculated >> values in the build process. >> > > FYI, this broke jhalfs's ability to automatically run the makefile > because of the lack of md5sums for bootscripts and udev-config > tarballs. Not likely a big deal as those of us building SVN had better > know why. However, when a release time comes, add another line to the > release checklist as those entities should probably be replaced with > real values in the book's source since they will be static. I haven't > looked yet, but I don't think it should be difficult. > Changed jhalfs svn to accommodate udev-config and bootscripts, skips md5sum test for these packages. George > -- DJ Lucas > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
[X] I am an editor of LFS or one of the related projects [ ] I use LFS as my primary Linux system [ ] I use LFS on more than one PC (including virtual machines) [ ] I deviate a lot from LFS (not counting package updates as deviations) [ ] I deviate a lot from BLFS (not counting package updates as deviations) I use the following package management technique: ( ) It's all in my head! ( ) I trust the lists of files in the book ( ) I rebuild everything every three months or less, so there is no need to manage anything! ( ) Installation script tracing with installwatch or checkinstall ( ) Installation script tracing with some other tool ( ) Timestamp-based "find" operation ( ) User-based ( ) RPM ( ) DPKG ( ) Simple binary tarballs produced with DESTDIR (X) Other DESTDIR-based method of producing binary packages ( ) Other I use the following features provided by a package manager: [X] Knowing where each file comes from [X] Clean uninstallation of a package [X] Removal of obsolete files when upgrading to a new version [X] Ability to upgrade toolchain components (most notably, glibc) painlessly [ ] Ability to revert mistakes easily and quickly by installing an old binary package [ ] Ability to compile once, deploy on many macines [X] Scripting the build I will ignore the future LFS advice on package management if it [ ] Can't be applied on a busy machine where many files are accessed/modified everyy minute [ ] Can't be used to transfer packages to another machine [ ] Interferes with config.site files described in DIY-linux [ ] Will clobber configuration files wen upgrading package versions [ ] Doesn't explain how to package software beyond BLFS [ ] Requires learning another language/syntax besides bash shell syntax [ ] Exists at all -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Happy Birthday LFS
Gerard Beekmans wrote: > Hey all, > > The LFS project is almost nine years old. LFS 1.0 was released on > December 16, 1999. That was the year I had moved to Canada, before my > immigration was even finalized. Earlier that year I started on the LFS > project. > > The details are a bit fuzzy because I don't have accurate records dating > that far back, but it all started some time in February of 1999. > > That makes LFS nine years old this month. It still boggles my mind some > days that LFS grew into what it has. > > Ciao! > > Gerard You wear your age well, you don't look a day over 5. A picture from when you were 1 or 2 (June 2000). http://tinyurl.com/2jtm8n -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Greg Schafer wrote: > Alexander E. Patrakov wrote: > >> The first step would be to convert everything to DESTDIR-style >> installation, and then adapt some existing (Slackware?) scripts to >> package the result. IMHO, RPM would be overkill here. > > Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware > scripts could be adapted judging by the content at Jaguar Linux: I agree with Greg, Pacman is superior to Slackwares Pkgtools and does not depend on a quirk only available in tar <= 1.13.. I have created numerous interchangeable PM modules (DPKG, Pacman, Pkgtools and Pkgutils) for my personal education/use, for Greg's DIY code and use the progenitor of Pacman, Per Liden's Pkgtools. I would not recommend the Slackware PM due to the 'tar' limitation and its lack of sophistication and DPKG is for masochists ( 3. A willingness or tendency to subject oneself to unpleasant or trying experiences.) > > http://www.jaguarlinux.com/ > > Regards > Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [PATCH] Add screen install attributes for final system packages
Dan Nicholson wrote:
> Another jhalfs helper. As has been discussed before, it would be nice to
> mark the screen sections with an attribute to announce that it will be
> installing to the system rather than just working in the source/build
> tree. Manuel suggested adding the attribute userlevel="install", so I've
> done that for the Ch. 6 packages and the kernel in Ch. 8.
>
> This allows a really simple stylesheet to be created so that interesting
> things can be done. For instance, I created a paco stylesheet to wrap the
> install commands like so:
>
> paco -lp+ ${package}-${version} "
> make install
> "
>
> Combined with the previous patch to export the package name and version
> number, LFS is practically ready for a package manager and it required
> no additional hacks.
>
> Any objections? Again, there was no diff in the HTML. There might still
> be interest in deciding what are install actions and what aren't, but
> that's a separate discussion.
These additions are benign and will have no impact on older versions
of jhalfs (2.2 or less). During the last quarter of 2006 similar changes
were discussed for jhalfs-3.0 but it died from lack of interest.
>
> --
> 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: ...)
Jeremy Huntwork wrote: > On Fri, Jul 20, 2007 at 11:38:30AM -0700, Dan Nicholson wrote: >> Thanks for the info. I think just to get started on handling multiple >> arches in LFS, we should focus on non-multilib 64 and just symlink >> /lib -> /lib64. Hopefully it doesn't bite elsewhere, but I think it's >> the fastest way to get up and running. Multilib is definitely the way >> to go, but I think it's more important to just get a 64 bit build in >> before handling the much larger case. Then again, I haven't done >> anything, so this is just speculation. > > Agreed. > > I believe I have the necessary changes worked through in a working copy > of the x86_64 branch I made the other day. Due to time constraints I > haven't been able to finish a full build, but I believe what is there > will work. I do plan on testing it fully before I commit any changes, > but I figured I'd show what I have and give someone else the opportunity > to build it if they like and/or look for any obvious errors. > > Here's the rendered book: > http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 Should we add lfs-x86_64 to to jhalfs now or wait a few weeks/months? I assume there will be a multi-lib version after all objections/ideas have been aired. (planning ahead for jhalfs) > > And here's the current diff (so you can see the changes in a glance): > http://linuxfromscratch.org/~jhuntwork/x86_64-changes.diff > > The two gcc pure64 patches come from CLFS. > > -- > JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: suggest 'make -j2' for SMP machines?
Deskin Miller wrote: > On 6/4/07, Miguel Bazdresch <[EMAIL PROTECTED]> wrote: >> Deskin Miller wrote: >>> [ should the book say anything about 'make -j X' on multi-core systems? ] >> ['make -j X' where X is number of cores is more or less optimal...] >> There are issues when running make with other than -j1. Some package builds will fail when make tries a parallel build. You can check out jhalfs' optimize section which has an incomplete black list of packages with MAKEFLAG issues. >> As far as mentioning it in the book... I'm not enthusiastic, since >> it's basic knowledge of how your computer works... OTOH we already >> say some pretty basic things, and the proliferation of multicore >> CPUs might warrant a mention of make -j. > This also applies to the 'older' Hyper-Threading Intel products. I saw a noticeable reduction in compile times when I went to -j2. > The concept of matching 'make -j X' to the number of cores isn't > difficult, but I'd argue it's worth a mention as much for those who > haven't had cause to wonder about 'make's various flags before, as to > give people a lesson in multi-core theory: in my own case, as a Linux > user for several years now, make -j was an eye-opener when I came > across it only yesterday, since I had never had a SMP or multi-core > system until very recently upon which to compile, and thus unwittingly > filtered out from my Linux knowledge the make flags which didn't have > any use to me, until now. > > In short: say it for those who lack 'make' knowledge, as well as those > who lack 'multi-core' knowledge. > > -Deskin Miller -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: sysklogd
Robert Connolly wrote: > Do any of you know assembly well enough to convert this: It has been a few years. > http://www.linuxfromscratch.org/~robert/new/dd.asm > to something gcc can compile? Are you looking to convert this to 'C' or just strip the unnecessary code And remove all the options, making bs=1 the > default, and 'dd from-file to-file' the only thing it does. > > robert > -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
blfs-bootscripts-6.1-HLFS patch
The patch sets up calls to /bin/install, should this not be /usr/bin/install ? -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: syslogd build error
Robert Connolly wrote:
> For now use:
>
> make RPM_OPT_FLAGS="-D_FORTIFY_SOURCE=0"
yup, works like a charm.
>
> Notice the added "_". I'll fix it in svn right now.
>
> robert
>
> On Tuesday March 27 2007 23:06, George Boudreau wrote:
>> Robert,
>> With a little hand-holding I was able to convince jhalfs to build most
>> of HLFS/glibc. At the moment I have bumped into the following errors
>> when I reach syslogd. (This build is with 2.6.20.4 and the associated
>> grsecurity patch.) Does the following trace ring any bells?
>>
>>
>> gcc -DFORTIFY_SOURCE=0 -O3 -DSYSV -fomit-frame-pointer -Wall
>> -fno-strength-reduce -DALLOW_KERNEL_LOGGING -c sysl
>> syslog.c:85: error: expected declaration specifiers or '...' before
>> numeric constant
>>
>> syslog.c:86: error: conflicting types for '__syslog_chk'
>>
>> /usr/include/bits/syslog.h:26: error: previous declaration of
>> '__syslog_chk' was here
>>
>> syslog.c:95: error: expected ')' before numeric constant
>>
>> syslog.c:99: error: expected identifier or '(' before '{' token
>>
>> make[1]: *** [syslog.o] Error 1
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
syslogd build error
Robert,
With a little hand-holding I was able to convince jhalfs to build most
of HLFS/glibc. At the moment I have bumped into the following errors
when I reach syslogd. (This build is with 2.6.20.4 and the associated
grsecurity patch.) Does the following trace ring any bells?
gcc -DFORTIFY_SOURCE=0 -O3 -DSYSV -fomit-frame-pointer -Wall
-fno-strength-reduce -DALLOW_KERNEL_LOGGING -c sysl
syslog.c:85: error: expected declaration specifiers or '...' before
numeric constant
syslog.c:86: error: conflicting types for '__syslog_chk'
/usr/include/bits/syslog.h:26: error: previous declaration of
'__syslog_chk' was here
syslog.c:95: error: expected ')' before numeric constant
syslog.c:99: error: expected identifier or '(' before '{' token
make[1]: *** [syslog.o] Error 1
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Greetings and a General Cleanup
Alexander E. Patrakov wrote: George Boudreau wrote: Just curious, what packages. At the very minimum: Ch5: cpio (for initramfs), cdrtools Ch6: isolinux, dhcpcd, pppd, openssl, lynx, GPM, eject, livecd-bootscripts. I added to the ability to append custom packages to the build in the svn:trunk of jhalfs. (see README.CUSTOM) The ch6 packages could be built using this feature. I assume the ch5 packages are temporary and only necessary to the build and not the final product This may not fit 100% of your needs but would reduce the number of mods to the book. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Greetings and a General Cleanup
Alexander E. Patrakov wrote: George Boudreau wrote: Alexander E. Patrakov wrote: George Boudreau wrote: Just curious, what packages. At the very minimum: Ch5: cpio (for initramfs), cdrtools Ch6: isolinux, dhcpcd, pppd, openssl, lynx, GPM, eject, livecd-bootscripts. I added to the ability to append custom packages to the build in the svn:trunk of jhalfs. (see README.CUSTOM) The ch6 packages could be built using this feature. Thanks, this is indeed a useful feature for those who build their own packages using jhalfs. However, if I use it, I would have to modify both the book and jhalfs. Modifying only the book seems more logical for me :) I see. You will create a custom book, LFS + BLFS-lite, and run jhalfs against the new book. The book would remain as a reference with the included lynx package as a reader. This CD would create a bootable, network ready install? I assume the ch5 packages are temporary and only necessary to the build and not the final product Correct. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Greetings and a General Cleanup
Alexander E. Patrakov wrote: George Boudreau wrote: I see. You will create a custom book, LFS + BLFS-lite, and run jhalfs against the new book. Well, calling the additions "BLFS-lite" would be a big stretch :) Just enough tools to read the book, copy-paste commands and get online. The book would remain as a reference with the included lynx package as a reader. This CD would create a bootable, network ready install? Yes, although this will not become the official LiveCD (because of the failed "doubles as a rescue CD" requirement and because it won't work on my system due to LVM). This CD was originally intended as a bad joke. But let it happen :) yes.. variations on a theme are valuable exercises. You seem to have your developers cap on.. s 1. Why not a USB based system, save those CD's for coasters. 2. Incorporate the Puppy-Linux cdrom (yes.. cdrom) write-back capabilities to create a user customizable CDROM. 3. Absolute minimum compile environment (CLFS bootstrap method) with network tools for a pure network build. Just some idea that have been floating around -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Greetings and a General Cleanup
Jeremy Huntwork wrote: Alexander E. Patrakov wrote: Indeed, jhalfs is just a very good tool. I have a plan of building a new MiniCD with it, by patching the minimum of additional packages into the LFS book and running the jhalfs script on that patched book. Is this OK for jhalfs maintainers? I, at the least, would be interested in seeing what comes of that. :) Just curious, what packages. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Upgrade to Linux-2.6.18
Matthew Burgess wrote: Hi folks, Incidentally, has anyone done any work on getting the headers_install approach integrated with jhalfs. Is any specific support required, or does it just require the "linux-libc-headers" page being replaced with a "linux headers" page? yes.. changing the page will suffice Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Book SVN-20060909, Linux-Headers
Hi Robert, Doing a HLFS/glibc build using jhalfs and I encountered a failure building 6.9. Linux-Headers-2.6.17.11-08232006 cp -va include/net/* /usr/include/net is not a valid directory. Am I missing something?? G -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Users Hint
M.Canales.es wrote:
El Sábado, 19 de Agosto de 2006 16:51, Chris Staub escribió:
Note: A similar warning should be added to the ALFS webpage, saying that
you should not even attempt ALFS until you can successfully build a
system manually without errors and without any help from support
channels, and that any user who does try ALFS without this prerequisite
will not get any help from the support channels.
The next entry will be added to the jhalfs README:
---
2. PREREQUISITES::
To use this tool you MUST:
- have experience building {c,h,b}LFS packages
- know how to edit and write shell scripts
- know how a Makefile works
- be able to trace build failures and to find what is causing it
(user error, package bug, {c,h,b}LFS command bug, or jhalfs code bug)
If you don't have the above skill, please don't use this tool.
--
Looks that enought?
It is enough to warn any users, we can only supply assistance to
jhalfs questions and cannot hold their hands.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
uClibc
Robert, The heat here in Toronto has baked my brain and it's dumb question time. I ran jhalfs against the uClibc branch and it died a horrible death on chap 5.4 uClibc. I noticed you no longer build the uClibc headers in a separate script, you jump in feet first into a full build. However uClibc is looking for stack_chk_guard and stack_chk_local_fail. This is not available until the embryo is built. Just a piece of info (or noise if you are already looking into this) The glibc branch ran to completion and I was able to boot and ping a remote site. (not a test but it's a start). Total build time 3h20m and a 3.2g intel 630 w/1g mem box. G -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
one last typo, kernel
Robert, I was sure there were no more script problems but this one is back.. 7.12. Linux-2.6.17.7 .. make CC="gcc -no-pie -fno-stack-protector-all" . change to . make CC="gcc -no-pie -fno-stack-protector" The -fno-stack-protector-all switch is no longer valid G -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
svn typo
Robert, One last typo. (at least jhalfs is good at catching cmd script issues :-) ) G. 7.12. Linux-2.6.17.7 .. install -m444 /sources/grsecurity-2.1.9-2.6.17.7-200607261817.patch.gz.gz /usr/src gunzip /usr/src/grsecurity-2.1.9-2.6.17.7-200607261817.patch.gz.gz should be .patch.gz cd /usr/src/linux-2.6.17.7 patch -Np1 -i ../grsecurity-2.1.9-2.6.17.7-200607261817.patch.gz should be .patch -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
misisng patch
Robert, The following patch seems to be missing, I have looked in your patches dir and did not notice it there.. http://www.linuxfromscratch.org/patches/hlfs/svn/glibc-2.4-iconv_unnest-1.patch -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New server specs
Randy McMurchy wrote: George Boudreau wrote these words on 04/13/06 18:42 CST: It is fast enough for me and does a full LFS build in well under 2 hours and can render a book in minutes. I have a 500mhz p3 that every hour looks to see if there are updates to the BLFS and LFS books. If so, it renders. LFS SVN renders in about 3 minutes on this box, and it's a 500mhz. Jeez, I'd hope your 3.2ghz machine can also render in just a couple of minutes. Or perhaps did you mean seconds, and accidentally typed minutes? :-) yes, my mistake, it was seconds.. 1.05 sys, 35.1 real. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New server specs
Ken Moffat wrote: But, I won't be surprised if a 3GHz system is not as fast as you think! Sure, the memory (PC3200, or 2700, or DDR2?) is faster than what I guess must be PC100 in the old box, but the cpu will need more clocks per instruction. It will definitely be faster in the short term, but maybe not providing as much room for growth as you hope. Anybody got any server benchmark results for old/current kit ? Ken Although not Intel's latest toy I run a P4-640 (3.2Ghz 64bit w/1g mem) and it does run toasty. At full tilt running -j3 builds it reaches 56deg in a mid-tower box with 4 fans. As a personal toy it is fine but I would want more cooling for the SATA drives. It is fast enough for me and does a full LFS build in well under 2 hours and can render a book in minutes. If I had my 'druthers I would have RAID 1 as I have lost disks in the past (oops, when was the last backup?) 900 series would be nice but stay away from the top end as it is overpriced for minimal performance gain, invest in disks and memory instead.. just a opinion George p.s. for the dreamers, how about a beowolf cluster with distcc. ( I have a extra Sinclair ZX81 and an Motorola 1802 system somewhere in this clutter I could donate.. :-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unbootable
I have lost the thread for this topic so I will reply to my own posting.. You bring up a good point: I should have mentioned that I built the glibc flavor. I wonder if this could be a glibc issue? That would cause havoc when the kernel tries to run init, I assume - but would it cause a kernel panic? I will build a 2.6.14.6/glibc version and see what happens.. I will take about 2 hours.. HLFS 2.6.14.6/glibc builds, boots and accesses the network. This build was done with the following jhalfs branch which pulls down the latest HLFS book with no changes made to the code and only recommended security switches enabled in the kernel. SVN="svn://svn.linuxfromscratch.org" svn co $SVN/ALFS/jhalfs/branches/experimental -jps -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
from LLH announce list.. it's official LLH is dead
LLH hasn't seen a new release for a lot more than six months now and up until today I hoped to get back on track with new releases. But I've just spent some time doing a 2.6.14 update, and it came back to me, that I'd have to spend up to 10 hours just to get a basic 2.6.14.0 ready. And there'd still be 2.6.15 waiting, 2.6.16 just around the corner plus sorting through all the bug reports that came in during those months and all the internal rearranging I either had planned or that's being forced by new kernel releases (eg. addition of asm-powerpc). I stopped having both the time and the will for such commitments a couple of months ago. Should anyone want to take over, I'd be happy to give hints, pointers, and whatnot. Just don't get overexcited -- diffs between new kernel versions get bigger, not smaller, and after a couple of years there's still no long term solution in sight. Oh, and women don't fall for the "I hack kernel stuff" line. I was lied to. -- In the year eighty five ten God is gonna shake his mighty head He'll either say, "I'm pleased where man has been" Or tear it down, and start again -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Just playing the devil's advocate but have you run your script against a 2.6.12 kernel and compared your output to the 'official' 2.6.12 llh files. Jim Gifford wrote: Tushar Teredesai wrote: BTW, instead of writing to /tmp/new_header file, the script should probably write to $header.orig. The file in /tmp may exist and may not be owned by the user running the script. Will be done in the next version, expect it shortly. Also since this is starting to become a hot topic, I've created a svn for the script, so we can track it's progress. http://svn.jg555.com Anyone interested in helping can submit patches to me also, I see this as a CLFS and LFS community project. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootstrapping GCC
Jeremy Huntwork wrote: Ryan Oliver wrote: I must admit I never really ever bothered doing a time comparison between the methods (the build takes as long as it takes). Would be interesting to get some figures... If we can get jhalfs set up to parse CLFS x86 -> x86, I can time the builds here. Jeremy, this is a work in progress but it does build x8x->x86, x86_64 multilib, and a lot of hand holding a x86_64 pure. -- JH jhaclfs-dev.tar.bz2 Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
uClibc and kernel build
Robert, I saw your query in the uClibc list and the reply.. whoopee, HLFS now compiles.. uClibc-0.9.28/linux-2.6.14.6 (using jhahlfs) +MALLOC_GLIBC_COMPAT=y George -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
HLFS SVN-20051113 missing patch?
Hello all While beating my way through the latest svn of hlfs I noticed a patch was missing when coreutils was upgraded from 5.2.1 to 5.93 >>> coreutils-5.93-uname_PIC-1.patch I substituted corecutils-5.93-uname-2.patch for the moment.. I have a bash script(s) which automate(s0 (somewhat) a uClibc chap5/6 build when I stumbled on the missing script.. George. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Feedback on jhalfs
Hi Jeremy, Functionality-- it produces a LFS system, what more could you ask for todo list-- improve 'make clean', there are some artifacts from chapters 6,7,8,9 I think the script is a useful tool. It may be all well and good to bash in commands by hand but if you want to rebuild a system from scratch for some reason the jhalfs script is just what the doctor ordered. (and as a bonus it grabs all the latest mods from the svn doc). It is not supposed to and does not replace the LFS book but is a supplement. George -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
