Re: What should I choose while installing Linux Kernel?
Modules are compiled separately and saved onto the hard drive, they will not be available until after the hard drive has been mounted and so if the kernel needs that module during the boot process then the kernel will panic and will not boot. Modules that have been placed into the initrd or initramfs *will* be available during bootup if early userspace has been properly programmed. And therein lies the rub: learning and debugging early userspace requires persistence and fortitude. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: What is 21?
On Tuesday 21 June 2011 09:42:10 Dominic Ringuet wrote: On Tue, Jun 21, 2011 at 8:22 AM, Webmaster ad...@hwlyz.tk wrote: For example: ls -l /usr/bin | more redirect_test.log 21 (BLFS 6.3 Page 37) What does 21 mean? 2 is stderr is a redirector 1 is stdout Without it, both normal output and errors will be printed in the file; with it, normal output goes in the file and error is on the screen. (unless standard output goes somewhere else) Examples: ... So far, there are no errors, the behavior is the same in both instances. The expression becomes meaningful only if there is an error: ls -al /non/existant/directory test.log 21 * will print No such file or directory on screen, leaving test.log empty ls -al /non/existant/directory test.log * will print No such file or directory in test.log Horseshoes and hand grenades. Your first 'error' example will place STDOUT and STDERR in test.log. Your second example will display the error message on the terminal and leave the log file empty. The general form 'XY' means close file descriptor (FD) X, then make it a duplicate of file descriptor Y. The order is important. The commands command 21 /dev/null and command /dev/null 21 result in very different output. The first closes file descriptor (FD) 2 then makes it a duplicate of FD 1, then closes FD 1 and opens it on /dev/null; the result is that the program's STDERR goes to wherever STDOUT was pointing, and STDOUT is dumped into the bit bucket. The second closes FD 1 and opens it on /dev/null, then closes FD 2 and makes it a duplicate of FD 1; the result is that the program's STDOUT and STDERR are both dumped in the bit bucket. You can even swap STDOUT and STDERR: command 31 12 23 3- Remember that computers are dumb: they do things in the order they're told. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev168 not work with mountfs of bootscript on x86_64 system ?
On Saturday 30 April 2011 21:32:01 Simon Geard wrote: I'd have expected 'udevadm settle' to block while this stuff's still happening - is that not the case, maybe with 168? I'd be real surprised if settle doesn't work. They haven't removed it *that* soon, have they? (There's been talk about it) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: setclock Question (lfs-bootscripts-20110424)
On Saturday 30 April 2011 23:00:42 al...@verizon.net wrote: Hello, The time sequence on my standard system would be: 1. '/lib/udev/rules.d/50-udev-default.rules': SUBSYSTEM==rtc, DRIVERS==rtc_cmos, SYMLINK+=rtc 2. '/etc/udev/rules.d/55-lfs.rules': # This causes the system clock to be set # as soon as /dev/rtc becomes available. SUBSYSTEM==rtc, ACTION==add, MODE=0644, \ RUN+=/etc/rc.d/init.d/setclock start KERNEL==rtc, ACTION==add, MODE=0644, \ RUN+=/etc/rc.d/init.d/setclock start -- I'm reformulating the questions/confusion of my OP: 1. FWIW, I don't see the relevance of rule 50-udev above (1) The rule in 50-udev creates the symlink '/dev/rtc' to the actual node '/dev/rtc0'. It isn't relevant to the clock being set or not being set. 2. What is a possible configuration that would trigger the _SUBSYSTEM_ action in 55-lfs (2) ? *As written*, the subsystem rule is triggered *if* the RTC is in subsystem rtc; if there is no such subsystem, the rule will never be triggered. The kernel rule will never be triggered because it is looking for a device with kernel name 'rtc'; this device doesn't exist. If this rule is changed to look for a device with correct kernel name of 'rtc0', it will be triggered. 4. I'm still puzzled about not being able to find any traces on the console about 'setclock' being run by udev (55-lfs above). Is it possible that inside udevd the standard message Setting system clock... goes somewhere else? The log-fog? The log level may be set to, or default to, 'err'. If you change it via udevadm control --log-priority=info or udevadm control --log-priority=debug you should see all the info you're looking for--'debug' will show a *ton* of info. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: setclock Question (lfs-bootscripts-20110424)
On Friday 29 April 2011 12:42:47 Andrew Benton wrote:
On Fri, 29 Apr 2011 08:57:54 -0700
bsquared bwcod...@gmail.com wrote:
Yes, I rebooted and checked /dev/rtc is a link to /dev/rtc0 which
matches kernel config.
--
Thank you,
-Brian
On re-reading my last message wasn't very clear. Yes I have the rtc
file, but the time is incorrrect. It appears that udev is not running
setclock.
What could be causing this? I looked in the logs and there is no
reference to udev,setclock.
It seems that /dev/rtc0 is matching this rule in 50-udev-default.rules
which is why it's making the symlink:
SUBSYSTEM==rtc, DRIVERS==rtc_cmos, SYMLINK+=rtc
The question is, why doesn't it match the 55-lfs.rules:
SUBSYSTEM==rtc, ACTION==add, MODE=0644,
RUN+=/etc/rc.d/init.d/setclock start KERNEL==rtc, ACTION==add,
MODE=0644, RUN+=/etc/rc.d/init.d/setclock start
This rule looks rather misshapen. Translated to more traditional C-ish logic:
if ((SUBSYSTEM == rtc) (ACTION == add)
(KERNEL == rtc) (ACTION == add)) {
MODE = 0644;
RUN += /etc/rc.d/init.d/setclock start;
MODE = 0644;
RUN += /etc/rc.d/init.d/setclock start;
}
I don't know if udev can handle a rule when conditions and actions are
intermixed and repeated. But if it didn't barf, it must've been OK.
Ordered more traditionally and removing the redundant parts, the rule would
be:
KERNEL==rtc,SUBSYSTEM==rtc,ACTION==add,RUN+=/etc/rc.d/init.d/setclock
start,MODE=0644
which would translate to C-ish:
if ((KERNEL == rtc) (SUBSYSTEM == rtc) (ACTION == add)) {
MODE = 0644;
RUN += /etc/rc.d/init.d/setclock start;
}
ACTION==add says to match the rule iff the device is being added for the
first time.
KERNEL==rtc says to match if the kernel name of the device is 'rtc'. I'll
bet this should be KERNEL==rtc0.
Debian has a nice rule in 85-hwclock.rules:
KERNEL==rtc0, RUN+=/lib/udev/hwclock-set $root/$name
Clearly they've added functionality to udev. But it provided the clue.
The other way to find information about a device:
udevadm info --query=all --name=/dev/rtc
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: setclock Question (lfs-bootscripts-20110424)
On Saturday 30 April 2011 01:11:01 Simon Geard wrote: Andrew's post is missing a newline, I think. It's actually two rules: SUBSYSTEM==rtc, ACTION==add, MODE=0644, RUN+=/etc/rc.d/init.d/setclock start and KERNEL==rtc, ACTION==add, MODE=0644, RUN+=/etc/rc.d/init.d/setclock start Simon. Ah, that makes more sense. But still, the kernel name is 'rtc0' (zero) which would explain why that particular rule is ineffective; the SUBSYSTEM rule becomes redundant. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Slightly OT: Building with a VM
On Tuesday 26 April 2011 00:25:52 me,apporc wrote: Hi Is there a book or someting like which i can refer to for these knowledge about disks , images files and partitions . I don't know how to mount a partition in a image file with offset .I want to know detailed knowledge about this . I hope you can give me an advice. Point one: the block stream in an image file is very much like the block (sector) stream on a hard drive. Point two: the man pages are your friend; 'man mount' and 'man losetup' will tell you what you need to know about mounting image files and using offsets into those images. Here is a very simple, generic example of mounting file disk.image onto mount point '/mnt' with an offset 234 bytes into the file: mount disk.image /mnt -o loop,offset=234 As to determining the actual offsets to use, you will have to read up on the particular VM technology used, be it QEMU, VMware, Xen, VirtualBox or any other system. I expect they will all be different. You will also have to research the various partition format available (MSDOS, PC98, GPT, Apple, SCO, BSD, etc.); they're all different. You should even find information via Google or Wikipedia about specific image file formats, but this takes time and persistence. I've learned what I know about the subject from the man pages, Google, Wikipedia and plenty of plain, dogged experimentation using dd, od and other shell tools to dissect image files in order to figure out what is where in the files. N -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Slightly OT: Building with a VM
Bother! Clicked the wrong button! On Thursday 21 April 2011 21:12:12 Neal Murphy wrote: Suppose you have a 100MB disk image file. In parted, you can: You can make a GPT partition table: mklabel gpt mkpart boot ext2 1mb 20mb mkpart swap linux-swap 20mb 30mb mkpart root ext4 30mb 50mb mkpart root-1 ext4 50mb 75mb mkpart root-2 ext4 75mb 100mb toggle 1 boot print quit A PC98 table is similar, except it sets all partitions bootable by default and doesn't seem to understand filesystem names: mklabel pc98 mkpart boot ext2 1mb 20mb mkpart swap linux-swap 20mb 30mb mkpart root ext4 30mb 50mb mkpart root-1 ext4 50mb 75mb mkpart root-2 ext4 75mb 100mb toggle 2 boot toggle 3 boot toggle 4 boot toggle 5 boot print quit Or you can use the traditional MSDOS partition scheme. mklabel msdos mkpart primary ext2 1mb 20mb mkpart primary linux-swap 20mb 30mb mkpart primary 30mb 50mb mkpart extended 50mb 100mb mkpart logical 51mb 75mb mkpart logical 76mb 100mb toggle 1 boot print quit Your VM should boot from any of them. Parted also seems to understand the difference between decimal (MB) and binary (MiB). If it doesn't work, I've a large selection of hats to choose for a snack. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Slightly OT: Building with a VM
On Friday 22 April 2011 00:34:42 Mike McCarty wrote: Neal Murphy wrote: Bother! Clicked the wrong button! [nice stuff snipped] I very much appreciate the suggestions for PT editors. Thanks! However, I'd like to get an answer to the question about the offsets within the file to get to the starts of the file systems. Am I missing something, like I need to allow for the BPB at the beginning of some of the partitions? Something like that? If so, then why does volume 2 mount w/o problem, based upon the computed offsets. What does fdisk mean when it says that the physical and logical start/end of a volume are not the same? I understand the usual layout of an MBR and the PT, and I'm not sure what inconsistency there can be, unless the BPB and the PT disagree in some way. Oh, duh. Out! Out, demons of stupidity! I inwardly sneer at others who don't answer the posed question. Then I go and do it myself. To answer your question, your VM system probably has some stuff at the beginning of the image, which is another offset to account for. Your fdisk output looks like this is the case. The difference between physical and logical start/end is most likely the difference between CHS/sector counting and LBA counting; fdisk is saying they don't line up. You probably don't have the correct offset(s). When you get it right, fdisk won't know it's not looking at a hard drive. Make a fresh, small-ish image file for your VM system, boot something, make a partition at the beginning, put EXT3 on it, then 'od -c|head' that node and remember the byte pattern at the beginning. Then put a known unique-ish data pattern in the boot sector. Close and exit the VM and look for those byte patterns. That'll give you the offset for the VM system and the offset for the boot sectors/partition table/multi-disk info. Yes, you can probably find the info on the web somewhere, but it's much more gratifying to find it yourself eh. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Incompatibility of udev and /usr
On Sunday 17 April 2011 01:26:59 DJ Lucas wrote: Ahh...lightbulb. This is why we currently have the udev-retry in our bootscripts. This is probably getting outside of the 'LFS Support' realm. Mayhap the next version of LFS will not need 'udev-retry' because either udev works, or the system has not been programmed correctly. I can't imagine why they'd get rid of 'settle' without providing a suitable replacement. The booting system *must* know when the devices have been created; it *must* wait until it knows that all necessary device nodes are ready. - devtmpfs is auto-populated with all devices the kernel knows; early userspace contortions to provide a usable environment are no longer needed - udev fills in the rest of the devices, loading modules as needed - udevadm settle 'pauses' booting until all device nodes are ready: a second or two - bootup continues This scheme works for initramfs and for booting to disk. It works on bare metal and in VMs. It works on single-core and multi-core CPUs. Maybe some day in the future all startup scripts will check for the existence of all device nodes they need and wait until they exist before proceeding. But for now, bootup must pause until nodes are all created. Honestly, if there's a rational for requiring a 'udev-retry', I've not seen it; once I got the one optimal 'lock' set up, it all works without retries and without failures, in RAM only or with hard/flash drive. Either all nodes are ready before initramfs/initrd proceeds with its startup tasks or all nodes are ready shortly after operation is pivoted to the final root's FS, depending on when udev is run. If ya'll have seen reasons for 'udev-retry', please share them. I'm not saying this to belittle anyone or anyone's efforts. I'm saying it because LFS *can* be improved. Udev may be *very* poorly documented, but it does work. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Incompatibility of udev and /usr
On Saturday 16 April 2011 21:55:30 Simon Geard wrote: My understanding is that the problem isn't with the location of libraries - it's with the location of data under /usr/share. Stuff like the pci.ids and usb.ids files, which are apparently required for some of the udev rules. Those files could presumably be moved to somewhere under /, but there's no obvious place to put them, no /share directory... Gently illuminating a point that does not necessarily invalidate your whole argument: pci.ids and the IDs used in drivers are not necessarily in sync. Udev should depend solely on the IDs compiled into the drivers; it can easily obtain this info from the driver itself. Udev v165 seems to care about pci.ids only in config.h*, configure, and configure.ac; pci.ids doesn't seem to be referenced anywhere else in the source. Neither 'pci.ids' nor #defines using the file seem to be used in any code, which makes sense since a driver should not claim any device that does not match its compiled-in IDs. I would expect usb.ids to be treated similarly. I wouldn't expect great changes within several releases of udev. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Kernel Help Requested
On Friday 08 April 2011 15:44:12 Andrew Benton wrote: On Fri, 8 Apr 2011 10:09:14 -0700 bsquared bwcod...@gmail.com wrote: One would think that there would be a script that could make a config from a running system. That's an interesting idea for an open sourced project. It wouldn't have to be perfect, as long as it booted the user could fine tweak it for themselves. If the specific kernel option is enabled, one can 'zcat /proc/config.gz' to obtain the config used to build the running kernel. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Kernel Help Requested
On Friday 08 April 2011 19:54:08 Andrew Benton wrote: On Fri, 8 Apr 2011 16:58:26 -0400 Neal Murphy neal.p.mur...@alum.wpi.edu wrote: If the specific kernel option is enabled, one can 'zcat /proc/config.gz' to obtain the config used to build the running kernel. Yes, but it's a chicken and egg situation. The first time you compile a kernel on a new computer all you have is the generic config from the distro you used to install LFS. It would be nice if there was a simple script that would use lsmod, lspci, lshw, dmidecode or whatever to probe the hardware and write a basic .config for you that would at least have some sensible defaults and would boot. If you just took the ubunut (or whatever) .config it would have _everything_ enabled as a module and it would take forever to compile. A script that at least disabled support for hardware you don't have would save a lot of time. Ah, right. I briefly considered doing something like this to automate preparing a system for Coreboot, some years back when I last *really* wanted to dump the braindead BIOSes most Intel/AMD mboards ship with. Then I realized it was probably a lot more involved than it seemed at first glance. N -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
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
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: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On Sunday 13 March 2011 14:12:20 Dan McGhee wrote:
On 03/13/2011 01:06 PM, Dan McGhee wrote:
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
I just found in the fine print of an example. ABS Guide uses it to allow
for spaces.
Generally, single- and double-quotes allow for spaces in strings and for null
(or empty) strings. Double-quotes allow $xxx shell variables to be expanded;
single-quotes prevent expansion. Learning to automatically quote strings leads
to long-term hair retention. I usually use quotes because they result in
clearer syntax than one gets when using \ escaping.
var=two words
if [ $var == two words ]; then ... fi
and
var=two\ words
if [ $var == two\ words ]; then ... fi
are equivalent; the quoted form is clearer and is often the only way to make
it work.
Also, I must amend my msg re: the explicit semi-colon I included following the
last command when using the ' { commands; } syntax. I was mistaken. They
aren't necessary when the commands are on separate lines, as in:
... {
command 1
command 2
}
but it won't hurt to have them there. Semi-colons are only needed to terminate
commands when they are on one line, as in:
... { command 2; command 2; }
It is standard, consistent shell syntax.
I thought I tested it both ways before clicking send; clearly I didn't.
N
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: gcc test failures
On Sunday 13 March 2011 15:50:43 Alex Bosworth wrote: I don't think this is a hardware problem as none of the other packages fail their tests and I don't encounter any crashes or errors during normal use. Don't be too quick to write off hardware problems. Building gcc is well known for uncovering latent hardware faults, just as it did when I first built it in the mid '90s and kept hitting the 'signal 11' error. When I build my firewall on my quad-core desktop (using 'make -j 4' for most packages), only two packages get the CPU up to 60C and hold it there for 1-3 minutes: gcc and the kernel. The kernel build is mostly 'busy work'. But the gcc build exercises a lot of the CPU and RAM; if there's a heat weakness or other hardware instability, building gcc may well uncover it. To be sure, I'm not saying it *is* a hardware problem. But if it only happens to GCC, it could be hardware-related. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: gcc test failures
On Sunday 13 March 2011 23:48:52 Alex Bosworth wrote: I were making use of -j2 make option, I wonder if would make a difference if I set it to -j1 and lower the priority for make (perhaps set it to +20 ?) and see if that helps to keep the heat low !? '-j 1' will definitely make a difference, but setting the nice value won't (assuming you aren't running any unrelated cycle-munching programs). If that isn't enough, then reduce the maximum processor frequency via cpufreq-utils or via the /proc or /sys interface. Take a gander at: http://idebian.wordpress.com/2008/06/22/cpu-frequency-scaling-in-linux/ Try setting it to 'powersave' while compiling gcc and otherwise set it to ondemand. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On Saturday 12 March 2011 19:00:56 Dan McGhee wrote:
# This one recovers from failed make.
if [ -e $logdir/make-`echo $package`.err ] \
[ ! -e $logdir/install-`echo $package`.err ]; then #Now build
removed make, make check and make install sections
fi
# This one recovers from a failed install
if [ -e $logdir/make-`echo $package`.log ] \
[ ! -e $HOME/$package-files.list ]; then
Technically, you may be mixing metaphors with this syntax. Perhaps the syntax
is valid, but it isn't doing what you expect. Try:
if [ -e file_1 -a ! -e file_2 ]; then
commands
fi
# equivalent: if test -e $file_1 -a ! -e file_2; then
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
Also, the syntax '-e $logdir/make-${package}.log' will eliminate a smidgeon
of complexity even though what you did is correct. Any time you aren't sure if
a shell var like $var will be, or is being, parsed correctly in context, put
the name in braces, as in ${var}.
Nothing else on your script pokes me in the eye with a sharp stick.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Wednesday 23 February 2011 04:54:10 Simon Geard wrote: Are you unaware then, that udev provides the /dev/disks/by-label directory, which contains volume labels as symlinks to the kernel-named devices? For example, my fstab file doesn't reference /dev/sda6 for the /home partition - it uses /dev/disk/by-label/home instead. Likewise, /boot is mounted as /dev/disk/by-label/boot and the swap partition as /dev/disk/by-label/swap. You must be superhuman, able to memorize names like 485cc6bb- ef7f-44ca-91c4-55d884c4083e, 4e23b7e0-af66-45b3-b0c2-a5af31c14c1b, 5e34b5db-1fa8-49e7-9250-fb95ea301579, 73B115E331E98B57, 74fbc4cd-784e-49fc-8d24-ca51623ba15c, 965800A05800816B, bbde5991- c72e-424f-97eb-00acfba10aff, f3ab5997-5ecd-4486-ab86-4fd172d714ea, which parritions they are and which HDs they belong to. Most ordinary humans really want to know that *this* hard drive is 'dska' and *that* hard drive is 'dskb', and want to see and use those names. They don't want to be mistyping ridiculously long, obscure, patternless, hexadecimal file names the few times they need to admin their systems. They don't want to be spelunking through their filesystems painstakingly matching random hex digits to be sure they are pulling the failed drive and not a good one. They want to fix the system and get back to using it. That I've been spelunking through systems from TOPS-10, through the various PDP-11 OSen, VMS, UNIX, Linux, Solaris, SCO, OS/9, BeOS, Haiku, et al and can find what I need to know is beside the point. I just remember that there are folks who are not experts in the subject but who still need to learn how to work with it. I'm not saying they should be molly-coddled; rather, I'm saying their level of knowledge and expertise should be taken into consideration. In the case of udev and its present 'status', Human Factors has been discarded. I'm also cognizant that LFS is a 'teaching' system that doesn't just ape what other distributions do. It might be useful to do more teaching in the fields of early userspace and udev. To return to the topic, without using the specific kernel feature, DEVTMPFS, one must manually create certain nodes in /dev in order to boot the system, even if one is using udev. If you mount a devtmpfs, the kernel will prepopulate it with the basic nodes it knows about; even here, a few nodes must exist in /dev in the initramfs. But if one enables the related kernel feature, DEVTMPFS_MOUNT, the kernel will automount a devtmpfs on the rootfs' /dev and populate it; with this feature, one can boot with 'init=/bin/sh' into a fully working shell with a minimal initramfs/initrd. These are the only cases that I know of in which nodes are automagically created in /dev. All others depend on user-space programs to create such nodes. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Tuesday 22 February 2011 19:44:24 al...@verizon.net wrote: Notes: 1. cp ... console /dev in 'udev' script doesn't work. (apparently, too late in the boot sequence.) 2. For reasons unknown, even if I start with the metal /dev empty, I end up with both null and console nodes in /dev at the end of boot. Go figure. The Udev police may get me one day but in the meantime I can have my full, CLEAN console log _and_ still use the excellent scripts Mr. Beekmans and all the other collaborators worked hard to design for our use and enjoyment. Thank you all. Having integrated udev almost from scratch for my advanced version of Smoothwall (I stole Debian's udev scripts), I've learned most of the ins and outs of udev, devtmpfs and what the kernel offers. If the option is enabled, the kernel has the ability to pre-populate /dev with all devices it knows about. Mounting devtmpfs on /dev triggers the action. The kernel will maintain its entries until something else touches them. Without this kernel facility, /dev must be pre-populated with a few (yes, 'few') nodes; /dev/pts usually needs to be made before mounting depts on it. Once devtmpfs is mounted and either prepopulated by the kernel or the booting system, udev can be started and triggered. It then walks the BIOS tree ins'ing modules for all devices it finds. When it replaces a kernel-made node, the kernel forgets about maintaining that node. It ain't easy figgerin' this stuff out. I upgraded my dev version to 2.6.35 weeks ago, and only Sunday did I find the last piece of the puzzle to get devtmpfs and udev working smoothly. The install bootup has no timing delays or pauses. Just create a single lock file, a single spin waiting for udev to start, a single wait for the lockfile to be erased, and a single wait for udev to settle. The rest of startup goes like grass through a goose. Booting to HD is even easier because USB isn't needed right off. I haven't checked to see if the kernel will populate /dev without using devtmpfs; it's working as-is: no sense in continuing the search for a solution. :) But that's the reward: figuring it out relying on partial documentation and improbable web search matches. Put simply, *something* creates nodes in /dev: - the build - the installer - the kernel - the initramfs/initrd init script - early userspace udev - the rootfs boot script - HD udev My media builder no longer pre-populates /dev with anything. And if I haven't already, I need to remove the stuff in /lib/udev used to prepopulate /dev. The kernel now takes care of all that when devtmpfs is mounted. I know my modernization of Smoothwall isn't LFS; I did borrow heavily from LFS during the early efforts to get 2.6.26 and 2.6.32 working, just as Smoothwall originally borrowed heavily from LFS when it was created years ago. But maybe my perspective will help someone else learn a little more about early user space, /dev and udev. N Speaking of the udev police... [rant] Digressing a little, I have a bone to pick with Kay Seivers and Greg K- H. Their attitude is that only symlinks should be used in /dev and created from udev rules (for the most part), and those symlinks may only be named with character sequences that are incomprehensible to ordinary humans. I believe they've overlooked the human factors aspect: that people cannot quickly pattern-match 50-byte filenames, that the kernel does not use symlink names in its reports (only the actual /dev node name), your primary hard drive may be hda today, sda tomorrow, sde the day after, and a couple other points. (Maybe I mispeak a little; Squebian Deeze uses partition names; now I cannot find *anywhere* the device associated with a FS! Aaaarrrgggh!) My bootup system works, but I may well enhance the udev scripts to create additional disk names (NAME+=...), because hdX and sdX are now meaningless. I'll create /dev/dsk[a-z] nodes based on the drive's short ID; the kernel is free to use any name it wants to, and the admin will have a short, constant, neurally- friendly name to use. In fact, kernel device names should be put in a /dev/kernel tree, hidden from normal users. Human Factors needs to be brought back to Linux in this respect, because humans (admins) need to be able to quickly match node names against something their brains readily recognize as much as the OS itself needs to be able to unambiguously recognize node names. Don't get me wrong. Udev is great work; I really like it: it's eliminated a couple hundred lines of startup script. It's just that now is the time to start working human factors back into that equation to make Linux friendly again.[/rant] -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: questions about modifying the temp tool chain
On Tuesday 11 January 2011 22:16:12 mike cutie and maia wrote: yes i am a blind user trying to do it its not always easy to copy from the book with a screen reader so i am throwing away this build and am going to try again and hope i have better luck this next time -Original Message- From: lfs-support-boun...@linuxfromscratch.org [mailto:lfs-support-boun...@linuxfromscratch.org] On Behalf Of Ken Moffat Sent: Tuesday, January 11, 2011 8:33 PM To: LFS Support List Subject: Re: questions about modifying the temp tool chain On Wed, Jan 12, 2011 at 01:55:24AM +, Ken Moffat wrote: [ stuff ] Alternatively, you've got accessibility issues. I know we've had occasional users with speech readers, but most of us can't advise on the issues. The thought of having to remember all of the information in the book scares me to death. This is one of the unrealized reasons I suggested including links on each page to the more important instruction and overview pages. Having unobtrusive links to the steps common to each package available on each page serves to remind users that those steps are there and, in this case, would help people who *must* memorize everything to do so. In time, we all memorize the book, but doing so is far easier when one can easily flip from page to page and quickly see what we're looking for. Waiting for text to be read must be extremely frustrating, as must be searching for a page of info when you can't see what you're looking for. While the Book may be technically correct, it isn't necessarily friendly. To be sure, I'm not suggesting the book be rewritten or reformatted just to coddle people through the entire process. But perhaps a checkbox that shows or hides the 'training wheels' would suffice. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem booting LFS 6.7
On Sunday 09 January 2011 18:52:55 Theodore Papamarkou wrote: Thank you very much! It worked for me! I've got linux from scratch installed!!! On 9 January 2011 22:07, Bruce Dubbs bruce.du...@gmail.com wrote: Theodore Papamarkou wrote: The problem though is that I rebooted the system several times without remounting it manually or automatically through /etc/fstab. If that's one of the mistakes I made, then I will have to do go through all the chapters of the book from the beginning, right...? Not necessarily. The file are probably in /mnt/lfs on /dev/sda1. Just mount sda3 somewhere else: mount /dev/sda3 /media mv -a /mnt/lfs/* /media umount /media mount /dev/sda3 /mnt/lfs And you should be OK to go from there. Technical query: while this would move all the files, shouldn't the boot sector also need to be set? Or did it work because Theodore is using grub from another partition? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Udev-165 (apparently) System Crash
On Saturday 08 January 2011 13:44:23 al...@verizon.net wrote: On Thu, 2011-01-06 at 02:08 AM, Simon Geard wrote: ... udevd supports a couple of options that might help, --debug and --debug-trace. 1. FWIW, udevd-165 does not (no-longer?) have a --debug-trace option. Maybe it's undocumented now (shades of Undocumented DOS of yore :) Please see 'man udevd'. 2. For argument sake, udevd writes to sys.log and daemon.log (identically). There are a few things that intrigue me (which might help in my non-kdump troubleshooting, if answered positively): 2.1. Udevd is active way before the main partition becomes read-WRITE (stemming from a chicken and egg situation, I suppose). Be that as it may, where's the mechanism that writes the accumulated udevd log from memory(?) to disk (/var/log/) ultimately (i.e. delayed)? 2.2. Can udevd (syslogd?) output be originally redirected to a different partition where it can go instantaneously, so I can find it postmortem and deduce the hardware element that bothers Udev? syslogd started early for this test, etc. 2.3. More simplistically, can I temporarily mount the main partition writable as soon as Udev discovers it and somehow start syslogd? As I mentioned, the crash occurs a few lines before the end of Udev run, i.e. long after Udev sees the partitions. Would syslogd start writing udevd output to disk immediately? That would involve creating an appropriate rule with some action in it, etc. Maybe splitting the udevd logic in two phases..., etc. I'd appreciate your thoughts. If 2.1-3 above too crazy, please disregard with my apologies. While I was integrating udev into my test/dev version of Smoothwall, I had to go through some 'contortions' when the system was in early boot (running in the initramfs). At this point, syslogd is not running and there is no hard drive available; logging is pretty much WYSIWYG. What follows is 'generic' Linux boot processes and may not mesh well with how LFS is actually booted. You may have to get your hands *really* dirty. You can modify the initramfs image (unpack it, modify it, repack it, reboot) by changing its init script to direct udev's STDOUT and STDERR to a file (in the tmpfs, of course). After udev runs (in the initramfs' init script), you can run a shell to examine the file. The bootup process will be suspended until you exit the shell. But you say 'the crash'. If the system is crashing (I, red-facedly, haven't paid attention), then you might try populating the initramfs' /dev with device nodes for your hard drive and modifying the initramfs' init script to mount the hard drive. Then run udev as verbosely as possible and redirect its stdout and stderr to a file on the hard drive. Be warned that playing in initramfs (early boot) is almost a black art. Things we take for granted, like standard TTY features, standard device nodes, and ordinary debugging tools may not exist. It's not as limiting as having only 18 toggles on the front panel, but it's still a bother. If you are truly desperate, you can always put the entire LFS / tree into the initramfs image. It'll be slow to unpack, but you'll have all the tools at your fingertips. You *will* need a lot of RAM to do this, though. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: jhalfs unexpected
On Tuesday 21 December 2010 12:22:05 Mike Hollis wrote: ... but I don't know how to call this core with gdb (gdb make core ? gdb gcc core ?) and even if I did it would probably not be useful for me. gdb fail31-frag.exe core is probably what will work, ifyou can find the fail31-frag program. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: bzip patch problem
On Sunday 12 December 2010 17:03:04 Randy McMurchy wrote: robert wrote these words on 12/12/10 12:43 CST: Suddenly, I suspected that to be the problem ... maybe not. In any case, I've one terminal and only one tab ... chroot. Things seem to be going swimmingly ... until this -npl -Npl moment. And just for completeness, you still have the syntax wrong. It is not Npl, it is Np1. That is a one at the end, not an el. This is getting away from pudgy digits and into ham-handed territory, I think. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Stumbling across the finish line
On Sunday 12 December 2010 01:09:39 Daryl Lee wrote: Well, I did it--sort of. After wrestling GRUB to the mat, I have succeeded in booting LFS 6.7 on my laptop that is already running Windows XP and Ubuntu 10.04. There is something very satisfying about that! But there is a lingering issue. When the new kernel boots, after the swap partition is mounted (or as part of mounting it--I can't really be sure) I get a message saying the file system is mounted and if I continue ***SEVERE*** damage will occur. Of course I answer no and then a few more messages stream by and I get a login prompt that actually works. Before I go digging into the code, can someone tell me what that warning is all about, and what I might do to boot without getting it? In case the answer requires it, my partitions are as follows: /dev/sda1Primary Windows XP NTFS /dev/sda2Primary Shared FAT32 /dev/sda3Extended /dev/sda5 Logical Ubuntu 10.04 ext3 /dev/sda6 Logical LFS 6.7 ext3 /dev/sda7 Logical swap Peruse your /etc/fstab to be certain you have correctly selected the partitions. On both Ubuntu *and* LFS. If that isn't it, it may be that LFS detects alien usage of swap (by Ubuntu). The warning may be related to suspending/hibernating Ubuntu. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Thursday 09 December 2010 16:22:34 Stuart Stegall wrote: My M3 runs better in the cold, and that has everything to do with cold. In this case though, this is in a temperature controlled Data Center with no competition for cycles. The program actually runs during the day, but if the build was done during the day, it will take a little bit longer, if it's done at night, it takes a bit less. Strangest thing I have ever experienced. *Something's* competing for cycles. First thing comes to mind is network traffic, like ARP or other broadcast traffic. Might be intersting to put an analyzer on the LAN segment and see what differs. If nothing else, you've discovered a true 'night and day' difference. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: make error with glibc on Fedora 14
On Wednesday 08 December 2010 12:19:10 Rosario Turco wrote: I have done the compilation without error with ../glibc-2.12.1/configure --prefix=/tools \ --host = $ LFS_TGT --build =$(../ glibc-2.12.1/scripts/config.guess) \ --disable-profile --enable-add-ons \ --enable-kernel = 2.6.22.5 --with-headers=/tools /include \ libc_cv_forced_unwind=yes libc_cv_c_cleanup= yes libc_cv_visibility_attribute=yes libc_cv_broken_visibility_attribute=no but the make show the error linking on the final ../i686-lfs-linux-gnu/bin/ld: can not find lgcc What must i see? Forgive me if I seem blunt; I must state this plainly and simply: you must see the incorrect syntax. Below, I show your incorrect syntax followed by the correct syntax, line by line. Three lines are correct; three are wrong. - Lines that start with BAD are your lines that contain invalid syntax. - Lines that start with FIX are lines I have corrected for you. - Lines that start with OK are your lines that are correct. Each line is presented on a single line. If needed, I'll repost the complete command with one command/option/item per line. - OK: ../glibc-2.12.1/configure --prefix=/tools \ BAD: --host = $ LFS_TGT --build =$(../ glibc-2.12.1/scripts/config.guess) \ FIX: --host=$LFS_TGT --build=$(../glibc-2.12.1/scripts/config.guess) \ OK: --disable-profile --enable-add-ons \ BAD: --enable-kernel = 2.6.22.5 --with-headers=/tools /include \ FIX: --enable-kernel=2.6.22.5 --with-headers=/tools/include \ BAD: libc_cv_forced_unwind=yes libc_cv_c_cleanup= yes FIX: libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes \ OK: libc_cv_visibility_attribute=yes libc_cv_broken_visibility_attribute=no - The correct pieces of text are there. But something seems to have randomly added spaces here and there and dropped the last, but still important, backslash (\). If your text editor is messing up the syntax, you must use another text editor, one that uses a fixed-pitch (monospaced) font like Courier and doesn't reformat content. You will likely never see the errors if you are using a proportionally-spaced font like Arial, Helvetica, Times and the like. If your email program is screwing the syntax, use another program. I always use fixed-pitch even for email, except in very rare circumstances. A 50% hit ratio may be OK in baseball, but computer commands must be 100% correct for them to work properly. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Tuesday 07 December 2010 04:55:43 robert wrote: unpacked udev-161.tar.bz2 cd udev-161 then copy and paste ... (the two dearchive operations are xvf??? and not jxvf??? 'tar xvf' unpacks a noncompressed tar archvie (.tar). 'tar xvfj' unpacks a bz2-compressed archive (.tar.bz2). 'tar xvfz' unpacks a gzip-compressed archive (.tar.gz, .tgz). -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Tuesday 07 December 2010 14:53:10 Bruce Dubbs wrote: When extracting, GNU tar is smart enough to recognize the compression type, if any, without being told. This capability has been in place for several years. Learn something new every day! I've been using the specific option for so long, it's second nature. Didn't mean to be misleading. Mayhap I encounter versions of tar that don't grok what they're reading -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc compilation ok on Fedora 14
On Sunday 05 December 2010 10:55:13 Rosario Turco wrote: ../glibc-2.12.1/configure - prefix = / tools \ - Host = $ LFS_TGT - build =$(../ glibc-2.12.1/scripts/config.guess) \ - Disable-profile - enable-add-ons \ - Enable-kernel = 2.6.22.5 - with-headers = / tools / include \ libc_cv_forced_unwind libc_cv_c_cleanup = yes = yes libc_cv_visibility_attribute=yes libc_cv_broken_visibility_attribute = no I surely hope the embedded spaces and lost hyphens are a result of language translation. Otherwise, I'm not sure that command has any chance of working. Options are introduced with --, not -. The option names are lower case (though this *might* not matter). The configure command's fifth line is missing a \ continuation character, and it has an extra yes. Correcting all that results in: ../glibc-2.12.1/configure --prefix=/tools \ --host=$LFS_TGT --build=$(../glibc-2.12.1/scripts/config.guess) \ --disable-profile --enable-add-ons \ --enable-kernel=2.6.22.5 --with-headers=/tools/include \ libc_cv_forced_unwind libc_cv_c_cleanup=yes \ libc_cv_visibility_attribute=yes libc_cv_broken_visibility_attribute=no Syntax is extremely important. As with humans, if you don't 'speak' the language correctly, the computer will not do what you expect. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: make mrproper
On Sunday 28 November 2010 12:08:15 robert wrote: ... That is the proximate end, as Aristotle might phrase it. Speaking of whom, odd that most people think of him as a genius. He believed and professed that women have fewer teeth than men. A really ignorant thing to postulate. Bordering on stupidity, given that he could actually have counted them. But perhaps he was being metaphoric, something of and estrogen/testosterone observation. In which case, I'm sure there are some who are inclined to believe him. Totally off-topic, you may be right. Perhaps women in his day weren't so easily scorned (much more subservient?) and the familiar proverb did not appear for a few centuries more: Beware the wrath of a woman scorned. I would imagine that, in time, men came to learn that women can have more, longer and sharper 'teeth'. Back to the subject to hand explicitly answering your question, 'make mrproper' is issued in the root directory of the kernel sources. That is, if you unpacked the linux sources for 2.4.27 in /home/robert/linux-2.4.27, you would 'cd /home/robert/linux-2.4.27;make mrproper'. Said elsely, 'mrproper' is defined in the top-level linux kernel makefile. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: GCC Build Instructions (was Re: Book-5.8_Adjusting the ...)
On Tuesday 26 October 2010 09:37:01 Randy McMurchy wrote: On 10/26/2010 7:09 AM, Brett Mahar wrote: I agree, there is no way that I could figure that out from reading the book. Then you failed to read Section 5.3 General Compilation Instructions. This has been discussed many times, and it has always been determined that we expect readers to actually *read* the book, and not skip any sections. And if you read the book, you'll come across a box labeled ... Brett, I'm sorry you wasted several hours; however, please answer this question. Why didn't you read Section 5.3, which in 5 minutes would have made the process perfectly clear? -- Randy Randy, you are correct. The information is all there. It probably works well for someone with a keen grasp of written English and someone who is already familiar with the build process. But the book is still wrong because it does not clearly and explicitly guide readers around this stumbling block. And this isn't the only stumbling block in the book. As a outsider, I see the LFS Team chanting their 'Read the Book' mantra, users showing up here confused, the LFS Team continuing their chanting, and users continuing to show up confused. There are times when judiciously repeating certain information can be extremely helpful, especially at locations known to trip people. Judicious repetition is a solid tool for reinforcing ideas and concepts; it is a tool that has been used for millenia. So why isn't judicious repetition good enough for LFS? I really don't understand the resistance to changing GCC now requires the GMP, MPFR and MPC packages. As these packages may not be included in your host distribution, they will be built with GCC: to something like GCC requires the GMP, MPFR and MPC libraries. Because they may not be included in your host distribution, they must be built as part of GCC. Be sure to unpack their tarballs within the GCC source directory (review chapter 5.3). '... now requires ...'? GCC has required those libraries for a long time; it's nothing new. Just state that those libraries are required. BTW, GCC requires the libraries, not the packages. '... will be built with GCC'? This evokes two thoughts. (1) Well, duh! EVERYTHING gets built with GCC! (2) OK; this is automatic; GCC knows how to do all this. Perhaps this should be reworded (1) to make it much clearer that those three libraries 'must be built AS PART OF gcc', or 'must be built INTEGRAL TO gcc', or 'must be built INTO gcc', and (2) to make it clearer that it's not automatic. While '... must be built ...' is not 100% true, it suffices to say they must be built as part of GCC and eliminates a little room for error. LFS users can learn the difference at another time. Doing the same thing over and over and expecting different results each time is a form of insanity. When LFS users keep stumbling at the same place, re-phrase that spot and guide them around the problem. Don't just keep chanting, Stupid users! RTFB! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: quot;autoquot; in /etc/fstab
On Monday 11 October 2010 07:56:17 rhubarb...@poetworld.net wrote: --- Original Message --- From: rhubarbpie...@gmail.com[mailto:rhubarbpie...@gmail.com] Sent: 10/10/2010 11:12:48 AM To : rhubarb...@poetworld.net Cc : Subject : FW: Re: FW: Re: auto in /etc/fstab On 10/10/2010 01:05 PM, rhubarb...@poetworld.net wrote: --- Original Message --- From: Bruce Dubbs[ mailto:bruce.du...@gmail.com ] Sent: 10/9/2010 7:36:52 PM To : lfs-support@linuxfromscratch.org Cc : Subject : FW: Re: auto in /etc/fstab If you know what the filesystem is, there is no reason not to specify it. -- Bruce I recently restored an imaged partition to a different file system. Had I listed its file type as auto in /etc/fstab ... Even if I know what the file system is, I see no reason to specify it. Binutils are getting better at recognizing a filesystem and loading its module(s) as needed before mounting it; it wasn't always thus. Regardless of that, there are two consumers of /etc/fstab: the computer, and the admin; it needs to be computer parsable and human grokable. I'll side more with Bruce on this one. (1) Fstab is where I usually 'document' which partitions have which filesystems. (2) I sometimes need to specify mount options; NTFS options don't work with reiserFS and reiserFS options don't work with vfat, etc. (3) Even if I know what the FS is, there's no guarantee I'll remember it in 6 months. Something like the following works well enough for me. Depending on the FS, a partition will be mounted on different dirs and/or have different mount options: /dev/sdh1 /mntntfs-3g rw,user,noauto,allow_other,default_permissions,\ umask=000,dmask=000,fmask=111 0 0 /dev/sdh1 /media/usb1 autorw,user,noauto -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SVN 20100923 - gcc-4.5.1, pass 1, won't compile
On Saturday 09 October 2010 13:54:28 Andrew Benton wrote: On Sat, 9 Oct 2010 13:58:07 +0200 Felice Murolo linux...@fel.hopto.org wrote: /bin/sh - /bin/dash dash causes a variety of problems, there's a script in glibc that uses bashisms, libtool uses bashisms. Avoid the problem: ln -sf bash /bin/sh For this very reason (the visual similarity between 'b' and 'd' which is easily missed), I still think the verify script should do more than print out a jumble of data. See the attached script; it can give folks a clean, tidy start to their project while helping to keep fenceposts out of their eyes. N host_check.sh Description: application/shellscript -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS Init scripts?
On Thursday 30 September 2010 16:32:09 Mark Knecht wrote: Am I fooling myself in thinking that for a very simple hardware system, maybe just an EXT2 boot, EXT3 / and a swap partition, that for this specific machine the init scripts might be reduced to something like 10-20 bash commands which get me to the bash command line where as root I could use the system? I's'll have to review the links posted earlier. When I was upgrading Smoothwall to use udev and initramfs, I didn't find much of anything of any use to guide me, so I puzzled my way through it, brute force. The simplest method of getting a root shell is to: -- cat END /init #! /bin/sh bash /dev/tty1 /dev/tty1 2/dev/tty1 END chmod +x /init --- But this might not give you job control (it definitely won't in early userspace), and you won't have any daemons started (udev, etc.) This is how I started on my trek to set up initramfs (the official Smoothwall still uses initrd). It was a journey of 3-4 months slogging through the bog of early userspace, getting mired in how to properly create an initramfs to begin with (that bit could be documented better; there's one and only one way to do it outside of having the kernel build do it for you). The next hard part was doing the pivot_root to switch from rootfs to the mounted hard drive. klibc wasn't too hard for the first iteration using kernel 2.6.26. But when I switched to 2.6.32, klibc simply would not build. Ever. And I could never find any reason for it. In sheer desparation, I tried 2.6.33; it finally built. And that klibc works fine with 2.6.32. The next bother was figuring out how to make udev work. Its parser is absolutely unforgiving; worse, its error messages aren't really that helpful. But I got it to work. The last thing that I haven't yet gotten to work smoothly are shells in early userspace. The aforementioned job control doesn't work and other things don't quite work as expected. I may yet try a sysvinit in the initramfs, if I can figure out how to roll it over to the proper sysvinit on the hard drive. Basically, what this all says is, There be dragons here. You may be on your own; as trepid as Search Rescue are, even they are reticent to fly into the dragon's lair. But do post when 10 lb. bricks fall on your toes. I'll chime in with what I've learned in the last 16 months. Smoothwall was based on a very early version of LFS (I believe), and I used LFS as a guide to update many of the core packages. My tidbits won't be a one-to-one match with LFS, but I think the different perspective will be useful. N -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: wget list
On Monday 20 September 2010 19:35:29 Jonathan Arnold wrote: And darn it all, I think just like last time, I missed the link to the wget-list at then of section 3.1 :( Don't feel too badly: consistency earns extra credit. :) :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: gcc compile error part 1
On Saturday 18 September 2010 12:53:42 Pablo Ontivero wrote: I resolve the problem, the situations is, because i don't read good, the problem is i don't put the mfpr and pmg folder into the gcc source code, i compile both separathly, so that's the problem. 40 lashes with a wet noodle. :) And welcome to the club! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-svn chap 6.7 (gcc: No such file or directory)
On Wednesday 08 September 2010 05:56:23 Martin Zajíc wrote:
I have another question about testing error.
I try to make LOG with '{} 21 | tee $BUILD_DIR/LOG_$PROGRAM.log'
but when I did it how can I test it for errors, becouse '$?' not
working even if the script inside ending with 'exit 1'.
echo Building section fubar
(
echo command /dev/tty
command || (echo command failed! exit 1)
echo command /dev/tty
command || (echo command failed! exit 1)
echo command /dev/tty
command || (echo command failed! exit 1)
echo command /dev/tty
command || (echo command failed! exit 1)
) $BUILD_DIR/LOG_$PROGRAM.log 21
Run it. You'll see 'tidy' progress. If you want to see the gory details,
run 'tail -f -s .1 $BUILD_DIR/LOG_$PROGRAM.log' in another window.
Oh, wait. I think I know the problem. You are using {} (curly braces) around
the code block instead of () (parens). They behave differently. Your script
is properly exitting from the {} environment, which is different from your
script's environment. Use parens; I think they'll do what you want.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Udev can't find my usb flash from initramfs
On Friday 03 September 2010 13:44:47 Thiago Padilha wrote: Hi, I have the entire LFS 6.6 inside a squashfs file. In grub I specify a small initramfs file that contains a minimal system with busybox, this small system only purpose is to mount the squashed file, and switch root to it. If the squashfs file is in my hd, the system boots fine, and all my hardware is detected properly. The problem is that I wanna put that squash file in my usb stick and since the busybox system isnt detecting it(the only persistent block device in /sys/block is sda which is my hd). ... Does anybody have a clue of what might be happening? You may need to mount /proc/bus/usb after the USB modules have been loaded. You may need to wait up to 20 seconds for any/all USB devices to become ready. Is udev doing its thing? If you don't have udev running in your initramfs, try manually creating the /dev/sdb node(s). -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: jhalfs 2.3.2
On Monday 30 August 2010 09:43:01 Andreas Kasenides wrote: I have been trying to build LFS 6.5 with jhalfs 2.3.2 but have found out that it fails with script 131-network. As far as I can tell this script tries to configure the network devices eth0,1... and lo (by doing a udev --test on devices in the /sys/classes/net/*)!! Isn't this the wrong thing to do at that point in the build? Since at that point we are running in a chroot environment it is not possible to discover any ethernet devices (or any devices for that matter) that udev is supposed to discover at boot time and appropriately mount the /sys filesystem. Am I missing something? This is based on what I learned integrating udev into a system that didn't have it. I've never looked to see if udev effects changes in /sys. You might just be missing something. /Sys needs to be mounted before udev can do its thing. With /proc and /sys mounted, udev should be able to at least find devices for testing purposes. I don't think the kernel cares how many 'coldplug/hotplug listeners' there are. Having more than one daemon on the host and one in chroot actually changing device names could cause problems, though I've never investigated it. But having more than one daemon monitoring device changes shouldn't hurt a'tall. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 70-persistent-net.rules
On Sunday 22 August 2010 09:20:29 Mike Johnston wrote: Thank you. That would work however, I want to make 30 instances for 30 machines. I need to generate the 70-persistent-net.rules file so each machine has fixed interface names. What I don't understand is that if its a symlink on read/write partition it consistently keeps adding to the file. If it's not a symlink but a real file, it doesn't regenerate and stays a fixed size. How does it know this? Are you saying that the *only* difference in your two scenarios is that 70-persistent-net.rules is a symlink in one and a real file in the other? That there is absolutely no other difference in the content of the two files? You may have to delve into the udevd source code to find the answer. You might try to configure udevd to use your RW partition directly and make /etc/udev a convenience symlink to the (now-correct) location. FWIW, it took me 2-3 months last year to integrate udev into Smoothwall. And only a couple weeks ago I found that my 70.persistent-net.rules wasn't right. It was days more before my install script *finally* generated the correct syntax. Udev now correctly renames my NICs as specified, keeps them that way, and does not add extraneous entries to the net rules file. I chalk this up to udev having less-than-crystal-clear documentation. Be certain your generated rules are absolutely identical in syntax to the rules that udevd generates. Any deviation, and udevd will silently puke out its own rules. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: project on distro
On Saturday 07 August 2010 06:43:22 Bavithra R wrote: hi friends I have an idea of doing Linux distro as my final year project. Will it be better if i start with any already installed linux OS or by using the LFS(Linux From Scratch) live cd directly? If i use any linux OS which would do better for creating distro? Bavithra, Technically, all existing GNU/Linux systems (Debian, RedHat, Fedora, et alia) are already distros; even LFS is one in a manner of speaking. If your project is to create a GNU/Linux distribution, it would be more instructional and educational to start with LFS and go from there. Glossing over many details, the many tasks involved in 'rolling yor own' include: - Deciding which functionality you want your distro to provide (such as print media publishing, A/V media preparation and presentation, Web/Email/IM distro for 'computer illiterates'). - Choosing the default locale (language, timezone) for your distro. - Choosing a suitable name for your distro. - Creating some artwork that uniquely identifies your distro. - Choosing a means of managing add-on software packages (automatic or manual) if you want one. Making users download and build any add-ons they want is valid, too. - Building LFS, boot LFS, then build it on itself. - Including additional software packages to achieve your chosen functionality. - Packaging it onto an installable CD/DVD. - Applying your graphics to the CD/DVD label and jevel box or envelope. - Writing clear, simple, lucid prose (up to three paragraphs) that states why your distro is the best. - Writing a press release and emailing it to news media outlets of your choosing. - Selling copies of the CD/DVD on ebay. Congratulations! You will have now built, packaged and marketed your own, custom GNU/Linux distribution. Your project won't be easy. It could take more than a year. There's a LOT to learn. (Here's a shameless plug for LFS.) I've been in the software business for 30 years, and it still took me a year to update the open source Smoothwall firewall. The major changes included upgrading: Linux: 2.6.16 - 2.6.26 - 2.6.32 IPTables: 1.3.7 - 1.4.2 - 1.4.8 GCC 3.3.5 - 4.3.2 - 4.4.3 integrating udev and initramfs, greatly enhancing the build system, and updating the 100 or so packages so that they would compile and work. I did it in two stages; the first stage took nine months and the second 2-3 months. Half of the time was spent figuring out why the existing bits wouldn't build with or work with the upgraded bits. I would not have been successful without LFS as a solid reference and certainly would have failed with the WWW to learn about arcane C/C++ syntax changes and other bugs resulting from 'long step' upgrades. So if you choose to build a custom distro as your final student project, start with LFS. You'll learn what's needed to build a GNU/Linux system starting from source code,and you'll find friendly, useful assistance here in the LFS supprt list. That'll be half of the battle won. Finishing the distro will be the other half of the battle. And the third half will entail everything else you didn't know and weren't warned about in advance. Plan wisely. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Networking Is My Weakest Area--A Really Basic Question
On Wednesday 21 July 2010 11:46:07 Dan McGhee wrote: On 07/21/2010 09:49 AM, Bruce Dubbs wrote: Dan McGhee wrote: On 07/19/2010 03:44 PM, Bruce Dubbs wrote: This is all discussed at 7.13. Configuring the network Script. A dhcp server does not interfere with a static ip address unless you assign a static ip address *and* the dhcp server assigns the same address. Usually the dhcp server will have a range of addresses it manages, say 192.168.1.10 - say 192.168.1.200. If the netmask os 255.255.255.0 (the default for 192.168.x.x), just make sure you *do* use an address in the block (192.168.1.x in this case) and *do not* use for x the network address 0, broadcast address 255, router address 1, or other statically assigned addresses. The numbers you use are critical. The form will get you up, but you have to use addresses that are right for your ISP or home network. I dug out my router book and learned that without changing anything the first address it assigns to computers on my network is 192.168.1.100 in the range 100-253. I can get the other 98, it reserves 1, by using the on-line utility. So here is what is in my ifconfig-wlan0/ipv4 file: ONBOOT=yes SERVICE=ipv4-static IP=192.168.1.100 GATEWAY=192.168.1.1 PREFIX=28 BROADCAST=192.168.1.255 I added 192.168.1.1 to /etc/resolv.conf I've been reading and just made these changes. Haven't tested them yet. My biggest conceptual error was that I thought all the static stuff got used only with an ISP and their stuff is all on the router. I've only a fuzzy understanding of terms like GATEWAY, NETMASK, BROADCAST. These are the things, and the ranges of numbers they use, I need to read up on. For example, I think my setup will work now, but if anything stops me it will be BROADCAST. At least that's what my guts are telling me. If PREFIX is the number of bits in the 'network' part of the address, then it probably should be '24', which is how most routers are conig'ed by default. Also, if your router starts addressing at .100, you don't want to use that address statically; try '.99'. In a nutshell: BROADCAST: the highest possible address on the LAN. NETMASK: the contiguous set of bits, left-to-right, that determine the network address of a LAN. The remaining bits, when combined with the network address, comprise the host address. Modern CIDR addresses make this a little easier to grok. GATEWAY: a 'door' to a network of unknown topology. You have your LAN and you know how to reach everything on it. You have access to the internet, yet you don't know how reach any particular node on it. But you don't *need* to know; you simply send your packets to the gateway, because it knows how to reach the rest of the internet. It would be the same if you had a second router on your LAN separating your LAN from three other LANs in your house. That second router would be the gateway to those other LANs; it would receive packets destined for those other LANs. Your internet router is still the *default* gateway: the router that gets all packets your computer doesn't know where to send (has no route to the destination). Say you want to use 192.168.10.0-192.168.10.255 on your LAN. That gives 3 octets of network address and one octet of node address. - You can have up to 254 nodes on the LAN - The CIDR address of the LAN is 192.168.10.0/24 - The netmask is 255.255.255.0 - The broadcast address is 192.168.10.255 (host part is all ones) - Nodes on the LAN can use addresses .1-.254 Now tweak it a bit (literally). Say you want to use 192.168.10.0-192.168.11.255 on your LAN. - You can have up to 510 nodes on the LAN - The CIDR address of the LAN is 192.168.10.0/23 - The netmask is 255.255.254.0 - The broadcast address is 192.168.11.255 (host part is all ones) - Nodes on the LAN can use addresses .10.1-.11.254 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Networking Is My Weakest Area--A Really Basic Question
On Wednesday 21 July 2010 18:30:06 Timothy Rice wrote: From someone for whom the description Networking is My Weakest Area is also apt, I'd just like to say thanks to Neal and Bruce for explaining all that stuff about GATEWAY, BROADCAST and NETMASK. Very lucid and helpful. Although the information is presented briefly in section 7.13: Configuring the Network, the discussion there is rather terse. Would it be a bad idea to copy and paste content from Bruce Neal's recent posts - either into the LFS book, or else into a Hint that the book then references? Here's a very good book by Lucian Gheorghe. Pretty much everything you'd want to know about networking is covered. Lucidly. Anyone who wants to learn about networking, firewalls and traffic control (QoS) or wants a convenient reference should buy it. http://download400.mediafire.com/7m754w6jc7sg/k0nkn10tnzz/Linux%2BFirewalls%2Band%2BQOS.pdf It is copyrighted material; Mr. Gheoghe deserves royalties for his work. If you find the book to be as good as I say it is, you should buy it; I did right after perusing the PDF, and I am very selective about the technical books I buy. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SOLVED with Catch 22 [Was: Networking Is My Weakest Area--A Really Basic Question]
On Wednesday 21 July 2010 19:06:54 Dan McGhee wrote: Name my localhost name Destination LAN IP 192.168.1.2 (that's the address I assigned in ifconfigwlan0/ipv4) Subnet mask 255.255.255.0 (if I understood what Bruce and Neal wrote) Default Gateway 192.168.1.2 (that's me again) Interface LAN Wireless (this was from a drop down box) Stinksys usually use 192.168.1.1 for the router's IP addr, by default. The destination LAN IP should be 192.168.1.0, if I understand the term correctly. The subnet mask is correct. Stinksys uses 255.255.255.0 masks, by default. For a home LAN, the default gateway is the IP address of your router; the router is the node that knows how to reach hosts off your local LAN (technically, all hosts--most of the internet--for which your computer does not have a route to). In your case, your router is (most likely) 192.168.1.1. Your computer can be 192.168.1.2. The subnet mask is 255.255.255.0. The DNS servers will be those listed on the Stinksys' WAN page. The broadcast address is 192.168.1.255. Anything else is more 'advanced'. When you get the right pegs in the right holes, it'll work. Don't give up. If it doesn't work the next time, post all of your relevant network info (nodes, addresses, masks, et al); one of us will straighten it out for you. Once you understand the logic of it all, you'll wonder why you didn't pick up on it sooner. The most basic thing to remember is that every node on the internet must have a unique IP address, including your nodes. Even though you are using private, non-routed addresses on your LAN, they must still have unique addresses. Think if you were attending a convention of women named 'Sue'. If you said, Hey, Sue! they'd all respond, because they don't know to whom you are speaking. Same with IP addresses. Also, every LAN must have a unique address. If you were attending a convention of families named Smith, you wouldn't know how to uniquely address *this* John Smith of all the John Smiths in attendance. Or, if you're a Star Trek fan, Seven of Nine (what a dish!) takes on a whole new meaning: unique addresses. Unrelated, I'm still doing battle with my updated Smoothwall system (upgrading v3.0 to very new kernel, glibc, gcc, iptables, binutils, et al). Now that it's mostly working, I'm trying to get it to build itsef. The whole thing builds from scratch (build system originally based on LFS), but only on my host Lenny system. It installs and runs, except the 6 LAN ports suddenly NOW have a tendency to be assigned ethX names in indeterminate order; I may have to reinstitute some install code that lets the user explicitly associate ethX names with MAC addresses; maybe I'll rogram it to assign ethX names in MAC-address order. And then change the ancient setup program to stop dealing with drivers because udev now does that, and just assign ethX names to interface colors (functions). I'm really on my own here; it's a matter of slogging through the swamp. (Why do I keep hearing 'Dueling Banjos' in the distance?) But the installed system right now can't find ld or as; clearly I missed a package (like binutils). It's been a year and a half or effort; what's another month? LFS got me through upgrading most of the packages in SWE3; 'tis my pleasure to give back one way or t'other. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hit a Speed Bumps with Grub 2
On Tuesday 20 July 2010 17:21:32 Dan McGhee wrote: Since my post of just an hour ago, my options have been reduced to one--write to the MBR. One of the files needed to make a completely independent bootable grub disk is stage2_eltorito, which is not present in /usr/lib/grub/i386-pc/, or anywhere else on / for that matter. The 'stage2_eltorito' sounds like one of the new Grub2-specific thingies. You might want to look for iso9660_stage1_5 (if you're working with LegGrub). It's not easy finding documentation that describes the differences between LegGrub and GrubNoLongerKnownAsTwo. But I did stumble across such a doc a few days ago. Of course, after perusing it, I forgot it since I didn't need it at the time. :( -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hit a Speed Bumps with Grub 2
On Tuesday 20 July 2010 18:00:12 Dan McGhee wrote: If you'd allow me to rant just for a second--or longer--the documentation for grub over the years has left a little to be desired You are much too kind, sir, exhibiting a forebearance that continues to escape me. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Networking Is My Weakest Area--A Really Basic Question
On Monday 19 July 2010 12:01:55 Dan McGhee wrote: I've never really taken the time to sit down and learn the nits and grits' of networking. I don't have enough knowledge to even make me dangerous. Over the years I've not ever really had anything to worry about because I had a hard-wired internet connection at home and whenever I went to hotspots, things just seemed to work. Because of this laptop, I now have a router, which, so far, I've used only to connect to the internet. It's possible that in the future, I may want to establish a network here in the house to access at least the printer on my PC. It's now time for me to customize the /etc/hosts file, and, obviously, I have a NIC. This is the file from my other laptop which runs LFS-6.3, uses a PCMCIA card and can connect to my router: 1. Your router's WAN port has the address assigned by ISP. This address is your public address. 2. Your router's LAN port has an address from one of the private ranges, typically 192.168.0.0/16 (google 'CIDR'). This address is the default gateway for your LAN. If its firmware is decent, the router will also have a built-in DNS server or proxy; if so, this address will also be the DNS server for your LAN. 3. Your router has a DHCP server that assigns addresses to hosts on your LAN that ask for one. By default, it randomly assigns an address in its configured range. 4. Your router's DHCP server also allows you to specify which hosts get which IP addresses, based on the host's NIC MAC address. These are known as static addresses. 5. If you want to manage your LAN's IP address usage in one place, do it with DHCP on your router. Assign static addresses to all hosts, including printers. The result will be that all hosts will be able to reach all others by name (they will all query the router to translate the name to an IP address). Your printers and file sharing will just work (unless you have Winders mixed in; its firewall usually prevents file sharing from working. 6. A good book for learning about networking, network security and traffic control, from the basics to inter-metropolitan WANs, is Designing and Implementing Linux Firewalls and QoS using netfilter, iproute2, and L7-filter (2006, Lucian Gheorghe, Packt Publishing, ISBN 1-904811-65-5). If you are persistent in googling, you can find a PDF online to review. After perusing the PDF, I ordered the book; and I've been configuring networks for 20 years. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Networking Is My Weakest Area--A Really Basic Question
On Monday 19 July 2010 13:33:43 Dan McGhee wrote: But, if I'm reading all this correctly, I'm not going to be able to connect to the interned until I install dhcp on my new system. Is that correct? Not exactly. You can work on a static IP address. Look on the router and determine the range from which it assigns addresses. Then choose something outside that range for your linux box (that also doesn't conflict with the box itself). You can't just use /etc/hosts. There will be a file in /etc that defines the interfaces and how they are configured. (On Debian, it's /etc/network/interfaces; dunno about other systems, or even LFS.) In that config file, you'd say the NIC is static, and specify the address, the LAN address, the netmask, the broadcast address, the default gateway, and maybe one or two other things. Of course, I may still be in the dark ages and there might have been some advances in recent years in this regard. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: /etc/limits
On Thursday 15 July 2010 07:38:08 Andrew Benton wrote:
Hello world.
I was reading today about a fork bomb
http://en.wikipedia.org/wiki/Fork_bomb
and running the example code :(){ :|: };: locked my system up hard. A
bit more reading lead me to conclude that the simplest way to restrict
the number of processes a user can spawn is by editing /etc/limits. echo
\* U128 /etc/limits
Is that a sensible limit? Will it cause any problems compiling or
running applications? Are there any other resources that should be
limited as a precaution? What do the rest of you put in /etc/limits?
/etc/limits is installed as part of shadow but the book doesn't give any
guidance as to what it should contain. Shouldn't the book at least set
some sane defaults?
Andy
Welcome to the Self-Inflicted Foot Perforation Club. :)
Every system is different. For example, I have a script that runs as many nc()
processes as it can in the background for a 1/2 second then quit; I was
testing a firewall, creating a DoS situation and then preventing it from
affecting the firewall during startup. I let it run free, and could not
generate more than 15-20 thousand processes, and usually not more than 5,000.
That was on a quad PhII with 8GB RAM.
On slower, older systems, I often locked up the system with errant scripts.
This went back to SysV68 in the early '90s, and even back to my first
computer: the ATT UNIXPC. Back then, /etc/limits wasn't well known or didn't
exist. The solution I created was to always 'nice --20 sh' before testing;
that way I'd always have a shell to kill errant scripts (though it was
sometimes a race).
Instead of changing /etc/limits, you can use the ulimit command in your
script. Try the command 'ulimit -a' in bash. If you think something might go
awry, set some limits. Suspect a program of a memory leak? Cap its RAM and VM
usage. Think it suffers excessive recursion? Limit its stack.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
On Wednesday 14 July 2010 18:07:13 Dan McGhee wrote: I hope everyone who reads this is getting a good laugh. No, just chuckling and nodding knowingly. As I hobble around on my bullet-riddled feet. Need the t-shirt? As long as *you* are laughing, all is well. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Syntax and Logic on a Build Script
On Tuesday 13 July 2010 20:20:56 Dan McGhee wrote: BUILD=$HOME/$package-build cd $BUILD #Double sanity check--visual and logical pwd if [ $(pwd) -ne $BUILD ] echo Check the build directory creation exit Status 1 You seem to have left out the 'then' and the 'fi': # Where are we going? BUILD=$HOME/$package-build # If the cd fails, whine and give up cd $BUILD || (echo Couldn't cd to '$BUILD'; exit 1) # Double sanity check--visual and logical pwd # If we aren't where we expect to be, we didn't listen to Mother if [ $(pwd) -ne $BUILD ]; then echo Check the build directory creation exit 1 fi -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Issues with second build of GCC
On Sunday 11 July 2010 10:21:53 littlebat wrote: On Sun, 11 Jul 2010 08:48:28 -0400 Robert Whitcomb rwhitc...@acm.org wrote: checking for i686-pc-linux-gnu-gcc... /mnt/lfs/sources/gcc-build/./gcc/xgcc in Section 5.10. GCC-4.4.3 - Pass 2 of LFS BOOK 6.6, it says: CC=$LFS_TGT-gcc -B/tools/lib/ So I remember the configure output should be something like below: checking for i686-lfs-linux-gnu-gcc... Maybe, check your environment value: $LFS_TGT A reading from the book of LFS, chapter 4.4, verses 18-19. The LFS_TGT variable sets a non-default, but compatible machine description for use when building our cross compiler and linker and when cross compiling our temporary toolchain. More information is contained in Section 5.2, “Toolchain Technical Notes”. Yessiree. i686-pc-linux-gnu is the default, so something has gone awry with your environment. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Issues with second build of GCC
On Sunday 11 July 2010 21:33:23 Robert Whitcomb wrote: Thanks very much for your help, the CC value was set wrong. But now I am running into another issue: /tools/i686-pc-linux-gnu/bin/ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/i686-pc-linux-gnu/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build' The crti.o file is is my /tools/lib folder, and I made sure the CC value was set correctly. What am I doing wrong? Thanks! What did you set LFS_TGT to? If you exactly followed the book, the above value (i686-pc-linux-gnu) is incorrect. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Issues with second build of GCC
On Sunday 11 July 2010 22:05:41 littlebat wrote: On Sun, 11 Jul 2010 21:33:23 -0400 Robert Whitcomb rwhitc...@acm.org wrote: Thanks very much for your help, the CC value was set wrong. But now I am running into another issue: /tools/i686-pc-linux-gnu/bin/ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/i686-pc-linux-gnu/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build' The crti.o file is is my /tools/lib folder, and I made sure the CC value was set correctly. What am I doing wrong? Thanks! CC=$LFS_TGT-gcc -B/tools/lib/ Have you missed -B/tools/lib/ in CC value? If still many errors appear, suggest delete the entire tools directory and restart from Chapter 4 again. Good idea. Since LFS_TGT appears to be 'i686-pc-linux-gnu', methinks the toolchain is building incorrectly. And the only way to fix that is to start anew. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: need an accurate answer: can we build LFS with parallel compiling?
On Wednesday 07 July 2010 10:53:43 littlebat wrote: On Wed, 07 Jul 2010 13:31:32 +0100 Andrew Benton b3n...@gmail.com wrote: On 07/07/10 12:10, littlebat wrote: So, I need some accurate answers: 1, Can we build LFS with parallel compiling through the book? Yes. A few packages won't build in parallel (openssl) and some packages sometimes fail to compile with a parallel build (xmlto) but pretty much everything else is fine with make -j$NUMBER 2, Can we build Chapter 5 with parallel compiling but do not use parallel compiling in the rest Chapters (includes Chapter 6 and Chapter 8)? I use make -j4 all the time. Doesn't give me any problems. I've had some problems in the past with make -j4 install not installing all of glibc's files so I now avoid installing in parallel. make install is mostly limited by disc input/output so I see no benefit in make -j4 install. Consequently I don't set MAKEFLAGS as it risks breaking make install for little benefit. Maybe I am lucky:-), I set MAKEFLAGS='-j 2' on my E7400 double cores CPU, no any exception appeared until I finished all the packages in Chapter 5. But, I think this should depends on the quality of the package itself. Maybe, after the next release of a package, it will refuse to do a parallel make or parallel make install just like you have experienced. Many packages must be configured and installed in uni-processor mode. I've found a *few* packages that must be built in uni-processor mode, such as groff, net-tools and snort. On a quad-core system, '-j 4' really only shines when building glibc, gcc and the kernel. There aren't many other packages that are truly large enough to benefit. The great limiter today is './configure'; it is slow. Some packages take 3 minutes to configure, and 5 seconds to compile. Aside, I think the ./configure mechanism needs to be reimplemented with significant paralelism. The admonition against building multiple packages in parallel exists because dependencies *among* packages are not identified; LFS is a 'follow these steps EXACTLY and you'll have no trouble' program :). If you go to the trouble to identify the interpackage dependecies and ensure that you build packages in the correct dependent order, there's no reason you couldn't build 5-10 packages simultaneously. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS (Version SVN-20100529) - booting in the new system - Problem
On Tuesday 06 July 2010 05:32:56 Face wrote: hello all, after solving my last problem i went Through the rest of the book without any problems. However, when i try to boot to the new system nothing happen i only get this Booting from Hard Disk ... and it freeze Your main problem is these two lines in menu.lst: set root='(hd0,1)' set root='(hd0,1)' This aspect of partition addressing is zero-based in grub. Change them to: set root='(hd0,0)' And don't forget to change references to '/dev/hd*' to '/dev/sd*', since the old IDE driver is on its way to meet the dodo and the neanderthal. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS (Version SVN-20100529) - booting in the new system - Problem
On Tuesday 06 July 2010 11:49:27 Andrew Benton wrote:
On 06/07/10 16:41, Neal Murphy wrote:
Your main problem is these two lines in menu.lst:
set root='(hd0,1)'
set root='(hd0,1)'
This aspect of partition addressing is zero-based in grub. Change them
to: set root='(hd0,0)'
That was true for grub legacy but the grub we use counts partitions from
1 so (hd0,1) is the correct way of saying /dev/hda1 to grub
Oh. :{ I stand corrected. Sometimes you *can* teach an old dog new tricks. :)
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Boot kernal Panic :(
On Sunday 04 July 2010 22:58:42 Dan McGhee wrote: On 07/04/2010 09:00 PM, Neal Murphy wrote: I still have occasion to point the shotgun in pseudo-random directions and pull the trigger; eventually I hit the broad side of the barn. I have found very few people who still use this tried and true, highly technical and engineering correct method of troubleshooting and problem solving. My problem is that my 2x4 is technologically challenged. Ah, I see yor problem. Mr. Stick only works on people, doncha know. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Boot kernal Panic :(
On Monday 05 July 2010 21:43:48 Saxon Landers wrote: Ok, fixed it. Setting the rootdelay to 10 gave me enough time to notice the USB was being mounted as sdb1, not sda1. a quick vim edit of the grub.cfg file ^^^ Checking file systems...[ OK] v fsck.ext3: Bad magic number in super-block while trying to open /dev/sda /dev/sda: Methinks you need to change /etc/fstab. (ergh, it's endless with me :/) That's what I thought while I was updating Smoothwall to Linux 2.6.26 and to use udev and initramfs, and updating most packages 2-3 years' worth. At times, I thought it would *never* work. But I kept plugging away at it. Nine months later, I had an ISO that would install, configure and run, but otherwise is almost the same as Smoothwall v3. Most of that time was spent getting initramfs to work. Linux isn't very clear about using these, and ONLY these, cpio options to build the initramfs. It isn't very clear that pivot_root MUST be built with klibc. And don't get me started on trying to build klibc for Linux 2.6.32. I completely gave up on that; no version of klibc will build on/for 2.6.32, and there's no apparent reason why, nor is there a set of identifiable patches that can be applied to any specific version of klibc that will allow it to be built for 2.6.32. Why 2.6.32? Because it's slated to receive long-term support. Give it time. You'll learn to recognize errors and where the solution should be applied. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Boot kernal Panic :(
On Sunday 04 July 2010 03:38:39 Saxon Landers wrote: ... i am compiling onto a USB flashdrive, 4gb in size. it is mounted on the ubuntu as /dev/sdb on /mnt/lfs. ... Booting the USB works no problem, the GRUB menu comes up with the two options (LFS and LFS recovery), and when one is run, it boots into what i assume is LFS (it has two tux pictures top-left), however after a short abount of time, it declares a kernal panic. The panic outlines that it cannot mount the root partition, and to set the root= in GRUB correctly (it is currently root=/dev/sdb) You have configured grub incorrectly, albeit inadvertently. When you boot from your hard drive, that drive will be /dev/sda, forcing the USB drive to be /dev/sdb. However, when you boot from the USB stick, *it* is /dev/sda and the hard drive will be /dev/sdb. So change your LFS to point to /dev/sda and it should work. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS (Version SVN-20100529) - 5.9. Binutils-2.20.1 - Pass 2
On Friday 02 July 2010 07:53:19 Ken Moffat wrote: ... but people can make the same error each time. And that's really OK: it's a mere reflection of their computer skills and we can help them with that. But expecting different results every time is a sure sign of insanity, or so I'm told. :) :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
On Friday 02 July 2010 12:14:51 Mike McCarty wrote: Simon Geard wrote: On Thu, 2010-07-01 at 17:59 -0500, Mike McCarty wrote: Apparently, it's the stated non-goal to support switching back by the authors (or at least owners) of the driver. So, unless he's willing to get the source for the driver, and rewrite portions of it himself, there's not going to be a way to go back. I don't think it's a matter of Nouveau specifically, as the kernel graphics infrastructure in general. Having any such driver loaded means using the graphics-mode console. That's the impression I got from Stephane's comments to Alex, and it makes sense to me that things work that way. If the driver supports changing modes, and there is an app which can make an ioctl() call, then the change can be made. The kernel probably won't notice the change, and it may get confused if, while the mode is selected, some other app (like the window manager) tries to make a call to display something. OTOH, my version (with X and GNOME) seems to switch to 80x25 very easily when I press CTRL-ALT-F1 through CTRL-ALT-F6, so the kernel must support _something_ along those lines. Hmmm. OP's problem is that his consoles are *not* 80x25; rather, they are closer to 64x250 (on his wide aspect ratio monitor). I believe he wants to change the resolution of the consoles, not X, to restore 'normal' 80x25 text mode. I have my 1280x1024 monitor 'set' to 64x160 (using an 8x16 or 9x16 font) because I want more information on the consoles. That's the mode of the console, which is independent of X. IIUC, the mode of the consoles cannot be changed after boot, though I could be wrong on this point. There *is* a parameter (vga=) that can be specified at boot or in LILO/grub that sets the console video mode during startup. But I can't recall how I did it. If he can find this parameter and set it, he may be able to set his console to display larger text. He might also be able to use 'vidmode' to set the default video mode in his linux image. There's a small chance he set the default mode when he configured his kernel. If he cannot find and set this parameter, he will be stuck with finding a larger font (perhaps 18x32) and using consolechars to set it on each of his consoles. References: http://www.pendrivelinux.com/vga-boot-modes-to-set-screen-resolution/ http://en.wikipedia.org/wiki/VESA_BIOS_Extensions http://www.linuxquestions.org/questions/debian-26/lilo-vga-modes-152575/ /usr/src/linux/Documentation/svga.txt -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS (Version SVN-20100529) - 5.9. Binutils-2.20.1 - Pass 2
On Friday 02 July 2010 15:11:31 Face wrote: well, thank you all, i will start over and see what will happen. I am using a shell script to do the book if someone could take a look at it, that would be nice . Sincerely Ah, you don't seem to have error detection in your script. After many of your actions, you could put || (echo 'action' failed.; exit 1) For example: tar -jxf ../mpfr-2.4.2.tar.bz2 $Logs || \ (echo Extracting mpfr failed.; exit 1) mv -v mpfr-2.4.2 mpfr | source $Msg || \ (echo Renaming mpfr failed.; exit 1) Also 'man bash' and read up on the 'trap' built-in. You can do something like: trap echo \'action' failed!\; exit 1 ERR; action-to-take; trap ERR For example: trap echo \Extracting mpfr failed.\; exit 1 ERR tar -jxf ../mpfr-2.4.2.tar.bz2 $Logs trap echo \Renaming mpfr failed.\; exit 1 ERR mv -v mpfr-2.4.2 mpfr | source $Msg trap ERR You might have to change the script to use bash instead of sh. Cleverly crafted, you should be able to catch most of the errors when they happen while maintaining a readable script. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Help with Glib-c 2.11.1 Pass 1 (ch 5.7) in LFS 6.6
On Tuesday 29 June 2010 12:57:21 Mike McCarty wrote: Andrew Benton wrote: On 29/06/10 11:50, Saxon Landers wrote: Hi there, im new to the mailing list, so please correct me if i make any mistakes. I have used linux for some time, and wanted to make my own, so ive gone for LFS. I am compiling onto a SanDisk Cruzer 4gb portable USB flash drive, so i am using /dev/sdb (without a specific partition) to save space. Is that even possible? How are you going to mount it if it doesn't have a partition? The mount command should be able to mount anything with a file system in it. CD-ROMS don't have partitions, nor do native USB sticks, nor floppies, nor ISO images, nor other files with file systems in them. AFAIK, there's no file system type defined for tapes, but with the proper definitions and driver, one would be able to mount a tape. I've done so with other operating systems which have that capability. An explicit example: 'mount -t ext3 /dev/sdb /mnt'. Oh, some USB sticks have partitions, but perhaps they aren't 'native'? If one is clever, one can create partition tables within partitions. And mount those subpartition partitions once they contain filesystems. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: bootloaders and USB
On Monday 28 June 2010 10:05:33 Eric Miller wrote: i'm trying to avoid using plop, the interface is very ugly and this is for a professional project. plop functions perfectly thoughit just looks like a video game from 1985. could I do a full boot into a small linux like tinycore and then do some kind of scripted chroot? If booting from CD is acceptable, then yes, you could use a miniscule Linux to create your own boot CD. Make an initramfs (paying *close* attention to the required and allowed cpio options) that contains the needed utilities, including Busybox. With the right bits, you can create a very slick UI. If plop functions perfectly, extract its files, extract its initrd/initramfs and create a better one. At least examine how they made it work. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.6 Chapter 8.1 Can't make new kernel
On Thursday 24 June 2010 16:25:45 Franz L. Kuhlmann wrote: ... ### I think the /bin/sh symlink is ok, (didn't try it in new shell yet - how do I do that BTW???) Both of the following commands display the symlink's target: ln -s /bin/sh readlink /bin/sh -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.6 Chapter 8.1 Can't make new kernel
On Thursday 24 June 2010 17:12:06 Bruce Dubbs wrote: Neal Murphy wrote: On Thursday 24 June 2010 16:25:45 Franz L. Kuhlmann wrote: ... ### I think the /bin/sh symlink is ok, (didn't try it in new shell yet - how do I do that BTW???) Both of the following commands display the symlink's target: ln -s /bin/sh readlink /bin/sh Or more conventionally: $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Aug 16 2009 /bin/sh - bash -- Bruce Ooops. That's what I *meant* to type. Mea maxima culpa! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: A sed syntax
On Wednesday 23 June 2010 02:24:51 littlebat wrote:
Hi,
I am learning LFS BOOK:
http://www.linuxfromscratch.org/lfs/view/6.6/chapter05/adjusting.html
Below is a sed syntax I can't understand and haven't found a place to
learn it.
code
sed -e /^\*cpp:$/{n;s,$, -isystem /tools/include,}
/code
Basically, '/^\*cpp:$/' is the address that matches lines that contain
exactly '*cpp:'. The braces indicate a 'compound command'. 'n;s' means
execute those two commands (n: print the pattern space; s: substitute the EOL
with the 'option'). The effect is, as you know, to append the option to the
end of all lines with just '*cpp:' on them.
The commas are an unusual selection, but perfectly valid, since the s command
allows pretty much any character to delimit the match and replace phrases.
This could be rewritten as
sed -e 's=^\(*cpp:\)=\1 -s system /tools/include/='
which would be a little more grokable.
The only thing you need to find in the manual is the definition and use of the
braces.
Good enough?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: stripping down lfs
On Wednesday 23 June 2010 19:25:52 Eric Miller wrote: hey all...haven't been here since 2002 lolz. I'm hoping to build a stripped down LFS to use on a livecd that will do one thing only: present the user with a simple scripted text menu, and then (based on the menu input) .dd an image to a usb thumb drive. ... My question: chapter six lists upwards to 60 packages...I'm sure I won't need many if not most of them in the final product. What is the smartest way to determine what is needed? Do I need to build complete LFS and then strip, or can I intelligently determine what i need to build, build its stripped down and go? I believe LFS produces a basic, fairly simple system that can build itself. I would suggest building LFS and then including on the live CD only those parts you need. For what you want to do, busybox should serve well. Udev would be good to have to find the thumb drive. Your initramfs can contain the entire live system unless your images are on the CD/DVD as well (no need to leave early boot). Your menu script can serve as init. You might want terminfo and ncurses to make a pretty ANSI 3.64 menu. Include the dependencies of those things and you should be about good to go. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: A Kernel patch overview?
On Sunday 20 June 2010 11:11:01 Paul Rogers wrote: Having just installed LFS-6.6 with kernel-2.6.32.7, I thought I'd look into patching it to the current patch level. OTOH, I'm on a 40Kbps dialup line and a 10MB patch-2.6.33 is big enough to: a) give me pause before attempting a few hours of downloading, b) suggest that there's some significant new features. Patch...34 is about the same size. IIRC the Changelog-2.6.33 is nearly that big, making it perhaps most of the patch file, but it's full of sign-offs and not a particular good place to find out what's new. Is there someplace where someone writes about what's new in kernel patches? New and removed features, considerations about implementation, etc.? Someplace where we can see what's in it, whether it has anything for us or not? http://www.kernel.org/ (look at the changelogs) For more civilized notes, try LWN.net. http://lwn.net/Kernel/ If you subscribe to http://lwn.net/headlines/rss, you'll receive cogent notices of all kernel updates, as well as many other things Linux; I think this feed averages 6-8 notices per day. To go back in time, you can go to http://lwn.net/Archives/ and go back two or three weeks (the most recent week or two being reserved for subscribers), click 'Kernel' for the week, scroll near the bottom to 'kernel tree' and you'll find the cogent summaries. Getting the daily RSS feeds lets you avoid this rigamarole going forward. Not necessarily for the faint of heart, but these notes *will* keep you informed. FWIW, KDE's Akregator works very nicely with LWN's feed and keeps all previous notes until I delete them. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: urgent
On Sunday 20 June 2010 17:42:52 Bruce Dubbs wrote: Andrew Benton wrote: It would take hundreds of gifted people more than a decade to achieve such a thing. Or Linus about a year. I'm not sure the OP could absorb that much info that quickly. The OP needs to select his hardware, learn the peripheral interfaces, design a consistent hardware control interface, then design a consistent user-space interface that presents the necessary APIs to control user access to hardware. Beyond that, the OP needs to select a language and learn to write in that language lucidly and clrealy so that he can return to old work weeks, months and even years later and figure out what he was thinking and doing in the past. Then he needs to select a programming language and learn it inside, outside, upside and downside. Next he needs to choose his 'best' methods, practices and procedures and learn them from every which way. Thus armed, he can design and implement any sort of operating system he chooses, because the way will be fairly clear. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
On Friday 18 June 2010 13:38:39 al...@verizon.net wrote:
Jun 18, 2010 12:41:04 PM, Andrew Benton wrote
me his comments on the subject.
Hi Andy,
Thanks for your message. As I told Neil below,
I'm hard at work at going over some log datails, etc. now.
(I was hoping against hope Neil's interesting workaround
will bring me afloat, but no cigar).
I'll get back with details and comments on your very
interesting words as soon as I have something more substantial,
Thanks again.
Jun 17, 2010 11:13:09 PM, neal.p.mur...@alum.wpi.edu wrote:
(EXCERPTS)
[We tried to] resolve this problem on a 'similar' system
[experiencing] the console screen blanking and not returning.
It wasn't the driver {1}, wasn't parameters, wasn't anything
[we] could figure out.
He was new to the system and Linux, but had probably been around
computers for 40-50 years {2}.
He found the solution himself:
setterm -powersave off -blank 0
Figure out a way to have the system run it during boot.
It solved his inexplicable problem and may well solve yours.
Hi Neal,
Thank you very much for your comments and willingness to help.
Unfortunately, the _workaround_ has not worked on _my_ system.
I even tried the formula after the system was fully up at the
command prompt (the system does come up all the way; you can
work blindly - login, setterm, etc.)
OK. So it is not a simple I'm sleeping and I can't wake up! problem. This is
about where you discard all notions of 'how it should work' and ask, How can
I see what it is really doing, since it doesn't seems to be do what is
expected? It almost sounds like the system has found another video card to
use. If the mainboard has a video card on it, try connecting to that one. If
the video card has two ports, try using the other one (you might need a
digital/analog display adapter). Try using a different video card. Eventually
you should find working video, which will be a strong clue.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
On Thursday 17 June 2010 21:29:35 al...@verizon.net wrote: Hello, i686-pc-linux-gnu, 2.6.34, udev-156, (B)LFS NVidia GeForce 8300GS I've been trying to install/run the nouveau nouveau kernel driver, to avoid installing the NVIDIA driver after each kernel upgrade. PROBLEM: So far, if on the nouveau kernel, I lose the video (the screen goes blank) on boot-up to command mode. I recently was of absolutely no use helping someone resolve just this problem on a 'similar' system. I did get him set up so the system would run fsck on upon powerdown on his command--reboot, fsck, powerdown--and never any other time, but the console screen blanking and not returning was beyond my ken. It wasn't the driver, wasn't parameters, wasn't anything I or a few others could figger out. He was new to the system and Linux, but had probably been around computers for 40-50 years, so wasn't a helpless noob. He found the solution himself: setterm -powersave off -blank 0 If setterm doesn't exist, find and build it. :) Then figure out a way to have the system run it during boot. It solved his inexplicable problem and may well solve yours. N -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: How to skip two settings
On Wednesday 16 June 2010 16:23:09 Parmenides wrote: There are some excellent distro actually, but not my favourite. They will install many packages I do not need. What's more, I very like a clean and fast linux and the console mode is enough. So, I choose the LFS. Additionally, the LFS give me a chance to get familiar with Linux more and more. Actually, I want to configure a virtual Linux running on VMWare and play a server's role. But, the default settings make automatical boot impossible. What you are looking to change is 'hidden' inside the initramfs/initrd. For the purpose of learning, you can unpack the LiveCD, disassemble it, unpack the initramfs (or initrd, whichever it uses), adjust it as you desire, repack it and repack the CD (or pack it into a hard drive partition or image file for VMware/QEMU/etc.) I've done this many times while tweaking Smoothwall until I finally got udev and the initramfs archive to work as I wanted them to (read: learned how udev and initramfs really work). I did this with both the ISO image and tweaking the early boot stuff on the hard drive. Only unfamiliarity prevents you from unpacking the live CD and fiddling with it until it does what you want. Using the live CD is not optimal, but it can't be beat for hands-on learning. Once you dive into that, though, you are kind-of on your own; not many people grok isolinux, initramfs/initrd, and the early boot environment, and it's way outside of building Linux from scratch. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: priority in install of packages
On Tuesday 15 June 2010 11:47:33 Bruce Dubbs wrote: On Tue, Jun 15, 2010 at 4:14 AM, Mohsen Pahlevanzadeh moh...@pahlevanzadeh.org wrote: Dear all, I'm in top of Chapter 5. Constructing a Temporary System.At this chapter some package is introduced that we must compile them.My question is: Do they have Chapter priority in compile same listed in chapter?For example if i compile package 5.12.expet before 5.11.tcl, is it problem? The order of the packages is carefully crafted to make sure prerequisites are built in the correct order. See the appendix for each packages dependencies. For instance, expect requires tcl. When we had a choice for the next package, it is added alphabetically, but there is really no reason to deviate from the order given in the book. You may, of course, do what pleases you, but be prepared to start over if it doesn't work. To be absolutely clear, and to directly answer the question, yes, it is a problem because Expect will fail to compile if the TCL programs and libraries are not found. To provide analogies, one cannot write an essay or poem until she has a sheet of paper on the table in front of her and a pencil in hand, and one cannot type and send an email until he has a working computer, an email program and an active internet connection. Just as the order of instructions in a computer program is very important, the order of the instructions in the human program called, The LFS Book is just as important. Functionally, it is exactly the same as an optimizing compiler; only after one learns how packages (instructions) are interdependent can one successfully reorder or optimize package compilation (instruction execution). (For non-English-speaking LFS users, I hope this translates well enough.) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Linux From Scratch (Version SVN-20100529) - 6.9. Glibc-2.11.2
On Saturday 12 June 2010 01:12:45 Chris Staub wrote:
On 06/12/2010 01:04 AM, Face Man wrote:
root:/sources/glibc-build# find /tools -name 'ld*'
/tools/x86_64-unknown-linux-gnu/bin/ld
/tools/x86_64-unknown-linux-gnu/bin/ld-old
/tools/bin/ldd
/tools/bin/ld-old
/tools/x86_64-lfs-linux-gnu/bin/ld
(Instructional; this code is from my modified Smoothwall build system, based
on LFS. They're very similar, but not necessarily identical. The student's
exercise is to go to the book and find the exact correlated steps.)
It looks like step 3 (below) of the final toolchain adjustment might not've
happened.
mv -v ${TOOLS_DIR}/bin/{ld,ld-old}
mv -v ${TOOLS_DIR}/$(gcc -dumpmachine)/bin/{ld,ld-old}
mv -v ${TOOLS_DIR}/bin/{ld-new,ld}
ln -sv ${TOOLS_DIR}/bin/ld ${TOOLS_DIR}/$(gcc -dumpmachine)/bin/ld
There's no ld, so there might not've been an ld-new to rename. The uncertainty
should lead the student back to stage 2 of building binutils, where perhaps
the last step didn't happen:
cp -v $(COMPILE_DIR)/ld/ld-new $(TOOLS_DIR)/bin
It is also possible that none of the steps to prepare for the second adjusting
were executed.
A better command to run might be:
find /tools -name ld\* -exec ls -l {} \;
which will illuminate symlinks and better help to backtrace the 'human
program' execution.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: live and learn
On Friday 11 June 2010 14:16:24 Mike McCarty wrote: Hope you keep learning for a long time. Mike To misquote a fictional character, Learn long and prosper. Same thing, really. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Some LFS 6.5 - 6.6 Inconsistencies
That's not so easy. We create the book with Docbook xml. I don't know of a way to to do that. We do have both a change log and a What's new section. We are trying to do a new release every 6 months. If you look at What's new, almost every package changes each time, but most use the instructions unchanged. Yeah, I generally work off the Changelog page when updating the scripts I build everything with, working up the list from whatever date I last built against. Works for me - Changelog open in one tab, and the index in a second one. FYI. This link might be useful: http://www.sagehill.net/docbookxsl/Changebars.html -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Glibc Make Error - Pass 1, Chapter 5.7, LFS Book 6.6
On Tuesday 08 June 2010 11:48:52 Paul Rogers wrote: mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed (bad class -- [], [^] or [) /[^ mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ] mawk: scripts/gen-sorted.awk: line 19: runaway regular expression /, , I've never used mawk, so I'm not familiar how similar it may be to gawk, but gawk is what the Host System Requirements specify. mawk isn't all that compatible with original AKW awk. Yes, I'm still using my 1988 edition of their AWK programming language book. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: HSR's
On Tuesday 08 June 2010 19:04:21 Paul Rogers wrote: You can minimize the interval with ln -sf bash /bin/sh. Then it stomps on the old link to dash and there's no appreciable interval when there's no /bin/sh--but it's still not to be advised when it's a shell something in your tty branch might have run you're messing with! This is somewhat true. The running shell will not be affected. Subsequent attempts to run that shell will fail. It's been a long time since shell scripts were 'cached' in the filesystem such that editting a script would cause the running script to fail. And it's likely been nearly as long since an executing binary has been 'cached' on its filesystem. Linux deletes the file from the FS, but keeps it available to all processes that have it open. It is deleted and forgotten when the last open FD is closed. So if you are running /bin/bash and you delete /bin/bash, your shell will continue to run until it closes the FD that has /bin/bash opened. Put differently, it is deleted from the FS directory and from the in-cache directory, but it cannot be deleted completely until the last process closes the FD. In a way, it is an orphan during the interim; it cannot be opened anew, but it can continue to be processed until the last FD that has it open is closed. So, in the case that spawned this thread, the used could have continued to use his shell, albeit vey carefully and judiciously, until he exitted that shell. Even if he performed an 'rm -rf /', his shell would continue to run and he would continue to be able to use shell built-ins until he exitted that shell. At that point, only the root directory, '.' and '..' would be accessible. Confused? Read up on tmpfs and how initramfs works. Hint: they both work with *no* filesystem structure, just directories and files with no backing store. They're one step removed from a RAM disk with a file structure layered on top. Were I to agree with software patents, this might be one of them. Another hint: it is what allows LiveCD Linux systems to run completely in RAM. Also read up on how file access works. When you open a file, you do not open the file on disk (normally). You ask the system to open the file for you. It creates an entry in the cache directory for that file, pages the file into memory over time, and allows you to access the file. When you close the file, it stays in cache until something else needs the memory more urgently. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: live and learn
On Tuesday 08 June 2010 16:54:52 Mike McCarty wrote: piper.guy1 wrote: One more thing. Seeing that this is a very risky thing to be advising in LFS 6.6, can I suggest that the authour(s) add some caveats around this instruction? The best way to do LFS is to pretend you are the computer, executing each command and understanding what each command does. In short time, you'll come to recognize what is happening and learn to pause before you hit the ENTER key. Been there, done that. Hmmm. May I produce a t-shirt that proclaims, Member of the 'I hosed my Linux system building LFS!' club ?? Besides, porking your main machine to the point where it won't boot, and figuring out how to get it back is half the fun, isn't it? :-) It's fun the first couple times. :) Then it just becomes tedious and a pain to figure out how to avoid it in the future. :D In a way, LFS is instructionary (as intended). If you do *exactly* what the book says, the probability is high that you will succeed and not hose your host system. I started playing with UNIX in 1986, and Linux in the mid-nineties. And just a couple weeks ago, I overwrote a disk that contained half of a couple striped MD filesystems. Lost nearly 10 years of pics and history. Another time, while redesigning the Smoothwall build system, I overwrote large bits of my host system because the build system did what I *told* it to do, not what I *wanted* it to do. Sigh. I *meant* to copy an external drive's image to a partition, *not* the whole drive. So if all you did was wipe out a link to a shell, you haven't tried hard enough. :) Almost any Linux distro that has a rescue mode (even Debian's netinstall CD will work, and its much quicker) will allow you to boot into a usable Linux and repair such minor damage. - boot the live or rescue system - don't use your host's FS as root - mount your host's root FS and/or /usr FS, as needed - find what you hosed and any alternatives - create a symlink from that which you lost to an alternative For example, if you deleted the symlink to dash, you can create a new link to dash. If you wiped out dash itself, you can create a symlink to just about anything that will act as a shell. Tclsh would do in a pinch; even perl or php would work. At the worst, you might have to find and download the bash/dash/csh/tcsh package, learn to unarchive it, and replace only what you deleted. You could get lucky and find the package cached in a package archive area, as you'd find in at least Debian or Ubuntu (an ancient African word meaning can't install Debian). And, yes, I have done 'rm -rf *' when in the root directory on my old ATT UNIXPC. I've since learned to be more careful. But, clearly, not careful enough. :) Just remember, it's only a computer. It can be restored to proper operating condition. In time, you'll learn to keep your personal data on a separate filesystem. You'll learn to pause before hitting ENTER. And in time you'll wonder why you stuck with Winders or Mac so long. '97-02, I used BeOS as my primary system. For a short time, I used Windows after, until Debian Etch was release. I've been using Linux as my primary system ever since. As Mike says, LFS is not for newbies. Though I might allow that it is not for newbies who have only one computer. Keep a computer, any computer, handy for internet access to search for the mistakes you make and how others have recovered. At least technically, we humans learn from our mistakes and are usually willing to help teach others to avoid and/or recover from theirs. Often you'll get a respone that details how to recover. Other times, you get a response like, There, there. This, too, shall pass. So welcome to the world of virtual reality, where the all that exists are meaningless bits. It is all virtual; none of it is tangible. It is there to be moulded to our own individual desires. In the future, pay close attention to *each* step of LFS. And be sure to follow each step *exactly*. [Fest3er steps off his soapbox and puts it away.] A possible future enhancement to 'the book' might be to incorporate checkboxes that a newbie would check off as she performs each step. Extra work? Yes. But worth it to make each step clearer? Yes again. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: live and learn
On Tuesday 08 June 2010 18:57:21 Bruce Dubbs wrote: Mike McCarty wrote: # cd LFS/6.3 # rm -rf build and deleted /dev from my host system! No discs, no printers, no terminals, etc. I rebooted with a Knoppix disc, let it populate /dev, and then mounted my hard drive, and copied (yes copied using cp) /dev onto my hard drive. I don't think that would not be the case today since udev mounts a tempfs on top of /dev and populates it upon boot. See 6.2.2. Mounting and Populating /dev. At one time, what you did would have been needed. But later, Mike says his system does not have udev. If Mike had known the 'basic' /dev entries needed, he probably could have used mknod to create them. He could have booted some Linux in a virtual system, archived /dev, copied it to the system he crippled and unarchived it. To quote an old SF TV show, Many such journeys are possible. :) :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: live and learn
On Tuesday 08 June 2010 20:05:46 Bruce Dubbs wrote: Neal Murphy wrote: I started playing with UNIX in 1986, and Linux in the mid-nineties. And just a couple weeks ago, I overwrote a disk that contained half of a couple striped MD filesystems. Lost nearly 10 years of pics and history. No backups? How is this different (in effect) from a failed disk drive. It differs in that I keep an eye on my hard drives. When they start to show signs of old age and failure, I buy a replacement and move everything to the new drive. (Euthenasia doesn't apply to hard drives.) I've been close to a drive failure (an 'older' WD 30GB drive), but heard it struggling to read and decided I should buy a replacement. And back when 1TB drives reached $80US, I bought two Hitachi SATA 3s to replace the perfectly functional and problem-free 400GB Apple SATA 1.5s I'd bought a few years years earlier; I needed more disk space. Alas, wiping out data is *not* the preferred method of acquiring more disk space. :( Of course, it didn't help that my ASUS dual dual-core Opteron mboard on-board power supply capacitors gave up their ghosts; that's when I bought the new mboard and a quad PhII 965 and 8GB RAM. (I truly *despise* waiting for Linux distribs to compile.) But you are right. I had no backups and no excuses. I have an empty 400GB drive that would have held most of that data. And there's no reason I could not have saved all the pics to DVDs. I didn't. I lost. Oh, well. No one died, and no critters or humans were harmed, so no foul. :) Too bad I didn't wipe out my ripped CDs. I could've re-ripped them. Sigh. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
On Thursday 03 June 2010 00:30:58 Chris Staub wrote: I just built Perl in Chapter 5, and I do have gdbm installed (this is on a couple-week-old LFS svn host system). I get gdbm.h NOT found. during Configure, and it doesn't look like anything in Perl tries to link to libgdbm. Dig deep. Perl's configure, trying to be ever-so-helpful, finds it (libgdbm.*) on the host (your LFS SVN host) and configures support for the package. (This is probably because there are CPAN packages that use gdbm and perl quietly configures support for gdbm, 'knowing' that you will someday use one of those packages. It was a real PITA digging out those extra four options: documentation is scant. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
On Thursday 03 June 2010 14:45:04 Chris Staub wrote: On 06/03/2010 11:33 AM, Neal Murphy wrote: On Thursday 03 June 2010 04:08:33 Simon Geard wrote: Curious... like Chris, I routinely build LFS from a host with gdbm installed (i.e LFS itself), and never observed any problems relating to perl. Indeed, even on completed LFS install, /usr/bin/perl isn't linked against gdbm, and runs fine if I remove the libgdbm libraries. Can you be more specific about the problems you're seeing? Does the perl executable fail to run at all, unable to link to libgdbm.so? Or is it something less obvious? Simon. I built on Debian Lenny. Perl's configure examines the host system looking for useful features. In my case, libgdbm was installed on Lenny; perl found it and configured support for it. Later in the the build, perl failed to run because it couldn't find libgdbm.so. This was obvious. What wasn't obvious was, Why? Still not enough info. At what point did Perl try to run, and how exactly? Is it just when running perl at all? With certain specific options and/or using certain Perl modules? IIRC, the problem became apparent when the toolchain perl tried to run in the chroot jail during the final build (Ch. 6 equivalent) before the final build of perl. It didn't matter what I did; toolchain perl always built with support for libgdbm and would fail because it couldn't find that lib in the chroot jail. It built in support for libgdbm because it found gdbm libs and headers on my Debian host. It found those things because the '-Dstatic_ext' option does not prevent it from doing so. If I may be so crass, that you haven't stumbled on this may be due purely to dumb luck. There are probably subtle differences between LFS' build steps and the steps I follow in my project. And this may very well be the issue, since nobody has reported this problem when building LFS before. I'd say that for this report to have any validity, you'd need share exactly what these differences are, in particular how Perl is built in Chapter 5 (of course giving more than just adding those 4 options to Configure). Typically when some package tries to pull something from the host, it's because of a goof-up in Chapter 5. - This oddity has not been reported before (here or anywhere). - This is not a problem report or support request. - It's a report of something I encountered whilst using 6.4 as a guide to updating a project that was originally based on LFS. - To the best of my ability to determine, perl's configure script explicitly searches the host filesystem for features it should support, an action which _can_ poison the toolchain. - I know that the normal 'static_ext' parameter does not prevent perl's configure from searching the host for features to support. - I am very sure that the extra four configure options do prevent perl's configure from potentially poisoning the toolchain with references to the host ysstem. According to Ch. 5, the intent is to have perl build only the four specified features, and build them statically into perl. As I understand, the '-Dstatic_ext=...' option that LFS uses tells perl only to build those features statically into perl. It doesn't restrain perl from building other extensions. It doesn't prevent perl's configure script from searching the host system. The real issue is that, as best as I can tell, perl's configure script searches the host's filesystems for features to support, which is not desired when building the toolchain. Why it does that to me when building on Debian Lenny and not to anyone else, I don't know. I do know that the extra parameters for perl's configure effectively limit it to searching ONLY the toolchain for features to support. Perhaps I was remiss in not putting 'FYI' in the subject, for it was my intent to save the next guy a lot of time tracking down something that is only a problem when building a toolchain, something that involves unclearly documented options. I don't dispute that the LFS build works. I've tried to avoid denigrating anyone's efforts. I offered the arcane, obscure info not to trick people into spinning their wheels, but rather to help make LFS better, more correct, and more bullet-proof.-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.6, Stage2, glibc, nscd.c:442
On Sunday 30 May 2010 12:45:54 Paul Rogers wrote: ... Yesterday I left my first few steps of Stage2 in place--their results are in the FHS, which Stage1 will ignore. I CAREFULLY backed my way to the Stage1 environment, then back through the Stage1 steps removing the packages through the Pass2 gcc. Then I restored the Pass1 gcc. Now I carefully examined the Pass2 build script, ensuring it's effectively identical to the book commands, and put an exit right after the configure. My script, of course, tee's the console log. I thought I found something after examining that, blowing off the build directory, and found in the source directory the gcc subdirectory had yesterday's date--configure must have written something. So I blew that off too and restarted with a clean one. Pass2 built, I saved both direcories off to a different partition for further examination. Then I stepped my way back through the Stage1 packages, restoring what I had saved immediately after building them in order. Then I tried rebuilding glibc, and it failed at the same spot. So whatever is happening in the Pass2 build is reproducible. That's where I am now. But now I have those build directories available to check. Only one comment: are you *certain* you have removed all related things before (or after) restoring a prior-built tarball? Just *one* stupid file in the wrong place can bollux the works. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.6, Stage2, glibc, nscd.c:442
On Tuesday 01 June 2010 04:46:36 Simon Geard wrote: On Mon, 2010-05-31 at 09:35 -0700, Paul Rogers wrote: On Mon, 2010-05-31 at 00:36 +0100, Ken Moffat wrote: What you are overlooking is that doing it my way comes with when it breaks, I get to keep all the pieces. What a curious thing to write in a SUPPORT forum of a LINUX distribution with the motto, YOUR DISTRO, YOUR RULES. Your distro, your rules - but going along with that, there's the unstated your rules, your problems. There's nothing wrong with exploring uncharted waters, but if you sail into the middle of here be dragons, you can't expect to stop and ask for directions... Simon. But one *can* bellow, Where am I? And of course, one should then expect the obligatory, Yer in a boat in the midst of the sea, ya dang fool! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
perl, gdbm and perl's obsequious help
Some time back (LFS 6.4), I discovered that perl's configure program can poison the build; it is designed to be extremely helpful by ferreting out features of the host system to support. Specifically in my case, because it found libgdbm on the host system, it configured perl to include support for gdbm; this causes the build to fail later because perl can't find libgdbm. Alas, such obsequiousness hoses the LFS build process. The standard LFS configure options for perl do not prevent this from happening. For review, the options are: -des -Dprefix=/tools -Dstatic_ext='Data/Dumper Fcntl IO POSIX' After days of gnashing teeth and rending garments (my hair is too short to pull out in tufts) and parsing perl's configure script, I developed the correct incantation: -des -Dprefix=/tools -Dstatic_ext=Data/Dumper Fcntl IO POSIX \ -Donlyextensions=Data/Dumper Fcntl IO POSIX \ -Dglincpth=/tools/include -Dglibpth=/tools/lib \ -Dinc_version_list=none The four extra options are required _when building the toolchain_ to ensure absolutely that perl's configure - configures those extensions and ONLY those extensions, and - cannot examine the host for features to support These options should work regardless of what is installed on the host build system. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
On Wednesday 02 June 2010 20:02:31 Bruce Dubbs wrote: Thanks for the report Neal. I wonder if the extra commands are needed now that gdbm is built in Chapter 6 before Perl. The extra options may be needed if perl is used in the build process before gdbm is built. N -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.6, Stage2, glibc, nscd.c:442
On Wednesday 02 June 2010 20:05:36 Paul Rogers wrote: But one *can* bellow, Where am I? And of course, one should then expect the obligatory, Yer in a boat in the midst of the sea, ya dang fool! But let's not AT ALL slight the purpose of LFS, to teach us how to build a functional Linux/GNU system. I'm sure we all agree, it DOES do that. And if that leads some of us to scoff at the idea of dragons, it has, in fact, done the job. I would say that when we instigate workarounds, we are proving the purpose of LFS. More power to LFS! I forgot to include a smiley. And an attribution. The query and response are nearly straight from one of Marshall Dodge's Bert and I recordings: an intrepid adventurer takes off in a balloon in down-east Maine and quickly find himself in a dense fog all day. And all night. The next day when he emerges from the fog, he's above a farmer in his field. He shouts down, Where am I? The farmer responds with typically dry down-east humor, Yer in a balloon, ya dang fool! An absolutely correct answer, but not very helpful at all. :) One purpose of LFS (mayhap unstated) is to help the user figure out how she got to be lost in the midst of the sea in the first place. She may not know where she is, but she should be able to determine just how she got there. LFS is, in a manner of speaking, navigation by dead reckoning. Everything should work. But sometimes your instruments are slightly out of calibration, and one step leaves you 'elsewhere'. After that, the rest of the journey is flawed. I'm in the middle of upgrading a firewall product to use Linux 2.6.32 and GCC 4.4.x; the product's build system was originally based on LFS. After nine months and much reference to LFS, I'd upgraded many packages and got it running with Linux 2.6.26 and GCC 4.3.2, generally using LFS 6.4 as a guide. But that wasn't new enough to work with the latest Atom-based appliances and mini-ITX boards. So off to upgrade again. This time, the changes were enough to keep me building and rebuilding the toolchain for several weeks until I tracked down the bugs in the Makefiles and shell scripts. Now I'm stuck on getting 2.6.32 to build with openswan 2.6.x. By-and-large, LFS is a great guide. The only real deficiency I've found is in the configure options for perl; it took me a week to dig through that script (and some source code) to find out why the toolchain perl insisted on on needing libgdbm; simply, it was doing exactly what it should: build to include all optional features it finds on the host. That, of course, poisons the toolchain. So, by all means, more power to LFS! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: chapter 6.16: configure: error: in `/sources/gcc-build/i686-pc-linux-gnu/libgcc':, ... C preprocessor /lib/cpp fails sanity check
On Wednesday 26 May 2010 13:19:54 Bruce Dubbs wrote: Neal Murphy wrote: On Wednesday 26 May 2010 08:33:20 linux fan wrote: On 5/26/10, Simon Geard delga...@ihug.co.nz wrote: I can't really see how things can be improved (short of blinking red text on *every* page), but it does seem like half the problems we deal with are from people not following it. Are people not even reading that entire General Compilation Instructions page, and skipping straight to the packages? The important note #1 in ch 5.3 is clear. However, General Compilation Instructions never specifies the flow of events expected to follow: 1 - make sure $LFS is set to the target directory (export LFS=/mnt/lfs) 2 - change directory to $LFS/sources 3 - unpack the package tarball 4 - change directory to the unpacked directory created by tar 5 - follow package build and install instructions 6 - change directory to $LFS/sources 7 - remove the unpacked directory created by tar We don't have it in a list, but it is in Section 5.3. I even put in a note as the very first thing in Binutils: Note Go back and re-read the notes in the previous section. Understanding the notes labeled important will save you a lot of problems later. I guess I'll need to reemphasize some more. :( Allow me to present a couple definitions. First, a 'user guide' is a documnet written in plain language prose that guides the user through some task or operation. Second, a 'reference manual' is a document written using less prose and more 'techno-ese' to provide all the syntax needed to perform variations of a task or operation. From a user guide viewpoint, I think the existing emphasis is great; the book is well-written. From a 'reference manual' viewpoint, the details and syntaces can be, mmm, hard to see. Recall the old adage, Tell 'em what you're going to tell 'em. Tell 'em. Then tell 'em what you told 'em. Perhaps what Linux Fan and I are trying to say is that the LFS book could be improved by adding that list to the bottom of the General Compilation Instructions. Think of it as a terse summary of the steps to be taken. Then put a link directly to that list on each package build page. Yes, it will be repetitious. But the human eye will ignore it it if it's not needed. Something like: Summary of general package build operations a. Pre-build steps 1. set $LFS equal to the target directory 2. cd to $LFS/sources 3. unpack the package archive 4. cd to the package directory b. Follow the package build and install instructions. c. Post-build steps 1. change directory to $LFS/sources 2. remove the unpacked directory created by tar 3. remove the build directory if created, unless told not to There it is in a nutshell: a handy reference reminder.-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: toolchain problem?
On Saturday 15 May 2010 14:09:45 henk.bosw...@hccnet.nl wrote: LFS 6.6 After the first pass of Binutils in chapter 5 I end up with 14 files (binaries) in /mnt/lfs/tools/bin, but they have names that include the $LFS_TGT, like this: i686-lfs-linux-gnu-addr2line i686-lfs-linux-gnu-ar i686-lfs-linux-gnu-as etc. In /mnt/lfs/tools/i686-linux-gnu/bin the files have their regular names, but there are only 8 instead of 14 of them: ... Can anyone tell me what I am doing wrong? Henk Boswijk If you look in the second pass of building the toolchain, you'll see that binutils and gcc are built using these explicit names in a further effort to insulate the build process from the host. These are the cross-compiling/linking tools. However, if you are really seeing /mnt/lfs/tools/i686-linux-gnu, then you have an error; it should be /mnt/lfs/tools/i686-lfs-linux-gnu. Methinks you may have mistyped it, though. N -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
