Re: fsck + localtime in BIOS
Hi, I notice this thread seems to have died off. I was wondering if someone who has privileges to update the boot scripts could take a look at this, since either localtime or UTC is suposed to be supported by the lfs-bootscripts, but as it is, localtime is slightly broken, depending on your timezone. Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Reply: Re: Default filesystem
Da: TheOldFellow <[EMAIL PROTECTED]> Inviato:sabato 3 febbraio 2007 8.45 A: Cc: Oggetto: Re: Default filesystem >I think it's wiki stuff, or hints maybe (if they are not stone dead), >for the moment. If we get sufficient interest, AND it looks stable, the >editors might put something in the book. You can't ask them to add new >stuff unless you know how to support it - and who will do the supporting! >R. Hi and sorry for replying only now... I wasn't asking that... if perceived in this way sorry it's my fault... It was only a reflection based on a private conversation with Alexander. Anyway, I've started using ReiserFS and XFS since they first appeared and had no troubles except for one of the first releases of xfs. I built several times the same lfs version on ext3, reiserfs, xfs and reiser4 to catch and confront build time; tried reconstructing file systems multiple times too. Reiser4 is young and the bug I experience, imo, it's not a minor one, for this reason I said "experimental" support; indeed there's a problem: to use it host system *must* be modified, opposed to lfs thinking. Regarding infos can be found in this thread: http://linuxfromscratch.org/pipermail/lfs-dev/2007-January/058764.html For the other file systems (IBM JFS, Axis JFFS and Red Hat JFFS2) I tried them only a couple of times (I experienced a lot of troubles with JFS years ago) so I'm not so qualified, anyway I've implemented these filesystems support in a project I'm working on. Dan said that one is free to use whatever filesystem wanted, that's true, and Alexander, in a private conversion, said, as already reported in a previous reply: "Anyway, I am afraid that any attempt to build LFS on any filesystem other than ext3 is now considered an unforgivable deviation from the book (reason for such thought: for a long time, reiserfsprogs failed to build, and xfsprogs page contained a dead link - but both issues are fixed now)." So a, possible bad or wrong, idea but why not moving file system tools from BLFS (as states the name it's beyond lfs) to LFS (supposing a different fs instead of ext3) ? I don't want to be misunderstood nor everything else; it's a simple and as already said possible bad or wrong or stupid idea... Friendly, Luca -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: fsck + localtime in BIOS
On Saturday 03 February 2007 08:40, Jack Brown wrote: > Hi, >I notice this thread seems to have died off. I was wondering if > someone who has privileges to update the boot scripts could take a look > at this, since either localtime or UTC is suposed to be supported by the > lfs-bootscripts, but as it is, localtime is slightly broken, depending > on your timezone. Hi Jack. Sorry that this seems to have got dropped. I've created a ticket in Trac, #1948, so it doesn't get forgotten about again. Feel free to add yourself to the Cc: field if you want to follow any activity on it. Bryan, the fix looks sane and simple enough, but I'm not sure what the process is for generating a tarball from our bootscripts in SVN. Is it just a case of tarring up an `svn export' of the lfs-bootscripts repo? Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Reply: Re: Default filesystem
[EMAIL PROTECTED] wrote: > So a, possible bad or wrong, idea but why not moving file system tools from > BLFS > (as states the name it's beyond lfs) to LFS (supposing a different fs instead > of ext3) ? The problem is that this would introduce optional packages to LFS (which is traditionally supposed to be linear). However, I think that this is already addressed by the following text in the book: http://www.linuxfromscratch.org/lfs/view/6.2/chapter09/reboot.html > Now that all of the software has been installed, it is time to reboot > your computer. However, you should be aware of a few things. The system > you have created in this book is quite minimal, and most likely will not > have the functionality you would need to be able to continue forward. By > installing a few extra packages from the BLFS book while still in our > current chroot environment, you can leave yourself in a much better > position to continue on once you reboot into your new LFS installation. So maybe it only remains to add a sentence about filesystem support programs below that. BTW, DIY Linux avoids the problem altogether by installing into a directory and not caring about the filesystem at all. Boot loaders are beyond DIY. Such approach has some benefits, e.g., it acknowledges that you may want to use the newly built system as a chroot only, or boot it via network on a different computer. However, saying "You have to make this system bootable somehow - see you there" (as DIY effectively does) is inconsistent with the goals of the LFS project. LFS boots the kernel with GRUB, and uses a partition (as opposed to, e.g., LVM volume) as a root filesystem. This is concrete, simple and educational, and in most (I stress: not all) cases reaches the intended result. Adding complex setups would mean that people try them even if such setups are beyond their abilities. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: fsck + localtime in BIOS
Matthew Burgess wrote: > Bryan, the fix looks sane and simple enough, but I'm not sure what > the process is for generating a tarball from our bootscripts in SVN. Actually, I'm not completely sure either. ;-) > Is it just a case of tarring up an `svn export' of the > lfs-bootscripts repo? It should be, but there may have been other steps. There used to be a render script on belgarath (/usr/bin/render-lfs-book-dev.sh) which also had some (commented-out) code in it to set up both udev-config and the bootscripts tarballs. But that script looks like it's gone from quantum (even though it's still trying to run from fcron?). Anyway, I used to refer to that script to know what to do when releasing a new udev-config, but I never really looked at the bootscripts portion of it all that closely. I suspect it was close to the same process for them. Looking at my shell history, it looks like when I made a udev-config tarball, I did an svn export, then renamed the directory to have the datestamp in its name, then tar/bzip2ed it, then grabbed an md5sum and updated the filename/md5sum in the book. Then, I scp'ed it to belg, did a "chgrp wwwdownloads", and moved it to the downloads.lfs.org vhost directory. Hopefully that's sufficient for the bootscripts. Actually I should have updated the bootscripts quite a while ago; recent udev versions require a different udev_retry script. The script is correct in the bootscripts SVN repo, but not in the book. If you want to update the bootscripts Makefile and regenerate the tarball, go ahead, otherwise I can. signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Default filesystem
On 2/2/07, Luca <[EMAIL PROTECTED]> wrote: > > "Anyway, I am afraid that any attempt to build LFS on any filesystem > other than ext3 is now considered an unforgivable deviation from the > book (reason for such thought: for a long time, reiserfsprogs failed to > build, and xfsprogs page contained a dead link - but both issues are > fixed now)." > > This led me to such reflection; I mean, if it is considered an " > unforgivable deviation" from the book it could imply that Ext3 is > officially supported while others not. I'm sorry, this is wrong. Just because the BLFS editors are lazy in updating the reiserfsprogs and xfsprogs pages doesn't imply that any *LFS editor thinks they're not preferred filesystems to build on. By no means would I turn anyone away who was building on non-ext3. You could build on vfat for all I care. I can't think of anything we do in either book that's filesystem dependent besides the actual `mkfs'. Both the books were pretty bad for a major part of the last year. I wouldn't read more into this than there is. If I was going to change anything, it would only be to say that these aren't the only possibilities for filesystems in LFS Ch. 2.3. It sounds like we're currently giving the impression that those are the only supported filesystems. Are you aware of any issues with the current reiserfsprogs or xfsprogs instructions? P.S. I'm glad to hear you had success building LFS on the other filesystems. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Default filesystem
Alexander E. Patrakov wrote: > [EMAIL PROTECTED] wrote: >> So a, possible bad or wrong, idea but why not moving file system tools from >> BLFS >> (as states the name it's beyond lfs) to LFS (supposing a different fs instead >> of ext3) ? > > The problem is that this would introduce optional packages to LFS (which is > traditionally supposed to be linear). However, I think that this is already > addressed by the following text in the book: > > http://www.linuxfromscratch.org/lfs/view/6.2/chapter09/reboot.html > So maybe it only remains to add a sentence about filesystem support programs > below that. > > BTW, DIY Linux avoids the problem altogether by installing into a directory > and not caring about the filesystem at all. Adding > complex setups would mean that people try them even if such setups are > beyond their abilities. > Having read this and thought about it some more, I guess I'd suggest changing the book to build into a directory, then add some chapters on moving the built system to a bootable partition - and then making it bootable. This way we can have a simple scheme for the Newbies and Volume Management or other exotica for the Gurus. This is what I actually do these days. Your last point is well made, however. I can't see much advantage to actually building the LFS core on an exotic filesystem, or maybe I'm missing something - perhaps it's much faster, for instance. On the whole, perhaps LFS has it right at the moment, anyone with the knowledge and desire can easily use the basic instructions - and even jhalfs - to do whatever they want, but the learners have a safe and predictable journey. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Default filesystem
On 2/3/07, TheOldFellow <[EMAIL PROTECTED]> wrote: > > Having read this and thought about it some more, I guess I'd suggest > changing the book to build into a directory, then add some chapters on > moving the built system to a bootable partition - and then making it > bootable. > > This way we can have a simple scheme for the Newbies and Volume > Management or other exotica for the Gurus. This is what I actually do > these days. Your last point is well made, however. It's not a bad idea, but isn't any Guru gonna be smart enough to know that they don't need to create a new filesystem/partition? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: fsck + localtime in BIOS
On 2/3/07, Bryan Kadzban <[EMAIL PROTECTED]> wrote: > > Looking at my shell history, it looks like when I made a udev-config > tarball, I did an svn export, then renamed the directory to have the > datestamp in its name, then tar/bzip2ed it, then grabbed an md5sum and > updated the filename/md5sum in the book. Then, I scp'ed it to belg, did > a "chgrp wwwdownloads", and moved it to the downloads.lfs.org vhost > directory. Hopefully that's sufficient for the bootscripts. Right, I asked Bruce to do it this way since the old way of generating the tarball left you in a position of not knowing the md5sum till after the render. The way it is now, any of the editors can commit away on udev-config or bootscripts. When they're ready, they generate a tarball just like Bryan explained above for downloads.lfs.org. This gives two bonuses in my mind: 1. A new tarball isn't created every time you make a commit. The editor controls when things are stable enough to roll a new version. 2. You create the tarball, so you know all the stats and can enter them in the book. This will invariably come out different in a script since the tarball has to contain info on all the dates/perms/ownership. -- Dan -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Default filesystem
Dan Nicholson wrote: > On 2/3/07, TheOldFellow <[EMAIL PROTECTED]> wrote: >> Having read this and thought about it some more, I guess I'd suggest >> changing the book to build into a directory, then add some chapters on >> moving the built system to a bootable partition - and then making it >> bootable. >> >> This way we can have a simple scheme for the Newbies and Volume >> Management or other exotica for the Gurus. This is what I actually do >> these days. Your last point is well made, however. > > It's not a bad idea, but isn't any Guru gonna be smart enough to know > that they don't need to create a new filesystem/partition? > > -- > Dan Yes, I rambled on about it, but in the end I agree with you. Alex makes a good point about not giving too much scope for getting it wrong - learners need to succeed to be encouraged. Frankly, I think LFS is just about right - which is one reason that there isn't much going on ;-) And so I get bored with it :-( What I need is something it can't handle, like Udev for several months a year ago, or a new booting scheme... R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Reply: RI: Re: Default filesystem
Da: Dan Nicholson <[EMAIL PROTECTED]> Inviato:sabato 3 febbraio 2007 18.43 A: LFS Developers Mailinglist Oggetto: Re: Default filesystem Hi. (Sorry but sending mail through ISP page so don't worry about formatting) I'll try to be as clearer as possible. While building LFS there is a step: creating the filesystem on the partition. In LFS book there is e2fsprogs package installed. Dan, as you said, the filesystem to choose is a personal choice. Let's say I choose reiserfs; I can't manage it with e2fsprogs, so the base system should include reiserfsprogs package to manage filesystem. There is no optional added step, but simply a "potential" base package needed added. This led me to the "conclusion" or perhaps more correct "thought" that file-system tools should be more appropriate in LFS book instead of BLFS, because the file-system is not optional but for file-system type there are options. Friendly, Luca -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Default filesystem
On 2/3/07, TheOldFellow <[EMAIL PROTECTED]> wrote: > > What I need is something it can't handle, like Udev for several months a > year ago, or a new booting scheme... This is actually something I want to bring up. Our booting is dog slow. Maybe it's time to look into making improvements. We could replace init with init-ng or upstart. Or, we could just work to parallelize the bootscripts like is done on RedHat and SuSE. I think this has been brought up before. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Reply: RI: Re: Default filesystem
On 2/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Let's say I choose reiserfs; I can't manage it with e2fsprogs, so the base > system > should include reiserfsprogs package to manage filesystem. > > There is no optional added step, but simply a "potential" base package needed > added. > > This led me to the "conclusion" or perhaps more correct "thought" that > file-system tools should be more appropriate in LFS book instead of BLFS, > because the file-system is not optional but for file-system type there are > options. I see what you're saying. Ch. 2.3 should be clearer that if you want to use an alternate filesystem, you need to make sure you add the correct tools to Ch. 6. Or, maybe the note should come in the Introduction in Ch. 8 - Making the System Bootable. Or, maybe the note should be on the e2fsprogs page. Or all of them. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Boot sequence speed-up?
Dan Nicholson wrote these words on 02/03/07 12:11 CST: > On 2/3/07, TheOldFellow <[EMAIL PROTECTED]> wrote: >> What I need is something it can't handle, like Udev for several months a >> year ago, or a new booting scheme... > > This is actually something I want to bring up. Our booting is dog > slow. Maybe it's time to look into making improvements. We could > replace init with init-ng or upstart. Or, we could just work to > parallelize the bootscripts like is done on RedHat and SuSE. I think > this has been brought up before. "dog slow". I suppose you'd have to enlighten me how much faster this old 500mhz system would boot if the boot sequence was "improved". On my last boot, the logs show this: >From kernel.log: Jan 9 23:46:01 rmlscsi kernel: klogd 1.4.1, log source = /proc/kmsg started. Jan 9 23:46:01 rmlscsi kernel: Inspecting /boot/System.map-2.6.14.3 Jan 9 23:46:01 rmlscsi kernel: Loaded 28586 symbols from /boot/System.map-2.6.14.3. Jan 9 23:46:01 rmlscsi kernel: Symbols match kernel version 2.6.14. >From daemon.log Jan 9 23:46:04 rmlscsi xinetd[1519]: removing shell [snip] Jan 9 23:46:04 rmlscsi xinetd[1519]: xinetd Version 2.3.14 started with libwrap loadavg options compiled in. Jan 9 23:46:04 rmlscsi xinetd[1519]: Started working: 4 available services Jan 9 23:46:05 rmlscsi rpc.statd[1552]: Version 1.0.8-rc4 Starting [snip] Jan 9 23:46:26 rmlscsi stunnel: LOG5[2269:3082909360]: stunnel 4.15 on i686-pc-linux-gnu with OpenSSL 0.9.8a 11 Oct 2005 Jan 9 23:46:26 rmlscsi stunnel: LOG5[2269:3082909360]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv4 Auth:LIBWRAP Jan 9 23:46:26 rmlscsi stunnel: LOG5[2269:3082909360]: 500 clients allowed >From cron.log (my last daemon to start in the rc sequence) Jan 9 23:46:27 rmlscsi crond[2280]: (CRON) STARTUP (fork ok) So, this means the system took approximately 26 seconds to boot. And here are the processes started (note this doesn't show the NFS daemons, as I've stopped and restarted the NFS services): root 1 0 0 Jan09 ?00:00:02 init [3] root 2 1 0 Jan09 ?00:00:00 [ksoftirqd/0] root 3 1 0 Jan09 ?00:00:04 [events/0] root 4 1 0 Jan09 ?00:00:00 [khelper] root 5 1 0 Jan09 ?00:00:00 [kthread] root 7 5 0 Jan09 ?00:00:02 [kblockd/0] root10 5 0 Jan09 ?00:00:00 [khubd] root 124 5 0 Jan09 ?00:00:00 [aio/0] root 123 1 0 Jan09 ?00:00:25 [kswapd0] root 125 1 0 Jan09 ?00:00:00 [cifsoplockd] root 202 5 0 Jan09 ?00:00:00 [kseriod] root 256 5 0 Jan09 ?00:00:00 [scsi_eh_0] root 329 1 0 Jan09 ?00:00:42 [kjournald] root 790 1 0 Jan09 ?00:00:00 [kjournald] root 791 1 0 Jan09 ?00:00:00 [kjournald] root 1310 1 0 Jan09 ?00:00:00 udevd root 1419 1 0 Jan09 ?00:00:09 syslogd -m 0 root 1428 1 0 Jan09 ?00:00:00 klogd dbus 1438 1 0 Jan09 ?00:00:00 /usr/bin/dbus-daemon --config-file=/etc/dbus-1/system.conf root 1488 1 0 Jan09 ?00:00:01 /usr/sbin/hald --retain-privileges root 1497 1488 0 Jan09 ?00:00:31 hald-addon-storage bin 1509 1 0 Jan09 ?00:00:00 /usr/sbin/portmap root 1519 1 0 Jan09 ?00:00:00 /usr/sbin/xinetd root 1932 1 0 Jan09 ?00:00:01 /usr/sbin/cupsd root 2071 1 0 Jan09 ?00:00:00 /usr/sbin/slapd root 2081 1 0 Jan09 ?00:00:00 /usr/X11R6/bin/nasd -aa -b root 2094 1 0 Jan09 ?00:00:00 /usr/sbin/sshd root 2149 1 0 Jan09 ?00:00:01 /usr/sbin/httpd -k start root 2158 1 0 Jan09 ?00:00:00 /bin/sh /usr/bin/mysqld_safe --user=mysql mysql 2193 2158 0 Jan09 ?00:00:19 /usr/sbin/mysqld --basedir=/usr --datadir=/srv/mysql --user=mysql --pid-file=/srv/my postgres 2195 1 0 Jan09 ?00:00:00 /usr/bin/postmaster -D /srv/pgsql/data -i apache2205 2149 0 Jan09 ?00:00:00 /usr/sbin/httpd -k start root 2206 1 0 Jan09 ?00:00:02 sendmail: accepting connections root 1 0 Jan09 ?00:00:06 /usr/sbin/snmpd root 2225 1 0 Jan09 ?00:00:00 /usr/sbin/snmptrapd apache2227 2149 0 Jan09 ?00:00:00 /usr/sbin/httpd -k start apache2228 2149 0 Jan09 ?00:00:00 /usr/sbin/httpd -k start apache2229 2149 0 Jan09 ?00:00:00 /usr/sbin/httpd -k start apache2230 2149 0 Jan09 ?00:00:00 /usr/sbin/httpd -k start apache2231 2149 0 Jan09 ?00:00:00 /usr/sbin/httpd -k start root 2250 1 0 Jan09 ?00:00:08 /usr/sbin/nmbd -D postgres 2257 2195 0 Jan09 ?00:00:00 postgres: writer process postgres 2258 2195 0 Jan09 ?00:00:00 postgres: stats buffer process postgres 2259 2258 0 Jan09 ?
Re: Boot sequence speed-up?
On 2/3/07, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Dan Nicholson wrote these words on 02/03/07 12:11 CST: > > On 2/3/07, TheOldFellow <[EMAIL PROTECTED]> wrote: > >> What I need is something it can't handle, like Udev for several months a > >> year ago, or a new booting scheme... > > > > This is actually something I want to bring up. Our booting is dog > > slow. Maybe it's time to look into making improvements. We could > > replace init with init-ng or upstart. Or, we could just work to > > parallelize the bootscripts like is done on RedHat and SuSE. I think > > this has been brought up before. > > "dog slow". I suppose you'd have to enlighten me how much faster this > old 500mhz system would boot if the boot sequence was "improved". On > my last boot, the logs show this: Mostly what I mean is that from the time boot has started to getting a prompt. If you have a laptop, for example, you're booting frequently and 25 seconds is kind of long. Or, at least, 25 seconds is much longer than it needs to be. Point is taken, though, and maybe "dog slow" isn't the right phrase. At the minimum, things could be vastly sped up by not serializing the whole operation. Read this article from IBM for an example. http://www-128.ibm.com/developerworks/linux/library/l-boot.html -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Boot sequence speed-up?
Randy McMurchy wrote: > On my last boot, the logs show this: > >>From kernel.log: > Jan 9 23:46:01 rmlscsi kernel: klogd 1.4.1, log source = /proc/kmsg > started. Note that this time is when klogd started, not when the kernel booted. (At klogd start time, it reads the kernel printk ring buffer and sends everything to syslogd, which drops the current time onto each line.) Well, unless you have your kernel logging timestamps in its printk messages, but I don't think those timestamps have this format. OTOH, sysklogd runs fairly early (it's at S10 in rc3.d, so it starts right after the rcsysinit.d stuff finishes starting), so from grub to your last daemon's start probably still isn't more than 30 seconds. The slowest parts are probably waiting for udev to finish, and running fsck. > Oh, also let me say that my systems are booted very infrequently > (when I go out of town, or there's an extended power outage), so 25 > seconds every month (or several months) seems acceptable. :-) Yeah, I feel the same way about my server (it gets booted maybe three or four times a year). But the machine I'm on right now is too loud at night, so I shut it down then, which means it boots up around once a day. When you boot more often, it obviously makes more sense to speed up the boot. ;-) signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Boot sequence speed-up?
Bryan Kadzban wrote these words on 02/03/07 12:55 CST: > But the machine I'm on right now is too loud at > night, so I shut it down then, which means it boots up around once a > day. When you boot more often, it obviously makes more sense to speed > up the boot. ;-) Point taken from you and Dan about machines that require frequent booting, but not to beat a dead horse, I'm throwing out one more statistic: On a much more modern machine than the 500mhz machine I threw out stats on already (2400+ Athlon), from the time boot logging starts and the time it ends is 12 seconds. And on this machine, a few more processes are started. Just out of curiosity (I can't right now), as soon as I can I'm going to boot my fastest machine and time it using a stopwatch from the time I press Enter at the GRUB prompt, to the time I get a prompt on the console. For you laptop guys, about how long does it take to boot from GRUB to prompt using the current bootscripts (I say from GRUB, as the GRUB menu is displayed almost instantaneously after BIOS checks and the system begins booting)? Please don't count any full fscking that may go on for you. Of course, this would skew results. -- Randy rmlscsi: [bogomips 1003.26] [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] 13:06:01 up 24 days, 13:20, 1 user, load average: 0.28, 0.10, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Boot sequence speed-up?
On Sat, Feb 03, 2007 at 10:45:58AM -0800, Dan Nicholson wrote: > On 2/3/07, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > Dan Nicholson wrote these words on 02/03/07 12:11 CST: > > > > > > This is actually something I want to bring up. Our booting is dog > > > slow. Maybe it's time to look into making improvements. We could > > > replace init with init-ng or upstart. Or, we could just work to > > > parallelize the bootscripts like is done on RedHat and SuSE. I think > > > this has been brought up before. > > > > "dog slow". I suppose you'd have to enlighten me how much faster this > > old 500mhz system would boot if the boot sequence was "improved". On > > my last boot, the logs show this: > > Mostly what I mean is that from the time boot has started to getting a > prompt. If you have a laptop, for example, you're booting frequently > and 25 seconds is kind of long. Or, at least, 25 seconds is much > longer than it needs to be. Point is taken, though, and maybe "dog > slow" isn't the right phrase. > > At the minimum, things could be vastly sped up by not serializing the > whole operation. Read this article from IBM for an example. > > http://www-128.ibm.com/developerworks/linux/library/l-boot.html > I've seen these things, they all sound absolutely wonderful. I do boot my desktops frequently, and into gdm - nowadays they are almost always switched off when I'm sleeping, and I might use two or three different machines during the day. My ibook OTOH is only booted infrequently (it sleeps beautifully). BUT, I've looked at this before from a high level - wait for the bios or OF to run whatever checks it can and then present the bootloader; select the desired kernel/system ; wait while udev, sysfs, and perhaps some machine-dependant slow low-level things bring the kernel up, then watch userspace. For me, the big delays in bringing up userspace are ntp, and to lesser extents dhcp, starting cups (varies - sometimes seems very slow, probably version dependant), and mounting an nfs share. Oh, and starting X itself - it doesn't matter how fast the machine gets, X always takes too long to start (several seconds, feels like an eternity!). Sure, for my desktops I could save time by running ntp in the background, but I like the comfort (or not) of seeing how far out the time was. The mounting, in my case, could be in the background but I definitely want to know if it fails. My best guess is that from power-on to graphical login takes towards a minute. If I save 10 seconds, it will be nice, but it's not that much of a difference. Still, I await your initial hint with interest ;) ĸ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: Boot sequence speed-up?
On 2/3/07, Ken Moffat <[EMAIL PROTECTED]> wrote: > On Sat, Feb 03, 2007 at 10:45:58AM -0800, Dan Nicholson wrote: > > > > At the minimum, things could be vastly sped up by not serializing the > > whole operation. Read this article from IBM for an example. > > > > http://www-128.ibm.com/developerworks/linux/library/l-boot.html > > > For me, the big delays in bringing up userspace > are ntp, and to lesser extents dhcp, starting cups (varies - > sometimes seems very slow, probably version dependant), and mounting > an nfs share. Oh, and starting X itself - it doesn't matter how > fast the machine gets, X always takes too long to start (several > seconds, feels like an eternity!). > > Sure, for my desktops I could save time by running ntp in the > background, but I like the comfort (or not) of seeing how far out > the time was. I don't think it's really in the background, though. At least on SuSE (which I had for a bit on my laptop when I first got it), all the bootscripts run as they always do, it's just not serial. It still has to wait until all the scripts complete before init returns. So, you'd still see the message coming from ntp, but it wouldn't stall the whole process while that was happening. It only stalls bootscripts which are dependent on ntp. Somehow, the messages from the different bootscripts weren't getting garbled. I don't know how, though. > Still, I await your initial hint with interest ;) It's one of the next things I want to play with :) I'll let you know when I make some progress, but I imagine that others have already done it. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Boot sequence speed-up?
Randy McMurchy wrote: > On a much more modern machine than the 500mhz machine I threw out > stats on already (2400+ Athlon), from the time boot logging starts > and the time it ends is 12 seconds. And on this machine, a few more > processes are started. That stat on this machine is only three seconds (14:18:11 to 14:18:14). But that three-second number really doesn't match up to anything I measured with a stopwatch, see below. > For you laptop guys, about how long does it take to boot from GRUB to > prompt using the current bootscripts (I say from GRUB, as the GRUB > menu is displayed almost instantaneously after BIOS checks and the > system begins booting)? Not a laptop, but I get 30 seconds from pressing enter in grub until getting the login: prompt. Notes: 1) This test included almost 10 seconds of just the kernel booting up. The bootscripts didn't start running until around second number 8 or 9. 2) This test also didn't quite use the current bootscripts: I've changed my copy of the udev script to add a 5-second sleep after the udevsettle call. Without that, I kept getting kernel messages while other scripts were coming up, because various stuff didn't happen in time. (I run with dmesg -n set at 7, but I don't care about all that detail while devices are being found, so for the duration of udev, I set dmesg -n 4. But it got set back before the drivers finished loading.) So take 5 seconds off for that modification. 3) About 5-6 seconds of that was waiting for a DHCP lease. I'm not sure what it is with this NIC, but it's quite slow at getting a lease. So the bootscripts themselves were only around 10 seconds of that time. But of course I don't start X up at boot time, either. The CPU is a dual-core Athlon 64 4200, if that matters. signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Optional libcap dependency in vsftpd
Dan Nicholson wrote these words on 02/03/07 12:39 CST: > vsftpd can use the library libcap (see vsf_findlibs.sh in the source > tree). It's a simple library that basically just wraps the syscalls in > and puts its API in . vsftpd > will just make the syscalls itself if doesn't exist > (see sysdeputil.c in the vsftpd source). > > http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/ > > Can I add this to the book? Things like this shouldn't really need 'permission'. I consider a missing dependency as a defect. Let's keep the option to fix defects available all the way up until the final release. Does this should too risky? I don't think so, but others may. -- Randy rmlscsi: [bogomips 1003.26] [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] 13:34:00 up 24 days, 13:48, 1 user, load average: 0.56, 0.22, 0.14 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Optional libcap dependency in vsftpd
On 2/3/07, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Dan Nicholson wrote these words on 02/03/07 12:39 CST: > > > > Can I add this to the book? > > Things like this shouldn't really need 'permission'. I consider a > missing dependency as a defect. Let's keep the option to fix defects > available all the way up until the final release. Yeah, that was dumb. I think I more mean, "Can I commit this now?" I'll put it in trunk and we'll figure out getting into the 6.2.x area. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Xorg-7 contents - #2216
I'm starting to add the contents for Xorg-7 (programs, libraries, directories). How explicit should I be with these things? Do we want full descriptions and index entries for the programs and libraries? I don't mind doing it, but I wanted to ask before I spend some time doing it. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Boot sequence speed-up?
On Sat, Feb 03, 2007 at 01:14:06PM -0600, Randy McMurchy wrote: > > Point taken from you and Dan about machines that require frequent > booting, but not to beat a dead horse, I'm throwing out one more > statistic: > > On a much more modern machine than the 500mhz machine I threw out > stats on already (2400+ Athlon), from the time boot logging starts > and the time it ends is 12 seconds. And on this machine, a few more > processes are started. > FWIW, here are my times for my fastest desktop (athlon64 4000+) and my latest (via C7D 1.5GHz, using an old LFS-6.1 system that was on the disk, static ip, no X). I don't have a stopwatch anymore, and my watch has a rotating second hand, so these times are only accurate to a couple of seconds. Also, I care about the time it takes to get to a bootloader prompt because it is part of the power-up experience. I restarted the timings from when I hit after selecting which kernel/system. All in seconds. a64 4000+ c7 power on0 0 bootloader prompt 14 16 select the kernel/system0 0 init starts 7 20 console prompt 54 gdm prompt 45 Slow things: On the C7, ntp takes about 19 seconds, nothing else stood out. On the athlon64, dhcp took about 5 seconds, ntp about 14 seconds, and X itself is dog slow to start. Might be the particular driver or the particular card. ĸ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: LFS Wiki UserNotes
On Saturday 03 February 2007 07:19, Dan Nicholson wrote: > On 2/2/07, Barius Drubeck <[EMAIL PROTECTED]> wrote: > > On the other hand, it is indeed a problem specific to supporting > > and maintaining ancient systems with ancient glibc, thus > > temporaly far *beyond* LFS, and therefore has little to do with a > > fresh LFS build of a new system. > > Actually, this isn't a problem specific to supporting ancient > glibcs. In this particular case, we're talking about timezone data > that was updated between glibc-2.3.2 and glibc-2.3.6, but the > timezone data can be updated at any time. If there's an update to > the timezone data now, is my glibc-2.3.6 considered ancient? Even > if you have glibc-2.5, it doesn't mean you have the most current > timezone data. Sorry, I overstated that a bit. What I meant is that timezone data changes tend to be announced well in advance, and thus tend to get integrated into glibc long before the change becomes effective. Certainly, there are no guarantees that this will be the case. Maybe it's even just wishful thinking And no, I don't consider glibc-2.3.6 ancient. Like I said, I overstated. (Although 2.4 has been around for almost a year.) But admit, your 2.3.6 does contain the tz update as per my wishful thinking above ;-) Thinking practically, what are the odds of more than one major tz change during the lifetime of an LFS book version? And how portable is the tz update procedure from one book version to another? IMHO, those two questions ought to be considered in choosing the optimal format and placement of the procedure. -- Barius -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Wiki UserNotes
On 2/3/07, Barius Drubeck <[EMAIL PROTECTED]> wrote: > > Thinking practically, what are the odds of more than one major tz > change during the lifetime of an LFS book version? And how portable > is the tz update procedure from one book version to another? IMHO, > those two questions ought to be considered in choosing the optimal > format and placement of the procedure. Like this zoneinfo update to glibc in November? http://sources.redhat.com/ml/glibc-cvs/2006-q4/msg00319.html I'm not sure how portable it is across glibc versions. I think it's just data, though, and could probably be safely updated. I believe it comes from the tzdata tarballs here: ftp://elsie.nci.nih.gov/pub/ -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg-7 contents - #2216
Dan Nicholson wrote these words on 02/03/07 13:55 CST: > I'm starting to add the contents for Xorg-7 (programs, libraries, > directories). How explicit should I be with these things? Do we want > full descriptions and index entries for the programs and libraries? I > don't mind doing it, but I wanted to ask before I spend some time > doing it. In the long run, yes, descriptions of programs and libs would be great. The directories thing should be a snap, as there simply isn't that many top-level dirs for X. You decide if you have the time/desire to do it. I *loathed* doing these when the concept of the index was developed, but I suppose it was a necessary evil. And since you missed out on all that fun, perhaps you *should* do them. :-) And, speaking of this, I'd like to thank Manuel, again, for his efforts in completing those program/lib descriptions. He did many, many of them during the XML conversion several months back. What a life-saver that was. -- Randy rmlscsi: [bogomips 1003.26] [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] 14:53:01 up 24 days, 15:07, 1 user, load average: 0.14, 0.18, 0.31 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg-7 contents - #2216
On 2/3/07, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Dan Nicholson wrote these words on 02/03/07 13:55 CST: > > I'm starting to add the contents for Xorg-7 (programs, libraries, > > directories). How explicit should I be with these things? Do we want > > full descriptions and index entries for the programs and libraries? I > > don't mind doing it, but I wanted to ask before I spend some time > > doing it. > > In the long run, yes, descriptions of programs and libs would be > great. The directories thing should be a snap, as there simply isn't > that many top-level dirs for X. You decide if you have the time/desire > to do it. Yeah, I think I'm gonna do them. The library descriptions might not be that accurate, but I'm just going to pull the program descriptions from the man pages. > I *loathed* doing these when the concept of the index was developed, > but I suppose it was a necessary evil. And since you missed out on > all that fun, perhaps you *should* do them. :-) After looking at it for about the 10th time, I think I finally understand how the and stuff works in the Contents section. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: fsck + localtime in BIOS
Matthew Burgess wrote: > > Hi Jack. Sorry that this seems to have got dropped. I've created a ticket > in > Trac, #1948, so it doesn't get forgotten about again. Feel free to add > yourself to the Cc: field if you want to follow any activity on it. > > > Matt. Thanks Matt Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
BLFS-6.2.0-rc1 Released!
Hi all, It is with great pride that the BLFS team announces the release of BLFS-6.2.0-rc1. This release is a candidate for the actual 6.2.0 release due out on February 14th, and is the complement to LFS 6.2. It has been almost 18 months since the last release of BLFS and many new packages and instructions have been added. For a summary of some of the changes, see: http://www.linuxfromscratch.org/blfs/view/6.2.0-rc1/preface/preface.html#foreword This candidate release does not have two Trac bugs fixed, which (one already is fixed in the development version of BLFS) both should be completed by the final release. You can view the release candidate at: http://www.linuxfromscratch.org/blfs/view/6.2.0-rc1/ Additional information, as well as additional download formats, is available at: http://www.linuxfromscratch.org/blfs/6.2.0-release_notes.html -- Randy rmlscsi: [bogomips 1003.26] [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] 18:37:01 up 24 days, 18:51, 1 user, load average: 0.36, 0.27, 0.42 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Problem regarding tcl-8.4.13 installation
I'm making LFS. During the installation of tcl-8.4.13 I got a problem during "make install". It gives an error"[EMAIL PROTECTED]:/mnt/lfs/sources/tcl8.4.13/unix$ make install Installing libtcl8.4.so to /tools/lib/ cp: cannot create regular file `/tools/lib/#inst.15380#': Permission denied mv: cannot stat `/tools/lib/#inst.15380#': No such file or directory chmod: cannot access `/tools/lib/libtcl8.4.so': No such file or directory make: *** [install-binaries] Error 1". But "configure" & "make" works properly. Please help. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
problem with util-linux
Hello, I,m new here and don't speak english, so, sorry my poor english. I am following the book at great length and occour a problem on chapter 5.30 . When i type "make -C text-utils more" i receive the following message make: Entering directory `/mnt/lfs/sources/tmp/util-linux-2.12r/text-utils' more not made since it requires ncurses or termcap But ncurses is installed. Somebody can help me? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS LiveCDs 6.2-4 - grub-install problems. (util-linux-2.12r?)
> > 2. The second is that once a kernel is running that it can't open > the root filesystem. It's not just a kernel problem, as even > kernels more recent than the 2.6.16 kernel (2.6.18 for example) > also fail to boot. > had a similar problem yesterday installing LFS 6.2 using LiveCD 6.2-4 on Toshiba U200 notebook. The new kernel could not open the root file system not recognizing /dev/sda3. Seems a problem with udev and kernel not populating /dev. It was solved by using the .config file from the LiveCD to compile a new kernel, sense the LiveCD booted and ran nicely on the notbook. Next boot with the new kernel compiled kernel booted smoothly and LFS 6.2 ran with no problem. Sami -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Changing chroot environment in LFS 6.2 gives error
Hi,
I am facing a problem regarding LFS 6.2. After installing all packages
successfully when I came to " Entering the Chroot Environment " & give
chroot "$LFS" /tools/bin/env -i \
HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h
this command it produced an
error
chroot: cannot run command `/tools/bin/env': No such file or directory .
But there is a file inside /tools/bin/ named env. When I run that it
gives
SSH_AGENT_PID=7632
SHELL=/bin/bash
DESKTOP_STARTUP_ID=
TERM=xterm
GTK_RC_FILES=/etc/gtk/gtkrc:/home/avik/.gtkrc-1.2-gnome2
WINDOWID=39849596
OLDPWD=/tools
USER=root
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.ogg=01;35:*.mp3=01;35:*.wav=01;35:
LFS=/mnt/lfs
SSH_AUTH_SOCK=/tmp/ssh-LUwJlf7594/agent.7594
GNOME_KEYRING_SOCKET=/tmp/keyring-KgG0mN/socket
USERNAME=avik
SESSION_MANAGER=unix/avik.mat3impex.india.net:/tmp/.ICE-unix/7594
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
DESKTOP_SESSION=default
GDM_XSERVER_LOCATION=local
PWD=/root
LANG=en_IN
GDMSESSION=default
SHLVL=2
HOME=/root
LANGUAGE=en_IN:en
GNOME_DESKTOP_SESSION_ID=Default
LOGNAME=avik
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-xxmG7SJDt7,guid=da07ae457ebe73de72b76bad780cd600
LESSOPEN=| /usr/bin/lesspipe %s
DISPLAY=:0.0
LESSCLOSE=/usr/bin/lesspipe %s %s
XAUTHORITY=/home/avik/.Xauthority
COLORTERM=gnome-terminal
_=/usr/bin/env
And as an lfs user it gives
TERM=xterm
LC_ALL=POSIX
LFS=/mnt/lfs
PATH=/tools/bin:/bin:/usr/bin
PWD=/home/lfs
PS1=${debian_chroot:+($debian_chroot)[EMAIL PROTECTED]:\w\$
SHLVL=1
HOME=/home/lfs
_=/tools/bin/env
My work is stopped at this point.
Please somebody help me.
with regards,
Avik SenGupta
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: testing dev list postings...
DJ Lucas wrote: > I can't see anything wrong, but I'm still having problems sending to > LFS-Dev...checking the other lists I'm sub'd to as well. I know Bruce > did something the other day to try to fix it and then I changed some > things on my end as well that should have corrected it properly (I > think). Bruce, if you (or any admin) get time, please review and see if > you see anything funny as to why I can't post there now. I am not > getting the not subscribed message as I was before. > > Subscribed address is [EMAIL PROTECTED] There were no messages from you being held from you. According to http://linuxfromscratch.org/pipermail/lfs-dev/2007-February/date.html#start you have not posted on lfs-dev this month. The only things I can think of is that the message never arrived or that the system somehow identified it as spam. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
